[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network Working Group                                            E. Ivov
Internet-Draft                                                     Jitsi
Intended status: Standards Track                              E. Marocco
Expires: August 3, 2013                                   Telecom Italia
                                                             C. Holmberg
                                                                Ericsson
                                                        January 30, 2013


       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 3, 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



Ivov, et al.             Expires August 3, 2013                 [Page 1]


Internet-Draft             Trickle ICE for SIP              January 2013


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





















Ivov, et al.             Expires August 3, 2013                 [Page 2]


Internet-Draft             Trickle ICE for SIP              January 2013


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



Ivov, et al.             Expires August 3, 2013                 [Page 3]


Internet-Draft             Trickle ICE for SIP              January 2013


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

   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:


         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




Ivov, et al.             Expires August 3, 2013                 [Page 4]


Internet-Draft             Trickle ICE for SIP              January 2013


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



Ivov, et al.             Expires August 3, 2013                 [Page 5]


Internet-Draft             Trickle ICE for SIP              January 2013


   MUST be of type 'application/sdp' as defined in Section 4 and
   [I-D.ivov-mmusic-trickle-ice].


6.  Example Flows

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


      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 =====>|               |
          |               |                         |               |




Ivov, et al.             Expires August 3, 2013                 [Page 6]


Internet-Draft             Trickle ICE for SIP              January 2013


                             Figure 1: Example


7.  Security Considerations

   [TODO]


8.  Acknowledgements

   [TODO]


9.  References

9.1.  Normative References

   [I-D.ivov-mmusic-trickle-ice]
              Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
              Incremental Provisioning of Candidates for the Interactive
              Connectivity Establishment (ICE) Protocol",
              draft-ivov-mmusic-trickle-ice-00 (work in progress),
              January 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [RFC6086]  Holmberg, C., Burger, E., and H. Kaplan, "Session
              Initiation Protocol (SIP) INFO Method and Package
              Framework", RFC 6086, January 2011.

9.2.  Informative References

   [I-D.keranen-mmusic-ice-address-selection]
              Keraenen, A. and J. Arkko, "Update on Candidate Address
              Selection for Interactive Connectivity Establishment



Ivov, et al.             Expires August 3, 2013                 [Page 7]


Internet-Draft             Trickle ICE for SIP              January 2013


              (ICE)", draft-keranen-mmusic-ice-address-selection-01
              (work in progress), July 2012.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3388]  Camarillo, G., Eriksson, G., Holler, J., and H.
              Schulzrinne, "Grouping of Media Lines in the Session
              Description Protocol (SDP)", RFC 3388, December 2002.

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [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, April 2010.


Appendix A.  Open issues

   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:
   1.  Should we allow for full trickle if support can be verified
       automatically and confirmed for a gruu with [RFC3840].
   2.  Can we pick between MID and stream indices for stream
       identification.









Ivov, et al.             Expires August 3, 2013                 [Page 8]


Internet-Draft             Trickle ICE for SIP              January 2013


Authors' Addresses

   Emil Ivov
   Jitsi
   Strasbourg  67000
   France

   Phone: +33 6 72 81 15 55
   Email: emcho@jitsi.org


   Enrico Marocco
   Telecom Italia
   Via G. Reiss Romoli, 274
   Turin  10148
   Italy

   Email: enrico.marocco@telecomitalia.it


   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com
























Ivov, et al.             Expires August 3, 2013                 [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/