... 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}
This is used for fallback from DTLS to SDES encryption, which we probably still
want to support. Setting a certificate puts the DTLS transport in a "DTLS
enabled" mode, so it should be delayed until SDP with "a=fingerprint" is set.
BUG=webrtc:6972
Review-Url: https://codereview.webrtc.org/2641633002
Cr-Commit-Position: refs/heads/master@{#16199}
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}
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}
Make P2PTransportChannel inherit from IceTransportInternal instead of
TransportChannelImpl and TransportChannel, so that the DTLS-related methods can
be separated from P2PTransportChannel.
BUG=webrtc:6951
Review-Url: https://codereview.webrtc.org/2608353003
Cr-Commit-Position: refs/heads/master@{#16041}
Reason for revert:
Breaks Chromium WebRTC FYI bots:
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Linux%20Builder/builds/12337
The error was masked by another breaking change that was committer earlier. This is the first build showing the error.
Original issue's description:
> Make P2PTransportChannel inherit from IceTransportInternal.
>
> Make P2PTransportChannel inherit from IceTransportInternal instead of
> TransportChannelImpl and TransportChannel, so that the DTLS-related methods can
> be separated from P2PTransportChannel.
>
> BUG=none
>
> Review-Url: https://codereview.webrtc.org/2590063002
> Cr-Commit-Position: refs/heads/master@{#15743}
> Committed: 12749d89d9TBR=deadbeef@webrtc.org,zhihuang@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/2594343002
Cr-Commit-Position: refs/heads/master@{#15751}
Make P2PTransportChannel inherit from IceTransportInternal instead of
TransportChannelImpl and TransportChannel, so that the DTLS-related methods can
be separated from P2PTransportChannel.
BUG=none
Review-Url: https://codereview.webrtc.org/2590063002
Cr-Commit-Position: refs/heads/master@{#15743}
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 means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
Reason for revert:
Broke a downstream user of SSLStreamAdapter. Need to add the new interface (returning error code instead of bool) in a backwards compatible way.
Original issue's description:
> Allow the DTLS fingerprint verification to occur after the handshake.
>
> This means the DTLS handshake can make progress while the SDP answer
> containing the fingerprint is still in transit. If the signaling path
> if significantly slower than the media path, this can have a moderate
> impact on call setup time.
>
> Of course, until the fingerprint is verified no media can be sent. Any
> attempted write will result in SR_BLOCK.
>
> This essentially fulfills the requirements of RFC 4572, Section 6.2:
>
> Note that when the offer/answer model is being used, it is possible
> for a media connection to outrace the answer back to the offerer.
> Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
> role, it MUST (as specified in RFC 4145 [2]) begin listening for an
> incoming connection as soon as it sends its offer. However, it MUST
> NOT assume that the data transmitted over the TLS connection is valid
> until it has received a matching fingerprint in an SDP answer. If
> the fingerprint, once it arrives, does not match the client's
> certificate, the server endpoint MUST terminate the media connection
> with a bad_certificate error, as stated in the previous paragraph.
>
> BUG=webrtc:6387
> R=mattdr@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/042041bf9585f92e962387c59ca805f1218338f9
> Cr-Commit-Position: refs/heads/master@{#14296}
TBR=pthatcher@webrtc.org,mattdr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2352863003
Cr-Commit-Position: refs/heads/master@{#14298}
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
R=mattdr@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2163683003 .
Cr-Commit-Position: refs/heads/master@{#14296}
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}
we will periodically check if any network does not have any connection on it and if yes, attempt to re-gather on those networks.
BUG=
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2025573002 .
Cr-Commit-Position: refs/heads/master@{#13367}
Previously, we were starting a periodic timer when the local
description was set. The first connection may be created at any
time after this happens, so after creating the first connection, we
need to wait until that timer next fires before sending a ping.
Now we just start that timer (and send the first ping) immediately
after the first connection becomes pingable.
This CL also removes the "Connect" method. The only vestigal
effect of this method was to start the periodic timer, which is
now not needed since it happens automatically.
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2099563004 .
Cr-Commit-Position: refs/heads/master@{#13331}
The "should I simulate EWOULDBLOCK?" determination now happens
solely in P2PTransportChannel. This also fixes a bug where the
"last packet id" was set even if no packet was sent.
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2099783002 .
Cr-Commit-Position: refs/heads/master@{#13307}
Reason for revert:
It turns out this revert was not necessary because the connection-state mapping for turn-turn connections was not done in connection.
Original issue's description:
> Revert of Revert "Revert of Update the BWE when the network route changes. (patchset #5 id:180001 of https://… (patchset #5 id:120001 of https://codereview.webrtc.org/2041593002/ )
>
> Reason for revert:
> ReadyToSendMedia did not consider the new presumed_writable state.
>
> Original issue's description:
> > Revert "Revert of Update the BWE when the network route changes. (patchset #5 id:180001 of https://codereview.webrtc.org/2000063003/ )"
> >
> > This reverts commit 72d41aa6da94dacb8a8464d1abd4ca7d1afffc65.
> >
> > New change made:
> > Do not reset the BWE when the new network route is not ready to send media.
> >
> > BUG=
> > R=pthatcher@webrtc.org, stefan@webrtc.org
> >
TBR=pthatcher@webrtc.org,stefan@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2094863003
Cr-Commit-Position: refs/heads/master@{#13282}
Every message will now be traced with the location from which it was
posted, including function name, file and line number.
This CL also writes a normal LOG message when the dispatch took more
than a certain amount of time (currently 50ms).
This logging should help us identify messages that are taking
longer than expected to be dispatched.
R=pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2019423006 .
Cr-Commit-Position: refs/heads/master@{#13104}
In some cases, the DTLS ClientHello may arrive before the server's
transport is writable (before it receives a STUN ping response), or
even before it receives a remote fingerprint. If this packet is
discarded, it may take a second for a it to be sent again.
So, this CL caches it instead of dropping it, and feeds it into
the SSL library once the handshake has been started.
BUG=webrtc:5789
Review-Url: https://codereview.webrtc.org/1912323002
Cr-Commit-Position: refs/heads/master@{#12634}
The problem with gmock is worked around by commenting out any other override declarations in classes using gmock.
NOPRESUBMIT=True
BUG=webrtc:3970
Review-Url: https://codereview.webrtc.org/1921653002
Cr-Commit-Position: refs/heads/master@{#12563}
This propagated into various other places. Also had to #include headers that
were implicitly pulled by "scoped_ptr.h".
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1920043002
Cr-Commit-Position: refs/heads/master@{#12501}
Instead of using a raw pointer output parameter. This affects
SSLStreamAdapter::GetPeerCertificate
Transport::GetRemoteSSLCertificate
TransportChannel::GetRemoteSSLCertificate
TransportController::GetRemoteSSLCertificate
WebRtcSession::GetRemoteSSLCertificate
This is a good idea in general, but will also be very convenient when
scoped_ptr is gone, since unique_ptr doesn't have an .accept() method.
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1802013002
Cr-Commit-Position: refs/heads/master@{#12262}
Also changed from unsigned to signed integer per the style guide.
By the way, I kept all delta-times to be 32-bit int.
The only things left in the p2p dir are
1. proberprober/main.cc where Time() is used as the input for a random number.
2. pseudotcp.cc: where 32-bit time info is sent over the wire.
BUG=webrtc:5636
Review URL: https://codereview.webrtc.org/1793553002
Cr-Commit-Position: refs/heads/master@{#12019}
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}
Also change the type of "time interval" to int from uint32.
Fixed a few TODO therein. I think we should have the following convention:
1. All time delay/intervals should have type int although the time instant should have time uint32_t.
2. "interval" is preferred to "delay" if the delay will be repeated (like rescheduling).
BUG=
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1762863002 .
Cr-Commit-Position: refs/heads/master@{#11888}
This appears to be dead code because GetTransport() is not used by WebRTC. It also adds dead code to DtlsTransportChannelWrapper and P2PTransportChannel.
BUG=
Review URL: https://codereview.webrtc.org/1691673002
Cr-Commit-Position: refs/heads/master@{#11662}
