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.
Link-local IPv6 addresses may have ZoneID attached at the end. It has
local meaning only and should not be send to other parties. This change
removes ZoneID from generated candidate string, and ignores ZoneID
when received candidate is parsed.
This reverts commit edb69295c0.
In that commit, active time was changed from time.Time to
Unix time in order to avoid allocations. Unfortunately, that
has the side effect of discarding the monotonic component of
time.Time, and therefore makes our code vulnerable to stepping
of the system clock.
Fixes#697
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.
Expose this error so pion/webrtc can handle gracefully.
rfc8839#section-5.1 specifies that a WebRTC Agent MUST
ignore any name/value pairs it doesn't understand.
Relates to pion/webrtc#1949
The webrtc-stats spec defines this field as:
> It is the protocol used by the endpoint to communicate with the TURN
> server. This is only present for local candidates. Valid values are
> "udp", "tcp", or "tls".
https://w3.org/TR/webrtc-stats/#dom-rtcicecandidatestats-relayprotocol
This change will allow us to have custom logic and members
per interface type. Relay candidates will have a completely different
read loop, and candidate specific state.
Relates to #47
Some constants were being incorrectly generated using 2^N (XOR)
instead of 1 << N. This resulted in incorrect candidate priorities
being used to evaluate candidate pairs.
Resolves#14.
