"Crypto required" is a property of the PeerConnection of construction
time; it has nothing to do with SDP. So I'm moving it out of
MediaContentDescription and putting it in the BaseChannel constructor
instead. This is more intuitive, and provides the added assurance that
"secure_required_" can't be flipped from "true" to "false".
BUG=None
Review-Url: https://codereview.webrtc.org/2537343003
Cr-Commit-Position: refs/heads/master@{#15579}
Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.
TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.
BUG=None
Review-Url: https://codereview.webrtc.org/2517883002
Cr-Commit-Position: refs/heads/master@{#15453}
Reason for revert:
Deletion of transport.h broke downstream builds.
Going to reland with transport.h containing enums/etc.
Original issue's description:
> Refactoring that removes P2PTransport and DtlsTransport classes.
>
> Their base class, Transport, still exists, but it now has a more specific
> role: a helper class that applies TransportDescriptions. And is renamed
> to JsepTransport as a result.
>
> TransportController is now the entity primarily responsible for managing
> TransportChannels. It also starts storing pointers to the DTLS and ICE
> chanels separately, which will make it easier to remove
> TransportChannel/TransportChannelImpl in a subsequent CL.
>
> BUG=None
>
> Committed: https://crrev.com/bd28681d02dee8c185aeb39207e8154f0ad14a37
> Cr-Commit-Position: refs/heads/master@{#15450}
TBR=pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
Review-Url: https://codereview.webrtc.org/2553043004
Cr-Commit-Position: refs/heads/master@{#15452}
Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.
TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.
BUG=None
Review-Url: https://codereview.webrtc.org/2517883002
Cr-Commit-Position: refs/heads/master@{#15450}
This isn't a performance test, so it may be running in a slow
environment, and shouldn't be subject to strict timeouts.
BUG=webrtc:6801
TBR=pthatcher@webrtc.org
Review-Url: https://codereview.webrtc.org/2539183005
Cr-Commit-Position: refs/heads/master@{#15370}
We still DCHECK for RTP, but not RTCP. RTCP packets can be sent before
offer/answer negotiation is complete, due to this bug:
https://bugs.chromium.org/p/webrtc/issues/detail?id=6809
This bug can only occur if the RTCP mux policy is "require", which is
why we started hitting it recently (the default in unit tests was
recently changed to "require").
BUG=webrtc:6776
TBR=pthatcher@webrtc.org
Review-Url: https://codereview.webrtc.org/2542233002
Cr-Commit-Position: refs/heads/master@{#15369}
There's no longer any need to make the two arguments have the same
signedness, so we can remove a bunch of superfluous (and sometimes
dangerous) casts.
It turned out I also had to fix the safe_cmp functions to properly handle
enums that are implicitly convertible to integers.
NOPRESUBMIT=true
BUG=webrtc:6645
Review-Url: https://codereview.webrtc.org/2534683002
Cr-Commit-Position: refs/heads/master@{#15281}
A WebRtcVideoEngine2 object seems to be reused between PeerConnections,
which means that the field trial added in
https://codereview.webrtc.org/2511703002/ may not activate/deactivate
as intended between calls. This CL removes the caching of video codecs,
which gets rid of this problem.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2521393004
Cr-Commit-Position: refs/heads/master@{#15265}
This CL will start to distinguish H264 profiles during SDP negotiation.
We currently don't look at the H264 profile at all and assume they are
all Constrained Baseline Level 3.1. This CL will start to check profiles
for equality when matching, and will generate the correct answer H264
level.
Each local supported H264 profile needs to be listed explicitly in the
list of local supported codecs, even if they are redundant. For example,
Baseline profile should be listed explicitly even though another profile
that is a superset of Baseline is also listed. The reason for this is to
simplify the code and avoid profile intersection during matching. So
VideoCodec::Matches will check for profile equality, and not check if
one codec is a subset of the other. This also leads to the nice property
that VideoCodec::Matches is symmetric, i.e. iif a.Matches(b) then
b.Matches(a).
BUG=webrtc:6337
TBR=tkchin@webrtc.org
Review-Url: https://codereview.webrtc.org/2483173002
Cr-Commit-Position: refs/heads/master@{#15051}
These functions currently copy cricket::Codec classes by value which is
expensive since they contain e.g. std::map<std::string, std::string>
containers with parameters. This CL avoids copying them altogether.
BUG=webrtc:6337
Review-Url: https://codereview.webrtc.org/2493733003
Cr-Commit-Position: refs/heads/master@{#15040}
Reason for revert:
This CL probably broke Chromium FYI.
Original issue's description:
> Stop caching supported codecs in WebRtcVideoEngine2
>
> We currently cache the result of GetSupportedCodecs in a member variable
> |video_codecs_| in WebRtcVideoEngine2. This means we need to keep
> |video_codecs_| and the result of GetSupportedCodecs in sync, which is
> error prone. It's simpler to just call GetSupportedCodecs when we need
> it, and we actually end up making fewer calls, so it's faster as well.
> This CL also returns all std::vectors by-value instead of by-ref. Move
> semantic together with in-place filtering of codecs actually end up with
> fewer copies, and it's also simpler to not return references.
>
> BUG=webrtc:6337
>
> Committed: https://crrev.com/9f71ec5a3e3175751f4475b126cfda89767363f2
> Cr-Commit-Position: refs/heads/master@{#15007}
TBR=tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6337
Review-Url: https://codereview.webrtc.org/2489173004
Cr-Commit-Position: refs/heads/master@{#15014}
We currently cache the result of GetSupportedCodecs in a member variable
|video_codecs_| in WebRtcVideoEngine2. This means we need to keep
|video_codecs_| and the result of GetSupportedCodecs in sync, which is
error prone. It's simpler to just call GetSupportedCodecs when we need
it, and we actually end up making fewer calls, so it's faster as well.
This CL also returns all std::vectors by-value instead of by-ref. Move
semantic together with in-place filtering of codecs actually end up with
fewer copies, and it's also simpler to not return references.
BUG=webrtc:6337
Review-Url: https://codereview.webrtc.org/2492473002
Cr-Commit-Position: refs/heads/master@{#15007}
Introduce rtc::PacketTransportInterface. Refactor cricket::TransportChannel.
Fix signal slots parameter types in all related code.
BUG=webrtc:6531
Review-Url: https://codereview.webrtc.org/2416023002
Cr-Commit-Position: refs/heads/master@{#14778}
Now that Chromium has taken libsrtp2, remove any compatibility bridge code in WebRTC that was only needed for libsrtp1.
Remove SRTP_RELATIVE_PATH now that Google's internal copy of libsrtp and the Chromium copy have the same directory structure.
Fix some include orderings per the Chromium C++ style guide.
Remove the `extern "C"` blocks now that the libsrtp headers include them (https://github.com/cisco/libsrtp/pull/195).
BUG=webrtc:6376
Review-Url: https://codereview.webrtc.org/2447893002
Cr-Commit-Position: refs/heads/master@{#14776}
Since WebRtcVideoSendStream have reconfigures the send codec to match the incoming captured frames widht and height they have not been used.
Framerate has just been set when parsing sdp to 60fps and not changed elsewhere.
This cl require some upstream projects to change first.
BUG=webrtc:5332
Review-Url: https://codereview.webrtc.org/2408153002
Cr-Commit-Position: refs/heads/master@{#14733}
It would be enough to say we're removing EnableSrtpDebugging because
it's never called, but the story is a bit more interesting.
libsrtp's debugging facilities are gated behind the reasonably-named
ENABLE_DEBUGGING macro:
b17c065a8a/srtp/crypto/include/err.h (186)
This code was imported to WebRTC from libjingle, but neither WebRTC or
Chromium ever set ENABLE_DEBUGGING. Even if someone had ever called
EnableSrtpDebugging, it wouldn't have done anything.
BUG=0
Review-Url: https://codereview.webrtc.org/2409513002
Cr-Commit-Position: refs/heads/master@{#14592}
This was missed in the first pass because this code only compiles in
Chromium.
BUG=webrtc:6376
Review-Url: https://codereview.webrtc.org/2407743002
Cr-Commit-Position: refs/heads/master@{#14591}
- Rename the data codec payload types to end with "PlType" instead of "Id", for consistency.
BUG=webrtc:2795
Review-Url: https://codereview.webrtc.org/2397413002
Cr-Commit-Position: refs/heads/master@{#14581}
This CL is a pure refactoring which should not result in any functinal
changes. It moves ownership of the RtcEventLog from webrtc::Call to the
webrtc::PeerConnection object.
This is done so that we can add RtcEventLog support for ICE events -
which will require the TransportController to have a pointer to the
RtcEventLog. PeerConnection is the closest common owner of both Call and
TransportController (through WebRtcSession).
BUG=webrtc:6393
Review-Url: https://codereview.webrtc.org/2353033005
Cr-Commit-Position: refs/heads/master@{#14578}
Also update gyp dependency from rtc_base to rtc_base_approved.
BUG=None.
Review-Url: https://codereview.webrtc.org/2368203002
Cr-Commit-Position: refs/heads/master@{#14497}
This changes most non-test related rtc_source_set targets to be
rtc_static_library instead. Targets without any .cc files are excluded.
This should bring back the build behavior we used to have with GYP
(i.e. same symbols exported in the libjingle_peerconnection.a file, which
are used by some downstream projects).
After doing an Android build with these changes:
$ nm --defined-only -g -C out/Release/lib.unstripped/libjingle_peerconnection_so.so | grep -i createpeerconnectionf
00077c51 T Java_org_webrtc_PeerConnectionFactory_nativeCreatePeerConnectionFactory
$ nm --defined-only -g -C out/Release/obj/webrtc/api/libjingle_peerconnection.a | grep -i createpeerconnectionf
00000001 T webrtc::CreatePeerConnectionFactory(rtc::Thread*, rtc::Thread*, rtc::Thread*, webrtc::AudioDeviceModule*, cricket::WebRtcVideoEncoderFactory*, cricket::WebRtcVideoDecoderFactory*)
00000001 T webrtc::CreatePeerConnectionFactory()
See https://chromium.googlesource.com/chromium/src/+/master/tools/gn/docs/cookbook.md#Note-on-static-libraries
for more details on this.
NOTICE: This should be further cleaned up in the future, to reduce
binary bloat and unnecessary linking time. Right now it's more
important to restore the desired build output though.
BUG=webrtc:6410, chromium:630755
Review-Url: https://codereview.webrtc.org/2361623004
Cr-Commit-Position: refs/heads/master@{#14364}
Remove a large number of targets that are no longer built, to reduce maintenance.
Only targets that have a GN version were removed.
BUG=webrtc:6323
NOTRY=True
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2340773003
Cr-Commit-Position: refs/heads/master@{#14231}
During GN vs GYP auditing it was discovered that some
GN targets that had public_configs were not exposing them
to dependents where the dependent depended on a group, which
in turn included that target as a dependency. Instead of
changing those public_configs to all_dependent_configs
(which would be a change from GYP), it's better to just change
those group targets to use public_deps instead.
BUG=webrtc:6323
NOTRY=True
TESTED=Generated GYP and GN project files on Mac and ran the
tools/gyp_flag_compare.py script before and after this patch was
applied. The file in question used for inspection was the
webrtc/api/webrtcsessiondescriptionfactory.cc
which is a part of the libjingle_peerconnection target.
Review-Url: https://codereview.webrtc.org/2344623002
Cr-Commit-Position: refs/heads/master@{#14222}
Remove common_inherited_config from the targets and add it to the
template instead.
BUG=webrtc:6187
NOTRY=True
Review-Url: https://codereview.webrtc.org/2311843002
Cr-Commit-Position: refs/heads/master@{#14069}
Remove common_config from the targets' config and add
it to the template instead.
BUG=webrtc:6187
NOTRY=True
Review-Url: https://codereview.webrtc.org/2300413002
Cr-Commit-Position: refs/heads/master@{#14063}
Defines the rtc_executable, rtc_source_set, rtc_test and
rtc_static_library templates.
These templates provide no functionality yet, but will enable common
configuration to be introduced, avoiding repetition in every target
Changes summary:
- Prepend rtc_ to test, source_set, executable and static_library targets
- Change "configs -= [" to "suppressed_configs += ["
- Include webrtc/build/webrtc.gni where it wasn't included yet
- Delete import("//testing/test.gni"), since rtc_test makes it unnecessary.
BUG=webrtc:6187
TBR=henrik.lundin@webrtc.org,tommi@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2301053002
Cr-Commit-Position: refs/heads/master@{#14043}
The only real difference between the two is that SetRtcpTransportChannel
had a workaround to prevent a signal from being emitted early.
Basically, in SetTransport, we want to switch the transport channels and
*then* update the state, rather than updating the state after changing
only one transport channel.
But this can be accomplished more easily by simply updating the state in
SetTransport directly.
Review-Url: https://codereview.webrtc.org/2274283004
Cr-Commit-Position: refs/heads/master@{#13945}
There were 3 different meanings for "ReadyToSend", for example, so it
was difficult to understand the meaning at first glance.
Also switching ASSERTs to RTC_DCHECKs.
Review URL: https://codereview.webrtc.org/2269173004 .
Cr-Commit-Position: refs/heads/master@{#13926}
Normally, when creating a data channel with an out-of-range ID,
createDataChannel returns nullptr. But due to an off-by-one
error, creating a data channel with ID 1023 returns a data channel
that silently fails later.
This probably occurred because it wasn't clear whether "kMaxSctpSid" was an
inclusive or exclusive maximum, so I changed the value to
"kMaxSctpStreams". This wasn't caught by unit tests because the
off-by-one error persisted to the unit tests as well.
Also getting rid of some dead code. We were adding SCTP streams to the
ContentDescription object but they weren't being used.
BUG=619849
R=pthatcher@webrtc.org, skvlad@webrtc.org
Review URL: https://codereview.webrtc.org/2254003002 .
Cr-Commit-Position: refs/heads/master@{#13906}
Removing a redundant variable used to track whether or not RTCP mux has
been fully negotiated. It's RtcpMuxFilter's job to do that, and it
already had the state, it just wasn't exposed.
Review-Url: https://codereview.webrtc.org/2260963002
Cr-Commit-Position: refs/heads/master@{#13856}
GCM cipher suites are optional (disabled by default) and can be enabled
through "PeerConnectionFactoryInterface::Options".
If compiled with Chromium (i.e. "ENABLE_EXTERNAL_AUTH" is defined), no
GCM ciphers can be used yet (see https://crbug.com/628400).
BUG=webrtc:5222, 628400
Review-Url: https://codereview.webrtc.org/1528843005
Cr-Commit-Position: refs/heads/master@{#13635}
This test verifies that SRTP errors are only signaled if a specific
amount of time has passed, and was using ProcessMessages(time) to
wait for an amount of time. But ProcessMessages may sometimes wait
for longer than the requested time (especially on TSAN bot, etc.).
BUG=webrtc:4690
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2184083004 .
Cr-Commit-Position: refs/heads/master@{#13597}
This change makes WebRTC no longer stop sending video when we receive an
EWOULDBLOCK error from the operating system. This was previously
causing calls on a slow link (where the first hop is slow) to rapidly
oscillate between starting and stopping video.
We still do need to stop sending packets if there is no known good
connection we can use for that. We used to generate a synthetic
EWOULDBLOCK error in that case. This CL replaces it with a different
code (ENOTCONN); EWOULDBLOCK no longer stops the stream but ENOTCONN
does.
I've updated all the places where we seemed to be generating EWOULDBLOCK
for reasons other than some buffer been full; please give it a thorough
look in case I missed something.
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2192963002 .
Cr-Commit-Position: refs/heads/master@{#13566}
