A Session Initiation Protocol (SIP) usage for Trickle ICE
draft-ivov-mmusic-trickle-ice-sip-00

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 03, 2013.

Copyright Notice

Copyright (c) 2013 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 (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Half vs Full Trickle
• 4. Encoding and Sending Candidate Information
• 5. Info Package
• 5.1. Overall Description
• 5.2. Applicability
• 5.3. INFO Package Name
• 5.4. INFO Package Parameters
• 5.5. SIP Option-Tags
• 5.6. INFO Message Body Parts
• 6. Example Flows
• 7. Security Considerations
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Open issues
• Authors' Addresses

1. Introduction

The vanilla specification of the Interactive Connectivity Establishment (vanilla ICE) protocol [RFC5245] 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 [I-D.ivov-mmusic-trickle-ice] 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.

2. Terminology

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

This specification makes use of all terminology defined by the protocol for Interactive Connectivity Establishment in [RFC5245] and its Trickle ICE extension [I-D.ivov-mmusic-trickle-ice]. It is assumed that the reader will be familiar with the terminology from both of them.

3. Half vs Full Trickle

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 [RFC3840], 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]

4. Encoding and Sending Candidate Information

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 [I-D.ivov-mmusic-trickle-ice].

      INFO sip:alice@example.com SIP/2.0
      ...
      Info-Package: trickle-ice
      Content-type: application/sdp
      Content-Disposition: Info-Package
      Content-length: ...

      a=mid:1
      a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
      a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx
      a=m-line-id:2
      a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx
      a=end-of-candidates

          

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 [RFC3388] as follows:

5. Info Package

5.1. Overall Description

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.

5.2. Applicability

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.

5.3. INFO Package Name

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

5.4. INFO Package Parameters

This document does not define any INFO package parameters.

5.5. SIP Option-Tags

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

5.6. INFO Message Body Parts

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 Section 4 and [I-D.ivov-mmusic-trickle-ice].

6. Example Flows

  
   STUN/Turn                                                STUN/TURN
    Servers          Alice                      Bob          Servers
       |               |                         |               |
       |<--------------|                         |               |
       |               |                         |               |
       |               |                         |               |
       |   Candidate   |                         |               |
       |               |                         |               |
       |               |                         |               |
       |   Discovery   |                         |               |
       |               |                         |               |
       |               |                         |               |
       |-------------->|     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 =====>|               |
       |               |                         |               |