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}
Previously when a Turn port is pruned, if its candidate has been sent to the remote side, the remote side will keep the candidate and use that to create connections.
We now signal the remote side to remove the candidates so that at least no new connection will be created using the removed candidates.
Also updated the virtual socket server to better support our test cases.
1. Allow the virtual socket server to set transit delay for packets sent from a given IP address.
2. Ensure the ordered packet delivery for each socket (Previously the delivery order is enforced on the whole test case, so if a udp packet gets delayed based on its IP address, all TCP packets sent after the UDP packet will be delayed at least until the UDP packet is received).
BUG=webrtc:6380
R=deadbeef@webrtc.org, pthatcher@webrtc.org, skvlad@webrtc.org
Review URL: https://codereview.webrtc.org/2261523004 .
Cr-Commit-Position: refs/heads/master@{#14297}
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}
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}
It may happen in some legitimate scenarios.
For example a turn port may have had a refresh request timeout, so it won't create a new connection for a ping from an unknown address.
R=deadbeef@webrtc.org
Review URL: https://codereview.webrtc.org/2327233002 .
Cr-Commit-Position: refs/heads/master@{#14173}
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}
Log the DTLS handshake error code in OpenSSLStreamAdapter.
Forward the error code to WebRTCSession with the Signals.
This part is only for the WebRTC native code.
To make it work, need another CL for Chromium.
BUG=webrtc:5959
Review-Url: https://codereview.webrtc.org/2167363002
Cr-Commit-Position: refs/heads/master@{#13940}
I found that, depending on when it's called, ClearGettingPorts may or
may not signal CandidatesAllocationDone, and may or may not continue
to gather more ports/candidates.
I'm fixing this inconsistency by having it always signal
CandidatesAllocationDone (if needed), and always stop gathering until
the next network change event. This makes it equivalent to
StopGettingPorts, except that it allows gathering to be restarted if
a network change occurs.
I also found that P2PTransportChannel was signaling "gathering
complete" even when continual gathering was enabled. This wasn't caught
by the unit tests due to the inconsistency of ClearGettingPorts as
described above.
Review-Url: https://codereview.webrtc.org/2124283003
Cr-Commit-Position: refs/heads/master@{#13908}
TURN server sockets were being destroyed asynchronously, which could
happen after the TurnServer itself (and even the VirtualSocketServer
used by the sockets) were destroyed.
This is fixed easily by using an AsyncInvoker (to ensure the async
operation doesn't occur after its initiator is destroyed), and keeping
the objects waiting for deletion in a unique_ptr vector.
Review-Url: https://codereview.webrtc.org/2264343002
Cr-Commit-Position: refs/heads/master@{#13907}
The added logs will be helpful for debugging.
If a session has stopped, terminate DoAllocate early.
Session::init always returns true, so there is no need to check the return value.
R=deadbeef@webrtc.org, skvlad@webrtc.org
Review URL: https://codereview.webrtc.org/2267163002 .
Cr-Commit-Position: refs/heads/master@{#13871}
The main issue was that upon receiving a binding response with a srflx
mapped address attribute, the local candidate was not updated from local
to srflx. This means the two ICE agents view the same pair differently;
one sees it as "X<->srflx" while the other sees it as "local<->X". This
causes sub-optimal prioritization and could result in the wrong pair
being selected if using aggressive nomination.
The other issue was that TCP prflx candidates were not differentiated from
UDP prflx candidates. This lead to TCP prflx candidates prioritized above TCP
host candidates.
After fixing these issues, I was able to re-enable many disabled tests, as well
as restore the check for the candidate types of the controlled agent.
BUG=webrtc:1953,webrtc:2383
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2125823004 .
Cr-Commit-Position: refs/heads/master@{#13734}
In the existing code, if the server address and the local IP family does not
match, we still create a TurnPort and destroy it later.
Instead, we could avoid creating it at the beginning.
This does not affect the client behavior except for the port creation.
BUG=
R=deadbeef@webrtc.org, pthatcher@webrtc.org, zhihuang@webrtc.org
Review URL: https://codereview.webrtc.org/2206713004 .
Cr-Commit-Position: refs/heads/master@{#13720}
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}
Add an ICE nomination attribute. If a connection switched on the controlling side, increase the nomination value set in the attribute.
The controlled side will also be ready for re-nomination option; it will switch if a nomination comes with a higher nomination value even though it may be at a lower priority.
Plus, don't nominate or re-nominate if the nomination value at the current connection has been acknowledged.
BUG=
R=deadbeef@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2163403002 .
Cr-Commit-Position: refs/heads/master@{#13631}
It was possible that "A < B" and "B < A" both evaluated to true.
This manifested as an assert on Windows, and a memory leak on Linux.
Note that the concept of "less than" is meaningless for this object.
The operator is only needed so the object can be used as a key in an
std::map.
BUG=webrtc:6068
R=honghaiz@webrtc.org, kjellander@webrtc.org, skvlad@webrtc.org
Review URL: https://codereview.webrtc.org/2187913002 .
Cr-Commit-Position: refs/heads/master@{#13598}
If a port is not used by any channel and if it has no connection for 30
seconds, it will be removed.
Note, as long as a port is used by a transport channel, it will be kept
even if it does not have any connection. This will be beneficial to
continual gathering because new connections can be created in the future
when network changes.
BUG=
R=pthatcher@webrtc.org, zhihuang@webrtc.org
Review URL: https://codereview.webrtc.org/2171183002 .
Cr-Commit-Position: refs/heads/master@{#13567}
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}
If all connections on a port is destroyed, it will schedule an event
to check if it is dead after a timeout. Previously if a new connection
is created but destroyed before the event is fired, it will destroy the
port. With this change, we will not destoy it until it times out again
after the last created connection is destroyed.
BUG=
R=pthatcher@webrtc.org, zhihuang@webrtc.org
Review URL: https://codereview.webrtc.org/2184013003 .
Cr-Commit-Position: refs/heads/master@{#13563}
We thought we could safely remove this, but older versions of Chrome
don't do role conflict resolution properly, so it's actually not safe
to yet.
BUG=628676
Review-Url: https://codereview.webrtc.org/2152963003
Cr-Commit-Position: refs/heads/master@{#13492}
Logging when a candidate is gathered or the gathering state or a
Port changes. This will make it easier to identify problems related
to candidate gathering.
Review-Url: https://codereview.webrtc.org/2122373004
Cr-Commit-Position: refs/heads/master@{#13490}
If the currently selected connection becomes not receiving and if a backup connection
becomes strong first, we will not switch the connection until X milliseconds is passed
but the selected connection is still not receiving and the backup connection is still receiving. This will prevent the connection switching from happening too frequently.
BUG=
Review-Url: https://codereview.webrtc.org/2143653005
Cr-Commit-Position: refs/heads/master@{#13480}
Merge with the latest webrtc native code.
Remove deprecated function Connect() in QuicTransportChannel.
Fix the compiling issue and broken unit tests by adding the network thread to QUIC related classes.
Review-Url: https://codereview.webrtc.org/2089553002
Cr-Commit-Position: refs/heads/master@{#13472}
Reason for revert:
Reverting because description was inaccurate. Will reland after updating description.
Original issue's description:
> Modify PeerConnection 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 been modified to use a QuicTransportChannel
> instead of a DtlsTransportChannelWrapper/DataChannel
> when QUIC should be used.
>
> Modification of previous in-flight CL: https://codereview.chromium.org/1844803002/
>
> Committed: https://crrev.com/36c8d69ce188102ae6fd48c371cf1518f08698fb
> Cr-Commit-Position: refs/heads/master@{#13470}
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/2146133002
Cr-Commit-Position: refs/heads/master@{#13471}
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 been modified to use a QuicTransportChannel
instead of a DtlsTransportChannelWrapper/DataChannel
when QUIC should be used.
Modification of previous in-flight CL: https://codereview.chromium.org/1844803002/
Review-Url: https://codereview.webrtc.org/2089553002
Cr-Commit-Position: refs/heads/master@{#13470}
The DtlsTransportChannel wasn't properly handling the
P2PTransportChannel becoming writable before receiving a remote
fingerprint; it wasn't starting the DTLS handshake whenever this
happened.
Review-Url: https://codereview.webrtc.org/2140283002
Cr-Commit-Position: refs/heads/master@{#13469}
If the test TURN server received two allocate requests from the same
address, it was replacing the old allocation but not deleting it.
Also switching to std::unique_ptr to make it less likely for this to
pop up again.
Review-Url: https://codereview.webrtc.org/2114063002
Cr-Commit-Position: refs/heads/master@{#13449}
