draft-ietf-mmusic-trickle-ice-sip-05.txt   draft-ietf-mmusic-trickle-ice-sip-06.txt 
Network Working Group E. Ivov Network Working Group E. Ivov
Internet-Draft Jitsi Internet-Draft Jitsi
Intended status: Standards Track T. Stach Intended status: Standards Track T. Stach
Expires: February 10, 2017 Unaffiliated Expires: May 4, 2017 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
August 9, 2016 October 31, 2016
A Session Initiation Protocol (SIP) usage for Trickle ICE A Session Initiation Protocol (SIP) usage for Trickle ICE
draft-ietf-mmusic-trickle-ice-sip-05 draft-ietf-mmusic-trickle-ice-sip-06
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
skipping to change at page 1, line 45 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 February 10, 2017. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . . 5 3.1. Discovery issues . . . . . . . . . . . . . . . . . . . . 5
3.2. Discovery issues . . . . . . . . . . . . . . . . . . . . 6 3.2. Relationship with the Offer/Answer Model . . . . . . . . 6
3.3. Relationship with the Offer/Answer Model . . . . . . . . 7 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 8
4. Incremental Signaling of ICE candidates . . . . . . . . . . . 9 4.1. Establishing the dialog . . . . . . . . . . . . . . . . . 8
4.1. Establishing the dialog . . . . . . . . . . . . . . . . . 9
4.1.1. Asserting dialog state through reliable Offer/Answer 4.1.1. Asserting dialog state through reliable Offer/Answer
delivery . . . . . . . . . . . . . . . . . . . . . . 9 delivery . . . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Asserting dialog state through unreliable 4.1.2. Asserting dialog state through unreliable
Offer/Answer delivery . . . . . . . . . . . . . . . . 10 Offer/Answer delivery . . . . . . . . . . . . . . . . 9
4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 12 4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 11
4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 13 4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 12
4.2. Delivering candidates in INFO messages . . . . . . . . . 15 4.2. Delivering candidates in INFO messages . . . . . . . . . 14
5. Initial discovery of Trickle ICE support . . . . . . . . . . 18 5. Initial discovery of Trickle ICE support . . . . . . . . . . 17
5.1. Provisioning support for Trickle ICE . . . . . . . . . . 18 5.1. Provisioning support for Trickle ICE . . . . . . . . . . 17
5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 19 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 18
5.3. Trickle ICE discovery through other protocols . . . . . . 20 5.3. Trickle ICE discovery through other protocols . . . . . . 19
5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 20 5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 19
6. Considerations for RTP and RTCP multiplexing . . . . . . . . 22 6. Considerations for RTP and RTCP multiplexing . . . . . . . . 21
7. Considerations for Media Multiplexing . . . . . . . . . . . . 23 7. Considerations for Media Multiplexing . . . . . . . . . . . . 22
8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 26 8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 25
9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 26 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 25
9.1. Overall Description . . . . . . . . . . . . . . . . . . . 26 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 25
9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Overall Description . . . . . . . . . . . . . . . . . . 28 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 27
10.2. Applicability . . . . . . . . . . . . . . . . . . . . . 28 10.2. Overall Description . . . . . . . . . . . . . . . . . . 28
10.3. Info Package Name . . . . . . . . . . . . . . . . . . . 28 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 28
10.4. Info Package Parameters . . . . . . . . . . . . . . . . 28 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 28
10.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 28 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 28
10.6. Info Message Body Parts . . . . . . . . . . . . . . . . 29 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 28
10.7. Info Package Usage Restrictions . . . . . . . . . . . . 29 10.7. Info Message Body Parts . . . . . . . . . . . . . . . . 29
10.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 29 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 29
10.9. Info Package Security Considerations . . . . . . . . . . 29 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 29
10.10. Info Package Security Considerations . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 29 11.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 29
11.2. application/trickle-ice-sdpfrag MIME Type . . . . . . . 30 11.2. application/trickle-ice-sdpfrag MIME Type . . . . . . . 30
11.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 32 11.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 32
11.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 32 11.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 33 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 33
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
15.1. Normative References . . . . . . . . . . . . . . . . . . 34 15.1. Normative References . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . 36 15.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
The Interactive Connectivity Establishment protocol The Interactive Connectivity Establishment protocol
[I-D.ietf-mmusic-rfc5245bis] (a.k.a. Vanilla ICE) describes a [I-D.ietf-mmusic-rfc5245bis] describes a mechanism for NAT traversal
mechanism for NAT traversal that consists of three main phases: a that consists of three main phases: a phase where an agent gathers a
phase where an agent gathers a set of candidate transport addresses set of candidate transport addresses (source IP address, port and
(source IP address, port and transport protocol), a second phase transport protocol), a second phase where these candidates are sent
where these candidates are sent to a remote agent and this gathering to a remote agent and this gathering procedure is repeated and,
procedure is repeated and, finally, a third phase where connectivity finally, a third phase where connectivity between all candidates in
between all candidates in both sets is checked (connectivity checks). both sets is checked (connectivity checks). Once these phases have
Once these phases have been completed, and only then, can both agents been completed, and only then, can both agents begin communication.
begin communication. According to the Vanilla ICE specification the According to [I-D.ietf-mmusic-rfc5245bis] the three phases above
three phases above happen consecutively, in a blocking way, which can happen consecutively, in a blocking way, which can introduce
introduce undesirable latency during session establishment. undesirable latency during session establishment.
The Trickle ICE extension defined in [I-D.ietf-ice-trickle] defines The Trickle ICE extension [I-D.ietf-ice-trickle] defines generic
generic semantics required for these ICE phases to happen semantics required for these ICE phases to happen simultaneously, in
simultaneously, in a non-blocking way and hence speed up session a non-blocking way and hence speed up session establishment.
establishment.
This specification defines a usage of Trickle ICE with the Session This specification defines a usage of Trickle ICE with the Session
Initiation Protocol (SIP)[RFC3261]. 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 Trickle and Full Trickle modes defined in [I-D.ietf-ice-trickle] Half Trickle and Full Trickle modes defined in [I-D.ietf-ice-trickle]
are to be used by SIP User Agents (UAs) depending on their are to be used by SIP User Agents (UAs) depending on their
expectations for support of Trickle ICE by a remote agent. expectations for support of Trickle ICE by a remote agent.
This document defines a new Info Package as specified in [RFC6086] This document defines a new Info Package as specified in [RFC6086]
for use with Trickle ICE. for use with Trickle ICE.
skipping to change at page 4, line 19 skipping to change at page 4, line 19
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 protocol for Interactive Connectivity Establishment in
[I-D.ietf-mmusic-rfc5245bis] and its Trickle ICE extension [I-D.ietf-mmusic-rfc5245bis] and its Trickle ICE extension
[I-D.ietf-ice-trickle]. It is assumed that the reader will be [I-D.ietf-ice-trickle]. It is assumed that the reader will be
familiar with the terminology from both of them. familiar with the terminology from both of them.
3. Protocol Overview 3. Protocol Overview
The semantics that Vanilla ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp] Using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the ICE
defines for exchanging ICE candidates are exclusively based on use of candidates are exchanged using SDP Offer/Answer as per [RFC3264].
Offers and Answers as per [RFC3264] over the Session Description This specification defines an additional mechanism where candidates
Protocol (SDP) [RFC4566]. This specification extends these mechanism can be exchanged using SIP INFO messages and a newly defined Info
by allowing ICE candidates to also be sent in parallel to the Offer/ Package [RFC6086]. This allows ICE candidates to also be sent in
Answer negotiation or after the completion of Offer/Answer parallel to an ongoing Offer/Answer negotiation and/or after the
negotiation. This extension is done through the use of SIP INFO completion of the Offer/Answer negotiation.
messages and a newly defined Info Package [RFC6086].
Typically, in cases where Trickle ICE is fully supported, a candidate Typically, in cases where Trickle ICE is fully supported, the Offerer
exchange would happen along the following lines: The Offerer would would send an INVITE request containing a subset of candidates. Once
send an INVITE containing a subset of candidates and then wait for an an early dialog is established the Offerer can continue sending
early dialog to be established. Once that happens, it will be able candidates in INFO requests within that dialog.
to continue sending candidates through in INFO requests and within
the same dialog.
Similarly, an Answerer can start or continue "trickling" ICE Similarly, an Answerer can send 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 5, line 37 skipping to change at page 5, line 37
| | 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. Discovery issues
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 [I-D.ietf-mmusic-ice-sip-sdp] 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
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 back-off
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 to benefit from Trickle ICE's full potential and reduce In order 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"
skipping to change at page 7, line 23 skipping to change at page 6, line 23
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.2. Relationship with the Offer/Answer Model
It is important to note that this specification does not require, From the perspective of all SIP middle boxes and proxies, and with
define, or even assume any mechanisms that would have an impact on the exception of the actual INFO messages, signaling in general and
the Offer/Answer model beyond the way it is already used by Vanilla Offer/Answer exchanges in particular would look the same way for
ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. From the perspective of Trickle ICE as they would for ICE for SIP
all SIP middle boxes and proxies, and with the exception of the [I-D.ietf-mmusic-ice-sip-sdp].
actual INFO messages, signaling in general and Offer/Answer exchanges
in particular would look the same way for Trickle ICE as they would
for Vanilla ICE for SIP.
+-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+
| 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 8, line 39 skipping to change at page 7, line 39
| | | |
| | | | | | | |
| | 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
signaling. signaling.
It is important to note that, as displayed on Figure 2, exchanging From an architectural viewpoint, as displayed on Figure 2, exchanging
candidates through SIP INFO messages are best represented as candidates through SIP INFO requests could be represented as
signaling between ICE agents and not between the traditional SIP and signaling between ICE agents and not between Offer/Answer modules of
Offer/Answer modules of SIP User Agents. Then, such INFO requests do SIP User Agents. Then, such INFO requests do not impact the state of
not impact the state of the Offer/Answer transaction other than the Offer/Answer transaction other than providing additional
providing additional candidates. Consequently, if a new offer is to candidates. Consequently, INFO requests are not considered Offers or
be send at some point in time it would include the candidates of the Answers. Nevertheless, candidates that have been exchanged using
previous offer and the candidates that were trickled in the meantime. INFO SHALL be included in subsequent Offers or Answers. The version
The version number in the "o=" line of that new offer would need to number in the "o=" line of that subsequent offer would need to be
be incremented by 1 per the rules in [RFC3264]. incremented by 1 per the rules in [RFC3264].
4. Incremental Signaling of ICE candidates 4. Incremental Signaling of ICE candidates
Trickle ICE agents will construct Offers and Answers as specified in Trickle ICE agents will construct Offers and Answers as specified in
[I-D.ietf-ice-trickle] with the following additional SIP-specific [I-D.ietf-ice-trickle] with the following additional SIP-specific
additions: additions:
1. Trickle ICE agents MUST indicate support for Trickle ICE by 1. Trickle ICE agents MUST indicate support for Trickle ICE by
including the option-tag 'trickle-ice' in a SIP Supported: header including the option-tag 'trickle-ice' in a SIP Supported: header
field within all SIP INVITE requests and responses. field within all SIP INVITE requests and responses.
skipping to change at page 13, line 31 skipping to change at page 12, line 31
| 183 (Answer) opt. | | 183 (Answer) opt. |
|<------------------------| |<------------------------|
| INFO/OK (SRFLX Cand.) | | INFO/OK (SRFLX Cand.) |
|<------------------------| |<------------------------|
| 200/ACK (Answer) | | 200/ACK (Answer) |
|<------------------------| |<------------------------|
Figure 6: A SIP UA sends an unreliable provisional response without Figure 6: A SIP UA sends an unreliable provisional response without
an Answer for establishing an early dialog an Answer for establishing an early dialog
When sending the Answer the agent MUST repeat all previously sent When sending the Answer the agent MUST repeat all currently known and
candidates, if any, and MAY include all newly gathered candidates used candidates, if any, and MAY include all newly gathered
since the last INFO request was sent. If that answer was sent in a candidates since the last INFO request was sent. If that Answer was
unreliable provisional response, the Answerers MUST repeat exactly sent in a unreliable provisional response, the Answerers MUST repeat
the same Answer in the 200 OK response in order to fulfill the exactly the same Answer in the 200 OK response in order to fulfill
corresponding requirements in [RFC3264]. In other words, an Offerer the corresponding requirements in [RFC3264]. In other words, an
needs to be prepared to receive fewer candidates in that repeated Offerer needs to be prepared to receive fewer candidates in that
Answer than previously exchanged via trickling. repeated Answer than previously exchanged via trickling.
4.1.4. Considerations for 3PCC 4.1.4. Considerations for 3PCC
Agents that have sent an Offer in a reliable provisional response and 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 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 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 to be in a state that would allow in-dialog INFO requests (see
Figure 7). Figure 7).
Alice Bob Alice Bob
skipping to change at page 17, line 4 skipping to change at page 16, line 4
Lines appearing in between or after "a=mid:" attributes will be Lines appearing in between or after "a=mid:" attributes will be
interpreted as media-level. interpreted as media-level.
Note that while this specification uses the "a=mid:" attribute Note that while this specification uses the "a=mid:" attribute
from [RFC5888], it does not define any grouping semantics. from [RFC5888], it does not define any grouping semantics.
Consequently, using the "a=group:" attribute from that same Consequently, using the "a=group:" attribute from that same
specification is neither needed nor used in Trickle ICE for SIP. specification is neither needed nor used in Trickle ICE for SIP.
All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:"
attributes that would allow mapping them to a specific ICE attributes that would allow mapping them to a specific ICE
generation. INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:" generation. An agent MUST discard any received INFO requests
attributes that do not match those of the current ICE processing containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not
session MUST be discarded. match those of the current ICE processing session.
The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the 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, same level as the ones in the Offer/Answer exchange. In other words,
if they were present as session-level attributes there, they will if they were present as session-level attributes there, they will
also appear at the beginning of all INFO message payloads, preceding also appear at the beginning of all INFO message payloads, preceding
all "a=mid:" attributes. If they were originally exchanged as media all "a=mid:" attributes. If they were originally exchanged as media
level attributes, potentially overriding session-level values, then level attributes, potentially overriding session-level values, then
they will also be included in INFO message payloads, following the they will also be included in INFO message payloads, following the
corresponding "a=mid:" attribute. corresponding "a=mid:" attribute.
In every INFO request agents MUST include all local candidates they In every INFO request agents MUST include all currently known and
have signaled previously. This is necessary in order to more easily used local candidates. This allows easier handling of problems that
avoid problems that would arise from unreliable transports. Mis- could arise from unreliable transports, like e.g. loss of messages
ordering can be detected through the CSeq: header field in the INFO and reordering. Mis-ordering can be detected through the CSeq:
request. As a consequence candidates cannot be removed unless an ICE header field in the INFO request.
restart is performed. Note that extension might be specified in the
future that enable such removal without a restart.
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, the ICE agents will then receive and process the candidates, the ICE agents will then receive and process the
remaining, actually new candidates according to the rules described remaining, actually new candidates according to the rules described
in [I-D.ietf-ice-trickle]. in [I-D.ietf-ice-trickle].
skipping to change at page 19, line 16 skipping to change at page 18, line 16
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 10.5 provides SIP UAs with a way of learning the defined in Section 10.6 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 9). response(s) for support of both GRUU and Trickle ICE (Figure 9).
skipping to change at page 26, line 46 skipping to change at page 25, line 46
Mux Category: IDENTICAL Mux Category: IDENTICAL
Example: a=end-of-candidate Example: a=end-of-candidate
9. Content Type 'application/trickle-ice-sdpfrag' 9. Content Type 'application/trickle-ice-sdpfrag'
9.1. Overall Description 9.1. Overall Description
A application/trickle-ice-sdpfrag body is used by the Trickle-ICE A application/trickle-ice-sdpfrag body is used by the Trickle-ICE
Info Package. It uses a subset of the possible SDP lines that are Info Package. It uses a subset of the possible SDP lines as defined
allowed based on the grammar defined in [RFC4566]. A valid body uses by the grammar defined in [RFC4566]. A valid body uses only media
only media descriptions and certain attributes that are needed and/or descriptions and certain attributes that are needed and/or useful for
useful for trickling candidates. The content adheres to the trickling candidates. The content adheres to the following grammar.
following grammar.
9.2. Grammar 9.2. Grammar
The grammar of an 'application/trickle-ice-sdpfrag' body is based the The grammar of an 'application/trickle-ice-sdpfrag' body is based the
following ABNF [RFC5234]. It specifies the subset of existing SDP following ABNF [RFC5234]. It specifies the subset of existing SDP
attributes, that are needed or useful for trickling candidates. attributes, that are needed or useful for trickling candidates.
; Syntax ; Syntax
trickle-ice-sdpfrag = session-level-fields trickle-ice-sdpfrag = session-level-fields
pseudo-media-descriptions pseudo-media-descriptions
skipping to change at page 28, line 12 skipping to change at page 27, line 12
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-
pacing-att, ice-options, candidate-attribute remote-candidate-att pacing-att, ice-options, candidate-attribute remote-candidate-att
from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute
; from [RFC5888], media-field, attribute-fields from [RFC4566]. The ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The
indicator for case-sensitivity %s is defined in [RFC7405]. indicator for case-sensitivity %s is defined in [RFC7405].
An Agent MUST ignore any received unknown extension-attribute-fields. An Agent MUST ignore any received unknown extension-attribute-fields.
10. Info Package 10. Info Package
10.1. Overall Description 10.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 [RFC3311]
introduces the following complications:
Blocking of messages: [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 UPDATE requests for candidate 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 back-off
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. Out-of-
dialog alternatives 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.
10.2. Overall Description
This specification defines an Info Package for use by SIP user agents This specification defines an Info Package for use by SIP user agents
implementing Trickle ICE. INFO requests carry ICE candidates implementing Trickle ICE. INFO requests carry ICE candidates
discovered after the peer user agents have confirmed mutual support discovered after the peer user agents have confirmed mutual support
for Trickle ICE. for Trickle ICE.
10.2. Applicability 10.3. Applicability
The purpose of the ICE protocol is to establish a media path in the The purpose of the ICE protocol is to establish a media path in the
presence of NAT and firewalls. The candidates are transported in presence of NAT and firewalls. The candidates are transported in
INFO requests and are part of this establishment. INFO requests and are part of this establishment.
Candidates sent by a Trickle ICE agent after the Offer, follow the Candidates sent by a Trickle ICE agent after the Offer, follow the
same signaling path and reach the same entity as the Offer itself. same signaling 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 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 goals of this specification is to allow operation of Trickle ICE in
as many environments as possible including those without GRUU as many environments as possible including those without GRUU
support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not
satisfy this goal. satisfy this goal.
10.3. Info Package Name 10.4. 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"
10.4. Info Package Parameters 10.5. Info Package Parameters
This document does not define any Info Package parameters. This document does not define any Info Package parameters.
10.5. SIP Option Tags 10.6. SIP Option Tags
[RFC6086] allows Info Package specifications to define SIP option- [RFC6086] allows Info Package specifications to define SIP option-
tags. This specification extends the option-tag construct of the SIP tags. This specification extends the option-tag construct of the SIP
grammar as follows: grammar as follows:
option-tag /= "trickle-ice" option-tag /= "trickle-ice"
SIP entities that support this specification MUST place the 'trickle- SIP entities that support this specification MUST place the 'trickle-
ice' option-tag in a SIP Supported: header field within all SIP ice' option-tag in a SIP Supported: header field within all SIP
INVITE requests and responses. 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.
10.6. Info Message Body Parts 10.7. Info Message Body Parts
Entities implementing this specification MUST include a payload of Entities implementing this specification MUST include a payload of
type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 all type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 all
SIP INFO requests. The payload is used to convey SDP encoded ICE SIP INFO requests. The payload is used to convey SDP encoded ICE
candidates. candidates.
10.7. Info Package Usage Restrictions 10.8. Info Package Usage Restrictions
This document does not define any Info Package Usage Restrictions. This document does not define any Info Package Usage Restrictions.
10.8. Rate of INFO Requests 10.9. Rate of INFO Requests
A Trickle ICE Agent with many network interfaces might create a high A Trickle ICE Agent with many network interfaces might create a high
rate of INFO requests if every newly detected candidate is trickled rate of INFO requests if every newly detected candidate is trickled
individually without aggregation. Implementor that are concerned individually without aggregation. Implementor that are concerned
about loss of packets in such a case might consider aggregating ICE about loss of packets in such a case might consider aggregating ICE
candidates and sending INFOS only at some configurable intervals. candidates and sending INFOS only at some configurable intervals.
10.9. Info Package Security Considerations 10.10. Info Package Security Considerations
See Section 12 See Section 12
11. IANA Considerations 11. IANA Considerations
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document. Please replace "I-D.ietf-ice-trickle" with the RFC number document. Please replace "I-D.ietf-ice-trickle" with the RFC number
of that document.] of that document.]
11.1. SDP 'end-of-candidate' Attribute 11.1. SDP 'end-of-candidate' Attribute
skipping to change at page 34, line 30 skipping to change at page 34, line 30
o considered comments from Christer Holmberg o considered comments from Christer Holmberg
o corrected grammar for INFO package, such that ice-ufrag/pwd are o corrected grammar for INFO package, such that ice-ufrag/pwd are
also allowed on media-level as specified in also allowed on media-level as specified in
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp]
o Added formal definition for the end-of-candidates attribute o Added formal definition for the end-of-candidates attribute
Changes from draft-ietf-mmusic-trickle-ice-sip-05
o considered further comments from Christer Holmberg
o editorial comments on section 3 addressed
o moved section 3.1 to section 10.1 and applied some edits
o replaced the term "previously sent candidates" with "currently
known and used candidates".
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-ice-trickle] [I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for "Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE) the Interactive Connectivity Establishment (ICE)
Protocol", draft-ietf-ice-trickle-03 (work in progress), Protocol", draft-ietf-ice-trickle-04 (work in progress),
July 2016. September 2016.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using
Interactive Connectivity Establishment (ICE) with Session Interactive Connectivity Establishment (ICE) with Session
Description Protocol (SDP) offer/answer and Session Description Protocol (SDP) offer/answer and Session
Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip-
sdp-10 (work in progress), July 2016. sdp-10 (work in progress), July 2016.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
skipping to change at page 35, line 15 skipping to change at page 35, line 27
[I-D.ietf-mmusic-rfc5245bis] [I-D.ietf-mmusic-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal", draft-ietf-mmusic- Translator (NAT) Traversal", draft-ietf-mmusic-
rfc5245bis-05 (work in progress), September 2015. rfc5245bis-05 (work in progress), September 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-31 (work in progress), June 2016. negotiation-36 (work in progress), October 2016.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-13 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14
(work in progress), June 2016. (work in progress), September 2016.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
skipping to change at page 36, line 31 skipping to change at page 36, line 45
Initiation Protocol (SIP) INFO Method and Package Initiation Protocol (SIP) INFO Method and Package
Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011,
<http://www.rfc-editor.org/info/rfc6086>. <http://www.rfc-editor.org/info/rfc6086>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<http://www.rfc-editor.org/info/rfc7405>. <http://www.rfc-editor.org/info/rfc7405>.
15.2. Informative References 15.2. Informative References
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
2002, <http://www.rfc-editor.org/info/rfc3311>.
[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, Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004, DOI 10.17487/RFC3840, August 2004,
<http://www.rfc-editor.org/info/rfc3840>. <http://www.rfc-editor.org/info/rfc3840>.
[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, DOI 10.17487/RFC5627, October 2009, (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009,
<http://www.rfc-editor.org/info/rfc5627>. <http://www.rfc-editor.org/info/rfc5627>.
 End of changes. 35 change blocks. 
173 lines changed or deleted 175 lines changed or added

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