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}
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}
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}
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}
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}
The fake clock has a few advantages:
1. It lets use verify that operations take the expected number of
round trips.
2. It makes the tests faster by letting us remove the equivalent
of "Sleep(500)" all over the tests.
3. It makes the tests less flaky, because sometimes sleeping for
500ms or waiting for 1s is not enough.
R=honghaiz@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2097793003 .
Cr-Commit-Position: refs/heads/master@{#13304}
Reason for revert:
Didn't intend to land yet. Chromium CL still needed.
Original issue's description:
> Add virtual Initialize methods to PortAllocator and NetworkManager.
>
> This will allow PeerConnection to handle hopping to the right thread
> and doing thread-specific initialization for the PortAllocator.
> This eliminates a required thread-hop for whatever is passing the
> PortAllocator into CreatePeerConnection.
>
> BUG=617648
> R=pthatcher@webrtc.org, skvlad@webrtc.org
>
> Committed: https://crrev.com/a6bdb0990a659ff9e7c4374f5033a6bcc4fbfb21
> Cr-Commit-Position: refs/heads/master@{#13283}
TBR=pthatcher@webrtc.org,skvlad@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=617648
Review-Url: https://codereview.webrtc.org/2092023004
Cr-Commit-Position: refs/heads/master@{#13284}
This will allow PeerConnection to handle hopping to the right thread
and doing thread-specific initialization for the PortAllocator.
This eliminates a required thread-hop for whatever is passing the
PortAllocator into CreatePeerConnection.
BUG=617648
R=pthatcher@webrtc.org, skvlad@webrtc.org
Review URL: https://codereview.webrtc.org/2097653002 .
Cr-Commit-Position: refs/heads/master@{#13283}
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}
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
>
> Committed: https://crrev.com/5b5d2cdad7018993272525a723ef34f7da5c45f2
> Cr-Commit-Position: refs/heads/master@{#13280}
TBR=pthatcher@webrtc.org,stefan@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/2098703004
Cr-Commit-Position: refs/heads/master@{#13281}
