Jitsi

Strasbourg 67000 France +33 6 72 81 15 55 emcho@jitsi.org

Telecom Italia

Via G. Reiss Romoli, 274 Turin 10148 Italy enrico.marocco@telecomitalia.it

Ericsson

Hirsalantie 11 02420 Jorvas Finland christer.holmberg@ericsson.com

The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal 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. This document defines usage semantics for Trickle ICE with SIP.

The vanilla specification of the Interactive Connectivity Establishment (vanilla ICE) protocol describes a mechanism for NAT traversal that consists of three main phases: a phase where an agent gathers a set of candidate 5-tuples (source IP address and port, destination IP address and port and a transport protocol), a second phase where these candidates are sent to a remote agent and this gathering is repeated and then a third phase where connectivity between all candidates in both sets is checked (connectivity checks). Only then can both agents begin communication, provided of course that ICE processing has successfully completed. According to that specification the three phases above happen consecutively, in a blocking way, which may lead to undesirable latency during session establishment. The trickle ICE extension defined in defines generic semantics required for these ICE phases to happen simultaneously, in a non-blocking way and hence speed up session establishment. This specification defines a usage of trickle ICE with the Session Initiation Protocol (SIP). In describes how and when SIP agents use the full and half trickle modes of operation, how they encode additional candidates and how they exchange them through use of SIP INFO requests. This document also defines a new Info Package for use with Trickle ICE.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . This specification makes use of all terminology defined by the protocol for Interactive Connectivity Establishment in and its Trickle ICE extension . It is assumed that the reader will be familiar with the terminology from both of them.

Trickle ICE defines a mode of operation called "half trickle". With half trickle the first offer in a session contains all candidates and subsequent trickling occurs from the offerer in this first offer/answer negotiation. Half trickle offers can hence be processed by both vanilla and trickle ICE agents, which offers an interesting advantage in cases where support for trickle cannot be verified prior to sending an offer. Unless agents are running within controlled environments or using GRUU, this would be the case with SIP. In spite of mechanisms such as the one defined in , a SIP UA cannot rely on consecutive requests reaching the same destination. An OPTIONS request querying capabilities can hence be routed to and answered by one entity and a subsequent INVITE by a completely different one. For all these reasons SIP UAs implementing trickle ICE SHOULD always perform half trickle, unless that behaviour is specifically overridden by configuration (which could be the case in controlled environments where every agent supports trickle ICE). [TODO maybe define a way for GRUU supporting agents to do full trickle]

Trickled candidates and end-of-candidates indications sent by trickle ICE SIP UAs are transported as payload in SIP INFO requests sent within the already established dialog. Such payloads are encoded in an SDP format as specified in . Since neither the "a=candidate" nor the "a=end-of-candidates" lines contain information matching them to a stream, this is handled through the use of MID as follows:

This specification defines an INFO package meant for use by SIP user agents implementing Trickle ICE. Typically INFO requests would carry ICE candidates discovered after the user agent has sent or received a trickle-ice offer.

The purpose of the ICE protocol is to establish a media path. The candidates that this specification transports in INFO requests are part of this establishment. There is hence no way for them to be transported through the not yet existing media path. Candidates sent by a trickle ICE agent after the offer, are meant to follow the same signalling path and reach the same entity as the offer itself. While it is true that GRUUs can be used to achieve this, one of the goals of this specification is to allow operation of trickle ICE in as many environments as possible including those with no GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not satisfy this goal.

This document defines a SIP INFO Package as per . The INFO Package token name for this package is "trickle-ice"

This document does not define any INFO package parameters.

allows Info Package specifications to define SIP option-tags. This document therefore stipulates that SIP entities that support trickle ICE and this specification MUST place the 'trickle-ice' option-tag in a SIP Supported header field. When responding to, or generating a SIP OPTIONS request a SIP entity MUST also include the 'trickle-ice' option-tag in a SIP Supported header field.

Entities implementing this specification MUST include SDP encoded ICE candidates in all SIP INFO requests. The MIME type for the payload MUST be of type 'application/sdp' as defined in and .

A typical successful (half) trickle ICE exchange with SIP would look this way:

| INVITE (Offer) | | | |------------------------>| | | | 180 (Answer) |-------------->| | |<------------------------| | | | | | | | INFO (more candidates) | Candidate | | |<------------------------| | | | Connectivity Checks | | | |<=======================>| Discovery | | | INFO (more candidates) | | | |<------------------------| | | | Connectivity Checks |<--------------| | |<=======================>| | | | | | | | 200 OK | | | |<------------------------| | | | | | | | 5245 SIP re-INVITE | | | |------------------------>| | | | 200 OK | | | |<------------------------| | | | | | | | | | | |<===== MEDIA FLOWS =====>| | | | | | ]]>

[TODO]

[TODO]

At the time of writing of this document the authors have no clear view on how and if the following list of issues should be address here: Should we allow for full trickle if support can be verified automatically and confirmed for a gruu with . Can we pick between MID and stream indices for stream identification.