There could be a mismatch between the two ends in candidate priority
when using peer reflexive. It happens in the following scenario
1. Client has two srflx candidates.
a. The first one gets discovered by LiveKit server as prflx.
b. The second one gets added via ice-trickle first and then
gets a STUN ping. So, it is srflx remote candidate from
server's point-of-view.
2. This leads to a priority issue.
a. Both candidates have same priority from client's point-of-view
(both are srflx).
b. But, from server's point-of-view, the first candidate has
higher priority (prflx).
3. The first candidate establishes connectivity and becomes
the selected pair (client is ICE controlling and server is
ICE controlled, server is in ICE lite).
4. libwebrtc does a sort and switch some time later based on RTT.
As client side has both at same priority, RTT based sorting
could make the second candidate the preferred one.
So, the client sends useCandidate=1 for the second candidate.
pion/ice does not switch because the selected pair is at
higher priority due to prflx candidate.
5. STUN pings do not happen and the ICE connection eventually fails.
ICE controlled agent should accept use-candidate unconditionally if
it is an ICE lite agentt.
Just in case existing behaviour is needed, it can be configured
using `EnableUseCandidateCheckPriority`.
NOTE: With aggressive nomination, the selected pair could change
a few times, but should eventually settle on what the controlling
side wants.
Allow the user to perform custom processing for inbound STUN Binding
requests. This allows users to do some of the following
* Log incoming Binding Requests for debugging
* Implement draft-thatcher-ice-renomination
* Implement custom CandidatePair switching logic
Resolves pion/webrtc#2539
Resolves pion/webrtc#2585
Resolves#623
By default TCP candidate type priority is UDP one minus 27 (except
relay), so that UDP+srlfx priority > TCP+host priority. That priority
offset can be configured using AgentConfig.
IPv6 TCP candidates are also supported.
This change adapts pion/ice to use a new interface for most network
related operations. The interface was formerly a simple struct vnet.Net
which was originally intended to facilicate testing. By replacing it
with an interface we have greater flexibility and allow users to hook
into the networking stack by providing their own implementation of
the interface.
When machine's network interface have more than one ip address and
user don't want expose one of these ips to remote peer, interface
filter can't work in this case, so add a ip filter for that.
Add config for accept aggressive nomination, it is useful for
compatible with chrome or other clients use aggressive nominate
to update nominate candidate pairs.
The original UDPMux only works for the HOST candidates.
UniversalUDPMux adds support for SRFLX candidates
and will later support Relay candidates.
UniversalUDPMux embeds UDPMuxDefault and
handles STUN server packets to discover XORMappedAddr
forwarding the remaining packets for muxing to UDPMuxDefault.
Enable user to implement the golang.org/x/net/proxy
dialer interface in order to have a customized dialer.
The customized dialer could be one that connect through
a corporate HTTP/HTTPS proxy.
Resolves#284
This addresses a few points issue of #245:
- Take a net.Listener instead of having global state
- Expose a net.TCPMux based API
Also, the unused closeChannel was removed from tcp_mux.go
Closes#253.
Previously in the connecting phase, a gathered peer reflexive candidate
which is by default nominated after 500mS, would have to wait 2s
(default taskLoopInterval) before being nominated.
pion/webrtc@v3 will be trickle by default, so removing
support from here. Users can easily simulate non-trickle
by setting a OnICECandidate callback.
This just reduces the amount of things we need to test/worry about.
This should be lower then defaultDisconnectTimeout otherwise
we are going to enter disconnected.
Also rename defaultDisconnectTimeout -> defaultDisconnectedTimeout
to make the tense consistent with other options
Resolves#190
