Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8840.
Authors Emil Ivov , Thomas Stach , Enrico Marocco , Christer Holmberg
Last updated 2015-07-06
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Flemming Andreasen
IESG IESG state Became RFC 8840 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to "Flemming Andreasen" <fandreas@cisco.com>
draft-ietf-mmusic-trickle-ice-sip-02
Network Working Group                                            E. Ivov
Internet-Draft                                                     Jitsi
Intended status: Standards Track                                T. Stach
Expires: January 7, 2016                                    Unaffiliated
                                                              E. Marocco
                                                          Telecom Italia
                                                             C. Holmberg
                                                                Ericsson
                                                            July 6, 2015

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

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

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 January 7, 2016.

Ivov, et al.             Expires January 7, 2016                [Page 1]
Internet-Draft             Trickle ICE for SIP                 July 2015

Copyright Notice

   Copyright (c) 2015 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Rationale. Why INFO . . . . . . . . . . . . . . . . . . .   5
     3.2.  Discovery issues  . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Relationship with the Offer/Answer Model  . . . . . . . .   7
   4.  Incremental Signalling of ICE candidates  . . . . . . . . . .   9
     4.1.  Establishing the dialog . . . . . . . . . . . . . . . . .   9
       4.1.1.  Asserting dialog state through reliable Offer/Answer
               delivery  . . . . . . . . . . . . . . . . . . . . . .   9
       4.1.2.  Asserting dialog state through unreliable
               Offer/Answer delivery . . . . . . . . . . . . . . . .  10
       4.1.3.  Initiating Trickle ICE without an SDP Answer  . . . .  12
       4.1.4.  Considerations for 3PCC . . . . . . . . . . . . . . .  13
     4.2.  Delivering candidates in INFO messages  . . . . . . . . .  15
   5.  Initial discovery of Trickle ICE support  . . . . . . . . . .  18
     5.1.  Provisioning support for Trickle ICE  . . . . . . . . . .  18
     5.2.  Trickle ICE discovery with GRUU . . . . . . . . . . . . .  19
     5.3.  Trickle ICE discovery through other protocols . . . . . .  20
     5.4.  Fallback to Half Trickle  . . . . . . . . . . . . . . . .  20
   6.  Considerations for RTP and RTCP multiplexing  . . . . . . . .  22
   7.  Considerations for Media Multiplexing . . . . . . . . . . . .  22
   8.  Content Type 'application/sdpfrag'  . . . . . . . . . . . . .  23
     8.1.  Overall Description . . . . . . . . . . . . . . . . . . .  23
     8.2.  Grammar . . . . . . . . . . . . . . . . . . . . . . . . .  24
   9.  Info Package  . . . . . . . . . . . . . . . . . . . . . . . .  24
     9.1.  Overall Description . . . . . . . . . . . . . . . . . . .  24
     9.2.  Applicability . . . . . . . . . . . . . . . . . . . . . .  24
     9.3.  Info Package Name . . . . . . . . . . . . . . . . . . . .  25
     9.4.  Info Package Parameters . . . . . . . . . . . . . . . . .  25
     9.5.  SIP Option Tags . . . . . . . . . . . . . . . . . . . . .  25

Ivov, et al.             Expires January 7, 2016                [Page 2]
Internet-Draft             Trickle ICE for SIP                 July 2015

     9.6.  Info Message Body Parts . . . . . . . . . . . . . . . . .  25
     9.7.  Info Package Usage Restrictions . . . . . . . . . . . . .  26
     9.8.  Rate of INFO Requests . . . . . . . . . . . . . . . . . .  27
     9.9.  Info Package Security Considerations  . . . . . . . . . .  27
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
     10.1.  application/sdpfrag MIME Type  . . . . . . . . . . . . .  27
     10.2.  SIP Info Package 'trickle-ice' . . . . . . . . . . . . .  28
     10.3.  SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . .  29
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  29
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  29
   13. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  29
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  30
     14.2.  Informative References . . . . . . . . . . . . . . . . .  31
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1.  Introduction

   The Interactive Connectivity Establishment protocol [RFC5245] (a.k.a.
   Vanilla ICE) describes a mechanism for NAT traversal that consists of
   three main phases: a phase where an agent gathers a set of candidate
   transport addresses (source IP address, port and transport protocol),
   a second phase where these candidates are sent to a remote agent and
   this gathering procedure is repeated and, finally, a third phase
   where connectivity between all candidates in both sets is checked
   (connectivity checks).  Once these phases have been completed, and
   only then, can both agents begin communication.  According to the
   Vanilla ICE specification the three phases above happen
   consecutively, in a blocking way, which can introduce undesirable
   latency during session establishment.

   The Trickle ICE extension defined in [I-D.ietf-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)[RFC3261].  It describes how ICE candidates
   are to be incrementally exchanged with SIP INFO requests and how the
   Half Trickle and Full Trickle modes defined in
   [I-D.ietf-mmusic-trickle-ice] 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 [RFC6086]
   for use with Trickle ICE.

Ivov, et al.             Expires January 7, 2016                [Page 3]
Internet-Draft             Trickle ICE for SIP                 July 2015

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.ietf-mmusic-trickle-ice].  It is
   assumed that the reader will be familiar with the terminology from
   both of them.

3.  Protocol Overview

   The semantics that Vanilla ICE [RFC5245] defines for exchanging ICE
   candidates are exclusively based on use of Offers and Answers as per
   [RFC3264] over the Session Description Protocol (SDP) [RFC4566].
   This specification extends these mechanism by allowing ICE candidates
   to also be sent in parallel to the Offer/Answer negotiation or after
   the completion of Offer/Answer negotiation.  This extension is done
   through the use of SIP INFO messages and a newly defined Info Package
   [RFC6086].

   Typically, in cases where Trickle ICE is fully supported, a candidate
   exchange would happen along the following lines: The Offerer would
   send an INVITE containing a subset of candidates and then wait for an
   early dialog to be established.  Once that happens, it will be able
   to continue sending candidates through in INFO requests and within
   the same dialog.

   Similarly, an Answerer can start or continue "trickling" ICE
   candidates using INFO messages within the dialog established by its
   18x provisional response.  Figure 1 shows such a sample exchange:

Ivov, et al.             Expires January 7, 2016                [Page 4]
Internet-Draft             Trickle ICE for SIP                 July 2015

      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          |                |
          |               |------------------------>|                |
          |               |                         |                |
          |               |    5245 SIP re-INVITE   |                |
          |               |------------------------>|                |
          |               |          200 OK         |                |
          |               |<------------------------|                |
          |               |            ACK          |                |
          |               |------------------------>|                |
          |               |                         |                |
          |               |<===== MEDIA FLOWS =====>|                |
          |               |                         |                |

              Figure 1: Sample Trickle ICE scenario with SIP

3.1.  Rationale.  Why INFO

   The decision to use SIP INFO requests as a candidate transport method
   is based primarily on their lightweight nature.  Once a dialog has
   been established, INFO messages can be exchanged both ways with no
   restrictions on timing and frequency and no risk of collision.

   On the other hand, using Offer/Answer and UPDATE requests, which from
   an [RFC5245] perspective is the traditional way of transporting ICE
   candidates, introduces the following complications:

   Need for a non-blocking mechanism:   [RFC3264] defines Offer/Answer
      as a strictly sequential mechanism.  There can only be a maximum
      of one exchange at any point of time.  Both sides cannot
      simultaneously send Offers nor can they generate multiple Offers
      prior to receiving an Answer.  Using UPDATEs for candidate

Ivov, et al.             Expires January 7, 2016                [Page 5]
Internet-Draft             Trickle ICE for SIP                 July 2015

      transport would therefore imply the implementation of a candidate
      pool at every agent where candidates can be stored until it is
      once again that agent's "turn" to emit an Answer or a new Offer.
      Such an approach would introduce non-negligible complexity for no
      additional value.

   Elevated risk of glare:   The sequential nature of Offer/Answer also
      makes it impossible for both sides to send Offers simultaneously.
      What's worse is that there are no mechanisms in SIP to actually
      prevent that.  [RFC3261], where the situation of Offers crossing
      on the wire is described as "glare", only defines a procedure for
      addressing the issue after it has occurred.  According to that
      procedure both Offers are invalidated and both sides need to retry
      the negotiation after a period between 0 and 4 seconds.  The high
      likelihood for glare to occur and the average two second backoff
      intervals would imply Trickle ICE processing duration would not
      only fail to improve but actually exceed those of Vanilla ICE.

   INFO messages decouple the exchange of candidates from the Offer/
   Answer negotiation and are subject to none of the glare issues
   described above, which makes them a very convenient and lightweight
   mechanism for asynchronous delivery of candidates.

   Using in-dialog INFO messages also provides a way of guaranteeing
   that candidates are delivered end-to-end, between the same entities
   that are actually in the process of initiating a session.  The
   alternative would have implied requiring support for Globally
   Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low
   adoption levels, would have constituted too strong of constraint to
   the adoption of Trickle ICE.

3.2.  Discovery issues

   In order for 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,
   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 actually using it.

   Contrary to other protocols, like XMPP [RFC6120], where "in advance"
   capability discovery is widely implemented, the mechanisms that allow
   this for SIP (i.e., a combination of UA Capabilities [RFC3840] and
   GRUU [RFC5627]) 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.

Ivov, et al.             Expires January 7, 2016                [Page 6]
Internet-Draft             Trickle ICE for SIP                 July 2015

   The Half Trickle mode of operation defined in the Trickle ICE
   specification [I-D.ietf-mmusic-trickle-ice] provides one way around
   this, by requiring first Offers to contain a complete set of ICE
   candidates and only using incremental provisioning for the rest of
   the sessions.

   While using Half Trickle does provide a working solution it also
   comes at the price of increased latency.  Section 5 therefore 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 on-line provisioning as a means of allowing 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.4 discusses the implementation
   and use of Half Trickle by SIP UAs where none of the above are an
   option.

3.3.  Relationship with the Offer/Answer Model

   It is important to note that this specification does not require,
   define, or even assume any mechanisms that would have an impact on
   the Offer/Answer model beyond the way it is already used by Vanilla
   ICE [RFC5245].  From the perspective of all SIP middle boxes and
   proxies, and with the exception of the actual INFO messages,
   signalling in general and Offer/Answer exchanges in particular would
   look the same way for Trickle ICE as they would for Vanilla ICE.

Ivov, et al.             Expires January 7, 2016                [Page 7]
Internet-Draft             Trickle ICE for SIP                 July 2015

   +-------------------------------+  +-------------------------------+
   |   Alice      +--------------+ |  | +--------------+       Bob    |
   |              | Offer/Answer | |  | | Offer/Answer |              |
   | +-------+    |    Module    | |  | |    Module    |    +-------+ |
   | |  ICE  |    +--------------+ |  | +--------------+    |  ICE  | |
   | | Agent |          |          |  |        |            | Agent | |
   | +-------+          |          |  |        |            +-------+ |
   +-------------------------------+  +-------------------------------+
         |              |                      |                |
         |              |    INVITE (Offer)    |                |
         |              |--------------------->|                |
         |              |     183 (Answer)     |                |
         |              |<---------------------|                |
         |              |                      |                |
         |                                                      |
         |             SIP INFO (more candidates)               |
         |----------------------------------------------------->|
         |             SIP INFO (more candidates)               |
         |<-----------------------------------------------------|
         |                                                      |
         |          STUN Binding Requests/Responses             |
         |----------------------------------------------------->|
         |          STUN Binding Requests/Responses             |
         |<-----------------------------------------------------|
         |                                                      |
         |              |                      |                |
         |              |  5245 SIP re-INVITE  |                |
         |              |--------------------->|                |
         |              |        200 OK        |                |
         |              |<---------------------|                |

       Figure 2: Distinguishing between Trickle ICE and traditional
                                signalling.

   It is important to note that, as displayed on Figure 2, exchanging
   candidates through SIP INFO messages are best represented as
   signalling between ICE agents and not between the traditional SIP and
   Offer/Answer modules of SIP User Agents.  Such INFO requests do not
   impact the state of Offer/Answer, nor do they have an impact on the
   version number in the "o=" line.  In that regard they are actually
   comparable to Peer Reflexive candidates that ICE agents can discover
   during ICE processing.

Ivov, et al.             Expires January 7, 2016                [Page 8]
Internet-Draft             Trickle ICE for SIP                 July 2015

4.  Incremental Signalling of ICE candidates

   Trickle ICE agents will construct Offers and Answers as specified in
   [I-D.ietf-mmusic-trickle-ice] with the following additional SIP-
   specific additions:

   1.  Trickle ICE agents MUST indicate support for Trickle ICE by
       including the option-tag 'trickle-ice' in a SIP Supported: header
       field within all SIP INVITE requests and responses.

   2.  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 messages
       carry an Info-Package: trickle-ice.  Trickle ICE agents MUST be
       prepared to receive INFO requests within that same dialog usage,
       containing additional candidates or an indication for the end of
       such candidates

   3.  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 will exist.

   The following section provide further details on how Trickle ICE
   agents establish the INVITE dialog usage such that they can trickle
   candidates.

4.1.  Establishing the dialog

   In order for SIP UAs to be able to start trickling, the following two
   conditions need to be satisfied:

   o  Trickle ICE support in the peer agent MUST be confirmed.

   o  The SIP dialog at both sides MUST be at least in the early state.

   Section 5 discusses in detail the various options for satisfying the
   first of the above conditions.  Regardless of those mechanisms
   however, 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.1.1.  Asserting dialog state through reliable Offer/Answer delivery

Ivov, et al.             Expires January 7, 2016                [Page 9]
Internet-Draft             Trickle ICE for SIP                 July 2015

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

    Figure 3: SIP Offerer can freely trickle as soon as it receives an
                                  Answer.

   Satisfying both conditions is also relatively trivial for ICE agents
   that have sent an Offer in an INVITE and that have received an Answer
   in a reliable provisioanl response.  It is guaranteed to have
   confirmed support for Trickle ICE within the Answerer (or lack
   thereof) and to have fully initialized the SIP dialog at both ends.
   Offerers and Answerers in the above situation can therefore freely
   commence trickling within the newly established dialog.

4.1.2.  Asserting 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 no know when or if it has been received (Figure 4).

Ivov, et al.             Expires January 7, 2016               [Page 10]
Internet-Draft             Trickle ICE for SIP                 July 2015

                   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 and 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 [RFC3262].  Retransmits MUST cease on
   receipt of a INFO request or on transmission of the answer in a 2xx
   response.  This is similar to the procedure described in section
   12.1.1 of [RFC5245] except that the STUN binding Request is replaced
   by the INFO request.

   The Offerer MUST send a Trickle ICE INFO request as soon as they
   receive an SDP Answer in an unreliable provisional response.  This
   INFO message can 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) or they can
   also deliver new new candidates (if available).  An end-of-candidates
   indication MAY be included in case candidate discovery has ended in
   the mean time.

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

Ivov, et al.             Expires January 7, 2016               [Page 11]
Internet-Draft             Trickle ICE for SIP                 July 2015

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

     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, the Answerers MUST
   repeat exactly the same Answer that was previously sent in the
   unreliable provisional response in order to fulfill the corresponding
   requirements in [RFC3264].  In other words, that Offerer needs to be
   prepared to receive less candidates in that repeated Answer than
   previously exchanged via trickling.

4.1.3.  Initiating Trickle ICE without an SDP Answer

   The possibility to convey arbitrary SDP fragments in SIPfrag message
   bodies [I-D.ivov-mmusic-sdpfrag] allows ICE agents to initiate
   trickling without actually sending an Answer.  Trickle ICE Agents MAY
   therefore respond to INVITEs with provisional responses without an
   Answer that only serve for establishing an early dialog.

   Agents that choose to establish the dialog in this way, M UST
   retransmit these responses with the exponential backoff timers
   described in [RFC3262].  Retransmits MUST cease on receipt of an INFO
   request or on transmission of the answer in a 2xx response.  This is
   again similar to the procedure described in section 12.1.1 of
   [RFC5245] except that an Answer is not yet provided.

Ivov, et al.             Expires January 7, 2016               [Page 12]
Internet-Draft             Trickle ICE for SIP                 July 2015

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

    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 previously sent
   candidates, if any, and MAY include all newly gathered candidates
   since the last INFO request was sent.  If that answer was sent in a
   unreliable provisional response, the Answerers MUST repeat exactly
   the same Answer in the 200 OK response in order to fulfill the
   corresponding requirements in [RFC3264].  In other words, an Offerer
   needs to be prepared to receive less candidates in that repeated
   Answer than previously exchanged via trickling.

4.1.4.  Considerations for 3PCC

   Agents that have sent an Offer in a reliable provisional response and
   that receive an Answer in a PRACK are also in a situation where
   support for Trickle ICE is confirmed and the SIP dialog is guaranteed
   to be in a state that would allow in-dialog INFO requests (see
   Figure 7).

Ivov, et al.             Expires January 7, 2016               [Page 13]
Internet-Draft             Trickle ICE for SIP                 July 2015

                   Alice                      Bob
                     |                         |
                     |        INVITE           |
                     |------------------------>|
                     |      183 (Offer)        |
                     |<------------------------|
                     |     PRACK (Answer)      |
                     |------------------------>|
                     |                         |
                     |               +----------------------+
                     |               |Bob:  I know Alice can|
                     |               |trickle and I know her|
                     |               |dialog is in the early|
                     |               |state. Send INFO!     |
                     |               +----------------------+
                     |                         |
                     |  INFO/OK (SRFLX Cand.)  |
                     |<------------------------|
                     |                         |
                     |  INFO/OK (SRFLX Cand.)  |
                     |------------------------>|
                     |     200 OK/ACK          |
                     |<------------------------|

     Figure 7: A SIP Offerer in a 3PCC scenario can also freely start
                trickling as soon as it receives an Answer.

   Trickle Agents that send an Offer in a 200 OK and receive an Answer
   in an ACK can still create a dialog and confirm support for Trickle
   ICE by sending an unreliable provisional response similar to
   Section 4.1.3.  According to [RFC3261], this unreliable response MUST
   NOT contain an Offer.

   The Trickle Agent (at the UAS) retransmits the provisional response
   with the exponential backoff timers described in [RFC3262].
   Retransmits MUST cease on receipt of a INFO request or on
   transmission of the answer in a 2xx response.  The peer Trickle Agent
   (at the UAC) MUST send a Trickle ICE INFO request as soon as they
   receive an unreliable provisional response (see Figure 8).

Ivov, et al.             Expires January 7, 2016               [Page 14]
Internet-Draft             Trickle ICE for SIP                 July 2015

                   Alice                      Bob
                     |                         |
                     |        INVITE           |
                     |------------------------>|
                     |      183 (-)            |
                     |<------------------------|
                     |  INFO/OK (SRFLX Cand.)  |
                     |------------------------>|
                     |                         |
                     |               +-----------------------+
                     |               |Bob:  I know Alice can |
                     |               |trickle and I know her |
                     |               |dialog is in the early |
                     |               |state.                 |
                     |               |INFO can be sent.      |
                     |               +-----------------------+
                     |                         |
                     |  INFO/OK (SRFLX Cand.)  |
                     |<------------------------|
                     |                         |
                     |      200 (Offer)        |
                     |<------------------------|
                     |       ACK (Answer)      |
                     |------------------------>|
                     |                         |

       Figure 8: A SIP UAC in a 3PCC scenario can also freely start
   trickling as soon as it receives an unreliable provisional response.

4.2.  Delivering candidates in INFO messages

   Whenever new ICE candidates become available for sending, agents
   would encode them in "a=candidate" lines as described by
   [I-D.ietf-mmusic-trickle-ice].  For example:

           a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
                     raddr 10.0.1.1 rport 8998

   The use of SIP INFO requests happens within the context of the Info
   Package as defined Section 9.  The MIME type for their payload MUST
   be set to 'application/sdpfrag' as defined in Section 8.

   Since neither the "a=candidate" nor the "a=end-of-candidates"
   attributes contain information that would allow correlating them to a
   specific "m=" line, this is handled through the use of pseudo "m="
   lines and identification tags in "a=mid:" attributes as defined in

Ivov, et al.             Expires January 7, 2016               [Page 15]
Internet-Draft             Trickle ICE for SIP                 July 2015

   [RFC5888].  Pseudo "m=" lines follow the SDP syntax for "m=" lines as
   defined in [I-D.ietf-mmusic-rfc4566bis], but provide no semantics
   other than indicating to which "m=" line a candidate belongs.
   Consequently, the receiving agent MUST ignore the remaining content
   of the pseudo m-line.  This guarantees that the 'application/sdpfrag'
   bodies do not interfere with the Offer/Answer procedures as specified
   in [RFC3264].

   When sending the INFO request, the agent MAY, if already known to the
   agent, include the same content into the pseudo m-line as for the
   corresponding Offer or Answer.  However, since Trickle-ICE might be
   decoupled from the Offer/Answer negotiation this content might be
   unknown to the agent.  In this case, the agent MUST include the
   following default values.

   o  The media is set to 'audio'.

   o  The port value is set to '9'.

   o  The proto value is set to 'RTP/AVP'.

   o  The fmt SHOULD appear only once and is set to '0'

   Agents MUST include a pseudo "m=" line and an identification tag in a
   "a=mid:" attribute for every "m=" line whose candidate list they
   intend to update.  Such "a=mid:" attributes MUST immediately precede
   the list of candidates for that specific "m=" line.  All
   "a=candidate" or "a=end-of-candidates" attributes following an
   "a=mid:" attribute, up until (and excluding) the next occurrence of
   an "a=mid:" attribute, pertain to the "m=" line identified by that
   identification tag.  An "a=end-of-candidates" attribute, preceding
   any "a=mid:" attributes, indicates the end of all trickling from that
   agent, as opposed to end of trickling for a specific "m=" line, which
   would be indicated by a media level "a=end-of-candidates" attribute.

   The use of "a=mid:" attributes allows for a structure similar to the
   one in SDP Offers and Answers where separate media-level and session-
   level sections can be distinguished.  In the current case, lines
   preceding any "a=mid:" attributes are considered to be session-level.
   Lines appearing in between or after "a=mid:" attributes will be
   interpreted as media-level.

      Note that while this specification uses the "a=mid:" attribute
      from [RFC5888], it does not define any grouping semantics.
      Consequently, using the "a=group:" attribute from that same
      specification is neither needed nor used in Trickle ICE for SIP.

Ivov, et al.             Expires January 7, 2016               [Page 16]
Internet-Draft             Trickle ICE for SIP                 July 2015

   All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:"
   attributes that would allow mapping them to a specific ICE
   generation.  INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:"
   attributes that do not match those of the current ICE processing
   session MUST be discarded.  The "a=ice-pwd:" and "a=ice-ufrag:"
   attributes MUST appear at the same level as the ones in the Offer/
   Answer exchange.  In other words, if they were present as sesssion-
   level attributes there, they will also appear at the beginning of all
   INFO message payloads, preceding all "a=mid:" attributes.  If they
   were originally exchanged as media level attributes, potentially
   overriding session-level values, then they will also be included in
   INFO message payloads, following the corresponding "a=mid:"
   attribute.

   In every INFO request agents MUST include all local candidates they
   have previously signalled.  This is necessary in order to more easily
   avoid problems that would arise from unreliability.  Misordering can
   be detected through the CSeq: header field in the INFO request.

   When receiving INFO requests carrying any candidates, agents will
   therefore first identify and discard the SDP lines containing
   candidates they have already received in previous INFO requests or in
   the Offer/Answer exchange preceding them.  Two candidates are
   considered to be equal if their IP address port, transport and
   component ID are the same.  After identifying and discarding known
   candidates, agents will then process the remaining, actually new
   candidates according to the rules described in
   [I-D.ietf-mmusic-trickle-ice].

   The following example shows the content of one sample candidate
   delivering INFO request:

Ivov, et al.             Expires January 7, 2016               [Page 17]
Internet-Draft             Trickle ICE for SIP                 July 2015

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

         a=ice-pwd:asd88fgpdd777uzjYhagZg
         a=ice-ufrag:8hhY
         m=audio 9 RTP/AVP 0
         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
                 raddr 10.0.1.1 rport 8998
         a=end-of-candidates
         m=audio 9 RTP/AVP 0
         a=mid:2
         a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx
                 raddr 10.0.1.1 rport 9000
         a=end-of-candidates

5.  Initial discovery of Trickle ICE support

   SIP User Agents (UAs) that support and intend to use trickle ICE are
   REQUIRED by [I-D.ietf-mmusic-trickle-ice] to indicate that in their
   Offers and Answers using the following attribute: "a=ice-
   options:trickle".  This makes discovery fairly straightforward for
   Answerers or for cases where Offers need to be generated within
   existing dialogs (i.e., when sending re-INVITE requests).  In both
   scenarios prior SDP would have provided the necessary information.

   Obviously, prior SDP is not available at the time a first Offer is
   being constructed and it is therefore impossible for ICE agents to
   determine support for incremental provisioning that way.  The
   following options are suggested as ways of addressing this issue.

5.1.  Provisioning support for Trickle ICE

   In certain situations it may be possible for integrators deploying
   Trickle ICE to know in advance that some or all endpoints reachable
   from within the deployment will support Trickle ICE.  This is likely
   to be the case, for example, for WebRTC clients that will always be
   communicating with other WebRTC clients or known Session Border
   Controllers (SBC) with support for this specification.

Ivov, et al.             Expires January 7, 2016               [Page 18]
Internet-Draft             Trickle ICE for SIP                 July 2015

   While the exact mechanism for allowing such provisioning is out of
   scope here, this specification encourages trickle ICE implementations
   to allow the option in the way they find most appropriate.

5.2.  Trickle ICE discovery with GRUU

   [RFC3840] provides a way for SIP user agents to query for support of
   specific capabilities using, among others, OPTIONS requests.  GRUU
   support on the other hand allows SIP requests to be addressed to
   specific UAs (as opposed to arbitrary instances of an address of
   record).  Combining the two and using the "trickle-ice" option tag
   defined in Section 9.5 provides SIP UAs with a way of learning the
   capabilities of specific US instances and then addressing them
   directly with INVITE requests that require SIP support.

   Such targeted trickling may happen in different ways.  One option
   would be for a SIP UA to learn the GRUU instance ID of a peer through
   presence and to then query its capabilities direction with an OPTIONS
   request.  Alternately, it can also just send an OPTIONS request to
   the AOR it intends to contact and then inspect the returned
   response(s) for support of both GRUU and Trickle ICE (Figure 9).

            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 |
              |-------------------------------------------------->|
              |                                                   |
              |                  183 (Answer)                     |
              |<--------------------------------------------------|
              |                INFO/OK (Trickling)                |
              |<------------------------------------------------->|
              |                                                   |
              |                      ...                          |
              |                                                   |

       Figure 9: Trickle ICE support discovery with OPTIONS and GRUU

Ivov, et al.             Expires January 7, 2016               [Page 19]
Internet-Draft             Trickle ICE for SIP                 July 2015

   Confirming support for Trickle ICE through [RFC3840] gives SIP UAs
   the options to engage in Full Trickle negotiation (as opposed to the
   more lengthy Half Trickle) from the very first Offer they send.

5.3.  Trickle ICE discovery through other protocols

   Protocols like XMPP [RFC6120] define advanced discovery mechanisms
   that allow specific features to be queried priory to actually
   attempting to use them.  Solutions like [RFC7081] define ways of
   using SIP and XMPP together which also provides a way for dual stack
   SIP+XMPP endpoints to make use of such features and verify Trickle
   ICE support for a specific SIP endpoint through XMPP.  [TODO expand
   on a specific way to do this or declare as out of scope]

5.4.  Fallback to Half Trickle

   In cases where none of the other mechanisms in this section are
   acceptable, SIP UAs should use the Half Trickle mode defined in
   [I-D.ietf-mmusic-trickle-ice].  With Half Trickle, agents initiate
   sessions the same way they would when using Vanilla ICE [RFC5245].
   This means that, prior to actually sending an Offer, agents would
   first gather ICE candidates in a blocking way and then send them all
   in that Offer.  The blocking nature of the process would likely imply
   that some amount of latency will be accumulated and it is advised
   that agents try to anticipate it where possible, like for example,
   when user actions indicate a high likelyhood for an imminent call
   (e.g., activity on a keypad or a phone going offhook).

   Using Half Trickle would result in Offers that are compatible with
   both Vanilla ICE and legacy [RFC3264] endpoints.

Ivov, et al.             Expires January 7, 2016               [Page 20]
Internet-Draft             Trickle ICE for SIP                 July 2015

      STUN/Turn                                                STUN/TURN
       Servers          Alice                      Bob          Servers
          |               |                         |               |
          |<--------------|                         |               |
          |               |                         |               |
          |               |                         |               |
          |   Candidate   |                         |               |
          |               |                         |               |
          |               |                         |               |
          |   Discovery   |                         |               |
          |               |                         |               |
          |               |                         |               |
          |-------------->|     INVITE (Offer)      |               |
          |               |------------------------>|               |
          |               |      183 (Answer)       |-------------->|
          |               |<------------------------|               |
          |               |                         |               |
          |               |  INFO (more candidates) |   Candidate   |
          |               |<------------------------|               |
          |               |  Connectivity Checks    |               |
          |               |<=======================>|   Discovery   |
          |               | INFO (more candidates)  |               |
          |               |<------------------------|               |
          |               |  Connectivity Checks    |<--------------|
          |               |<=======================>|               |
          |               |                         |               |
          |               |          200 OK         |               |
          |               |<------------------------|               |
          |               |                         |               |
          |               |    5245 SIP re-INVITE   |               |
          |               |------------------------>|               |
          |               |          200 OK         |               |
          |               |<------------------------|               |
          |               |                         |               |
          |               |                         |               |
          |               |<===== MEDIA FLOWS =====>|               |
          |               |                         |               |

    Figure 10: Example - A typical (Half) Trickle ICE exchange with SIP

   It is worth reminding that once a single Offer or Answer had been
   exchanged within a specific dialog, support for Trickle ICE will have
   been determined.  No further use of Half Trickle will therefore be
   necessary within that same dialog and all subsequent exchanges can
   use the Full Trickle mode of operation.

Ivov, et al.             Expires January 7, 2016               [Page 21]
Internet-Draft             Trickle ICE for SIP                 July 2015

6.  Considerations for RTP and RTCP multiplexing

   [OPEN ISSUE: These considerations are of general relevance
   and might be better suited for draft-ietf-mmusic-trickle-ice.]

   The following consideration describe options for Trickle-ICE in order
   to give some guidance to implementors on how trickling can be
   optimized with respect to providing RTCP candidates.  However, these
   considerations are neither meant to be exhaustive nor guaranteed to
   be suitable for all sorts of deployments.

   Handling of RTP and RCTP multiplexing [RFC5761] is already considered
   in sections 4.1.1.1, 4.3, and 5.7.1 of [RFC5245], respectively.
   These considerations are still valid for Trickle ICE, however,
   trickling provides more flexibility for the sequence of candidate
   exchange, e.g. in case of RTCP multiplexing.

   While a Half Trickle Offerer would have to send an offer compliant to
   [RFC5245] including candidates for all components, this flexibility
   allows a Full Trickle Offerer to initially send only RTP candidates
   (component 1) if it assumes that RTCP multiplexing is supported by
   the Answerer.  A Full Trickle Offerer would need to start gathering
   and trickling RTCP candidates (component 2) only after having
   received an indication in the answer that the answerer unexpectedly
   does not support RTCP multiplexing.

   A Trickle answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in
   the application/sdp-frag body if it supports and uses RTP and RCTP
   multiplexing.  Receipt of this attribute at the Offerer in an INFO
   request prior to the Answer indicates that the Answerer supports and
   uses RTP and RCTP multiplexing.  The Offerer can use this information
   e.g. for stopping gathering of RTCP candidates and/or for freeing
   corresponding resources.

7.  Considerations for Media Multiplexing

   [OPEN ISSUE: These considerations are of general relevance
   and might be better suited for draft-ietf-mmusic-trickle-ice.]

   The following consideration describe options for Trickle-ICE in order
   to give some guidance to implementors on how trickling can be
   optimized with respect to providing candidates in case of Media
   Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation].  However,
   these considerations are neither meant to be exhaustive nor
   guaranteed to be suitable for all sorts of deployments.

   ICE candidate exchange is already considered in section 11 of
   [I-D.ietf-mmusic-sdp-bundle-negotiation].  These considerations are

Ivov, et al.             Expires January 7, 2016               [Page 22]
Internet-Draft             Trickle ICE for SIP                 July 2015

   still valid for Trickle ICE, however, trickling provides more
   flexibility for the sequence of candidate exchange, especially in
   Full Trickle mode.

   Except for bundle-only m-lines, a Half Trickle Offerer would have to
   send an offer with candidates for all bundled m-lines.  The
   additional flexibility, however, allows a Full Trickle Offerer to
   initially send only candidates for the m-line with the suggested
   offerer BUNDLE address.

   Latest on receipt of the answer, the Offerer will detect if BUNDLE is
   supported and if the suggested offerer BUNDLE address was selected.
   In this case the Offerer does need to trickle further candidates for
   the remaining m-lines in a bundle.  However, if BUNDLE is not
   supported, the Full Trickle Offerer needs to gather and trickle
   candidates for the remaining m-lines as necessary.  If the answerer
   selects a Offerer BUNDLE address different from suggested Offerer
   BUNDLE address, the Full Trickle Offerer needs to gather and trickle
   candidates for the m-line that carries the selected Offerer BUNDLE
   address.

   A Trickle answerer MAY include an "a=group: BUNDLE" attribute
   [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/sdp-frag
   body if it supports and uses bundling.  When doing so, the Answerer
   MUST include all identification-tags in the same order that is used
   or will be used in the Answer.

   Receipt of this attribute at the Offerer in an INFO request prior to
   the Answer indicates that the Answerer supports and uses bundling.
   The Offerer can use this information e.g. for stopping the gathering
   of candidates for the remaining m-lines in a bundle and/or for
   freeing corresponding resources.

8.  Content Type 'application/sdpfrag'

8.1.  Overall Description

   A valid application/sdpfrag part could be obtained by starting with
   some valid SDP session description [I-D.ietf-mmusic-rfc4566bis] and
   deleting any number of lines.

   The exact content of an 'application/sdpfrag' body MUST be specified
   the using protocol.  This document specifies the content for usage
   with Trickle ICE.

Ivov, et al.             Expires January 7, 2016               [Page 23]
Internet-Draft             Trickle ICE for SIP                 July 2015

8.2.  Grammar

   This section provides an Augmented BNF grammar for SDP.  ABNF is
   defined in [RFC5234].

   The ABNF of an 'application/sdpfrag' body is based on
   [I-D.ietf-mmusic-rfc4566bis] with the following modification

      ; SDPfrag Syntax
             sdp-frag = *1proto-version
                        *1origin-field
                        *1session-name-field
                        *1information-field
                        *1uri-field
                        *1email-fields
                        *1phone-fields
                        *1connection-field
                        *1bandwidth-fields
                        *1time-fields
                        *1key-field
                        *1attribute-fields
                        *1media-descriptions

9.  Info Package

9.1.  Overall Description

   This specification defines an Info Package for use by SIP user agents
   implementing Trickle ICE.  INFO requests carry ICE candidates
   discovered after the peer user agents have confirmed mutual support
   for Trickle ICE.

9.2.  Applicability

   The purpose 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 are part of this establishment.

   Candidates sent by a Trickle ICE agent after the Offer, 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 without GRUU
   support.  Using out-of-dialog SUBSCRIBE/NOTIFY requests would not
   satisfy this goal.

Ivov, et al.             Expires January 7, 2016               [Page 24]
Internet-Draft             Trickle ICE for SIP                 July 2015

9.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"

9.4.  Info Package Parameters

   This document does not define any Info Package parameters.

9.5.  SIP Option Tags

   [RFC6086] allows Info Package specifications to define SIP option-
   tags.  This specification extends the option-tag construct of the SIP
   grammar as follows:

    option-tag /= "trickle-ice"

   SIP entities that support this specification MUST place the 'trickle-
   ice' option-tag in a SIP Supported: 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:
   header field.

9.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/sdpfrag' as defined in Section 4.2 and
   [I-D.ietf-mmusic-trickle-ice].

   The Trickle-ICE Info Package uses only a subset of the possible SDP
   Fragments that are allowed based on the grammar defined in
   Section 8.2.  The package uses only media descriptions and certain
   attributes that are needed or useful for trickling candidates.  This
   subset adheres to the following grammar.

Ivov, et al.             Expires January 7, 2016               [Page 25]
Internet-Draft             Trickle ICE for SIP                 July 2015

   ;  Syntax
      trickle-ice-sdpfrag =   session-level-fields
                              pseudo-media-descriptions
      session-level-fields = [bundle-group-attribute CRLF]
                             [ice-lite-attribute CRLF]
                              ice-pwd-attribute CRLF
                              ice-ufrag-attribute CRLF
                             [ice-options-attribute CRLF]
                                                         [end-of-candidates-attribute CRLF]
                              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-options-attribute  =  %s"a="  ice-options
      bundle-group-attribute = "a=group:" bundle-semantics
                                *(SP identification-tag)
      bundle-semantics = "BUNDLE"
          end-of-candidates-attribute  = %s"a=" end-of-candidates-att
      extension-attribute-fields   = attribute-fields

      pseudo-media-descriptions    =  *( media-field
                                         trickle-ice-attribute-fields
                                        [extension-attribute-fields] ) ; for future extensions
      trickle-ice-attribute-fields =    mid-attribute CRLF
                                       ["a=rtcp-mux" CRLF]
                                      *(candidate-attributes CRLF)
                                       [remote-candidate-attribute CRLF]
                                       [end-of-candidates-attribute CRLF]
          remote-candidate-attribute   = %s"a=" remote-candidate-att
          candidate-attributes         = %s"a=" candidate-attribute

   with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-
   options, candidate-attribute remote-candidate-att from [RFC5245],
   identification-tag, mid-attribute ; from [RFC5888], media-field,
   attribute-fields from [I-D.ietf-mmusic-rfc4566bis] and end-of-
   candidates-att from [I-D.ietf-mmusic-trickle-ice].  The indicator for
   case-sensitivity %s is defined in [RFC7405].

   [NOTE: end-of-candidates-att currently lacks a formal definition in
   [I-D.ietf-mmusic-trickle-ice]]

9.7.  Info Package Usage Restrictions

   This document does not define any Info Package Usage Restrictions.

Ivov, et al.             Expires January 7, 2016               [Page 26]
Internet-Draft             Trickle ICE for SIP                 July 2015

9.8.  Rate of INFO Requests

   A Trickle ICE Agent with many network interfaces might create an
   excessive rate of INFO requests if every newly detected candidate is
   trickled individually without aggregation.  Therefore, Trickle ICE
   Agent SHOULD wait for XXX ms or longer after the latest INFO request
   was sent before for sending newly detected candidates in a subsequent
   INFO request.

   [OPEN ISSUE: What rate will give a good trade-off? 100ms, 200ms?]

9.9.  Info Package Security Considerations

   See section Section 11

10.  IANA Considerations

   [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
   document.]

10.1.  application/sdpfrag MIME Type

      Type name: application

      Subtype name: sdpfrag

      Required parameters: None.

      Optional parameters: None.

      Encoding considerations:

         SDP files are primarily UTF-8 format text.  The "a=charset:"
         attribute may be used to signal the presence of other character
         sets in certain parts of an SDP file (see
         [I-D.ietf-mmusic-rfc4566bis]).  Arbitrary binary content cannot
         be directly represented in SDP.

      Security considerations:

         See [I-D.ietf-mmusic-rfc4566bis]) and RFCXXXX

      Interoperability considerations:

Ivov, et al.             Expires January 7, 2016               [Page 27]
Internet-Draft             Trickle ICE for SIP                 July 2015

         See RFCXXXX

      Published specification:

         See RFCXXXX

      Applications which use this media type:

         Voice over IP, video teleconferencing, streaming media, instant
         messaging, Trickle-ICE among others.

      Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh File Type Code(s): none

      Person and email address to contact for further information:

         IETF MMUSIC working group mmusic@ietf.org

      Intended usage:

         Trickle-ICE for SIP as specified in RFCXXXX.  Further usages
         need a specification on the exact content of an 'application/
         sdpfrag' body in the using protocol.

      Author/Change controller:

         IETF MMUSIC working group mmusic@ietf.org

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

Ivov, et al.             Expires January 7, 2016               [Page 28]
Internet-Draft             Trickle ICE for SIP                 July 2015

       +-------------+-----------+
       | Name        | Reference |
       +-------------+-----------+
       | trickle-ice | [RFCXXXX] |
       |             |           |
       +-------------+-----------+

10.3.  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] and updates the
   "Option Tags" section of the SIP Parameter Registry with the
   following entry:

    +-------------+-------------------------------------------+-----------+
    | Name        | Description                               | Reference |
    +-------------+-------------------------------------------+-----------+
    | trickle-ice | This option tag is used to indicate that  | [RFCXXXX] |
    |             | a UA supports and understands Trickle-ICE |           |
    +-------------+-------------------------------------------+-----------+

11.  Security Considerations

   The Security Considerations of [RFC5245], [RFC6086],
   [I-D.ietf-mmusic-trickle-ice] apply.  This document clarifies how the
   above specifications are used together for trickling candidates and
   does not create addtitional security risks.

12.  Acknowledgements

   The authors would like to thank Paul Kyzivat and Jonathan Lennox and
   Martin Thomson for making various suggestions for improvements and
   optimisations.  Adam Roach was co-author of [I-D.ivov-mmusic-sdpfrag]
   which was merged into this document.

13.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing].

   Changes from draft-ietf-mmusic-trickle-ice-sip-01

   o  Editorial Clean up

   o  IANA Consideration added

Ivov, et al.             Expires January 7, 2016               [Page 29]
Internet-Draft             Trickle ICE for SIP                 July 2015

   o  Security Consideration added

   o  RTCP and BUNDLE Consideration added with rules for including
      "a=rtcp-mux" and ""a=group: BUNDLLE" attributes

   o  3PCC Consideration added

   o  Clarified that 18x w/o answer is sufficient to create a dialog
      that allows for trickling to start

   o  Added remaining Info Package definition sections as outlined in
      section 10 of [RFC6086]

   o  Added definition of application/sdpfrag making draft-ivov-mmusic-
      sdpfrag obsolete

   o  Added pseudo m-lines as additional separator in sdpfrag bodies for
      Trickle ICE

   o  Added ABNF for sdp-frag bodies and Trickle-ICE package

14.  References

14.1.  Normative References

   [I-D.ietf-mmusic-rfc4566bis]
              Handley, M., Jacobson, V., Perkins, C., and A. Begen,
              "SDP: Session Description Protocol", draft-ietf-mmusic-
              rfc4566bis-15 (work in progress), May 2015.

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

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

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

   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, June 2002.

Ivov, et al.             Expires January 7, 2016               [Page 30]
Internet-Draft             Trickle ICE for SIP                 July 2015

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

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

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

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

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

   [RFC7405]  Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC
              7405, December 2014.

14.2.  Informative References

   [I-D.ietf-mmusic-sdp-bundle-negotiation]
              Holmberg, C., Alvestrand, H., and C. Jennings,
              "Negotiating Media Multiplexing Using the Session
              Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
              negotiation-22 (work in progress), June 2015.

   [I-D.ivov-mmusic-sdpfrag]
              Ivov, E. and A. Roach, "Internet Media Type application/
              sdpfrag", draft-ivov-mmusic-sdpfrag-00 (work in progress),
              February 2015.

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

   [RFC5627]  Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent URIs (GRUUs) in the Session Initiation Protocol
              (SIP)", RFC 5627, October 2009.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761, April 2010.

Ivov, et al.             Expires January 7, 2016               [Page 31]
Internet-Draft             Trickle ICE for SIP                 July 2015

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.

   [RFC7081]  Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX:
              Combined Use of the Session Initiation Protocol (SIP) and
              the Extensible Messaging and Presence Protocol (XMPP)",
              RFC 7081, November 2013.

Authors' Addresses

   Emil Ivov
   Jitsi
   Strasbourg  67000
   France

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

   Thomas Stach
   Unaffiliated
   Vienna  1130
   Austria

   Email: thomass.stach@gmail.com

   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 January 7, 2016               [Page 32]