This change maintains full backward compatibility while adopting
modern Go type alias conventions for better code clarity.
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Replace manual atomic operations with atomic.Bool type for better
type safety and cleaner code. This modernizes the atomic usage
pattern from atomic.LoadInt32/StoreInt32 to the newer Load/Store
methods on atomic.Bool.
- Update activeTCPConn.closed field type from int32 to atomic.Bool
- Replace atomic.LoadInt32(&a.closed) with a.closed.Load()
- Replace atomic.StoreInt32(&a.closed, 1) with a.closed.Store(true)
All existing functionality preserved with improved type safety.
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
tweak
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Pion incorrectly resets the consent timer when sending any traffic.
The consent timer must only be reset on STUN traffic.
RFC 7675
> Consent expires after 30 seconds. That is, if a valid STUN binding
> response has not been received from the remote peer's transport
> address in 30 seconds, the endpoint MUST cease transmission on that
> 5-tuple. STUN consent responses received after consent expiry do not
> re-establish consent and may be discarded or cause an ICMP error.
While not spec compliant, some implementations allow for empty extension
values. This aligns with our behavior for empty foundation values.
And makes the parser more forgiving for bad implementations.
Added `AddExtension` and `RemoveExtension` methods to `ICECandidate`,
allowing extensions to be managed dynamically.
Ensure that `TCPType` is stored in one place (candidate.TCPType)
- Rewrote `UnmarshalCandidate` to better align with RFC5245.
- Added Candidate `Extensions` and `GetExtension`.
- Updated `Equal` and `Marshal` to accommodate these changes.
- New Type `CandidateExtension` to handle.
listenUDPInPortRange wasn't passing the Zone and would always fail to
bind. This would cause high CPU usage as every port in the range would
be attempted and fail.
Fixes#742
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.
Xiaobo Liu
PionandSean DuBois
sirzooroandGitHub
Joe Turki
oto313andGitHub
cnderrauberandGitHub
renovate[bot]andJoe Turki
Paul WellsandGitHub
Amin ChelohandSean DuBois
WofWcaandSean DuBois
Nikita KarmatskikhandSean DuBois
Raja SubramanianandGitHub
ARJUN SHAJIandSean DuBois