To allow end-to-end QuicDataChannel usage with a
PeerConnection, RTCConfiguration has been modified to
include a boolean for whether to do QUIC, since negotiation of
QUIC is not implemented. If one peer does QUIC, then it will be
assumed that the other peer must do QUIC or the connection
will fail.
PeerConnection has been modified to create data channels of type
QuicDataChannel when the peer wants to do QUIC.
WebRtcSession has ben modified to use a QuicDataTransport
instead of a DtlsTransportChannelWrapper/DataChannel
when QUIC should be used
QuicDataTransport implements the generic functions of
BaseChannel to manage the QuicTransportChannel.
Committed: https://crrev.com/34b54c36a533dadb6ceb70795119194e6f530ef5
Review-Url: https://codereview.webrtc.org/2166873002
Cr-Original-Commit-Position: refs/heads/master@{#13645}
Cr-Commit-Position: refs/heads/master@{#13657}
Reason for revert:
Reverting because it broke an RTP data channel test on the FYI bots.
Original issue's description:
> Modified PeerConnection and WebRtcSession for end-to-end QuicDataChannel usage.
>
> To allow end-to-end QuicDataChannel usage with a
> PeerConnection, RTCConfiguration has been modified to
> include a boolean for whether to do QUIC, since negotiation of
> QUIC is not implemented. If one peer does QUIC, then it will be
> assumed that the other peer must do QUIC or the connection
> will fail.
>
> PeerConnection has been modified to create data channels of type
> QuicDataChannel when the peer wants to do QUIC.
>
> WebRtcSession has ben modified to use a QuicDataTransport
> instead of a DtlsTransportChannelWrapper/DataChannel
> when QUIC should be used
>
> QuicDataTransport implements the generic functions of
> BaseChannel to manage the QuicTransportChannel.
>
> Committed: https://crrev.com/34b54c36a533dadb6ceb70795119194e6f530ef5
> Cr-Commit-Position: refs/heads/master@{#13645}
TBR=pthatcher@webrtc.org,zhihuang@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/2206793007
Cr-Commit-Position: refs/heads/master@{#13647}
To allow end-to-end QuicDataChannel usage with a
PeerConnection, RTCConfiguration has been modified to
include a boolean for whether to do QUIC, since negotiation of
QUIC is not implemented. If one peer does QUIC, then it will be
assumed that the other peer must do QUIC or the connection
will fail.
PeerConnection has been modified to create data channels of type
QuicDataChannel when the peer wants to do QUIC.
WebRtcSession has ben modified to use a QuicDataTransport
instead of a DtlsTransportChannelWrapper/DataChannel
when QUIC should be used
QuicDataTransport implements the generic functions of
BaseChannel to manage the QuicTransportChannel.
Review-Url: https://codereview.webrtc.org/2166873002
Cr-Commit-Position: refs/heads/master@{#13645}
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}
When the flag prune_turn_ports is set, When a high-priority turn port becomes available, it will prune low-priority ones. The pruned port will not be used for creating connections locally and its candidates will not be sent over to the remove side (unless they have been sent before being pruned).
This effectively reduces the number of TURN candidates and connections created by TURN ports.
BUG=
R=deadbeef@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2093623004 .
Committed: https://crrev.com/17aac053f585e892114974d2eb248e05ad37f973
Cr-Original-Commit-Position: refs/heads/master@{#13335}
Cr-Commit-Position: refs/heads/master@{#13354}
Reason for revert:
Breaks Win32/Win64 Debug bots in client.webrtc waterfall
Original issue's description:
> Add config to prune low-priority TURN ports for creating connections
> When the flag prune_turn_ports is set, When a high-priority turn port becomes available, it will prune low-priority ones. The pruned port will not be used for creating connections locally and its candidates will not be sent over to the remove side (unless they have been sent before being pruned).
>
> This effectively reduces the number of TURN candidates and connections created by TURN ports.
>
> BUG=
> R=deadbeef@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/17aac053f585e892114974d2eb248e05ad37f973
> Cr-Commit-Position: refs/heads/master@{#13335}
TBR=pthatcher@webrtc.org,deadbeef@webrtc.org,honghaiz@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2111663003
Cr-Commit-Position: refs/heads/master@{#13342}
Reason for revert:
Reverting all CLs related to moving the eventlog, as they break Chromium tests.
Original issue's description:
> Move RtcEventLog object from inside VoiceEngine to Call.
>
> In addition to moving the logging object itself, this also moves the interface from PeerConnectionFactory to PeerConnection, which makes more sense for this functionality. An API parameter to set an upper limit to the size of the logfile is introduced.
> The old interface on PeerConnectionFactory is not removed in this CL, because it is called from Chrome, it will be removed after Chrome is updated to use the PeerConnection interface.
>
> BUG=webrtc:4741,webrtc:5603,chromium:609749
> R=solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org, tommi@webrtc.org
>
> Committed: https://crrev.com/1895526c6130e3d0e9b154f95079b8eda7567016
> Cr-Commit-Position: refs/heads/master@{#13321}
TBR=solenberg@webrtc.org,tommi@webrtc.org,stefan@webrtc.org,terelius@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4741,webrtc:5603,chromium:609749
Review-Url: https://codereview.webrtc.org/2111813002
Cr-Commit-Position: refs/heads/master@{#13340}
Reason for revert:
Reverting all CLs related to moving the eventlog, as they break Chromium tests.
Original issue's description:
> Fix to make the start/stop functions for the Rtc Eventlog non-virtual.
>
> This is needed to prevent the Chromium import bot from breaking.
>
> BUG=
> R=tommi@webrtc.org
>
> Committed: https://crrev.com/df6ecea8ac7c4c3bddeda089d5fb9eccdf38a0a6
> Cr-Commit-Position: refs/heads/master@{#13324}
TBR=tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2111803002
Cr-Commit-Position: refs/heads/master@{#13339}
When the flag prune_turn_ports is set, When a high-priority turn port becomes available, it will prune low-priority ones. The pruned port will not be used for creating connections locally and its candidates will not be sent over to the remove side (unless they have been sent before being pruned).
This effectively reduces the number of TURN candidates and connections created by TURN ports.
BUG=
R=deadbeef@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2093623004 .
Cr-Commit-Position: refs/heads/master@{#13335}
In addition to moving the logging object itself, this also moves the interface from PeerConnectionFactory to PeerConnection, which makes more sense for this functionality. An API parameter to set an upper limit to the size of the logfile is introduced.
The old interface on PeerConnectionFactory is not removed in this CL, because it is called from Chrome, it will be removed after Chrome is updated to use the PeerConnection interface.
BUG=webrtc:4741,webrtc:5603,chromium:609749
R=solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1748403002 .
Cr-Commit-Position: refs/heads/master@{#13321}
This CL turns nativeConfiguration into createNativeConfiguration returning a
pointer or nil on failure. This method's certificate generation is updated to
use the new API and reports failure (nil) if unsuccessful instead of relying on
the default certificate. We also remove the implicit assumption (now incorrect)
that RSA is the default. This is the same type of changes as was done in
https://codereview.webrtc.org/1965313002 but this file
(RTCPeerConnectionInterface.mm) was forgotten.
With no more usages of kIdentityName it and dtlsidentitystore.cc is removed.
Also removes unnecessary #include in peerconnectioninterface.h that was still
remnant due to an indirect include of kIdentityName.
RTCConfiguration+Private.h now lists method nativeEncryptionKeyTypeForKeyType
which was added in the above mentioned prior CL.
BUG=webrtc:5707, webrtc:5708
Review-Url: https://codereview.webrtc.org/2035473004
Cr-Commit-Position: refs/heads/master@{#13089}
This is one less DtlsIdentityStoreInterface implementation, and one step closer
to removing this interface in favor of RTCCertificateGeneratorInterface.
This also removes PeerConnectionInterface::CreatePeerConnectionWithStore which
is no longer needed.
BUG=webrtc:5707, webrtc:5708
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2020623002 .
Cr-Commit-Position: refs/heads/master@{#12990}
The store was used in WebRtcSessionDescriptionFactory to generate certificates,
now a generator is used instead (new API). PeerConnection[Factory][Interface],
and WebRtcSession are updated to pass generators all the way down to the
WebRtcSessionDescriptionFactory instead of stores.
The webrtc implementation of a generator, RTCCertificateGenerator, is used as
the default generator (peerconnectionfactory.cc:189) instead of the webrtc
implementation of a store, DtlsIdentityStoreImpl.
The generator is fully parameterized and does not generate RSA-1024 unless you
ask for it (which makes sense not to do beforehand since ECDSA is now default).
The store was not fully parameterized (known filed bug).
The "top" layer, PeerConnectionFactoryInterface::CreatePeerConneciton, is
updated to take a generator instead of a store.
Many unittests still use a store, to allow them to continue to do so the
factory gets CreatePeerConnectionWithStore which uses the old function
signature (and invokes the new signature by wrapping the store in an
RTCCertificateGeneratorStoreWrapper). As soon as the FakeDtlsIdentityStore is
turned into a certificate generator instead of a store, the unittests will be
updated and we can remove CreatePeerConnectionWithStore.
This is a reupload of https://codereview.webrtc.org/2013523002/ with minor
changes.
BUG=webrtc:5707, webrtc:5708
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2017943002 .
Cr-Commit-Position: refs/heads/master@{#12984}
This allows webrtc to not gather on cellular networks if wifi or
other low cost networks are present.
BUG=
Review-Url: https://codereview.webrtc.org/1987833002
Cr-Commit-Position: refs/heads/master@{#12979}
This will make it much less likely for application developers to not
realize the object is reference counted.
It also fixes a bug in the Java PeerConnection binding, by allowing a
reference to be transferred in the OnRemoveStream call via std::move.
BUG=webrtc:5128
R=pthatcher@webrtc.org, tkchin@webrtc.org
Review URL: https://codereview.webrtc.org/1972793003 .
Cr-Commit-Position: refs/heads/master@{#12976}
Reason for revert:
There are more CreatePeerConnection calls than I anticipated/had found in Chromium, like remoting/protocol/webrtc_transport.cc. Reverting due to broken Chromium FYI bots.
Original issue's description:
> Replacing DtlsIdentityStoreInterface with RTCCertificateGeneratorInterface.
>
> The store was used in WebRtcSessionDescriptionFactory to generate certificates,
> now a generator is used instead (new API). PeerConnection[Factory][Interface],
> and WebRtcSession are updated to pass generators all the way down to the
> WebRtcSessionDescriptionFactory instead of stores.
>
> The webrtc implementation of a generator, RTCCertificateGenerator, is used as
> the default generator (peerconnectionfactory.cc:189) instead of the webrtc
> implementation of a store, DtlsIdentityStoreImpl.
> The generator is fully parameterized and does not generate RSA-1024 unless you
> ask for it (which makes sense not to do beforehand since ECDSA is now default).
> The store was not fully parameterized (known filed bug).
>
> The "top" layer, PeerConnectionFactoryInterface::CreatePeerConnection, is
> updated to take a generator instead of a store. But as to not break Chromium,
> the old function signature taking a store is kept. It is implemented to invoke
> the generator version by wrapping the store in an
> RTCCertificateGeneratorStoreWrapper. As soon as Chromium is updated to use the
> new function signature we can remove the old CreatePeerConnection.
> Due to having multiple CreatePeerConnection signatures, some calling places
> are updated to resolve the ambiguity introduced.
>
> BUG=webrtc:5707, webrtc:5708
> R=phoglund@webrtc.org, tommi@webrtc.org
> TBR=tkchin@webrc.org
>
> Committed: 400781a209TBR=tkchin@webrtc.org,tommi@webrtc.org,phoglund@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5707, webrtc:5708
Review-Url: https://codereview.webrtc.org/2020633002
Cr-Commit-Position: refs/heads/master@{#12948}
The store was used in WebRtcSessionDescriptionFactory to generate certificates,
now a generator is used instead (new API). PeerConnection[Factory][Interface],
and WebRtcSession are updated to pass generators all the way down to the
WebRtcSessionDescriptionFactory instead of stores.
The webrtc implementation of a generator, RTCCertificateGenerator, is used as
the default generator (peerconnectionfactory.cc:189) instead of the webrtc
implementation of a store, DtlsIdentityStoreImpl.
The generator is fully parameterized and does not generate RSA-1024 unless you
ask for it (which makes sense not to do beforehand since ECDSA is now default).
The store was not fully parameterized (known filed bug).
The "top" layer, PeerConnectionFactoryInterface::CreatePeerConnection, is
updated to take a generator instead of a store. But as to not break Chromium,
the old function signature taking a store is kept. It is implemented to invoke
the generator version by wrapping the store in an
RTCCertificateGeneratorStoreWrapper. As soon as Chromium is updated to use the
new function signature we can remove the old CreatePeerConnection.
Due to having multiple CreatePeerConnection signatures, some calling places
are updated to resolve the ambiguity introduced.
BUG=webrtc:5707, webrtc:5708
R=phoglund@webrtc.org, tommi@webrtc.orgTBR=tkchin@webrc.org
Review URL: https://codereview.webrtc.org/2013523002 .
Cr-Commit-Position: refs/heads/master@{#12947}
The caller can set a negative or zero file size to avoid using a limit.
BUG=
Review-Url: https://codereview.webrtc.org/1974453002
Cr-Commit-Position: refs/heads/master@{#12730}
Depends on this CL in order to work in Chromium:
https://codereview.chromium.org/1976673002/
It works by creating pooled PortAllocatorSessions which can be picked up
by a P2PTransportChannel when needed (after a local description is set).
This can optimize candidate gathering time when there is some time between
creating a PeerConnection and setting a local description.
R=pthatcher@webrtc.org
Committed: 48e9d05f51
Review URL: https://codereview.webrtc.org/1956453003 .
Cr-Commit-Position: refs/heads/master@{#12729}
Reason for revert:
Breaks remoting_unittests. They defined their own operator== which conflicts with this one.
I'll remove the operator== in a roll CL. But until it's approved, I'm reverting this so the FYI bots will pass.
Original issue's description:
> Implement RTCConfiguration.iceCandidatePoolSize.
>
> It works by creating pooled PortAllocatorSessions which can be picked up
> by a P2PTransportChannel when needed (after a local description is set).
>
> This can optimize candidate gathering time when there is some time between
> creating a PeerConnection and setting a local description.
>
> R=pthatcher@webrtc.org
>
> Committed: 48e9d05f51TBR=pthatcher@webrtc.org,honghaiz@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/1972043004
Cr-Commit-Position: refs/heads/master@{#12709}
It works by creating pooled PortAllocatorSessions which can be picked up
by a P2PTransportChannel when needed (after a local description is set).
This can optimize candidate gathering time when there is some time between
creating a PeerConnection and setting a local description.
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1956453003 .
Cr-Commit-Position: refs/heads/master@{#12708}
But keep #including scoped_ptr.h in .h files, so as not to break
WebRTC users who expect those .h files to give them rtc::scoped_ptr.
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1930463002
Cr-Commit-Position: refs/heads/master@{#12530}
This eliminates some instances rtc:Optional and makes the code
simpler. No changes in defaults or other behaviour are intended.
BUG=webrtc:4906
Review URL: https://codereview.webrtc.org/1818033002
Cr-Commit-Position: refs/heads/master@{#12326}
and signaling the remote side to remove its remote candidate by setting the candidate priority to 0.
BUG=
Review URL: https://codereview.webrtc.org/1648813004
Cr-Commit-Position: refs/heads/master@{#11958}
Moved VideoSourceInterface to MediaStreamInterface.h
Renamed VideoSourceTest to VideoCapturerTrackSourceTest
Renamed VideoSource to VideoCaptureTrackSource and cl lint and cl format.
BUG=webrtc:5426
TBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1770003002 .
Cr-Commit-Position: refs/heads/master@{#11893}
all interfaces that formerly took constraints parameters
in name=value form.
This is in preparation for making Chrome only use these
explicit interfaces.
BUG=webrtc:4906
Review URL: https://codereview.webrtc.org/1717583002
Cr-Commit-Position: refs/heads/master@{#11870}
This feature is off by default and can be turned on by setting IceConfig. When turned on, we'll choose a Turn/Turn (UDP takes higher priroity) over the other types of connections while no any connection is writable. However, when there is best connection or there is pending triggered check, those will take higher priority.
BUG=webrtc:4591
Review URL: https://codereview.webrtc.org/1577233006
Cr-Commit-Position: refs/heads/master@{#11850}
In addition to the code moved from talk/app/webrtc
there were some files in webrtc/api/objctests that still
had the libjingle license header.
BUG=webrtc:5418
TBR=tkchin@webrtc.org
NOTRY=True
Review URL: https://codereview.webrtc.org/1680293005
Cr-Commit-Position: refs/heads/master@{#11552}
The previously disabled warnings that were inherited from
talk/build/common.gypi are now replaced by target-specific disabling
of only the failing warnings. Additional disabling was needed since the stricter
compilation warnings that applies to code in webrtc/.
License headers will be updated in a follow-up CL.
Other modifications:
* Updated the header guards.
* Sorted the includes using chromium/src/tools/sort-headers.py
except for these files:
talk/app/webrtc/peerconnectionendtoend_unittest.cc
talk/app/webrtc/java/jni/androidmediadecoder_jni.cc
talk/app/webrtc/java/jni/androidmediaencoder_jni.cc
webrtc/media/devices/win32devicemanager.cc
The HAVE_SCTP define was added for the peerconnection_unittests target
in api_tests.gyp.
I also checked that none of
SRTP_RELATIVE_PATH
HAVE_SRTP
HAVE_WEBRTC_VIDEO
HAVE_WEBRTC_VOICE
were used by the talk/app/webrtc code.
For Chromium, the following changes will need to be applied to the roll CL that updates the
DEPS for WebRTC and libjingle:
https://codereview.chromium.org/1615433002
BUG=webrtc:5418
NOPRESUBMIT=True
R=deadbeef@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1610243002 .
Cr-Commit-Position: refs/heads/master@{#11545}
