A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)
updated by
- rfc-9725 — WebRTC-HTTP Ingestion Protocol (WHIP)
Extracted elements (30)
Each INFO request cumulatively includes all candidates from previous INFO requests so that candidate ordering is preserved end-to-end per RFC 8838 requirements, and so that message loss or reordering (detectable via CSeq) does not cause candidates to be missed by the ICE implementation.
In-dialog INFO messages were preferred over out-of-dialog alternatives (e.g., SUBSCRIBE/NOTIFY) because they guarantee end-to-end delivery between the exact entities initiating the session without requiring GRUU support, which has seen low adoption levels.
SIP INFO requests were chosen over UPDATE/Offer-Answer for candidate transport because INFO messages decouple candidate exchange from Offer/Answer negotiation, avoiding glare issues (where simultaneous Offers invalidate each other with up to 4-second backoff) and the sequential blocking nature of Offer/Answer defined in RFC 3264.
A Full Trickle Offerer may initially send only RTP candidates (component 1) assuming RTCP multiplexing is supported, and only start gathering RTCP candidates (component 2) after receiving an Answer indicating the Answerer does not support RTCP multiplexing.
An Offerer assuming Trickle ICE support MUST include a SIP Require: trickle-ice header field so that if the assumption is incorrect, the failure is operationally trackable and recoverable by resending without the Require header.
Middleboxes that monitor SIP sessions must remain in the signaling path of INFO requests and understand the 'application/trickle-ice-sdpfrag' body, since Trickle ICE uses INFO in addition to Offer/Answer for candidate exchange.
When none of the Trickle ICE discovery mechanisms are applicable, SIP UAs should use Half Trickle mode, where the first Offer contains a complete set of ICE candidates. Half Trickle Offers are compatible with both ICE SIP endpoints (RFC 8839) and legacy endpoints (RFC 3264), and once a single Offer/Answer is exchanged Full Trickle can be used thereafter.
Agents initiating Trickle ICE without an SDP Answer (via provisional response without Answer) MUST retransmit these responses with exponential backoff timers per RFC 3262, ceasing on receipt of an in-dialog request or on transmission of the 2xx Answer.
All INFO requests MUST carry the 'ice-pwd' and 'ice-ufrag' attributes. An agent MUST discard any received INFO requests containing 'ice-pwd' and 'ice-ufrag' attributes that do not match those of the current ICE Negotiation Session.
An agent MUST include all currently known and used local candidates in every INFO request, repeating previously sent candidates in the same order. Newly gathered candidates MUST be added at the end of that list.
An implementation MUST aggregate ICE candidates when an unreliable transport protocol such as UDP is used, and a Trickle ICE Agent MUST NOT have more than one INFO request pending at any one time.
Candidates that have been exchanged using INFO requests SHALL be included in subsequent Offers or Answers, and the version number in the 'o=' line of the subsequent Offer needs to be incremented by 1 per RFC 3264 rules.
In case of a 'm/c=' line with default values, none of the eventually trickled candidates will match the default destination. This situation MUST NOT cause an ICE mismatch.
Retransmissions of unreliable provisional responses MUST cease on receipt of an INFO request carrying a 'trickle-ice' Info Package body, on receipt of any other in-dialog request from the Offerer, or on transmission of the Answer in a 2xx response.
SIP entities that support this specification MUST place the 'trickle-ice' option-tag in a SIP Supported: or Require: header field within all SIP INVITE requests and responses, and also in responses to or generation of SIP OPTIONS requests.
The Offerer MUST include the 'ice-options:trickle' attribute and MUST include a 'mid' attribute in each 'm=' line of the initial Offer. If sending an Offer before knowing candidates for a media description, the port MUST be set to the default value '9'.
Trickle ICE Agents MUST indicate support for Trickle ICE by including the ice-option 'trickle' within all SDP Offers and Answers in accordance with RFC 8838.
When an Answerer sends an Answer in an unreliable provisional response, the Offerer MUST send a Trickle ICE INFO request as soon as it receives that Answer; this INFO request MUST repeat the candidates that were already provided in the Offer.
When receiving INFO requests, agents MUST first identify and discard candidates already received in previous INFO requests or in the Offer/Answer exchange, then MUST forward new candidates to the ICE Agents in the same order as received.
When sending the Answer in the 200 OK response to the INVITE, the Answerer MUST repeat exactly the same Answer that was previously sent in the unreliable provisional response. The Offerer MUST ignore the candidate information in that 200 OK response.
When the Offerer has no candidates for a media description and omits the host IP, it MUST NOT include the 'rtcp' attribute to avoid potential ICE mismatch for the RTCP transport address.
Pseudo 'm=' lines are used in 'application/trickle-ice-sdpfrag' bodies to link candidate attributes to specific media descriptions via 'mid' attribute identification tags. Receivers MUST ignore any remaining content of the pseudo 'm=' line not defined in this document.
The SDP 'end-of-candidates' attribute is a property attribute (no value) that, when included by a sending agent in an Offer, Answer, or INFO request, indicates it will not trickle further candidates. It applies to the whole session at session level or to the corresponding media description at media level.
The 'trickle-ice' Info Package is defined for use with SIP INFO requests to carry ICE candidates. INFO requests carry an 'Info-Package: trickle-ice' header and a body of type 'application/trickle-ice-sdpfrag'.
This document registers the media type 'application/trickle-ice-sdpfrag' (type: application, subtype: trickle-ice-sdpfrag, text content following SDP grammar subset defined in Section 9.2) for use exclusively by the 'trickle-ice' Info Package.
This document registers the SDP 'end-of-candidates' attribute (property attribute, no value, media and session level, Mux Category: IDENTICAL) in the SDP Parameters registry.
This document registers the SIP Info Package named 'trickle-ice' in the Info Packages Registry, and the SIP option tag 'trickle-ice' in the Option Tags subregistry of the SIP Parameters registry to indicate UA support and understanding of Trickle ICE.
The security considerations of RFC 6086 (SIP INFO), RFC 8838 (Trickle ICE), and RFC 8839 (ICE SDP Offer/Answer) all apply. The new Info Package 'trickle-ice' and the media type 'application/trickle-ice-sdpfrag' do not introduce additional security considerations beyond those specifications when used in the Trickle ICE context.
Trickling can begin only when two conditions are met: (1) Trickle ICE support at the peer agent is confirmed, and (2) a dialog has been created between the peers. For reliable provisional responses with PRACK, both conditions are satisfied immediately; for unreliable responses, the Answerer must wait for an INFO request from the Offerer to confirm the early dialog is established at both ends.
The 'application/trickle-ice-sdpfrag' body grammar (ABNF) consists of session-level fields (ice-pwd, ice-ufrag, ice-options, ice-pacing, end-of-candidates, bundle-group, extension attributes) followed by pseudo media descriptions containing mid, candidate, remote-candidate, end-of-candidates, rtcp, rtcp-mux, and rtcp-mux-only attributes.