Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)
obsoletes
Extracted elements (30)
The 'remote-candidates' attribute exists to eliminate a race condition: after the controlling agent nominates a pair, an updated offer may reach the answerer before the STUN Binding response confirming the pair is valid. Including the selected remote candidates in the offer lets the answerer wait to confirm validity before answering.
The role-conflict resolution mechanism is needed because in third-party call control flows (e.g., RFC 3725 flow III variant), both agents receive offerless INVITEs and respond with offers, causing both to believe they are the controlling agent. The tie-breaking procedures in RFC 8445 resolve this.
The updated offer after ICE completion is required not because the agents themselves need new information — they already agreed on candidates — but because off-path components (ALGs, SBCs, QoS tools, diagnostic monitors) rely on the SDP 'c='/'m=' lines to reflect where media is actually flowing.
ICE works through an ALG only if the ALG correctly handles the SDP. An SBC acting as a proper B2BUA will strip unknown ICE attributes, causing ICE to be disabled. If an SBC passes ICE attributes but modifies the default media destination, an ICE mismatch is detected and ICE is aborted.
When ICE is used with SIP forking, a single offer may produce multiple answers. ICE proceeds independently for each offer/answer pair with its own candidates, checklists, and state. The connectivity checks' username fragments correlate media streams to the specific callee.
After nomination, the connection address, port, and transport protocol in each 'c=' and 'm=' line MUST match the nominated pair. The controlling agent MUST include the 'remote-candidates' attribute for each data stream in the Completed state, listing remote candidates of each nominated pair.
All ICE agents MUST follow Section 11 of RFC 8445 for sending keepalives, regardless of whether the data stream is inactive, sendonly, recvonly, or sendrecv, and regardless of the bandwidth attribute.
An agent compliant with this specification MUST include an SDP 'ice-options' attribute with an 'ice2' attribute value. If a peer does not include 'ice2', the agent can assume the peer is compliant to RFC 5245.
An agent generating local candidates MUST NOT use FQDN addresses. An agent processing remote candidates MUST ignore 'candidate' lines that include FQDNs or unrecognized IP address versions.
An ICE-lite implementation MUST include an SDP 'ice-lite' attribute; a full implementation MUST NOT include that attribute.
If the answer does not indicate ICE support, or includes 'ice-mismatch' for all active data streams, the offerer MUST terminate ICE for the entire session and fall back to RFC 3264 procedures. If only some streams have 'ice-mismatch', ICE MUST be terminated only for those streams.
Once an agent has provided local candidates to its peer in an offer or answer, the agent MUST be prepared to receive STUN connectivity check Binding requests on those candidates.
Presence of 'ice-mismatch' in an answer for a data stream implies both agents support ICE but ICE procedures MUST NOT be used for that stream, and RFC 3264 procedures MUST be used instead; the answerer MUST also omit 'candidate' attributes for that stream.
The 'ice-ufrag' attribute MUST NOT be longer than 32 characters when sending (for STUN username attribute compatibility), but an implementation MUST accept up to 256 characters when receiving. The 'ice-ufrag' and 'ice-pwd' MUST be chosen randomly at the start of a session.
To restart ICE, an agent MUST change both the 'ice-pwd' and the 'ice-ufrag' for the data stream in an offer. Implementations MUST NOT use setting the connection address to '0.0.0.0'/'::' for call hold; instead MUST use 'inactive' and 'sendonly'.
When generating the initial answer accepting ICE, the answerer MUST include 'candidate' attributes for each available candidate, plus 'ice-ufrag', 'ice-pwd', and 'ice-options' with 'ice2'. The answerer MUST use the same transport protocol as the offer 'm=' line.
When generating the initial offer, in each 'm=' section the offerer MUST include SDP 'candidate' attributes for each available candidate, and MUST include 'ice-ufrag', 'ice-pwd', and 'ice-options' with 'ice2'. A full ICE implementation SHOULD include 'ice-pacing'; a lite implementation MUST NOT.
Component IDs in ICE candidates are positive integers starting at 1. For RTP-based streams, the RTP media component MUST have component-id 1 and the RTCP component MUST have component-id 2.
The 'ice-options' attribute (session- and media-level) carries a space-separated list of ice-option-tags indicating extensions the agent supports. The 'ice2' tag signals compliance with RFC 8445. Extensions are negotiated bilaterally.
The 'ice-pacing' session-level attribute indicates the desired Ta connectivity-check pacing interval in milliseconds. Default is 50 ms. Both agents use the larger of the two indicated values. Lite implementations MUST NOT include this attribute.
RFC 8839 establishes a 'Candidate Attribute Extensions' subregistry under SDP Parameters. Extensions must use the 'cand-extension' syntax and are registered under the Specification Required policy with name, change control contact, description, and specification reference.
RFC 8839 maintains the ICE Options Registry (Specification Required policy) for 'ice-options' identifiers. Option tags are RECOMMENDED to be no longer than 20 characters. Registrations must include the option identifier, change control contact, a short description, and specification references.
RFC 8839 updates the IANA SDP Attributes registry with eight ICE-related attributes: 'candidate' (media-level, Mux: TRANSPORT), 'remote-candidates' (media-level, TRANSPORT), 'ice-lite' (session-level, NORMAL), 'ice-mismatch' (media-level, NORMAL), 'ice-pwd' (session/media, TRANSPORT), 'ice-ufrag' (session/media, TRANSPORT), 'ice-options' (session-level, NORMAL), and 'ice-pacing' (session-level, NORMAL).
An attacker who can modify offer/answer exchanges can direct media to a DoS target or insert themselves into a data stream. TLS transport for SIP signaling is RECOMMENDED to protect offer/answer integrity and confidentiality.
For privacy, an agent MAY conceal the related address and port in a candidate by setting the address to '0.0.0.0' (IPv4) or '::' (IPv6) and the port to '9', rather than revealing the true base address.
The voice hammer attack is an amplification attack in which a malicious participant includes a victim's address as the media destination. ICE mitigates this by requiring connectivity checks to succeed before media is sent; a third-party target will fail the checks. RFC 7675 (STUN consent freshness) provides additional protection.
ICE concludes when each checklist reaches Completed or Failed. The controlling agent sends an updated offer to align 'c='/'m=' lines with the nominated pair if needed. Failed checklists require a subsequent offer to remove the stream (port set to zero).
The 'candidate' attribute encodes: foundation (1–32 ice-chars), component-id (1–3 DIGIT), transport (UDP or extension), priority (1–10 DIGIT), connection-address, port, cand-type (host/srflx/prflx/relay), optional rel-addr and rel-port, and optional name/value extensions.
The 'ice-pwd' attribute encodes a password of 22 to 256 ice-chars (at least 128 bits of randomness); the 'ice-ufrag' attribute encodes a fragment of 4 to 256 ice-chars (at least 24 bits of randomness), where ice-char = ALPHA / DIGIT / '+' / '/'.
The 'remote-candidates' attribute is a media-level attribute encoding one or more 'component-id SP connection-address SP port' tuples. A value MUST be present for each component of the data stream.