draft-ietf-mmusic-trickle-ice-sip-01.txt   draft-ietf-mmusic-trickle-ice-sip-02.txt 
Network Working Group E. Ivov Network Working Group E. Ivov
Internet-Draft Jitsi Internet-Draft Jitsi
Intended status: Standards Track E. Marocco Intended status: Standards Track T. Stach
Expires: July 19, 2015 Telecom Italia Expires: January 7, 2016 Unaffiliated
E. Marocco
Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
January 15, 2015 July 6, 2015
A Session Initiation Protocol (SIP) usage for Trickle ICE A Session Initiation Protocol (SIP) usage for Trickle ICE
draft-ietf-mmusic-trickle-ice-sip-01 draft-ietf-mmusic-trickle-ice-sip-02
Abstract Abstract
The Interactive Connectivity Establishment (ICE) protocol describes a The Interactive Connectivity Establishment (ICE) protocol describes a
Network Address Translator (NAT) traversal mechanism for UDP-based Network Address Translator (NAT) traversal mechanism for UDP-based
multimedia sessions established with the offer/answer model. The ICE multimedia sessions established with the Offer/Answer model. The ICE
extension for Incremental Provisioning of Candidates (Trickle ICE) extension for Incremental Provisioning of Candidates (Trickle ICE)
defines a mechanism that allows ICE agents to shorten session defines a mechanism that allows ICE agents to shorten session
establishment delays by making the candidate gathering and establishment delays by making the candidate gathering and
connectivity checking phases of ICE non-blocking and by executing connectivity checking phases of ICE non-blocking and by executing
them in parallel. them in parallel.
This document defines usage semantics for Trickle ICE with the This document defines usage semantics for Trickle ICE with the
Session Initiation Protocol (SIP). Session Initiation Protocol (SIP).
Status of This Memo Status of This Memo
skipping to change at page 1, line 43 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 19, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Rationale. Why INFO . . . . . . . . . . . . . . . . . . . 4 3.1. Rationale. Why INFO . . . . . . . . . . . . . . . . . . . 5
3.2. Discovery issues . . . . . . . . . . . . . . . . . . . . 5 3.2. Discovery issues . . . . . . . . . . . . . . . . . . . . 6
3.3. Relationship with the Offer/Answer Model . . . . . . . . 6 3.3. Relationship with the Offer/Answer Model . . . . . . . . 7
4. Incremental signalling of ICE candidates . . . . . . . . . . 8 4. Incremental Signalling of ICE candidates . . . . . . . . . . 9
4.1. Asserting Offer/Answer delivery and dialog state . . . . 8 4.1. Establishing the dialog . . . . . . . . . . . . . . . . . 9
4.2. Delivering candidates in INFO messages . . . . . . . . . 12 4.1.1. Asserting dialog state through reliable Offer/Answer
4.3. Initiating trickle ICE without an SDP Answer . . . . . . 14 delivery . . . . . . . . . . . . . . . . . . . . . . 9
5. Initial discovery of trickle ICE support . . . . . . . . . . 14 4.1.2. Asserting dialog state through unreliable
5.1. Provisioning support for trickle ICE . . . . . . . . . . 15 Offer/Answer delivery . . . . . . . . . . . . . . . . 10
5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 15 4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 12
5.3. Trickle ICE discovery through other protocols . . . . . . 16 4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 13
5.4. Fallback to half trickle . . . . . . . . . . . . . . . . 16 4.2. Delivering candidates in INFO messages . . . . . . . . . 15
6. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Initial discovery of Trickle ICE support . . . . . . . . . . 18
6.1. Overall Description . . . . . . . . . . . . . . . . . . . 19 5.1. Provisioning support for Trickle ICE . . . . . . . . . . 18
6.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 19
6.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 19 5.3. Trickle ICE discovery through other protocols . . . . . . 20
6.4. Info Package Parameters . . . . . . . . . . . . . . . . . 19 5.4. Fallback to Half Trickle . . . . . . . . . . . . . . . . 20
6.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . . 19 6. Considerations for RTP and RTCP multiplexing . . . . . . . . 22
6.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 20 7. Considerations for Media Multiplexing . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Content Type 'application/sdpfrag' . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Overall Description . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 24
9.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 25
9.4. Info Package Parameters . . . . . . . . . . . . . . . . . 25
9.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 25
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 1. Introduction
The vanilla specification of the Interactive Connectivity The Interactive Connectivity Establishment protocol [RFC5245] (a.k.a.
Establishment (vanilla ICE) protocol [RFC5245] describes a mechanism Vanilla ICE) describes a mechanism for NAT traversal that consists of
for NAT traversal that consists of three main phases: a phase where three main phases: a phase where an agent gathers a set of candidate
an agent gathers a set of candidate transport addresses (source IP transport addresses (source IP address, port and transport protocol),
address, port and transport protocol), a second phase where these a second phase where these candidates are sent to a remote agent and
candidates are sent to a remote agent and this gathering procedure is this gathering procedure is repeated and, finally, a third phase
repeated and, finally, a third phase where connectivity between all where connectivity between all candidates in both sets is checked
candidates in both sets is checked (connectivity checks). Once these (connectivity checks). Once these phases have been completed, and
phases have been completed, and only then, can both agents begin only then, can both agents begin communication. According to the
communication. According to the Vanilla ICE specification the three Vanilla ICE specification the three phases above happen
phases above happen consecutively, in a blocking way, which may lead consecutively, in a blocking way, which can introduce undesirable
to undesirable latency during session establishment. latency during session establishment.
The trickle ICE extension defined in [I-D.ietf-mmusic-trickle-ice] The Trickle ICE extension defined in [I-D.ietf-mmusic-trickle-ice]
defines generic semantics required for these ICE phases to happen defines generic semantics required for these ICE phases to happen
simultaneously, in a non-blocking way and hence speed up session simultaneously, in a non-blocking way and hence speed up session
establishment. establishment.
The present specification defines a usage of trickle ICE with the This specification defines a usage of Trickle ICE with the Session
Session Initiation Protocol (SIP). It describes how ICE candidates Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates
are to be incrementally exchanged with SIP INFO requests and how the are to be incrementally exchanged with SIP INFO requests and how the
half and full-trickle modes defined in [I-D.ietf-mmusic-trickle-ice] Half Trickle and Full Trickle modes defined in
are to be used by SIP User Agents (UAs) depending on their [I-D.ietf-mmusic-trickle-ice] are to be used by SIP User Agents (UAs)
expectations for support of trickle ICE by a remote agent. depending on their expectations for support of Trickle ICE by a
remote agent.
This document defines a new Info Package [RFC6086] for use with This document defines a new Info Package as specified in [RFC6086]
Trickle ICE. for use with Trickle ICE.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This specification makes use of all terminology defined by the This specification makes use of all terminology defined by the
protocol for Interactive Connectivity Establishment in [RFC5245] and protocol for Interactive Connectivity Establishment in [RFC5245] and
its Trickle ICE extension [I-D.ietf-mmusic-trickle-ice]. It is its Trickle ICE extension [I-D.ietf-mmusic-trickle-ice]. It is
assumed that the reader will be familiar with the terminology from assumed that the reader will be familiar with the terminology from
both of them. both of them.
3. Protocol Overview 3. Protocol Overview
The semantics that vanilla ICE [RFC5245] defines for exchanging ICE The semantics that Vanilla ICE [RFC5245] defines for exchanging ICE
candidates are exclusively based on use of Offers and Answers as per candidates are exclusively based on use of Offers and Answers as per
[RFC3264] over the Session Description Protocol (SDP) [RFC4566]. [RFC3264] over the Session Description Protocol (SDP) [RFC4566].
This specification extends these mechanism by allowing ICE candidates This specification extends these mechanism by allowing ICE candidates
to also be sent after the completion of Offer/Answer negotiation, 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 through the use of SIP INFO messages and a newly defined Info Package
[RFC6086]. [RFC6086].
Specifically, in cases where trickle ICE is fully supported, a Typically, in cases where Trickle ICE is fully supported, a candidate
typical exchange would happen along the following lines: The offerer exchange would happen along the following lines: The Offerer would
would send an INVITE containing a subset of candidates and then wait send an INVITE containing a subset of candidates and then wait for an
for an early dialog to be established. Once that happens, it will be early dialog to be established. Once that happens, it will be able
able to continue sending candidates through in INFO requests and to continue sending candidates through in INFO requests and within
within the same dialog. the same dialog.
Similarly, once it has sent an answer (though not earlier) an Similarly, an Answerer can start or continue "trickling" ICE
answerer can continue "trickling" ICE candidates using INFO messages candidates using INFO messages within the dialog established by its
within the dialog established by its 18x provisional response. 18x provisional response. Figure 1 shows such a sample exchange:
Figure 1 shows such a sample exchange:
STUN/Turn STUN/TURN STUN/Turn STUN/TURN
Servers Alice Bob Servers Servers Alice Bob Servers
| | | | | | | |
| STUN Bi.Req. | INVITE (Offer) | | | STUN Bi.Req. | INVITE (Offer) | |
|<--------------|------------------------>| | |<--------------|------------------------>| |
| | 183 (Answer) | TURN Alloc Req | | | 183 (Answer) | TURN Alloc Req |
| STUN Bi.Resp. |<------------------------|--------------->| | STUN Bi.Resp. |<------------------------|--------------->|
|-------------->| INFO/OK (SRFLX Cand.) | | |-------------->| INFO/OK (SRFLX Cand.) | |
| |------------------------>| TURN Alloc Resp| | |------------------------>| TURN Alloc Resp|
skipping to change at page 4, line 43 skipping to change at page 5, line 35
| | 5245 SIP re-INVITE | | | | 5245 SIP re-INVITE | |
| |------------------------>| | | |------------------------>| |
| | 200 OK | | | | 200 OK | |
| |<------------------------| | | |<------------------------| |
| | ACK | | | | ACK | |
| |------------------------>| | | |------------------------>| |
| | | | | | | |
| |<===== MEDIA FLOWS =====>| | | |<===== MEDIA FLOWS =====>| |
| | | | | | | |
Figure 1: Sample trickle ICE scenario with SIP Figure 1: Sample Trickle ICE scenario with SIP
3.1. Rationale. Why INFO 3.1. Rationale. Why INFO
The decision to use SIP INFO requests as a candidate transport method The decision to use SIP INFO requests as a candidate transport method
is based primarily on their lightweight nature. Once a dialog has is based primarily on their lightweight nature. Once a dialog has
been established, INFO messages can be exchanged both ways with no been established, INFO messages can be exchanged both ways with no
restrictions on timing and frequency and no risk of collision. restrictions on timing and frequency and no risk of collision.
On the other hand, using offer/answer and UPDATE requests, which from On the other hand, using Offer/Answer and UPDATE requests, which from
an [RFC5245] perspective is the traditional way of transporting ICE an [RFC5245] perspective is the traditional way of transporting ICE
candidates, introduces the following complications: candidates, introduces the following complications:
Need for a turn-based mechanism: [RFC3264] defines Offer/Answer as Need for a non-blocking mechanism: [RFC3264] defines Offer/Answer
a strictly sequential mechanism. There can only be a maximum of as a strictly sequential mechanism. There can only be a maximum
one exchange at any point of time. Both sides cannot of one exchange at any point of time. Both sides cannot
simultaneously send offers nor can they generate multiple offers simultaneously send Offers nor can they generate multiple Offers
prior to receiving an answer. Using UPDATEs for candidate prior to receiving an Answer. Using UPDATEs for candidate
transport would therefore imply the implementation of a candidate transport would therefore imply the implementation of a candidate
pool at every agent where candidates can be stored until it is 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. once again that agent's "turn" to emit an Answer or a new Offer.
Such an approach would introduce non-negligible complexity for no Such an approach would introduce non-negligible complexity for no
additional value. additional value.
Elevated risk of glare: The sequential nature of Offer/Answer also Elevated risk of glare: The sequential nature of Offer/Answer also
makes it impossible for both sides to send offers simultaneously. makes it impossible for both sides to send Offers simultaneously.
What's worse is that there are no mechanisms in SIP to actually What's worse is that there are no mechanisms in SIP to actually
prevent that. [RFC3261], where the situation of offers crossing prevent that. [RFC3261], where the situation of Offers crossing
on the wire is described as "glare", only defines a procedure for on the wire is described as "glare", only defines a procedure for
addressing the issue after it has occurred. According to that addressing the issue after it has occurred. According to that
procedure both offers are invalidated and both sides need to retry procedure both Offers are invalidated and both sides need to retry
the negotiation after a period between 0 and 4 seconds. The high the negotiation after a period between 0 and 4 seconds. The high
likelihood for glare to occur and the average two second backoff likelihood for glare to occur and the average two second backoff
intervals would imply trickle ICE processing duration would not intervals would imply Trickle ICE processing duration would not
only fail to improve but actually exceed those of vanilla ICE. only fail to improve but actually exceed those of Vanilla ICE.
INFO messages have no impact on the Offer/Answer negotiation and are INFO messages decouple the exchange of candidates from the Offer/
subject to none of the glare issues described above, which makes them Answer negotiation and are subject to none of the glare issues
a very convenient and lightweight mechanism for asynchronous delivery described above, which makes them a very convenient and lightweight
of candidates. mechanism for asynchronous delivery of candidates.
Using in-dialog INFO messages also provides a way of guaranteeing Using in-dialog INFO messages also provides a way of guaranteeing
that candidates are delivered end-to-end, between the same entities that candidates are delivered end-to-end, between the same entities
that are actually in the process of initiating a session. The that are actually in the process of initiating a session. The
alternative would have implied requiring support for Globally alternative would have implied requiring support for Globally
Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low
adoption levels, would have constituted too strong of constraint to adoption levels, would have constituted too strong of constraint to
the adoption of trickle ICE. the adoption of Trickle ICE.
3.2. Discovery issues 3.2. Discovery issues
In order for to benefit from trickle ICE's full potential and reduce In order for to benefit from Trickle ICE's full potential and reduce
session establishment latency to a minimum, trickle ICE agents need session establishment latency to a minimum, Trickle ICE agents need
to generate SDP offers and answers that contain incomplete, to generate SDP Offers and Answers that contain incomplete,
potentially empty sets of candidates. Such offers and answers can potentially empty sets of candidates. Such Offers and Answers can
only be handled meaningfully by agents that actually support only be handled meaningfully by agents that actually support
incremental candidate provisioning, which implies the need to confirm incremental candidate provisioning, which implies the need to confirm
such support before actually using it. such support before actually using it.
Contrary to other protocols, like XMPP [RFC6120], where "in advance" Contrary to other protocols, like XMPP [RFC6120], where "in advance"
capability discovery is widely implemented, the mechanisms that allow capability discovery is widely implemented, the mechanisms that allow
this for sip (i.e., a combination of UA Capabilities [RFC3840] and this for SIP (i.e., a combination of UA Capabilities [RFC3840] and
GRUU [RFC5627]) have only seen low levels of adoption. This presents GRUU [RFC5627]) have only seen low levels of adoption. This presents
an issue for trickle ICE implementations as SIP UAs do not have an an issue for Trickle ICE implementations as SIP UAs do not have an
obvious means of verifying that their peer will support incremental obvious means of verifying that their peer will support incremental
candidate provisioning. candidate provisioning.
The "half trickle" mode of operation defined in the trickle ICE The Half Trickle mode of operation defined in the Trickle ICE
specification [I-D.ietf-mmusic-trickle-ice] provides one way around specification [I-D.ietf-mmusic-trickle-ice] provides one way around
this, by requiring first offers to contain a complete set of ICE this, by requiring first Offers to contain a complete set of ICE
candidates and only using incremental provisioning for the rest of candidates and only using incremental provisioning for the rest of
the sessions. the sessions.
While using "half trickle" does provide a working solution it also While using Half Trickle does provide a working solution it also
comes at the price of increased latency. Section 5 therefore makes comes at the price of increased latency. Section 5 therefore makes
several alternative suggestions that enable SIP UAs to engage in full several alternative suggestions that enable SIP UAs to engage in Full
trickle right from their first offer: Section 5.1 discusses the use 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 of on-line provisioning as a means of allowing use of Trickle ICE for
all endpoints in controlled environments. Section 5.2 describes all endpoints in controlled environments. Section 5.2 describes
anticipatory discovery for implementations that actually do support anticipatory discovery for implementations that actually do support
GRUU and UA Capabilities and Section 5.4 discusses the implementation 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 and use of Half Trickle by SIP UAs where none of the above are an
option. option.
3.3. Relationship with the Offer/Answer Model 3.3. Relationship with the Offer/Answer Model
It is important to note that this specification does not require, It is important to note that this specification does not require,
define, or even assume any mechanisms that would have an impact on 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 the Offer/Answer model beyond the way it is already used by Vanilla
ICE [RFC5245]. From the perspective of all SIP middle boxes and ICE [RFC5245]. From the perspective of all SIP middle boxes and
proxies, and with the exception of the actual INFO messages, proxies, and with the exception of the actual INFO messages,
signalling in general and Offer/Answer exchanges in particular would signalling in general and Offer/Answer exchanges in particular would
look the same way for trickle as they would for vanilla ICE. look the same way for Trickle ICE as they would for Vanilla ICE.
+-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+
| Alice +--------------+ | | +--------------+ Bob | | Alice +--------------+ | | +--------------+ Bob |
| | Offer/Answer | | | | Offer/Answer | | | | Offer/Answer | | | | Offer/Answer | |
| +-------+ | Module | | | | Module | +-------+ | | +-------+ | Module | | | | Module | +-------+ |
| | ICE | +--------------+ | | +--------------+ | ICE | | | | ICE | +--------------+ | | +--------------+ | ICE | |
| | Agent | | | | | | Agent | | | | Agent | | | | | | Agent | |
| +-------+ | | | | +-------+ | | +-------+ | | | | +-------+ |
+-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+
| | | | | | | |
skipping to change at page 7, line 36 skipping to change at page 8, line 36
|----------------------------------------------------->| |----------------------------------------------------->|
| STUN Binding Requests/Responses | | STUN Binding Requests/Responses |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| | | |
| | | | | | | |
| | 5245 SIP re-INVITE | | | | 5245 SIP re-INVITE | |
| |--------------------->| | | |--------------------->| |
| | 200 OK | | | | 200 OK | |
| |<---------------------| | | |<---------------------| |
Figure 2: Distinguishing between trickle ICE and traditional Figure 2: Distinguishing between Trickle ICE and traditional
signalling. signalling.
It is important to note that, as displayed on Figure 2, exchanging It is important to note that, as displayed on Figure 2, exchanging
candidates through SIP INFO messages are best represented as candidates through SIP INFO messages are best represented as
signalling between ICE agents and not between the traditional SIP and signalling between ICE agents and not between the traditional SIP and
Offer/Answer modules of SIP User Agents. Such INFO requests do not 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 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 version number in the "o=" line. In that regard they are actually
comparable to Peer Reflexive candidates that ICE agents can discover comparable to Peer Reflexive candidates that ICE agents can discover
during ICE processing. during ICE processing.
4. Incremental signalling of ICE candidates 4. Incremental Signalling of ICE candidates
Trickle ICE agents will construct offers and answers the same way a
[RFC5245] compatible agent would, with the following two main
differences:
o First, all offers and answers sent by the trickle ICE capable Trickle ICE agents will construct Offers and Answers as specified in
agents MUST indicate support for trickle ICE through the "trickle" [I-D.ietf-mmusic-trickle-ice] with the following additional SIP-
ice-options tag defined in [I-D.ietf-mmusic-trickle-ice]: specific additions:
a=ice-options:trickle 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.
o Second, offers and answers may contain all, some, or no ICE 2. Trickle ICE agents MAY exchange additional ICE candidates using
candidates at all. 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
Once an agent has sent an offer or an answer indicating support for 3. Trickle ICE agents MAY exchange additional ICE candidates before
trickle ICE, it MUST be prepared to receive SIP INFO requests within the Answerer has sent the Answer provided that an invite dialog
that same dialog, containing additional candidates or an indication usage is established at both Trickle ICE agents. Note that in
for the end of such candidates. case of forking multiple early dialogs will exist.
Similarly, as soon as a SIP UA has established a dialog (including an The following section provide further details on how Trickle ICE
early state one) it MAY begin sending INFO requests containing agents establish the INVITE dialog usage such that they can trickle
additional candidates or end-of-candidates indications. Such INFO candidates.
requests MUST be sent within that same dialog. This is necessary so
that the candidates from these INFO messages could be delivered to
the same entities that initiated the session.
4.1. Asserting Offer/Answer delivery and dialog state 4.1. Establishing the dialog
In order for SIP UAs to be able to start trickling, the following two In order for SIP UAs to be able to start trickling, the following two
conditions need to be satisfied: conditions need to be satisfied:
o Trickle ICE support in the peer agent MUST be confirmed. 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. 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 Section 5 discusses in detail the various options for satisfying the
first of the above conditions. Regardless of those mechanisms first of the above conditions. Regardless of those mechanisms
however, agents are certain to have a clear understanding of whether however, agents are certain to have a clear understanding of whether
their peers support trickle ICE once an offer and and an answer have their peers support trickle ICE once an Offer and an Answer have been
been exchanged, which needs to happen anyway for ICE processing to exchanged, which also allows for ICE processing to commence (see
commence (see Figure 3). Figure 3).
Alice Bob 4.1.1. Asserting dialog state through reliable Offer/Answer delivery
| | Alice Bob
| INVITE (Offer) | | |
|------------------------>| | INVITE (Offer) |
| 183 (Answer) | |------------------------>|
|<------------------------| | 183 (Answer) |
| | |<------------------------|
+----------------------+ | | PRACK/OK |
|Alice: I know Bob can| | |------------------------>|
|trickle and I know his| | | |
|dialog is in the early| | +----------------------------------------+
|state. Send INFO! | | |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.) |
|------------------------>|
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| |
Figure 3: SIP Offerer can freely trickle as soon as it receives an Figure 3: SIP Offerer can freely trickle as soon as it receives an
answer. Answer.
Satisfying both conditions is also relatively trivial for ICE agents Satisfying both conditions is also relatively trivial for ICE agents
that have sent an offer in an INVITE and that have received an that have sent an Offer in an INVITE and that have received an Answer
answer. Regardless of how that answer was delivered, it is in a reliable provisioanl response. It is guaranteed to have
guaranteed to have confirmed support for trickle ICE within the confirmed support for Trickle ICE within the Answerer (or lack
answerer (or lack thereof) and to have fully initialized the SIP thereof) and to have fully initialized the SIP dialog at both ends.
dialog at both ends. Offerers in the above situation can therefore Offerers and Answerers in the above situation can therefore freely
freely commence trickling within the newly established dialog (see commence trickling within the newly established dialog.
Figure 4).
Alice Bob 4.1.2. Asserting dialog state through unreliable Offer/Answer delivery
| |
| 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.) |
|<------------------------|
| |
Figure 4: A SIP Offerer in a 3PCC scenario can also freely start The situation is a bit more delicate for agents that have received an
trickling as soon as it receives an answer. 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).
Agents that have sent an offer in a reliable provisional response or Alice Bob
in a 200 OK and that receive an answer in a PRACK or in an ACK are | |
also in a similar situation because, by the time the offer and the | INVITE (Offer) |
answer are exchanged, support for trickle ICE will be confirmed and |------------------------>|
the SIP dialog is guaranteed to be in a state that would allow in- | 183 (Answer) |
dialog INFO requests. |<------------------------|
| |
| +----------------------+
| |Bob: I don't know if |
| |Alice got my 183 or if|
| |her dialog is already |
| |in the early state. |
| | Can I send INFO??? |
| +----------------------+
| |
The situation is a bit more delicate for agents that have received an Figure 4: A SIP UA that sent an Answer in an unreliable provisional
offer in an INVITE request and have sent an answer in an unreliable response does not know if it was received and if the dialog at the
provisional response because, once the response has been sent, there side of the Offerer has entered the early state
is no way for the answerer to know when or if it has been received
(Figure 5).
Alice Bob In order to clear this ambiguity as soon as possible, the answerer
| | needs to retransmit the provisional response with the exponential
| INVITE (Offer) | backoff timers described in [RFC3262]. Retransmits MUST cease on
|------------------------>| receipt of a INFO request or on transmission of the answer in a 2xx
| 183 (Answer) | 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.
| +----------------------+
| |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 5: A SIP UA that has answer-ed in an unreliable provisional The Offerer MUST send a Trickle ICE INFO request as soon as they
response cannot know exactly when it is received and when the dialog receive an SDP Answer in an unreliable provisional response. This
at the side of the receiver has entered the early state 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.
In order to clear this ambiguity as soon as possible, trickle ICE SIP As soon as an Answerer has received such an INFO request, the
UAs MUST send a trickle ICE INFO request as soon as they receive an Answerer has an indication that a dialog is well established at both
SDP Answer in an unreliable provisional response. This INFO message ends and MAY begin trickling (Figure 5).
can only contain the candidates that were already provided in the
offer (as would be the case when half trickle is performed or when no
new candidates have been learned since then) or they can also deliver
new information, such as new candidates (if available) or an end-of-
candidates indication in case candidate discovery has ended in the
mean time.
As soon as answerers have received such INFO requests, they would Alice Bob
have an indication that a dialog is well established at both ends and | |
they MAY begin trickling (Figure 6). | INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|------------------------>|
| |
| +----------------------+
| |Bob: Now I know Alice|
| | is ready. Send INFO! |
| +----------------------+
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| |
| 200/ACK (Answer) |
|<------------------------|
Alice Bob Figure 5: A SIP UA that received an INFO request after sending an
| | unreliable provisional response knows that the dialog at the side of
| INVITE (Offer) | the receiver has entered the early state
|------------------------>|
| 183 (Answer) |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|------------------------>|
| |
| +----------------------+
| |Bob: Now I know Alice|
| | is ready. Send INFO! |
| +----------------------+
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| |
Figure 6: A SIP UA that has answer-ed in an unreliable provisional When sending the Answer in the 200 OK response, the Answerers MUST
response cannot know exactly when it is received and when the dialog repeat exactly the same Answer that was previously sent in the
at the side of the receiver has entered the early state 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.
Obviously, if PRACK [RFC3262] requests are supported and used, there 4.1.3. Initiating Trickle ICE without an SDP Answer
is no need for the above as the PRACKs themselves would provide
sufficient indication for the state of the dialog. 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.
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).
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).
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 4.2. Delivering candidates in INFO messages
Whenever new ICE candidates become available for sending, agents Whenever new ICE candidates become available for sending, agents
would encode them in "a=candidate" lines as described by would encode them in "a=candidate" lines as described by
[I-D.ietf-mmusic-trickle-ice]. For example: [I-D.ietf-mmusic-trickle-ice]. For example:
a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
raddr 10.0.1.1 rport 8998 raddr 10.0.1.1 rport 8998
The use of SIP INFO requests happens within the context of an Info The use of SIP INFO requests happens within the context of the Info
Package specifically defined for the purpose (Section 6). Package as defined Section 9. The MIME type for their payload MUST
be set to 'application/sdpfrag' as defined in Section 8.
Such INFO requests MUST be sent within the existing SIP dialog. The Since neither the "a=candidate" nor the "a=end-of-candidates"
MIME type for their payload MUST be set to 'application/sdpfrag' as attributes contain information that would allow correlating them to a
defined in [I-D.ivov-dispatch-sdpfrag]. specific "m=" line, this is handled through the use of pseudo "m="
lines and identification tags in "a=mid:" attributes as defined in
Since neither the "a=candidate" nor the "a=end-of-candidates" lines [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as
contain information that would allow correlating them to a specific defined in [I-D.ietf-mmusic-rfc4566bis], but provide no semantics
"m=" line, this is handled through the use of MID [RFC5588]. Agents other than indicating to which "m=" line a candidate belongs.
MUST include the corresponding "a=mid" line for every "m=" line whose Consequently, the receiving agent MUST ignore the remaining content
candidate list they intend to update. Such "a=mid" lines MUST of the pseudo m-line. This guarantees that the 'application/sdpfrag'
immediately precede the list of candidates for that specific "m=" bodies do not interfere with the Offer/Answer procedures as specified
line. All "a=candidate" or "a=end-of-candidates" lines following an in [RFC3264].
"a=mid" line, up until (and excluding) the next occurrence of an
"a=mid" line, pertain the the "m=" line identified by that MID.
"a=end-of-candidates" lines preceding any "a=mid" lines indicate 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" line).
The use of "a=mid" lines allows for a structure similar to the one in When sending the INFO request, the agent MAY, if already known to the
SDP offers and answers where one can distinguish separate media-level agent, include the same content into the pseudo m-line as for the
and session-level sections. In the current case lines preceding any corresponding Offer or Answer. However, since Trickle-ICE might be
"a=mid" lines are considered to be session-level. Lines appearing in decoupled from the Offer/Answer negotiation this content might be
between or after "a=mid" lines will be interpreted as media-level. unknown to the agent. In this case, the agent MUST include the
following default values.
Note that while this specification uses the a=mid: attribute from o The media is set to 'audio'.
[RFC5588], 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.
All INFO requests MUST carry the "ice-pwd" and "ice-ufrag" attributes o The port value is set to '9'.
that would allow mapping them to a specific ICE generation. INFO
requests containing ice-ufrag and ice-pwd values that do not match o The proto value is set to 'RTP/AVP'.
those of the current ICE processing session MUST be discarded. The
"ice-pwd" and "ice-ufrag" attributes MUST appear at the same level as o The fmt SHOULD appear only once and is set to '0'
the ones in the Offer/Answer exchange. In other words, if they were
present as sesssion-level attributes there, they will also appear at Agents MUST include a pseudo "m=" line and an identification tag in a
the beginning of all INFO message payloads, preceding all "a=mid" "a=mid:" attribute for every "m=" line whose candidate list they
lines. If they were originally exchanged as media level attributes, intend to update. Such "a=mid:" attributes MUST immediately precede
potentially overriding session-level values, then they will also be the list of candidates for that specific "m=" line. All
included in INFO message payloads, following the corresponding "a=candidate" or "a=end-of-candidates" attributes following an
"a=mid' line. "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.
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 In every INFO request agents MUST include all local candidates they
have previously signalled. This is necessary in order to more easily have previously signalled. This is necessary in order to more easily
avoid problems that would arise from misordering and unreliability. 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 When receiving INFO requests carrying any candidates, agents will
therefore first identify and discard the SDP lines containing therefore first identify and discard the SDP lines containing
candidates they have already received in previous INFO requests or in candidates they have already received in previous INFO requests or in
the Offer/Answer exchange preceding them. Two candidates are the Offer/Answer exchange preceding them. Two candidates are
considered to be equal if their IP address port, transport and considered to be equal if their IP address port, transport and
component ID are the same. After identifying and discarding known component ID are the same. After identifying and discarding known
candidates, agents will then process them remaining ones (the actual candidates, agents will then process the remaining, actually new
new candidates) according to the rules described in candidates according to the rules described in
[I-D.ietf-mmusic-trickle-ice]. [I-D.ietf-mmusic-trickle-ice].
The following example shows the content of one sample candidate The following example shows the content of one sample candidate
delivering INFO request: delivering INFO request:
INFO sip:alice@example.com SIP/2.0 INFO sip:alice@example.com SIP/2.0
... ...
Info-Package: trickle-ice Info-Package: trickle-ice
Content-type: application/sdp Content-type: application/sdp
Content-Disposition: Info-Package Content-Disposition: Info-Package
Content-length: ... Content-length: ...
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1 a=mid:1
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 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=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx
raddr 10.0.1.1 rport 8998 raddr 10.0.1.1 rport 8998
a=end-of-candidates
m=audio 9 RTP/AVP 0
a=mid:2 a=mid:2
a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx
raddr 10.0.1.1 rport 9000 raddr 10.0.1.1 rport 9000
a=end-of-candidates a=end-of-candidates
4.3. Initiating trickle ICE without an SDP Answer 5. Initial discovery of Trickle ICE support
The possibility to convey arbitrary SDP fragments in SIP message
bodies [I-D.ivov-dispatch-sdpfrag] allows ICE agents to initiate
trickling without actually sending an answer. Trickle ICE answerers
MAY therefore respond to INVITEs with provisional responses that only
contain the information necessary for ICE processing to begin.
Agents that choose to do so, need to send in these responses all ICE-
related session level information that would have otherwise been
present in an SDP answer. At the very least these responses MUST
include the "ice-options" attribute for "trickle" and all other ICE
options they support.
The "ice-ufrag" and "ice-pwd" options MUST also be present in all 183
responses and they MAY appear as either session or media level
attributes.
5. Initial discovery of trickle ICE support
SIP User Agents (UAs) that support and intend to use trickle ICE are 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 REQUIRED by [I-D.ietf-mmusic-trickle-ice] to indicate that in their
offers and answers using the following attribute: "a=ice- Offers and Answers using the following attribute: "a=ice-
options:trickle". This makes discovery fairly straightforward for options:trickle". This makes discovery fairly straightforward for
answerers or for cases where offers need to be generated within Answerers or for cases where Offers need to be generated within
existing dialogs (i.e., when sending re-INVITE requests). In both existing dialogs (i.e., when sending re-INVITE requests). In both
scenarios prior SDP would have provided the necessary information. scenarios prior SDP would have provided the necessary information.
Obviously, prior SDP is not available at the time a first offer is Obviously, prior SDP is not available at the time a first Offer is
being constructed and it is therefore impossible for ICE agents to being constructed and it is therefore impossible for ICE agents to
determine support for incremental provisioning that way. The determine support for incremental provisioning that way. The
following options are suggested as ways of addressing this issue. following options are suggested as ways of addressing this issue.
5.1. Provisioning support for trickle ICE 5.1. Provisioning support for Trickle ICE
In certain situations it may be possible for integrators deploying In certain situations it may be possible for integrators deploying
trickle ICE to know in advance that some or all endpoints reachable Trickle ICE to know in advance that some or all endpoints reachable
from within the deployment will support trickle ICE. This is likely from within the deployment will support Trickle ICE. This is likely
to be the case, for example, for WebRTC clients that will always be to be the case, for example, for WebRTC clients that will always be
communicating with other WebRTC clients or known Session Border communicating with other WebRTC clients or known Session Border
Controllers (SBC) with support for this specification. Controllers (SBC) with support for this specification.
While the exact mechanism for allowing such provisioning is out of While the exact mechanism for allowing such provisioning is out of
scope here, this specification encourages trickle ICE implementations scope here, this specification encourages trickle ICE implementations
to allow the option in the way they find most appropriate. to allow the option in the way they find most appropriate.
5.2. Trickle ICE discovery with GRUU 5.2. Trickle ICE discovery with GRUU
[RFC3840] provides a way for SIP user agents to query for support of [RFC3840] provides a way for SIP user agents to query for support of
specific capabilities using, among others, OPTIONS requests. GRUU specific capabilities using, among others, OPTIONS requests. GRUU
support on the other hand allows SIP requests to be addressed to support on the other hand allows SIP requests to be addressed to
specific UAs (as opposed to arbitrary instances of an address of specific UAs (as opposed to arbitrary instances of an address of
record). Combining the two and using the "trickle-ice" option tag record). Combining the two and using the "trickle-ice" option tag
defined in Section 6.5 provides SIP UAs with a way of learning the defined in Section 9.5 provides SIP UAs with a way of learning the
capabilities of specific US instances and then addressing them capabilities of specific US instances and then addressing them
directly with INVITE requests that require SIP support. directly with INVITE requests that require SIP support.
Such targeted trickling may happen in different ways. One option 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 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 presence and to then query its capabilities direction with an OPTIONS
request. Alternately, it can also just send an OPTIONS request to request. Alternately, it can also just send an OPTIONS request to
the AOR it intends to contact and then inspect the returned the AOR it intends to contact and then inspect the returned
response(s) for support of both GRUU and trickle ICE (Figure 7). response(s) for support of both GRUU and Trickle ICE (Figure 9).
Alice Bob Alice Bob
| | | |
| OPTIONS sip:b1@example.com SIP/2.0 | | OPTIONS sip:b1@example.com SIP/2.0 |
|-------------------------------------------------->| |-------------------------------------------------->|
| | | |
| 200 OK | | 200 OK |
| Contact: sip:b1@example.com;gr=hha9s8d-999a | | Contact: sip:b1@example.com;gr=hha9s8d-999a |
| ;audio;video|;trickle-ice;... | | ;audio;video|;trickle-ice;... |
|<--------------------------------------------------| |<--------------------------------------------------|
skipping to change at page 16, line 26 skipping to change at page 19, line 48
|-------------------------------------------------->| |-------------------------------------------------->|
| | | |
| 183 (Answer) | | 183 (Answer) |
|<--------------------------------------------------| |<--------------------------------------------------|
| INFO/OK (Trickling) | | INFO/OK (Trickling) |
|<------------------------------------------------->| |<------------------------------------------------->|
| | | |
| ... | | ... |
| | | |
Figure 7: Trickle ICE support discovery with OPTIONS and GRUU Figure 9: Trickle ICE support discovery with OPTIONS and GRUU
Confirming support for trickle ICE through [RFC3840] gives SIP UAs Confirming support for Trickle ICE through [RFC3840] gives SIP UAs
the options to engage in full trickle negotiation (as opposed to the the options to engage in Full Trickle negotiation (as opposed to the
more lengthy half-trickle) from the very first offer they send. more lengthy Half Trickle) from the very first Offer they send.
5.3. Trickle ICE discovery through other protocols 5.3. Trickle ICE discovery through other protocols
Protocols like XMPP [RFC6120] define advanced discovery mechanisms Protocols like XMPP [RFC6120] define advanced discovery mechanisms
that allow specific features to be queried priory to actually that allow specific features to be queried priory to actually
attempting to use them. Solutions like [RFC7081] define ways of attempting to use them. Solutions like [RFC7081] define ways of
using SIP and XMPP together which also provides a way for dual stack 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 SIP+XMPP endpoints to make use of such features and verify Trickle
ICE support for a specific SIP endpoint through XMPP. [TODO expand ICE support for a specific SIP endpoint through XMPP. [TODO expand
on a specific way to do this] on a specific way to do this or declare as out of scope]
5.4. Fallback to half trickle 5.4. Fallback to Half Trickle
In cases where none of the other mechanisms in this section are In cases where none of the other mechanisms in this section are
acceptable, SIP UAs should use the "half trickle" mode defined in acceptable, SIP UAs should use the Half Trickle mode defined in
[I-D.ietf-mmusic-trickle-ice]. With half trickle, agents initiate [I-D.ietf-mmusic-trickle-ice]. With Half Trickle, agents initiate
sessions the same way they would when using vanilla ICE [RFC5245]. sessions the same way they would when using Vanilla ICE [RFC5245].
This means that, prior to actually sending an offer, agents would This means that, prior to actually sending an Offer, agents would
first gather ICE candidates in a blocking way and then send them all 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 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 some amount of latency will be accumulated and it is advised
that agents try to anticipate it where possible, like for example, that agents try to anticipate it where possible, like for example,
when user actions indicate a high likelyhood for an imminent call when user actions indicate a high likelyhood for an imminent call
(e.g., activity on a keypad or a phone going offhook). (e.g., activity on a keypad or a phone going offhook).
Using half trickle would result in offers that are compatible with Using Half Trickle would result in Offers that are compatible with
both vanilla ICE and legacy [RFC3264] endpoints both. both Vanilla ICE and legacy [RFC3264] endpoints.
A typical (half) trickle ICE exchange with SIP would look this way:
STUN/Turn STUN/TURN STUN/Turn STUN/TURN
Servers Alice Bob Servers Servers Alice Bob Servers
| | | | | | | |
|<--------------| | | |<--------------| | |
| | | | | | | |
| | | | | | | |
| Candidate | | | | Candidate | | |
| | | | | | | |
| | | | | | | |
skipping to change at page 18, line 43 skipping to change at page 21, line 43
| | | | | | | |
| | 5245 SIP re-INVITE | | | | 5245 SIP re-INVITE | |
| |------------------------>| | | |------------------------>| |
| | 200 OK | | | | 200 OK | |
| |<------------------------| | | |<------------------------| |
| | | | | | | |
| | | | | | | |
| |<===== MEDIA FLOWS =====>| | | |<===== MEDIA FLOWS =====>| |
| | | | | | | |
Figure 8: Example Figure 10: Example - A typical (Half) Trickle ICE exchange with SIP
It is worth reminding that once a single offer or answer had been It is worth reminding that once a single Offer or Answer had been
exchanged within a specific dialog, support for trickle ICE will have exchanged within a specific dialog, support for Trickle ICE will have
been determined. No further use of half trickle will therefore be been determined. No further use of Half Trickle will therefore be
necessary within that same dialog and all subsequent exchanges can necessary within that same dialog and all subsequent exchanges can
use the full trickle mode of operation. use the Full Trickle mode of operation.
6. Info Package 6. Considerations for RTP and RTCP multiplexing
6.1. Overall Description [OPEN ISSUE: These considerations are of general relevance
and might be better suited for draft-ietf-mmusic-trickle-ice.]
This specification defines an Info Package meant for use by SIP user The following consideration describe options for Trickle-ICE in order
agents implementing Trickle ICE. Typically INFO requests would carry to give some guidance to implementors on how trickling can be
ICE candidates discovered after the user agent has sent or received a optimized with respect to providing RTCP candidates. However, these
trickle-ice offer. considerations are neither meant to be exhaustive nor guaranteed to
be suitable for all sorts of deployments.
6.2. Applicability 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.
The purpose of the ICE protocol is to establish a media path. The While a Half Trickle Offerer would have to send an offer compliant to
candidates that this specification transports in INFO requests are [RFC5245] including candidates for all components, this flexibility
part of this establishment. There is hence no way for them to be allows a Full Trickle Offerer to initially send only RTP candidates
transported through the not yet existing media path. (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.
Candidates sent by a trickle ICE agent after the offer, are meant to A Trickle answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in
follow the same signalling path and reach the same entity as the the application/sdp-frag body if it supports and uses RTP and RCTP
offer itself. While it is true that GRUUs can be used to achieve multiplexing. Receipt of this attribute at the Offerer in an INFO
this, one of the goals of this specification is to allow operation of request prior to the Answer indicates that the Answerer supports and
trickle ICE in as many environments as possible including those with uses RTP and RCTP multiplexing. The Offerer can use this information
no GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would e.g. for stopping gathering of RTCP candidates and/or for freeing
not satisfy this goal. corresponding resources.
6.3. Info Package Name 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
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.
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.
9.3. Info Package Name
This document defines a SIP Info Package as per [RFC6086]. The Info This document defines a SIP Info Package as per [RFC6086]. The Info
Package token name for this package is "trickle-ice" Package token name for this package is "trickle-ice"
6.4. Info Package Parameters 9.4. Info Package Parameters
This document does not define any Info package parameters. This document does not define any Info Package parameters.
6.5. SIP Option-Tags 9.5. SIP Option Tags
[RFC6086] allows Info Package specifications to define SIP option- [RFC6086] allows Info Package specifications to define SIP option-
tags. This document therefore stipulates that SIP entities that tags. This specification extends the option-tag construct of the SIP
support trickle ICE and this specification MUST place the 'trickle- grammar as follows:
ice' option-tag in a SIP Supported header field.
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 When responding to, or generating a SIP OPTIONS request a SIP entity
MUST also include the 'trickle-ice' option-tag in a SIP Supported MUST also include the 'trickle-ice' option-tag in a SIP Supported:
header field. header field.
6.6. Info Message Body Parts 9.6. Info Message Body Parts
Entities implementing this specification MUST include SDP encoded ICE Entities implementing this specification MUST include SDP encoded ICE
candidates in all SIP INFO requests. The MIME type for the payload candidates in all SIP INFO requests. The MIME type for the payload
MUST be of type 'application/sdp' as defined in Section 4.2 and MUST be of type 'application/sdpfrag' as defined in Section 4.2 and
[I-D.ietf-mmusic-trickle-ice]. [I-D.ietf-mmusic-trickle-ice].
7. Security Considerations 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.
[TODO] ; 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
8. Acknowledgements 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
The authors would like to thank Thomas Stach for suggesting the INFO with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-
acknowledgements used in the specification as a way of avoiding options, candidate-attribute remote-candidate-att from [RFC5245],
making PRACKs mandatory, Paul Kyzivat and Jonathan Lennox and Thomas identification-tag, mid-attribute ; from [RFC5888], media-field,
Stach for making various other suggestions for improvements and attribute-fields from [I-D.ietf-mmusic-rfc4566bis] and end-of-
optimisations. candidates-att from [I-D.ietf-mmusic-trickle-ice]. The indicator for
case-sensitivity %s is defined in [RFC7405].
9. References [NOTE: end-of-candidates-att currently lacks a formal definition in
[I-D.ietf-mmusic-trickle-ice]]
9.1. Normative References 9.7. Info Package Usage Restrictions
This document does not define any Info Package Usage Restrictions.
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:
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.
+-------------+-----------+
| 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
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] [I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", draft-ietf- Connectivity Establishment (ICE) Protocol", draft-ietf-
mmusic-trickle-ice-01 (work in progress), February 2014. mmusic-trickle-ice-02 (work in progress), January 2015.
[I-D.ivov-dispatch-sdpfrag]
Ivov, E. and A. Roach, "Internet Media Type application/
sdpfrag", draft-ivov-dispatch-sdpfrag-03 (work in
progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002. (SIP)", RFC 3262, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. 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 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 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 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
Initiation Protocol (SIP) INFO Method and Package Initiation Protocol (SIP) INFO Method and Package
Framework", RFC 6086, January 2011. Framework", RFC 6086, January 2011.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC
Protocol (XMPP): Core", RFC 6120, March 2011. 7405, December 2014.
9.2. Informative References 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, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC5588] Williams, N., "Generic Security Service Application
Program Interface (GSS-API) Extension for Storing
Delegated Credentials", RFC 5588, July 2009.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (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.
[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: [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX:
Combined Use of the Session Initiation Protocol (SIP) and Combined Use of the Session Initiation Protocol (SIP) and
the Extensible Messaging and Presence Protocol (XMPP)", the Extensible Messaging and Presence Protocol (XMPP)",
RFC 7081, November 2013. RFC 7081, November 2013.
Authors' Addresses Authors' Addresses
Emil Ivov Emil Ivov
Jitsi Jitsi
Strasbourg 67000 Strasbourg 67000
France France
Phone: +33 6 72 81 15 55 Phone: +33 6 72 81 15 55
Email: emcho@jitsi.org Email: emcho@jitsi.org
Thomas Stach
Unaffiliated
Vienna 1130
Austria
Email: thomass.stach@gmail.com
Enrico Marocco Enrico Marocco
Telecom Italia Telecom Italia
Via G. Reiss Romoli, 274 Via G. Reiss Romoli, 274
Turin 10148 Turin 10148
Italy Italy
Email: enrico.marocco@telecomitalia.it Email: enrico.marocco@telecomitalia.it
Christer Holmberg Christer Holmberg
Ericsson Ericsson
 End of changes. 115 change blocks. 
375 lines changed or deleted 851 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/