Skip to content

RFC 8840: A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)

  • E. Ivov,  
  • T. Stach,  
  • E. Marocco,  
  • C. Holmberg
Proposed Standard
This RFC was updated, see

Abstract

The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.

This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The document also defines a new SIP Info Package to support this usage together with the corresponding media type. Additionally, a new Session Description Protocol (SDP) "end-of-candidates" attribute and a new SIP option tag "trickle-ice" are defined.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

1. Introduction

The Interactive Connectivity Establishment (ICE) protocol [] describes a mechanism for Network Address Translator (NAT) traversal that consists of three main phases.

During the first phase, an agent gathers a set of candidate transport addresses (source IP, port, and transport protocol). This is followed by a second phase where these candidates are sent to a remote agent within the Session Description Protocol (SDP) body of a SIP message. At the remote agent, the gathering procedure is repeated and candidates are sent to the first agent. Once the candidate information is available, a third phase starts in parallel where connectivity between all candidates in both sets is checked (connectivity checks). Once these phases have been completed, and only then, both agents can begin communication.

According to [], the three phases above happen consecutively, in a blocking way, which can introduce undesirable setup delay during session establishment. The Trickle ICE extension [] defines generic semantics required for these ICE phases to happen in a parallel, non-blocking way and hence speeds up session establishment.

This specification defines a usage of Trickle ICE with the Session Initiation Protocol (SIP)[]. It describes how ICE candidates are to be exchanged incrementally using SIP INFO requests [] and how the Half Trickle and Full Trickle modes defined in [] are to be used by SIP User Agents (UAs) depending on their expectations for support of Trickle ICE by a remote agent.

This document defines a new Info Package as specified in [] for use with Trickle ICE together with the 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 [] [] when, and only when, they appear in all capitals, as shown here.

This specification makes use of terminology defined by the ICE protocol in [] and by its Trickle ICE extension in []. It is assumed that the reader is familiar with the terminology from both documents.

[] also describes how ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol [] and its extension Traversal Using Relays around NAT (TURN) [].

3. Protocol Overview

When using ICE for SIP according to [], the ICE candidates are exchanged solely via SDP Offer/Answer as per []. This specification defines an additional mechanism where candidates can be exchanged using SIP INFO messages and a newly defined Info Package []. This also allows ICE candidates to be sent in parallel to an ongoing Offer/Answer negotiation and/or after the completion of the Offer/Answer negotiation.

Typically, in cases where Trickle ICE is fully supported, the Offerer sends an INVITE request containing a subset of candidates. Once an early dialog is established, the Offerer can continue sending candidates in INFO requests within that dialog.

Similarly, an Answerer can send ICE candidates using INFO requests within the dialog established by its 18x provisional response. Figure 1 shows such a sample exchange:

   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 SIP

3.1. Discovery Issues

In order to benefit from Trickle ICE's full potential and reduce session establishment latency to a minimum, Trickle ICE Agents need to generate SDP Offers and Answers that contain incomplete and potentially empty sets of candidates. Such Offers and Answers can only be handled meaningfully by agents that actually support incremental candidate provisioning, which implies the need to confirm such support before using it.

Contrary to other protocols, where "in advance" capability discovery is widely implemented, the mechanisms that allow this for SIP (i.e., a combination of UA capabilities [] and Globally Routable User Agent URIs (GRUUs) []) have only seen low levels of adoption. This presents an issue for Trickle ICE implementations as SIP UAs do not have an obvious means of verifying that their peer will support incremental candidate provisioning.

The Half Trickle mode of operation defined in the Trickle ICE specification [] provides one way around this, by requiring the first Offer to contain a complete set of local ICE candidates and using only incremental provisioning of remote candidates for the rest of the session.

While using Half Trickle does provide a working solution, it also comes at the price of increased latency. Therefore, Section 5 makes several alternative suggestions that enable SIP UAs to engage in Full Trickle right from their first Offer: Section 5.1 discusses the use of online provisioning as a means of allowing the use of 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 the implementation and use of Half Trickle by SIP UAs where none of the above are an option.

3.2. Relationship with the Offer/Answer Model

From the perspective 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 []. However, in order to have the full picture of the candidate exchange, the newly introduced INFO messages need to be considered as well.

+-------------------------------+  +-------------------------------+
|   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 Signaling

From an architectural viewpoint, as displayed in Figure 2, exchanging candidates through SIP INFO requests could be represented as signaling between ICE modules and not between Offer/Answer modules of SIP UAs. Then, such INFO requests do not impact the state of the Offer/Answer transaction other than providing additional candidates. Consequently, INFO requests are not considered Offers or Answers. Nevertheless, 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 [].

4. Incremental Signaling of ICE Candidates

Trickle ICE Agents will exchange ICE descriptions compliant to [] via Offer/Answer procedures and/or INFO request bodies. This requires the following SIP-specific extensions:

  1. Trickle ICE Agents MUST indicate support for Trickle ICE by including the SIP option-tag "trickle-ice" in a SIP Supported: header field within all SIP INVITE requests and responses.
  2. Trickle ICE Agents MUST indicate support for Trickle ICE by including the ice-option "trickle" within all SDP Offers and Answers in accordance to [].
  3. 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.
  4. Trickle ICE Agents MAY exchange additional ICE candidates using INFO requests within an existing INVITE dialog usage (including an early dialog) as specified in []. 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.
  5. 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 provide further details on how Trickle ICE Agents perform the initial Offer/Answer exchange (Section 4.1), perform subsequent Offer/Answer exchanges (Section 4.2), and establish the INVITE dialog usage (Section 4.3) such that 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 [].

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 cannot know the RTP Control Protocol (RTCP) transport address; thus, it MUST NOT include the "rtcp" attribute []. This avoids potential ICE mismatch (see []) for the RTCP transport address.

If the Offerer wants to use RTCP multiplexing [] and/or exclusive RTCP multiplexing [], 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 [] and MUST include in each "m=" line a "mid" attribute in accordance to []. The "mid" attribute identifies the "m=" line to which a candidate belongs and helps in case of multiple "m=" lines, when candidate gathering could occur in an order different from 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 [].

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 []).

4.1.3. Sending the Initial Answer

If the Answerer includes candidates in its initial Answer, it MUST encode these candidates as specified in [].

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 cannot know the RTCP transport address; thus, it MUST NOT include the "rtcp" attribute []. This avoids potential ICE mismatch (see []) for the RTCP transport address.

If the Answerer accepts the use of RTCP multiplexing [] and/or exclusive RTCP multiplexing [], 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 [] and MUST include in each "m=" line a "mid" attribute in accordance to [].

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 [].

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 []).

4.2. Subsequent Offer/Answer Exchanges

Subsequent Offer/Answer exchanges are handled the same as regular ICE (see of []).

If an Offer or Answer needs to be sent while the ICE Agents are in the middle of trickling, of [] 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 discusses in detail 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 allows for ICE processing to 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 Answer

As shown in Figure 3, satisfying both conditions is relatively trivial for ICE Agents that have sent an Offer in an INVITE and that have received an Answer in a reliable provisional response. It is guaranteed to have confirmed support (or lack thereof) for Trickle ICE at the Answerer and to have fully initialized the SIP dialog at both ends. Offerers and Answerers (after receipt of the PRACK request) in the above situation can therefore freely commence trickling within the newly established dialog.

4.3.2. Establishing Dialog State through Unreliable Offer/Answer Delivery

The situation is a bit more delicate for agents that have received an Offer in an INVITE request and have sent an Answer in an unreliable provisional response because, once the response has been sent, the Answerer does not know when or if it has been received (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 state

In order to clear this ambiguity as soon as possible, the Answerer needs to retransmit the provisional response with the exponential backoff timers described in []. These retransmissions 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. The Offerer cannot send in-dialog requests until it receives a response, so the arrival of such a request proves that the response has arrived. Using the INFO request for dialog confirmation is similar to the procedure described in of [], except that the STUN binding request is replaced by the INFO request.

The Offerer MUST send a Trickle ICE INFO request as soon as it receives an SDP Answer in an unreliable provisional response. This INFO request MUST repeat the candidates that were already provided in the Offer (as would be the case when Half Trickle is performed or when new candidates have not been learned since then). The first case could happen when Half Trickle is used and all candidates are already in the initial offer. The second case could happen when Full Trickle is used and the Offerer is currently gathering additional candidates but did not yet get them. Also, if the initial Offer did not contain any candidates, depending on how the Offerer gathers its candidates and how long it takes to do so, this INFO could still contain no candidates.

When Full Trickle is used and if newly learned candidates are available, the Offerer SHOULD also deliver these candidates in said INFO request, unless it wants to hold back some candidates in reserve, e.g., in case these candidates are expensive to use and would only be trickled if all other candidates failed.

The Offerer SHOULD include an "end-of-candidates" attribute in case candidate discovery has ended in the meantime and no further candidates are to be trickled.

As soon as an Answerer has received such an INFO request, the Answerer has an indication that a dialog is established at both ends and trickling can begin (Figure 5).

Note: The "+SRFLX" in Figure 5 indicates that 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 state

When sending the Answer in the 200 OK response to the INVITE request, the Answerer needs to repeat exactly the same Answer that was previously sent in the unreliable provisional response in order to fulfill the corresponding requirements in []. Thus, the Offerer needs to be prepared for receiving a different number of candidates in that repeated Answer than previously exchanged via trickling and MUST ignore the candidate information in that 200 OK response.

4.3.3. Initiating Trickle ICE without an SDP Answer

The ability to convey arbitrary candidates in INFO message bodies allows ICE Agents to initiate trickling without actually sending an Answer. Trickle ICE Agents can therefore respond to an INVITE request with provisional responses without an SDP Answer []. Such provisional responses serve for establishing an early dialog.

Agents that choose to establish the dialog in this way MUST retransmit these responses with the exponential backoff timers described in []. These retransmissions MUST cease on receipt of an INFO request carrying a "trickle-ice" Info Package body, on receipt of any in-dialog requests from the Offerer, or on transmission of the Answer in a 2xx response. The Offerer cannot send in-dialog requests until it receives a response, so the arrival of such a request proves that the response has arrived. This is again similar to the procedure described in of [], except that an Answer is not yet provided.

Note: The "+SRFLX" in Figure 6 indicates that 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 dialog

When sending the Answer, the agent MUST repeat all currently known and used candidates, if any, and MAY include all newly gathered candidates since the last INFO request was sent. However, if that Answer was already sent in an unreliable provisional response, the Answerers MUST repeat exactly the same Answer in the 200 OK response to the INVITE request in order to fulfill the corresponding requirements in []. In case that trickling continued, an Offerer needs to be prepared for receiving fewer candidates in that repeated Answer than previously exchanged via trickling and MUST ignore the candidate information in that 200 OK response.