ICE candidate attribute (a=candidate:) advertising a reachable transport address.
What problem this solves
ICE candidates in SDP tell peers which IP/port combinations to test for
connectivity through NAT. Each a=candidate: line must become structured
fields (priority, type, foundation) for trickle ICE and answer generation.
Candidates are gathered locally or via STUN/TURN and exchanged in SDP so peers can run ICE connectivity checks and pick a working path through NAT.
Wire form follows RFC 8445 candidate syntax.
RFCs
Summary
Types
@type t() :: %XMediaLib.SDP.Candidate{ component_id: non_neg_integer(), foundation: String.t(), ip: String.t(), port: non_neg_integer(), priority: non_neg_integer(), rest: String.t() | nil, transport: String.t(), type: String.t() }
Parsed ICE candidate fields.
Fields
:foundation- stable id grouping related candidates:component_id- RTP (1) or RTCP (2) component when not muxed:transport- lower-layer protocol, usuallyudportcp:priority- ICE priority for pair ordering:ip- candidate IP address:port- candidate port:type-host,srflx,prflx, orrelay:rest- unparsed trailing tokens (extensions, related address, etc.)