RFC 8840
A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)
RFC 8840 💖 Trickle ICE over SIP, aka the "don't make me wait" protocol ✨
Bestie, the title block is giving important energy 📋 This was published by the IETF in January 2021 as a Standards Track document (ISSN 2070-1721). The authors are E. Ivov (Jitsi), T. Stach (Unaffiliated), E. Marocco (Telecom Italia), and C. Holmberg (Ericsson). The full title is "A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)" 🦋 The title block doesn't list anything it obsoletes or updates.
Abstract 🌸
Okay so ICE is the NAT traversal mechanism for UDP-based multimedia sessions that get set up with the Offer/Answer model 🔥 Trickle ICE is the extension that makes the whole thing faster. ICE Agents can stop blocking each other: candidate gathering and connectivity checking run non-blocking and in parallel, so session setup takes way less time ⚡
This document explains how to use Trickle ICE with the Session Initiation Protocol (SIP) 📞 It also defines a new SIP Info Package, plus its media type, to support this. On top of that, there's a new Session Description Protocol (SDP) end-of-candidates attribute and a new SIP option tag, trickle-ice 💅
Status of This Memo 🧾
This is an Internet Standards Track document. ✨ It's a product of the Internet Engineering Task Force (IETF), it reflects the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication. You can find more on Internet Standards in Section 2 of RFC 7841 🎀
For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8840 🔍
Copyright Notice 🫶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💜
Table of Contents 🗂️
1. Introduction
2. Terminology
3. Protocol Overview
3.1. Discovery Issues
3.2. Relationship with the Offer/Answer Model
4. Incremental Signaling of ICE Candidates
4.1. Initial Offer/Answer Exchange
4.1.1. Sending the Initial Offer
4.1.2. Receiving the Initial Offer
4.1.3. Sending the Initial Answer
4.1.4. Receiving the Initial Answer
4.2. Subsequent Offer/Answer Exchanges
4.3. Establishing the Dialog
4.3.1. Establishing Dialog State through Reliable Offer/Answer
Delivery
4.3.2. Establishing Dialog State through Unreliable Offer/
Answer Delivery
4.3.3. Initiating Trickle ICE without an SDP Answer
4.4. Delivering Candidates in INFO Requests
5. Initial Discovery of Trickle ICE Support
5.1. Provisioning Support for Trickle ICE
5.2. Trickle ICE Discovery with Globally Routable User Agent
URIs (GRUUs)
5.3. Fall Back to Half Trickle
6. Considerations for RTP and RTCP Multiplexing
7. Considerations for Media Multiplexing
8. SDP "end-of-candidates" Attribute
8.1. Definition
8.2. Offer/Answer Procedures
9. Content Type "application/trickle-ice-sdpfrag"
9.1. Overall Description
9.2. Grammar
10. Info Package
10.1. Rationale -- Why INFO?
10.2. Overall Description
10.3. Applicability
10.4. Info Package Name
10.5. Info Package Parameters
10.6. SIP Option Tags
10.7. INFO Request Body Parts
10.8. Info Package Usage Restrictions
10.9. Rate of INFO Requests
10.10. Info Package Security Considerations
11. Deployment Considerations
12. IANA Considerations
12.1. SDP "end-of-candidates" Attribute
12.2. Media Type "application/trickle-ice-sdpfrag"
12.3. SIP Info Package "trickle-ice"
12.4. SIP Option Tag "trickle-ice"
13. Security Considerations
14. References
14.1. Normative References
14.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🚀
The Interactive Connectivity Establishment (ICE) protocol [RFC8445] is the NAT traversal mechanism we're talking about, and it has three main phases 🧩
In the first phase, an agent gathers a set of candidate transport addresses (source IP, port, and transport protocol) 🔎 Next, those candidates get sent to a remote agent inside the Session Description Protocol (SDP) body of a SIP message. The remote agent repeats the gathering procedure and sends its candidates back to the first agent 💌 Then comes the third phase, which starts in parallel: connectivity between all candidates in both sets gets checked (connectivity checks). Only once all of that is done, and not one moment before, can both agents start talking 🫠
According to [RFC8445], those three phases happen one after another in a blocking way, and that can add annoying setup delay 😭 That's where the Trickle ICE extension [RFC8838] comes in. It defines the generic semantics needed for these phases to run in parallel and without blocking, which speeds up session establishment 🏎️💨
This specification shows how to use Trickle ICE with the Session Initiation Protocol (SIP)[RFC3261] 🎀 It explains how ICE candidates get exchanged bit by bit using SIP INFO requests [RFC6086], and how SIP User Agents (UAs) should use the Half Trickle and Full Trickle modes defined in [RFC8838], depending on whether they expect the remote agent to support Trickle ICE 🦋
This document also defines a new Info Package, as specified in [RFC6086], for use with Trickle ICE. It comes with its corresponding media type, SDP attribute, and SIP option tag 💜
2. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🔐 Basically, the words only count as formal requirements when they're written in all caps, so keep an eye out for that 👀
This spec uses terminology defined by the ICE protocol in [RFC8445] and by its Trickle ICE extension in [RFC8838]. It assumes you're already familiar with the terms from both documents 🧠
[RFC8445] also explains how ICE uses the Session Traversal Utilities for NAT (STUN) protocol [RFC5389] and its extension, Traversal Using Relays around NAT (TURN) [RFC5766] 🛰️
3. Protocol Overview 🗺️
When you use ICE for SIP following [RFC8839], the ICE candidates get exchanged only through SDP Offer/Answer, as per [RFC3264] 📨 This specification adds another mechanism: candidates can be sent in SIP INFO messages using a newly defined Info Package [RFC6086]. That means ICE candidates can go out in parallel with an ongoing Offer/Answer negotiation, or after the Offer/Answer negotiation is already finished 🫶
Typically, when Trickle ICE is fully supported, the Offerer sends an INVITE request with a subset of candidates in it. Once an early dialog is established, the Offerer keeps sending candidates in INFO requests within that dialog 💅
The Answerer can do the same thing: it sends ICE candidates using INFO requests within the dialog created by its 18x provisional response 🍓 Figure 1 shows what that looks like:
STUN/TURN STUN/TURN
Servers Alice Bob Servers
| | | |
| STUN Bi.Req. | INVITE (Offer) | |
|<--------------|------------------------>| |
| | 183 (Answer) | TURN Alloc Req |
| STUN Bi.Resp. |<------------------------|--------------->|
|-------------->| INFO/OK (SRFLX Cand.) | |
| |------------------------>| TURN Alloc Resp|
| | INFO/OK (Relay Cand.) |<---------------|
| |<------------------------| |
| | | |
| | More Cands & ConnChecks| |
| |<=======================>| |
| | | |
| | 200 OK | |
| |<------------------------| |
| | ACK | |
| |------------------------>| |
| | | |
| |<===== MEDIA FLOWS =====>| |
| | | |
Note: "SRFLX" denotes server-reflexive candidates
Figure 1: Sample Trickle ICE Scenario with SIP3.1. Discovery Issues 🔍
okay so, to get the full magic of Trickle ICE and cut session establishment latency down to basically nothing 💨, Trickle ICE Agents need to generate SDP Offers and Answers that contain incomplete and potentially empty sets of candidates. The catch is that only agents that actually support incremental candidate provisioning can handle those meaningfully, so you have to confirm that support before you start using it 🫶
Unlike other protocols, where "in advance" capability discovery is widely implemented, the mechanisms that allow this for SIP (a combo of UA capabilities [RFC3840] and Globally Routable User Agent URIs (GRUUs) [RFC5627]) have only seen low levels of adoption 😭. That's a problem for Trickle ICE implementations, because SIP UAs don't have an obvious way to check whether their peer will support incremental candidate provisioning 💀
The Half Trickle mode of operation defined in the Trickle ICE specification [RFC8838] is one way around this 🌸. It requires the first Offer to contain a complete set of local ICE candidates, and then only uses incremental provisioning of remote candidates for the rest of the session.
Half Trickle totally works, but it comes with increased latency 🙈. So Section 5 has some alternatives that let SIP UAs engage in Full Trickle right from their first Offer ✨. Section 5.1 discusses online provisioning as a way to use Trickle ICE for all endpoints in controlled environments. Section 5.2 describes anticipatory discovery for implementations that actually do support GRUU and UA capabilities, and Section 5.3 discusses implementing and using Half Trickle by SIP UAs where none of the above are an option 💅
3.2. Relationship with the Offer/Answer Model 🦋
From the point of view of SIP middleboxes and proxies, the Offer/Answer exchange for Trickle ICE looks partly similar to the Offer/Answer exchange for regular ICE for SIP [RFC8839]. But to get the full picture of the candidate exchange, you also have to consider the newly introduced INFO messages 👀
+-------------------------------+ +-------------------------------+
| Alice +--------------+ | | +--------------+ Bob |
| | Offer/Answer | | | | Offer/Answer | |
| +--------+ | Module | | | | Module | +--------+ |
| | ICE | +--------------+ | | +--------------+ | ICE | |
| | Module | | | | | | Module | |
| +--------+ | | | | +--------+ |
+-------------------------------+ +-------------------------------+
| | | |
| | INVITE (Offer) | |
| |--------------------->| |
| | 183 (Answer) | |
| |<---------------------| |
| | | |
| |
| SIP INFO (more candidates) |
|----------------------------------------------------->|
| SIP INFO (more candidates) |
|<-----------------------------------------------------|
| |
| STUN Binding Requests/Responses |
|----------------------------------------------------->|
| STUN Binding Requests/Responses |
|<-----------------------------------------------------|
| |
Figure 2: Distinguishing between Trickle ICE and Traditional
SignalingHere's the architecture vibe 🧠. As in Figure 2, exchanging candidates through SIP INFO requests can be represented as signaling between ICE modules, not between the Offer/Answer modules of SIP UAs. That means the INFO requests don't change the state of the Offer/Answer transaction beyond handing over extra candidates. So INFO requests are not considered Offers or Answers. Still, candidates that have been exchanged using INFO requests SHALL be included in subsequent Offers or Answers ⭐. The version number in the o= line of that subsequent Offer needs to be incremented by 1 per the rules in [RFC3264] 🔥
4. Incremental Signaling of ICE Candidates 🎀
Trickle ICE Agents will exchange ICE descriptions compliant to [RFC8838] via Offer/Answer procedures and/or INFO request bodies. This needs the following SIP-specific extensions 🧚
- Trickle ICE Agents MUST indicate support for Trickle ICE by including the SIP option-tag
trickle-icein a SIPSupported:header field within all SIP INVITE requests and responses. - Trickle ICE Agents MUST indicate support for Trickle ICE by including the ice-option
tricklewithin all SDP Offers and Answers in accordance to [RFC8838]. - Trickle ICE Agents MAY include any number of ICE candidates, i.e., from zero to the complete set of candidates, in their initial Offer or Answer. If the complete candidate set is already included in the initial Offer, it is called Half Trickle 🍓
- Trickle ICE Agents MAY exchange additional ICE candidates using INFO requests within an existing INVITE dialog usage (including an early dialog) as specified in [RFC6086]. The INFO requests carry an
Info-Package: trickle-ice. Trickle ICE Agents MUST be prepared to receive INFO requests within that same dialog usage, containing additional candidates and/or an indication that trickling of such candidates has ended 🌈 - Trickle ICE Agents MAY exchange additional ICE candidates before the Answerer has sent the Answer, provided that an invite dialog usage is established at both Trickle ICE Agents. Note that in case of forking, multiple early dialogs may exist 🍀
The following sections give you the details on how Trickle ICE Agents do the initial Offer/Answer exchange (Section 4.1), do subsequent Offer/Answer exchanges (Section 4.2), and establish the INVITE dialog usage (Section 4.3) so they can incrementally trickle candidates (Section 4.4) 💖
4.1. Initial Offer/Answer Exchange 🌷
4.1.1. Sending the Initial Offer 📤
If the Offerer includes candidates in its initial Offer, it MUST encode these candidates as specified in [RFC8839] ✍️
If the Offerer wants to send its initial Offer before knowing any candidate for one or more media descriptions, it MUST set the port to the default value 9 for these media descriptions. If the Offerer does not want to include the host IP address in the corresponding "c="line, e.g., due to privacy reasons, it SHOULD include a default address in the "c="line, which is set to the IPv4 address 0.0.0.0 or to the IPv6 equivalent :: 🙈
In this case, the Offerer obviously can't know the RTP Control Protocol (RTCP) transport address, so it MUST NOT include the rtcp attribute [RFC3605]. This avoids potential ICE mismatch (see [RFC8839]) for the RTCP transport address 🛡️
If the Offerer wants to use RTCP multiplexing [RFC5761] and/or exclusive RTCP multiplexing [RFC8858], it still will include the rtcp-mux and/or rctp-mux-only attribute in the initial Offer 🎶
In any case, the Offerer MUST include the ice-options:trickle attribute in accordance to [RFC8838] and MUST include in each m= line a mid attribute in accordance to [RFC5888]. The mid attribute identifies the m= line that a candidate belongs to, and it helps when there are multiple m= lines, since candidate gathering could happen in a different order than the order of the m= lines 🧩
4.1.2. Receiving the Initial Offer 📥
If the initial Offer included candidates, the Answerer uses these candidates to start ICE processing as specified in [RFC8838] 🚀
If the initial Offer included the ice-options:trickle attribute, the Answerer MUST be prepared for receiving trickled candidates later on 👀
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 (see [RFC8839]) 💅
4.1.3. Sending the Initial Answer 📤
If the Answerer includes candidates in its initial Answer, it MUST encode these candidates as specified in [RFC8839] ✍️
If the Answerer wants to send its initial Answer before knowing any candidate for one or more media descriptions, it MUST set the port to the default value 9 for these media descriptions. If the Answerer does not want to include the host IP address in the corresponding "c="line, e.g., due to privacy reasons, it SHOULD include a default address in the "c="line, which is set to the IPv4 address 0.0.0.0 or to the IPv6 equivalent :: 🙈
In this case, the Answerer obviously can't know the RTCP transport address, so it MUST NOT include the rtcp attribute [RFC6086]. This avoids potential ICE mismatch (see [RFC8839]) for the RTCP transport address 🛡️
If the Answerer accepts the use of RTCP multiplexing [RFC5761] and/or exclusive RTCP multiplexing [RFC8858], it will include the rtcp-mux attribute in the initial Answer 🎶
In any case, the Answerer MUST include the ice-options:trickle attribute in accordance to [RFC8838] and MUST include in each m= line a mid attribute in accordance to [RFC5888] 🧩
4.1.4. Receiving the Initial Answer 📥
If the initial Answer included candidates, the Offerer uses these candidates to start ICE processing as specified in [RFC8838] 🚀
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 (see [RFC8839]) 💅
4.2. Subsequent Offer/Answer Exchanges 🔁
Subsequent Offer/Answer exchanges are handled the same as regular ICE (see Section 4.4 of [RFC8839]) 🙌
If an Offer or Answer needs to be sent while the ICE Agents are in the middle of trickling, Section 4.4 of [RFC8839] applies. This means that an ICE Agent includes candidate attributes for all local candidates it had trickled previously for a specific media stream 🫶
4.3. Establishing the Dialog 🤝
In order to be able to start trickling, the following two conditions need to be satisfied at the SIP UAs:
- Trickle ICE support at the peer agent MUST be confirmed.
- A dialog MUST have been created between the peers.
Section 5 goes into detail on the various options for satisfying the first of the above conditions. However, regardless of those mechanisms, agents are certain to have a clear understanding of whether their peers support trickle ICE once an Offer and an Answer have been exchanged, which also lets ICE processing commence (see Figure 3) ✨
4.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery ✨
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| PRACK/OK |
|------------------------>|
| |
+----------------------------------------+
|Alice and Bob know that both can trickle|
|and know that the dialog is in the early|
|state. Send INFO! |
+----------------------------------------+
| |
| INFO/OK (+SRFLX Cand.) |
|------------------------>|
| INFO/OK (+SRFLX Cand.) |
|<------------------------|
| |
Note: "SRFLX" denotes server-reflexive candidates
Figure 3: A SIP Offerer can freely trickle as soon as it receives
an AnswerOkay so, look at Figure 3 🦋 Alice sends an Offer in an INVITE, Bob answers in a reliable provisional response, and then Alice sends her PRACK/OK. Now they both know the other side can trickle and that the dialog is still in the early state, so it's INFO time 💅. The way this just works is giving me so much joy, no cap.
Satisfying both of those conditions is honestly pretty trivial for ICE Agents that sent an Offer in an INVITE and got an Answer in a reliable provisional response 🎀. It's guaranteed that they've confirmed Trickle ICE support (or the lack of it) at the Answerer, and that the SIP dialog is fully set up at both ends 🫶. So Offerers and Answerers (once the PRACK request has been received) can freely start trickling inside the brand new dialog. Iconic. 👑
4.3.2. Establishing Dialog State through Unreliable Offer/Answer Delivery
It gets a bit more delicate for agents that got an Offer in an INVITE request and sent an Answer in an unreliable provisional response 😭. Once that response is sent, the Answerer has no idea when it's been received, or if it's been received at all (Figure 4).
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| |
| +----------------------+
| |Bob: I don't know if |
| |Alice got my 183 or if|
| |her dialog is already |
| |in the early state. |
| | Can I send INFO??? |
| +----------------------+
| |
Figure 4: A SIP UA that sent an Answer in an unreliable
provisional response does not know if it was received or if the
dialog at the side of the Offerer has entered the early stateTo clear up this confusion as fast as possible 🙈, the Answerer has to retransmit the provisional response using the exponential backoff timers from [RFC3262]. These retransmissions MUST cease once an INFO request carrying a "trickle-ice" Info Package body arrives, once any other in-dialog request arrives from the Offerer, or once the Answer goes out in a 2xx response. The Offerer can't send in-dialog requests until it has received a response, so if one of those requests shows up, that proves the response got there 🧚. Using the INFO request for dialog confirmation works a lot like the procedure in Section 7.1.1 of [RFC8839]. The only difference is that the STUN binding request gets swapped out for the INFO request.
The Offerer MUST send a Trickle ICE INFO request as soon as it gets an SDP Answer in an unreliable provisional response. This INFO request MUST repeat the candidates that were already given in the Offer (like when Half Trickle is done, or when no new candidates have been learned since then) 🍓. The first case can happen when Half Trickle is used and every candidate is already in the initial offer. The second case can happen when Full Trickle is used and the Offerer is still gathering more candidates but hasn't got them yet. Also, if the initial Offer had no candidates at all, this INFO could still have zero candidates, depending on how the Offerer gathers them and how long that takes ⏳.
When Full Trickle is used and newly learned candidates are available, the Offerer SHOULD also deliver those candidates in that INFO request. The exception is if it wants to hold some back in reserve, for example because they're expensive to use and should only be trickled if everything else fails 💸.
The Offerer SHOULD include an "end-of-candidates" attribute if candidate discovery has ended in the meantime and nothing else will be trickled 🏁.
As soon as an Answerer gets an INFO request like this, it knows the dialog is established at both ends, and trickling can begin 🌸 (Figure 5).
Note that the "+SRFLX" in Figure 5 means additional newly learned server-reflexive candidates are included. 💜
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| INFO/OK (+SRFLX Cand.) |
|------------------------>|
| |
| +----------------------+
| |Bob: Now I know Alice|
| | is ready. Send INFO! |
| +----------------------+
| INFO/OK (+SRFLX Cand.) |
|<------------------------|
| |
| 200/ACK (Answer) |
|<------------------------|
Note: "SRFLX" denotes server-reflexive candidates
Figure 5: A SIP UA that received an INFO request after sending an
unreliable provisional response knows that the dialog at the side
of the receiver has entered the early stateWhen the Answer goes out in the 200 OK response to the INVITE request, the Answerer has to repeat exactly the same Answer it sent earlier in the unreliable provisional response 📜. That's how it meets the requirements in [RFC3264]. So the Offerer needs to be ready for a different number of candidates in that repeated Answer than what was swapped earlier through trickling. The Offerer MUST ignore the candidate information in that 200 OK response. Main character energy, but for the Offerer, it's ignore-and-move-on 🙅♀️✨.
4.3.3. Initiating Trickle ICE without an SDP Answer
Being able to put arbitrary candidates in INFO message bodies means ICE Agents can start trickling without actually sending an Answer 🦋. So Trickle ICE Agents can answer an INVITE request with provisional responses that have no SDP Answer, see [RFC3261]. These provisional responses are what set up an early dialog 🎀.
Agents that go this route MUST retransmit these responses using the exponential backoff timers from [RFC3262]. Those retransmissions MUST cease once an INFO request with a "trickle-ice" Info Package body arrives, once any in-dialog request arrives from the Offerer, or once the Answer goes out in a 2xx response. The Offerer can't send in-dialog requests until it has received a response, so if one of those requests arrives, it proves the response made it 💖. This is again similar to the procedure in Section 6.1.1 of [RFC8839], except that no Answer has been provided yet.
Note that the "+SRFLX" in Figure 6 means additional newly learned server-reflexive candidates are included. 🌈
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (-) |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|------------------------>|
| |
| +----------------------+
| |Bob: Now I know again|
| | that Alice is ready. |
| | Send INFO! |
| +----------------------+
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| 183 (Answer) opt. |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| 200/ACK (Answer) |
|<------------------------|
Note: "SRFLX" denotes server-reflexive candidates
Figure 6: A SIP UA sends an unreliable provisional response
without an Answer for establishing an early dialogWhen the agent sends the Answer, it MUST repeat all of the candidates it currently knows about and uses, if there are any 🍓. It MAY also include all the newly gathered candidates since the last INFO request was sent. But if that Answer already went out in an unreliable provisional response, the Answerers MUST repeat exactly the same Answer in the 200 OK response to the INVITE request, so the requirements in [RFC3264] stay happy 🫶. If trickling kept going, the Offerer needs to be ready for fewer candidates in that repeated Answer than what was already traded through trickling, and it MUST ignore the candidate information in that 200 OK response 💅. Lowkey the most dramatic part of the whole flow, but it all makes sense now. 🔥
4.4. Delivering Candidates in INFO Requests 📬
Okay bestie, whenever new ICE candidates become available for sending, agents wrap them up as "candidate" attributes, as described in [RFC8839]. For example:
a=candidate:1 1 UDP 2130706432 200a0b:12f0::1 5000 typ hostSIP INFO requests happen inside the Info Package from Section 10 💌 The media type [RFC6838] for their payload MUST be set to "application/trickle-ice-sdpfrag" as defined in Section 9 📦 and the INFO request body follows the grammar in Section 9.2 🧾
Here's the tricky bit 🥺 Neither the "candidate" nor the "end-of-candidates" attributes say which "m=" line they belong to. So we use pseudo "m=" lines to fix that 🪄
Pseudo "m=" lines follow the SDP syntax for "m=" lines from [RFC4566], and they link back to the real "m=" line in the SDP Offer or Answer through the identification tag in a "mid" attribute [RFC5888] 🔗 A pseudo "m=" line has no meaning beyond telling you which "m=" line a candidate is for, so the receiving agent MUST ignore any leftover content on it that this document doesn't define. That's how we make sure the "application/trickle-ice-sdpfrag" bodies don't mess with the Offer/Answer procedures in [RFC3264] 🙅♀️
When sending the INFO request, the agent MAY include the same content on the pseudo "m=" line that's on the matching "m=" line in the Offer or Answer, but only if it already knows that content. Trickle ICE can be decoupled from Offer/Answer, so sometimes the agent just doesn't know it. In that case, the agent MUST include these default values:
- The media field is set to 'audio'.
- The port value is set to '9'.
- The proto value is set to 'RTP/AVP'.
- The fmt field MUST appear only once and is set to '0'.
Agents MUST include a pseudo "m=" line and an identification tag in a "mid" attribute for every "m=" line whose candidate list they want to update 🎯 Those "mid" attributes MUST immediately precede the list of candidates for that specific "m=" line.
All "candidate" or "end-of-candidates" attributes that come after a "mid" attribute, up until (but not including) the next pseudo "m=" line, belong to the "m=" line that the identification tag points to 🫶
Also, the INFO request body does NOT have to have as many pseudo "m=" lines as the Offer/Answer has "m=" lines, and the pseudo "m=" lines don't have to be in the same order as the "m=" lines they belong to. Matching works through the "mid" attributes, because candidates are grouped into sections headed by "pseudo" "m=" lines, and those sections have "mid" values that point back to the real "m=" line 🧩
An "end-of-candidates" attribute that comes before the first pseudo "m=" line means "I'm done trickling, full stop" for the whole agent. That's different from a media-level "end-of-candidates" attribute, which only means "I'm done with this one specific "m=" line" 🛑
Check out Figure 7 for an example of what the INFO request content looks like 👀
The pseudo "m=" lines give you a structure that's a lot like SDP Offers and Answers, where you can tell apart session-level and media-level sections. Here, any lines before the first pseudo "m=" line count as session level, and lines in between or after pseudo "m=" lines get read as media level 🌸
Note that while this specification uses the "mid" attribute from [RFC5888], it does not define any grouping semantics.
All INFO requests MUST carry the "ice-pwd" and "ice-ufrag" attributes, so they can be mapped to one specific ICE generation 🔑 An agent MUST discard any received INFO request whose "ice-pwd" and "ice-ufrag" attributes don't match the ones for the current ICE Negotiation Session 🗑️
The "ice-pwd" and "ice-ufrag" attributes MUST sit at the same level they did in the Offer/Answer exchange. So if they were session-level attributes, they show up at the very beginning of every INFO request payload, before the first pseudo "m=" line. If they were exchanged as media-level attributes (maybe overriding session-level values), they show up in the INFO request payload after the matching pseudo "m=" lines 💅
Now, when candidates get trickled, [RFC8838] says each candidate must be delivered to the receiving Trickle ICE implementation no more than once, and in the same order it was sent. If the signaling protocol retransmits candidates, those retransmissions need to be hidden from the ICE implementation 🙈 Here's how that's handled.
Since the agent doesn't fully know the state of the ICE Negotiation Session at its peer, it MUST include all currently known and used local candidates in every INFO request. Basically, the agent MUST repeat in the INFO request body every candidate that was previously sent under the same combination of "ice-pwd" and "ice-ufrag", in the same order they were sent before. In other words, the order of the previously sent candidate list MUST NOT change in later INFO requests, and newly gathered candidates MUST be added at the end of that list 📋 Yes, repeating everything is extra overhead, but it makes it way easier to deal with problems from unreliable transports, like lost or reordered messages. You can spot those through the CSeq: header field in the INFO request 🕵️♀️
On top of that, an ICE Agent needs to follow Section 17 of [RFC8838] for keeping candidate order while trickling ✨
When receiving INFO requests that carry any candidates, agents MUST first find and discard the attribute lines with candidates they already received, either in earlier INFO requests or in the Offer/Answer exchange before them 🧹
Candidates count as equal if their IP address, port, transport, and component ID are all the same. After discarding the ones they already know, agents MUST pass the actual new candidates to the ICE Agents in the same order they came in the INFO request body. The ICE Agents then process those new candidates using the rules in [RFC8838] 🚀
Receiving an "end-of-candidates" attribute in an INFO request body is the peer saying "I won't send any more candidates." This only counts if the "ice-ufrag" and "ice-pwd" attributes match the current ICE generation 🏁 At the session level (before any pseudo "m=" line), it applies to the whole session. At the media level, it only applies to the matching "m=" line. The handling of these end-of-candidates indications is defined in [RFC8838] 💜
Figure 7 shows what a candidate-delivering INFO request looks like. In this example, the "end-of-candidates" attributes say that candidate gathering is finished and no more INFO requests are coming 🎀
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package
Content-length: 862
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1
a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host
a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host
a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host
a=candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx
raddr 192.0.2.1 rport 8998
a=candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx
raddr 192.0.2.1 rport 8998
a=end-of-candidates
m=audio 9 RTP/AVP 0
a=mid:2
a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host
a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host
a=candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host
a=candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx
raddr 192.0.2.1 rport 9998
a=candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx
raddr 192.0.2.1 rport 9998
a=end-of-candidates
Note: In a real INFO request, there will be no line breaks
in the "candidate" attributes
Figure 7: An Example for the Content of an INFO Request5. Initial Discovery of Trickle ICE Support 🔍
SIP UAs are REQUIRED by [RFC8838] to show that they support Trickle ICE and plan to use it, by putting the "ice-options:trickle" attribute in their Offers and Answers 🙋♀️ They also MUST include the SIP option-tag "trickle-ice" in a SIP Supported: or Require: header field. This makes discovery pretty easy for Answerers, and for cases where Offers need to be generated within existing dialogs (like when sending UPDATE or re-INVITE requests). In both situations, the earlier SDP bodies already gave the info needed 💖
Obviously, that info isn't around when the very first Offer is being built, so ICE Agents can't tell that way whether incremental provisioning is supported 😭 The following options are suggested for dealing with that.
5.1. Provisioning Support for Trickle ICE 🛠️
Sometimes integrators deploying Trickle ICE can know ahead of time that some or all endpoints reachable from within their deployment will support Trickle ICE 🌈 That's the case, for example, when Session Border Controllers (SBCs) that support this specification are used to connect to UAs that don't support Trickle ICE.
The exact mechanism for allowing this kind of provisioning is out of scope here. This specification does encourage Trickle ICE implementations to allow the option in whatever way they find most appropriate ✨
That said, an Offerer that assumes Trickle ICE support MUST include a SIP Require: trickle-ice header field 🔒 That way, if the provisioned assumption of Trickle ICE support turns out to be wrong, the failure is (a) easy to track down operationally, and (b) recoverable by the client. In other words, the client can resend the request without the SIP Require: header field and without assuming Trickle ICE support 🫶
5.2. Trickle ICE Discovery with Globally Routable User Agent URIs (GRUUs) ✨
Okay so [RFC3840] lets SIP UAs ask about specific capabilities using OPTIONS requests, among other things. 💅 Then [RFC5627] gives us GRUU support, which means SIP requests can target one specific UA instead of just any random device behind an address of record. 🦋 Put those two together and add the "trickle-ice" option tag from Section 10.6, and SIP UAs can figure out what a specific UA instance can do and then send it INVITE requests that need Trickle ICE support, straight to that device. It's giving direct message energy 📩💜
There are a few ways to learn those capabilities. One option is to get a peer's GRUU instance ID through presence and then ask about its capabilities with an OPTIONS request. 🧚 Or you can just send an OPTIONS request to the Address of Record (AOR) you want to reach and check the response(s) for support of both GRUU and Trickle ICE (Figure 8). Heads up though, bestie: if you use the GRUU, the INVITE request can only go to that one particular device, so forking is off the table for that request. 🙈
Alice Bob
| |
| OPTIONS sip:b1@example.com SIP/2.0 |
|-------------------------------------------------->|
| |
| 200 OK |
| Contact: sip:b1@example.com;gr=hha9s8d-999a |
| ;audio;video|;trickle-ice;... |
|<--------------------------------------------------|
| |
| INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 |
| Supported: trickle-ice |
| (Offer) |
|-------------------------------------------------->|
| |
| 183 (Answer) |
|<--------------------------------------------------|
| INFO/OK (Trickling) |
|<------------------------------------------------->|
| |
| ... |
| |Figure 8: Trickle ICE Support Discovery with OPTIONS and GRUU
Once [RFC3840] confirms Trickle ICE support, SIP UAs get to go with Full Trickle negotiation from the very first Offer they send 🎀 instead of the longer Half Trickle. Main character energy, no cap. 👑
5.3. Fall Back to Half Trickle
If none of the other mechanisms in this section work out, SIP UAs should use the Half Trickle mode from [RFC8838] 🫶 With Half Trickle, agents start sessions the same way they would when using ICE for SIP [RFC8839]. So before they even send an Offer, they gather ICE candidates in a blocking way and then send all of them in that Offer. ⏳ That blocking part means some latency builds up, so it's advised that agents try to anticipate it where possible, like when user actions suggest a call is about to happen (for example, activity on a keypad or a phone going off hook). Be early, be iconic 🔥
Using Half Trickle gives you Offers that work with both ICE SIP endpoints [RFC8839] and legacy endpoints [RFC3264]. Compatibility queen behavior 🌈
STUN/TURN STUN/TURN
Servers Alice Bob Servers
| | | |
|<--------------| | |
| | | |
| | | |
| Candidate | | |
| | | |
| | | |
| Discovery | | |
| | | |
| | | |
|-------------->| INVITE (Offer) | |
| |---------------------------->| |
| | 183 (Answer) |-------------->|
| |<----------------------------| |
| | INFO (repeated candidates) | |
| |---------------------------->| |
| | | |
| | INFO (more candidates) | Candidate |
| |<----------------------------| |
| | Connectivity Checks | |
| |<===========================>| Discovery |
| | INFO (more candidates) | |
| |<----------------------------| |
| | Connectivity Checks |<--------------|
| |<===========================>| |
| | | |
| | 200 OK | |
| |<----------------------------| |
| | | |
| |<======= MEDIA FLOWS =======>| |
| | | |Figure 9: Example of a Typical (Half) Trickle ICE Exchange with SIP
Quick reminder, babe: once a single Offer or Answer has been swapped within a dialog, Trickle ICE support is figured out for that dialog 💖 So you don't need Half Trickle again in that same dialog, and every later exchange can use Full Trickle mode. Glow up unlocked ✨
6. Considerations for RTP and RTCP Multiplexing 🦋
This section gives some tips (well, guidance) for implementers on how to optimize trickling when it comes to RTCP candidates. 🧠
Handling of the "rtcp" attribute [RFC3605] and the "rtcp-mux" attribute for RTP/RTCP multiplexing [RFC5761] is already covered in Section 5.1.1.1 of [RFC8445] and in [RFC5761]. Those considerations still count for Trickle ICE 💅 but trickling gives you more flexibility in the order of candidate exchange when RTCP multiplexing is involved.
If the Offerer supports RTP/RTCP multiplexing exclusively as specified in [RFC8858], the procedures in that document apply to handling the "rtcp-mux-only", "rtcp", and "rtcp-mux" attributes. 🎀
A Half Trickle Offerer has to send an Offer that follows [RFC8839] and [RFC5761], including candidates for all components. 😭 A Full Trickle Offerer has way more flexibility: it can send only RTP candidates (component 1) in the initial Offer, assuming the Answerer supports RTCP multiplexing. 🙌 It only needs to start gathering and trickling RTCP candidates (component 2) after the Answer says the Answerer unexpectedly doesn't support RTCP multiplexing. Plot twist, but we handled it 🌸
A Trickle Answerer MAY include an "rtcp-mux" attribute [RFC5761] in the "application/trickle-ice-sdpfrag" body if it supports and uses RTP and RTCP multiplexing. 🧚 The Trickle Answerer needs to follow the guidance on using the "rtcp" attribute given in [RFC8839] and [RFC3605]. If the Offerer gets this attribute in an INFO request before the Answer arrives, that means the Answerer supports and uses RTP and RTCP multiplexing. The Offerer can use that info to stop gathering RTCP candidates and/or free up the resources tied to them. ⭐
Here's an example Offer that shows support for RTP and RTCP multiplexing. Screenshot it, it's so clean 📸
v=0
o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
s=
c=IN IP6 2001:db8:a0b:12f0::3
t=0 0
a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8
m=audio 5000 RTP/AVP 0
a=mid:1
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ hostOnce the dialog is set up as described in Section 4.3, the Answerer sends this INFO request. 💌
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package
Content-length: 161
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1
a=rtcp-mux
a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ hostThis INFO request says the Answerer supports and uses RTP and RTCP multiplexing too. ✨ That means the Offerer can skip gathering RTCP candidates, or release the ones it already has. 🫧 If the INFO request doesn't have the "rtcp-mux" attribute, the Offerer has to gather RTCP candidates, unless it wants to wait for an Answer that confirms whether or not RTP and RTCP multiplexing is supported. 🤔 And if the Offerer already sent RTCP candidates in an earlier INFO request, it still has to repeat them in later INFO requests, even after the Answerer confirmed multiplexing support and the Offerer released its RTCP candidates. Yes, even then, periodt 💀💅
7. Considerations for Media Multiplexing ✨
okay bestie, this section is all about how to make trickling smarter when you're doing Media Multiplexing 🦋 It's basically a set of options that give implementers some guidance on sending candidates efficiently. You'll want to already know [RFC8843] before you dive in, ngl 🌸
Candidate exchange is already covered in Section 10 of [RFC8843] 💅 Those considerations still apply to Trickle ICE, BUT trickling gives you more flexibility in the order you send candidates, especially in Full Trickle mode. it's giving freedom 🕊️
Except for bundle-only m= lines, a Half Trickle Offerer has to send an Offer with candidates for all bundled m= lines. The extra flexibility, though, lets a Full Trickle Offerer start off by sending candidates only for the m= line with the suggested Offerer BUNDLE address 🎀
When the Answer comes back, the Offerer can figure out two things: whether BUNDLE is supported by the Answerer, and whether the suggested Offerer BUNDLE address was picked. If both check out, the Offerer doesn't need to trickle any more candidates for the other bundled m= lines 🙌 But if BUNDLE isn't supported, the Full Trickle Offerer needs to gather and trickle candidates for the remaining m= lines as necessary 😭 And if the Answerer picks an Offerer BUNDLE address that's different from the suggested one, the Full Trickle Offerer needs to gather and trickle candidates for the m= line that carries the selected Offerer BUNDLE address 💜
A Trickle Answerer SHOULD include a group:BUNDLE attribute [RFC8843] at session level in the application/trickle-ice-sdpfrag body if it supports and uses bundling. When it does that, the Answerer MUST include all identification-tags in the same order that is used or will be used in the Answer. Main character energy, but make sure the order is right 👑
Receiving this attribute at the Offerer in an INFO request before the Answer tells the Offerer that the Answerer supports and uses bundling 🧚 The Offerer can use that info to stop gathering candidates for the remaining m= lines in a bundle and/or to free up the resources tied to them ✨
Here's an example Offer that shows off support for Media Multiplexing 🍓
v=0
o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
s=
c=IN IP6 2001:db8:a0b:12f0::3
t=0 0
a=group:BUNDLE foo bar
a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8
m=audio 10000 RTP/AVP 0
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host
m=video 10002 RTP/AVP 31
a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:midThis example Offer says yes to RTP and RTCP multiplexing, and it only has a candidate attribute for the m= line with the suggested Offerer BUNDLE address. Once the dialog is set up the way Section 4.3 describes, the Answerer sends this INFO request 💖
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package
Content-length: 219
a=group:BUNDLE foo bar
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:foo
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ hostThis INFO request shows that the Answerer supports and uses Media Multiplexing too 🦋 Notice that the Answerer only includes a single pseudo m= line, because it doesn't need candidates matching the second m= line from the Offer 🌈
The INFO request also tells you the Answerer accepted the suggested Offerer BUNDLE address 🎉 That means the Offerer can skip gathering RTP and RTCP candidates for the other m= lines, or skip releasing candidates it already gathered. But if the INFO request didn't have the group:BUNDLE attribute, the Offerer has to gather RTP and RTCP candidates for the other m= lines, unless it wants to wait for an Answer that finally confirms whether Media Multiplexing is supported or not 🫶
No matter if you're using Full Trickle or Half Trickle mode, the rules from [RFC8859] apply to both the Offerer and the Answerer when they put the attributes from Section 9.2 into the application/trickle-ice-sdpfrag body 💅
8. SDP "end-of-candidates" Attribute ✨
8.1. Definition
okay so this section introduces a brand new SDP attribute, end-of-candidates, which can live at the media level or the session level [RFC4566] 🌸 It's a property attribute [RFC4566], so it has no value, just vibes. When you include it in an Offer or Answer, you're basically saying "hey, I'm done, I won't trickle any more candidates" 🙈 At session level it covers the whole session. At media level it only covers that one media description 💜
Name: end-of-candidates
Value: N/A
Usage Level: media and session level
Charset Dependent: no
Mux Category: IDENTICAL
Example: a=end-of-candidates8.2. Offer/Answer Procedures
The Offerer or Answerer MAY include an end-of-candidates attribute when candidate discovery has ended and no more candidates are going to be trickled 🧚 The Offerer or Answerer MUST include the end-of-candidates attribute together with the ice-ufrag and ice-pwd attributes of the current ICE generation, as required by [RFC8838] 🔥 Same deal as before: session level covers the whole session, media level covers only the matching media description 🎀
When an Offerer or Answerer gets an end-of-candidates attribute, and the ice-ufrag and ice-pwd attributes match the current ICE generation, that means the peer has finished gathering candidates. It applies to the whole session or just the matching media description, depending on where it showed up 👑 The receiving agent passes the end-of-candidates indication along to the ICE Agent, and the ICE Agent acts as specified in [RFC8838] ✨
9. Content Type "application/trickle-ice-sdpfrag" 🍓
9.1. Overall Description
The application/trickle-ice-sdpfrag body is used exclusively by the trickle-ice Info Package 🦋 Any other SDP-related applications need to define their own media type, no shortcuts 🙅♀️ The INFO request body uses a subset of the SDP lines that the grammar in [RFC4566] allows. A valid body only uses pseudo m= lines and the attributes that are needed and/or useful for trickling candidates 💖 The content follows the grammar below, so let's look at that next 🌈
9.2. Grammar
The grammar of an application/trickle-ice-sdpfrag body is based on the following ABNF [RFC5234] 💅 It specifies the subset of existing SDP attributes that's needed or useful for trickling candidates. The grammar uses the indicator for case-sensitive %s, defined in [RFC7405], but it also imports grammar for other SDP attributes that come before the [RFC7405] production. A sender SHOULD use lower case for attributes from that earlier grammar, but a receiver MUST treat them as case insensitive 🫶
; Syntax
trickle-ice-sdpfrag = session-level-fields
pseudo-media-descriptions
session-level-fields = *(session-level-field CRLF)
session-level-field = ice-lite-attribute /
ice-pwd-attribute /
ice-ufrag-attribute /
ice-options-attribute /
ice-pacing-attribute /
end-of-candidates-attribute /
bundle-group-attribute /
extension-attribute-fields
; for future extensions
ice-lite-attribute = %s"a" "=" ice-lite
ice-pwd-attribute = %s"a" "=" ice-pwd-att
ice-ufrag-attribute = %s"a" "=" ice-ufrag-att
ice-pacing-attribute = %s"a" "=" ice-pacing-att
ice-options-attribute = %s"a" "=" ice-options
end-of-candidates-attribute = %s"a" "=" end-of-candidates
end-of-candidates = %s"end-of-candidates"
bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics
*(SP identification-tag)
bundle-semantics = "BUNDLE"
extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field
trickle-ice-attribute-fields )
trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF)
trickle-ice-attribute-field = mid-attribute /
candidate-attributes /
ice-pwd-attribute /
ice-ufrag-attribute /
remote-candidate-attribute /
end-of-candidates-attribute /
rtcp-attribute /
rtcp-mux-attribute /
rtcp-mux-only-attribute /
extension-attribute-fields
; for future extensions
rtcp-attribute = %s"a" "=" %s"rtcp"
rtcp-mux-attribute = %s"a" "=" %s"rtcp-mux"
rtcp-mux-only-attribute = %s"a" "=" %s"rtcp-mux-only"
candidate-attributes = %s"a" "=" candidate-attribute
remote-candidate-attribute = %s"a" "=" remote-candidate-attQuick grammar hint: ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-pacing-att, ice-options, candidate-attribute, and remote-candidate-att all come from [RFC8839] 🧚 identification-tag and mid-attribute come from [RFC5888], and media-field and attribute-fields come from [RFC4566] 💜 The rtcp attribute is defined in [RFC3605], the rtcp-mux attribute is defined in [RFC5761], and the rtcp-mux-only attribute is defined in [RFC8858]. Those last ones don't have formal grammar in their own RFCs, so the grammar is reproduced here 🌸
The ice-pwd and ice-ufrag attributes MUST appear at the same level as they did in the Offer/Answer exchange 🔥 In other words, if they were session-level attributes, they'll also show up at the very beginning of all INFO request payloads, before any pseudo m= lines. If they were originally exchanged as media-level attributes, potentially overriding the session-level values, they'll be included in INFO request payloads right after the matching pseudo m= line 🎀
An Agent MUST ignore any received unknown extension-attribute-fields 🙅♀️✨
10. Info Package 🌈
10.1. Rationale -- Why INFO? 🎀
Okay so the big question is why we picked SIP INFO requests to carry candidates 🤔 The main reason is that they're super lightweight 🦋 Once a dialog is set up, INFO requests can go both ways with no restrictions on timing or frequency, and there's no risk of collision 💅
A key fact here is that sending Trickle ICE candidates in one direction is totally uncoupled from sending them in the other 🫶 So each direction can have its own stream of INFO requests, and those streams don't have to line up with each other. And since each INFO request cumulatively includes the contents of all the previous INFO requests in that direction, the ordering between INFO requests doesn't need to be preserved ✨ That's what makes these largely independent INFO requests work so well together 💖
Now compare that with UPDATE or the other Offer/Answer mechanisms, which assume the messages in each direction are tightly coupled with the messages in the other direction 🙈 Using Offer/Answer and UPDATE requests [RFC3311] would bring along some drama:
- Blocking of messages: Offer/Answer is defined as a strictly sequential mechanism in [RFC3264] 😩 There can only be a maximum of one active exchange at any point of time. Both sides can't send Offers at the same time, and they can't generate multiple Offers before receiving an Answer. So using UPDATE requests for candidate transport would mean every agent needs a candidate pool, where candidates get stored until it's once again that agent's "turn" to emit an Answer or a new Offer. That's a lot of complexity for no extra value 💀
- Elevated risk of glare: The sequential nature of Offer/Answer also makes it impossible for both sides to send Offers simultaneously, and what's worse is that there are no mechanisms in SIP to actually prevent that 😭 [RFC3261] calls the situation where Offers cross on the wire "glare", but it only defines a procedure for dealing with it after it has happened. According to that procedure, both Offers are invalidated and both sides need to retry the negotiation after a period between 0 and 4 seconds. With glare that likely and an average two-second backoff, Trickle ICE processing wouldn't just fail to improve, it would actually exceed the duration of regular ICE 🙃
INFO messages decouple the exchange of candidates from the Offer/Answer negotiation, and they're not subject to any of the glare issues above 🌸 That makes them a super convenient and lightweight way to deliver candidates asynchronously 🧚
Using in-dialog INFO messages also guarantees that candidates are delivered end to end, between the same entities that are actually in the process of initiating a session 👑 Out-of-dialog alternatives would have meant requiring support for GRUU [RFC5627]. Given GRUU's relatively low adoption levels, that would have been too strong of a constraint on adopting Trickle ICE 🥲
10.2. Overall Description 🍓
This specification defines an Info Package for use by SIP UAs implementing Trickle ICE ✨ INFO requests carry ICE candidates discovered after the peer UAs have confirmed mutual support for Trickle ICE 🫶
10.3. Applicability 🌈
The whole point of the ICE protocol is to establish a media path in the presence of NAT and firewalls 🏰 The candidates are transported in INFO requests, and they're part of that establishment ✨
Candidates sent by a Trickle ICE Agent after the Offer follow the same signaling path and reach the same entity as the Offer itself 💜 Sure, GRUUs can be used to achieve this, but one of the goals of this specification is to allow Trickle ICE to work in as many environments as possible, including ones without GRUU support 🦋 Using out-of-dialog SUBSCRIBE/NOTIFY requests would not satisfy that goal 🙅♀️
10.4. Info Package Name 🎀
This document defines a SIP Info Package as per [RFC6086] 💅 The Info Package token name for this package is "trickle-ice" ✨
10.5. Info Package Parameters 🌸
This document does not define any Info Package parameters 🤷♀️
10.6. SIP Option Tags 💖
[RFC6086] allows Info Package specifications to define SIP option-tags 🧚 This specification extends the option-tag construct of the SIP grammar like so:
option-tag /= "trickle-ice"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 🔥
When responding to, or generating, a SIP OPTIONS request, a SIP entity MUST also include the "trickle-ice" option-tag in a SIP Supported: or Require: header field 🫶
10.7. INFO Request Body Parts 🍓
Entities implementing this specification MUST include a payload of type "application/trickle-ice-sdpfrag" in SIP INFO requests, as defined in Section 9.2 📦 The payload is used to convey SDP-encoded ICE candidates 💜
10.8. Info Package Usage Restrictions 🌈
This document does not define any Info Package Usage Restrictions 🙌
10.9. Rate of INFO Requests 🌊
Okay, this one's important 🚨 IP addresses can be gathered rapidly, so a Trickle ICE Agent with lots of network interfaces might create a high rate of INFO requests if every newly detected candidate gets trickled individually without aggregation 😵💫 So an implementation MUST aggregate ICE candidates in case an unreliable transport protocol such as UDP is used 🛑 A Trickle ICE Agent MUST NOT have more than one INFO request pending at any one time 🙅♀️ When INFO messages are sent over an unreliable transport, they get retransmitted according to the rules in [RFC3261], Section 17.1.2.1 🔁
If the INFO requests are sent on top of TCP, which is probably the standard way, it's not an issue for the network anymore 🫧 It can still be one for SIP proxies and other intermediaries forwarding the SIP INFO messages though 👀 Also, an endpoint may not be able to tell that it has congestion controlled transport all the way 🤷♀️
10.10. Info Package Security Considerations 🔐
See Section 13 🫶
11. Deployment Considerations 🚀
Trickle ICE uses two mechanisms for the exchange of candidate information ✨ That imposes new requirements on certain middleboxes that some networks use, e.g., for monitoring purposes 👀 The first mechanism, SDP Offers and Answers, is already used by regular ICE and is assumed to be supported 💅 The second mechanism, INFO request bodies, needs to be considered by those middleboxes as well when Trickle ICE is used 🙈 Such middleboxes need to make sure they remain in the signaling path of the INFO requests, and that they understand the INFO request body 🫡
12. IANA Considerations 📋
12.1. SDP "end-of-candidates" Attribute 🎀
This section defines a new SDP media-level and session-level [RFC4566] "end-of-candidates" attribute 🦋 It's a property attribute [RFC4566], so it has no value ✨
Name: end-of-candidates
Value: N/A
Usage Level: media and session
Charset Dependent: no
Purpose: The sender indicates that it will not trickle further
ICE candidates.
O/A Procedures: RFC 8840 defines the detailed SDP Offer/Answer
procedures for the "end-of-candidates" attribute.
Mux Category: IDENTICAL
Reference: RFC 8840
Example: a=end-of-candidates12.2. Media Type "application/trickle-ice-sdpfrag" 💌
This document defines the new media type "application/trickle-ice-sdpfrag" in accordance with [RFC6838] 🌸
Type name: application
Subtype name: trickle-ice-sdpfrag
Required parameters: None.
Optional parameters: None.
Encoding considerations: The media contents follow the same rules as
SDP, except as noted in this document. The media contents are
text, with the grammar specified in Section 9.2.
Although the initially defined content of a trickle-ice-sdpfrag
body does only include ASCII characters, UTF-8-encoded content
might be introduced via extension attributes. The "charset"
attribute may be used to signal the presence of other character
sets in certain parts of a trickle-ice-sdpfrag body (see
[RFC4566]). Arbitrary binary content cannot be directly
represented in SDP or a trickle-ice-sdpfrag body.
Security considerations: See [RFC4566] and RFC 8840
Interoperability considerations: See RFC 8840
Published specification: See RFC 8840
Applications that use this media type: Trickle ICE
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh File Type Code(s): N/A
Person and email address to contact for further information: The
IESG (iesg@ietf.org)
Intended usage: Trickle ICE for SIP as specified in RFC 8840.
Restrictions on usage: N/A
Author/Change controller: The IESG (iesg@ietf.org)
Provisional registration? (standards tree only): N/A12.3. SIP Info Package "trickle-ice" 🧁
This document defines a new SIP Info Package named "trickle-ice" and updates the "Info Packages Registry" with the following entry ✨
+=============+===========+
| Name | Reference |
+=============+===========+
| trickle-ice | RFC 8840 |
+-------------+-----------+
Table 112.4. SIP Option Tag "trickle-ice" 🏷️
This specification registers a new SIP option tag "trickle-ice" as per the guidelines in Section 27.1 of [RFC3261] 💅 It also updates the "Option Tags" subregistry of the SIP Parameters registry with the following entry 🫶
+=============+==============================+===========+
| Name | Description | Reference |
+=============+==============================+===========+
| trickle-ice | This option tag is used to | RFC 8840 |
| | indicate that a UA supports | |
| | and understands Trickle ICE. | |
+-------------+------------------------------+-----------+
Table 213. Security Considerations 🔐
The Security Considerations of [RFC6086], [RFC8838], and [RFC8839] apply 🛡️ This document clarifies how those specifications are used together for trickling candidates, and it does not create additional security risks ✨
The new Info Package "trickle-ice" and the new media type "application/trickle-ice-sdpfrag" do not introduce additional security considerations when used in the context of Trickle ICE 🙌 Neither one is intended to be used for other applications, so any security considerations for their use in other contexts are out of the scope of this document 🚧
14. References 📚
14.1. Normative References 🧾✨
okay bestie, these are the normative receipts, the ones you literally need to read to implement this stuff. Every one is listed with its full details 💅
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997,https://www.rfc-editor.org/info/rfc2119. - [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI
10.17487/RFC3261, June 2002,https://www.rfc-editor.org/info/rfc3261. - [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, DOI
10.17487/RFC3262, June 2002,https://www.rfc-editor.org/info/rfc3262. - [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI
10.17487/RFC3264, June 2002,https://www.rfc-editor.org/info/rfc3264. - [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI
10.17487/RFC3605, October 2003,https://www.rfc-editor.org/info/rfc3605. - [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI
10.17487/RFC4566, July 2006,https://www.rfc-editor.org/info/rfc4566. - [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI
10.17487/RFC5234, January 2008,https://www.rfc-editor.org/info/rfc5234. - [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI
10.17487/RFC5761, April 2010,https://www.rfc-editor.org/info/rfc5761. - [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI
10.17487/RFC5888, June 2010,https://www.rfc-editor.org/info/rfc5888. - [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, DOI
10.17487/RFC6086, January 2011,https://www.rfc-editor.org/info/rfc6086. - [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI
10.17487/RFC6838, January 2013,https://www.rfc-editor.org/info/rfc6838. - [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI
10.17487/RFC7405, December 2014,https://www.rfc-editor.org/info/rfc7405. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI
10.17487/RFC8174, May 2017,https://www.rfc-editor.org/info/rfc8174. - [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI
10.17487/RFC8445, July 2018,https://www.rfc-editor.org/info/rfc8445. - [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", RFC 8838, DOI
10.17487/RFC8838, January 2021,https://www.rfc-editor.org/info/rfc8838. - [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, A., and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)", RFC 8839, DOI
10.17487/RFC8839, January 2021,https://www.rfc-editor.org/info/rfc8839. - [RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI
10.17487/RFC8843, January 2021,https://www.rfc-editor.org/info/rfc8843. - [RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)", RFC 8858, DOI
10.17487/RFC8858, January 2021,https://www.rfc-editor.org/info/rfc8858. - [RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI
10.17487/RFC8859, January 2021,https://www.rfc-editor.org/info/rfc8859.
14.2. Informative References 📚🌸
these ones are the background reading, super helpful for context but not required to implement, so think of them as the lore 🦋
- [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI
10.17487/RFC3311, October 2002,https://www.rfc-editor.org/info/rfc3311. - [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI
10.17487/RFC3840, August 2004,https://www.rfc-editor.org/info/rfc3840. - [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI
10.17487/RFC5389, October 2008,https://www.rfc-editor.org/info/rfc5389. - [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI
10.17487/RFC5627, October 2009,https://www.rfc-editor.org/info/rfc5627. - [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI
10.17487/RFC5766, April 2010,https://www.rfc-editor.org/info/rfc5766.
Acknowledgements 💖
the authors wanna give a huge shoutout to Flemming Andreasen, Ayush Jain, Paul Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount, and Martin Thomson for reviewing and/or making all sorts of suggestions to improve and optimize things. 🫶
the authors also thank Flemming Andreasen for shepherding this document, and Ben Campbell for his AD review and suggestions. they also thank Benjamin Kaduk, Adam Roach, Mirja Kühlewind, and Eric Rescorla for their comments and/or text proposals for improving the document during IESG review. 🙌
many thanks to Dale Worley for the Gen-Art review and proposed enhancements for several sections. 🎀
many thanks to Joerg Ott for the TSV-Art review and suggested improvements. 🌈
and the authors thank Shawn Emery for the Security Directorate review. 👑
Authors' Addresses 🧚
meet the squad! ✨
- Emil Ivov
- Jitsi
- 67000 Strasbourg
- France
- Phone:
+33 6 72 81 15 55 - Email:
emcho@jitsi.org
- Thomas Stach
- Unaffiliated
- 1130 Vienna
- Austria
- Email:
thomass.stach@gmail.com
- Enrico Marocco
- Telecom Italia
- Via G. Reiss Romoli, 274
- 10148 Turin
- Italy
- Email:
enrico.marocco@telecomitalia.it
- Christer Holmberg
- Ericsson
- Hirsalantie 11
- FI-02420 Jorvas
- Finland
- Email:
christer.holmberg@ericsson.com
that's the whole RFC, bestie 🌈💅🦋 we did it!!
📦 where this page comes from
- ietf: rfc8840 2021-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms