SrtpTransport currently just delegates everything to RtpTransport.
Also makes BaseChannel::rtp_transport_ an RtpTransportInternal and constructs an SrtpTransport if srtp is required.
BUG=webrtc:7013
Review-Url: https://codereview.webrtc.org/2981013002
Cr-Commit-Position: refs/heads/master@{#19095}
This will eventually be a unique_ptr<RtpTransportInternal> so that we can choose to use an RtpTransport or SrtpTransport.
BUG=None
Review-Url: https://codereview.webrtc.org/2974903003
Cr-Commit-Position: refs/heads/master@{#18987}
I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
BUG=webrtc:7634
NOPRESUBMIT=True # cpplint errors that aren't caused by this CL.
Review-Url: https://codereview.webrtc.org/2969623003
Cr-Commit-Position: refs/heads/master@{#18870}
Can be enabled by setting "enable_encrypted_rtp_header_extensions" in
"crypto_options" of "PeerConnectionFactoryInterface::Options" and will
only be used if both peers support it.
BUG=webrtc:3411
Review-Url: https://codereview.webrtc.org/2761143002
Cr-Commit-Position: refs/heads/master@{#18842}
This CL makes the WebRTC more modular and allows the users to build
WebRTC without audio and video(DataChannel only).
The BUILD files in call/, logging/, media/ and pc/ are modified to
support modular WebRTC.
The dependencies on Call and RtcEventLog are removed from the
PeerConnection. Instead of being created internally, they would be
passed in by the PeerConnectionFactory.
Add the CreateModularPeerConnectionFactory function which allow the
users to create a PeerConnectionFactory with the modules they need.
If the users want to build WebRTC without audio and video, they can
pass in null pointers for modules they don't need. (MediaEngine,
VideoEncoderFactory etc.)
BUG=webrtc:7613
Review-Url: https://codereview.webrtc.org/2854123003
Cr-Commit-Position: refs/heads/master@{#18617}
Reason for revert:
Broken downstream projects
Original issue's description:
> Wire up BWE stats through WebrtcSession so that they are filled in both for audio and video calls.
>
> Prior to this CL Call::Stats were collected via WebRtcVideoEngine2, but not via WebRtcVoiceEngine, causing these stats to be missing for audio-only calls. Call lives on the peerconnection/session level and should only be collected once independent on how many streams we have.
>
> BUG=webrtc:5079
> R=deadbeef@webrtc.org, hbos@webrtc.org
>
> Review-Url: https://codereview.webrtc.org/2863123002 .
> Cr-Commit-Position: refs/heads/master@{#18384}
> Committed: e80f4c91d0TBR=hbos@webrtc.org,deadbeef@webrtc.org,holmer@google.com,stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5079
Review-Url: https://codereview.webrtc.org/2916793003
Cr-Commit-Position: refs/heads/master@{#18386}
Prior to this CL Call::Stats were collected via WebRtcVideoEngine2, but not via WebRtcVoiceEngine, causing these stats to be missing for audio-only calls. Call lives on the peerconnection/session level and should only be collected once independent on how many streams we have.
BUG=webrtc:5079
R=deadbeef@webrtc.org, hbos@webrtc.org
Review-Url: https://codereview.webrtc.org/2863123002 .
Cr-Commit-Position: refs/heads/master@{#18384}
Before this CL, we would negotiate:
- No crypto suites for data m= sections.
- A full set for audio m= sections.
- The full set, minus SRTP_AES128_CM_SHA1_32 for video m= sections.
However, this doesn't make sense with BUNDLE, since any DTLS
association could end up being used for any type of media. If
video is "bundled on" the audio transport (which is typical), it
will actually end up using SRTP_AES128_CM_SHA1_32.
So, this CL moves the responsibility of deciding SRTP crypto suites out
of BaseChannel and into DtlsTransport. The only two possibilities are
now "normal set" or "normal set + GCM", if enabled by the PC factory
options.
This fixes an issue (see linked bug) that was occurring when audio/video
were "bundled onto" the data transport. Since the data transport
wasn't negotiating any SRTP crypto suites, none were available to use
for audio/video, so the application would get black video/no audio.
This CL doesn't affect the SDES SRTP crypto suite negotiation;
it only affects the negotiation in the DLTS handshake, through
the use_srtp extension.
BUG=chromium:711243
Review-Url: https://codereview.webrtc.org/2815513012
Cr-Commit-Position: refs/heads/master@{#17810}
This will eventually implement webrtc::RtpTransportInterface from api/ortc.
It needs to live in the pc build target until the pc <- ortc dependency is inverted.
BUG=webrtc:7013
Review-Url: https://codereview.webrtc.org/2792223002
Cr-Commit-Position: refs/heads/master@{#17534}
This CL is a reland of https://codereview.webrtc.org/2722423003 which got
reverted due to compile errors when rolling into Chromium.
Original CL description:
Improve testing of SRTP external auth code paths.
Previously code behind ENABLE_EXTERNAL_AUTH was only compiled with Chromium
but developed in WebRTC, which made testing rather complicated. This caused
some trouble in the past (e.g. https://crbug.com/628400#c1)
This CL helps in that the external auth code is now compiled with WebRTC
and the srtpfilter integration gets tested.
BUG=chromium:628400
Review-Url: https://codereview.webrtc.org/2735613002
Cr-Commit-Position: refs/heads/master@{#17052}
Reason for revert:
Breaks compilation in FYI bots, e.g. here:
http://build.chromium.org/p/chromium.webrtc.fyi/builders/Win%20Builder/builds/9314
FAILED: obj/third_party/webrtc/pc/rtc_pc/channel.obj
ninja -t msvc -e environment.x86 -- E:\b\c\goma_client/gomacc.exe "E:\b\depot_tools\win_toolchain\vs_files\d3cb0e37bdd120ad0ac4650b674b09e81be45616\VC\bin\amd64_x86/cl.exe" /nologo /showIncludes /FC @obj/third_party/webrtc/pc/rtc_pc/channel.obj.rsp /c ../../third_party/webrtc/pc/channel.cc /Foobj/third_party/webrtc/pc/rtc_pc/channel.obj /Fd"obj/third_party/webrtc/pc/rtc_pc_cc.pdb"
e:\b\c\b\win_builder\src\third_party\webrtc\pc\channel.cc(176): error C2819: type 'cricket::SrtpFilter' does not have an overloaded member 'operator ->'
e:\b\c\b\win_builder\src\third_party\webrtc\pc\srtpfilter.h(45): note: see declaration of 'cricket::SrtpFilter'
e:\b\c\b\win_builder\src\third_party\webrtc\pc\channel.cc(176): note: did you intend to use '.' instead?
e:\b\c\b\win_builder\src\third_party\webrtc\pc\channel.cc(176): error C2232: '->cricket::SrtpFilter::EnableExternalAuth': left operand has 'class' type, use '.'
Original issue's description:
> Improve testing of SRTP external auth code paths.
>
> Previously code behind ENABLE_EXTERNAL_AUTH was only compiled with Chromium
> but developed in WebRTC, which made testing rather complicated. This caused
> some trouble in the past (e.g. https://crbug.com/628400#c1)
>
> This CL helps in that the external auth code is now compiled with WebRTC
> and the srtpfilter integration gets tested.
>
> BUG=chromium:628400
>
> Review-Url: https://codereview.webrtc.org/2722423003
> Cr-Commit-Position: refs/heads/master@{#17030}
> Committed: ac170d5c21TBR=deadbeef@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:628400
Review-Url: https://codereview.webrtc.org/2734643002
Cr-Commit-Position: refs/heads/master@{#17031}
Previously code behind ENABLE_EXTERNAL_AUTH was only compiled with Chromium
but developed in WebRTC, which made testing rather complicated. This caused
some trouble in the past (e.g. https://crbug.com/628400#c1)
This CL helps in that the external auth code is now compiled with WebRTC
and the srtpfilter integration gets tested.
BUG=chromium:628400
Review-Url: https://codereview.webrtc.org/2722423003
Cr-Commit-Position: refs/heads/master@{#17030}
With ENABLE_EXTERNAL_AUTH, external auth will only be used depending
on the selected cipher (allowed for non-GCM, not allowed for GCM).
BUG=webrtc:5222, chromium:628400
Review-Url: https://codereview.webrtc.org/2720663003
Cr-Commit-Position: refs/heads/master@{#16955}
This CL adds the following interfaces:
* RtpTransportController
* RtpTransport
* RtpSender
* RtpReceiver
They're implemented on top of the "BaseChannel" object, which is normally used
in a PeerConnection, and roughly corresponds to an SDP "m=" section. As a result
of this, there are several limitations:
* You can only have one of each type of sender and receiver (audio/video) on top
of the same transport controller.
* The sender/receiver with the same media type must use the same RTP transport.
* You can't change the transport after creating the sender or receiver.
* Some of the parameters aren't supported.
Later, these "adapter" objects will be gradually replaced by real objects that don't
have these limitations, as "BaseChannel", "MediaChannel" and related code is
restructured. In this CL, we essentially have:
ORTC adapter objects -> BaseChannel -> Media engine
PeerConnection -> BaseChannel -> Media engine
And later we hope to have simply:
PeerConnection -> "Real" ORTC objects -> Media engine
See the linked bug for more context.
BUG=webrtc:7013
TBR=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2675173003
Cr-Commit-Position: refs/heads/master@{#16842}
This is the naming scheme we've been using for internal interfaces.
Also, this CL will introduce a PacketTransportInterface in the webrtc namespace,
which would get too easily confused with the rtc:: one:
https://codereview.webrtc.org/2675173003/
BUG=None
Review-Url: https://codereview.webrtc.org/2679103006
Cr-Commit-Position: refs/heads/master@{#16539}
Bulk of the changes were done using
git grep -l '#include "webrtc/base/common.h"' | \
xargs sed -i '\,^#include.*webrtc/base/common\.h,d'
followed by adding back the include in the few places where it is
still needed, and in one case (pseudotcp.cc) instead deleting its use
of RTC_UNUSED.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2644103002
Cr-Commit-Position: refs/heads/master@{#16263}
... As opposed to DtlsTransportInternal.
The code is suboptimal right now, storing two pointers to the different
interfaces. This will all be cleaned up when we have an "RtpTransport"
abstraction that BaseChannel can use.
This CL also cleans up the "fake transport" classes a bit, and gives
them their own header files.
BUG=None
Review-Url: https://codereview.webrtc.org/2648233003
Cr-Commit-Position: refs/heads/master@{#16258}
DtlsTransportChannelWrapper is renamed to be DtlsTransport which inherits from
DtlsTransportInternal. There will be no concept of "channel" in p2p level.
Both P2PTransportChannel and DtlsTransport don't depend on TransportChannel
and TransportChannelImpl any more and they are removed in this CL.
BUG=none
Review-Url: https://codereview.webrtc.org/2606123002
Cr-Commit-Position: refs/heads/master@{#16173}
Reason for revert:
Failed the memory check.
May need to fix the memory leak.
Original issue's description:
> make the DtlsTransportWrapper inherit form DtlsTransportInternal
>
> BUG=none
>
> Review-Url: https://codereview.webrtc.org/2606123002
> Cr-Commit-Position: refs/heads/master@{#16160}
> Committed: 5aed06c8d3TBR=deadbeef@webrtc.org,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/2639203004
Cr-Commit-Position: refs/heads/master@{#16162}
Previously: Failed to setup RTCP mux filter.
Now: rtcpMuxPolicy is 'require', but media description does not
contain 'a=rtcp-mux'.
BUG=webrtc:6966
Review-Url: https://codereview.webrtc.org/2622553003
Cr-Commit-Position: refs/heads/master@{#16062}
Previously, BaseChannel supported a "no RTCP" mode, which wasn't
being used any more and is being deleted.
Also, "RTCP mux required" previously worked by calling "ActivateRtcpMux"
after construction. Now it works by explicitly passing a
"require_rtcp_mux" parameter into the constructor.
BUG=None
Review-Url: https://codereview.webrtc.org/2622613004
Cr-Commit-Position: refs/heads/master@{#16045}
The BaseChannel can set the transport directly without depending on
TransportController.
When initializing the network of the BaseChannel, the ChannelManager will
create TransportChannels with the TransportController.
When enabling bundling, WebRtcSession will get or create TransportChannels
with the TransportController.
When a TransportChannel of the BaseChannel needs to be destroyed, it will
fire a signal to notify the WebRtcSession.
BUG=none.
Review-Url: https://codereview.webrtc.org/2614263002
Cr-Commit-Position: refs/heads/master@{#16043}
Bulk of changes done using
git grep -l 'RTC_DCHECK(false)' | \
xargs sed -i 's/RTC_DCHECK(false)/RTC_NOTREACHED()/'
peerconnection.cc also used RTC_DCHECK(false && "msg") in two places,
which were updated manually.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2623313004
Cr-Commit-Position: refs/heads/master@{#16026}
The BaseChannel code is geared around RTP; the presence of media engines,
send and receive streams, SRTP, SDP directional attribute negotiation, etc.
It doesn't make sense to use it for SCTP as well. This separation should make
future work both on BaseChannel and the SCTP code paths easier.
SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
doesn't get confused with webrtc::DataChannel any more.
Beyond just moving code around, some consequences of this CL:
- We'll now stop using the worker thread for SCTP. Packets will be
processed right on the network thread instead.
- The SDP directional attribute is ignored, as it's supposed to be.
BUG=None
Review-Url: https://codereview.webrtc.org/2564333002
Cr-Original-Commit-Position: refs/heads/master@{#15906}
Committed: 67b3bbe639
Review-Url: https://codereview.webrtc.org/2564333002
Cr-Commit-Position: refs/heads/master@{#15973}
Reason for revert:
Hitting DCHECK in chromium's WebrtcTransportTest.TerminateDataChannel and WebrtcTransportTest.DataStreamLate. Will investigate and reland.
Original issue's description:
> Separating SCTP code from BaseChannel/MediaChannel.
>
> The BaseChannel code is geared around RTP; the presence of media engines,
> send and receive streams, SRTP, SDP directional attribute negotiation, etc.
> It doesn't make sense to use it for SCTP as well. This separation should make
> future work both on BaseChannel and the SCTP code paths easier.
>
> SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
> directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
> doesn't get confused with webrtc::DataChannel any more.
>
> Beyond just moving code around, some consequences of this CL:
> - We'll now stop using the worker thread for SCTP. Packets will be
> processed right on the network thread instead.
> - The SDP directional attribute is ignored, as it's supposed to be.
>
> BUG=None
>
> Review-Url: https://codereview.webrtc.org/2564333002
> Cr-Commit-Position: refs/heads/master@{#15906}
> Committed: 67b3bbe639TBR=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/2614813003
Cr-Commit-Position: refs/heads/master@{#15908}
The BaseChannel code is geared around RTP; the presence of media engines,
send and receive streams, SRTP, SDP directional attribute negotiation, etc.
It doesn't make sense to use it for SCTP as well. This separation should make
future work both on BaseChannel and the SCTP code paths easier.
SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
doesn't get confused with webrtc::DataChannel any more.
Beyond just moving code around, some consequences of this CL:
- We'll now stop using the worker thread for SCTP. Packets will be
processed right on the network thread instead.
- The SDP directional attribute is ignored, as it's supposed to be.
BUG=None
Review-Url: https://codereview.webrtc.org/2564333002
Cr-Commit-Position: refs/heads/master@{#15906}
"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}
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}
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}
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}
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}
