draft-ietf-mmusic-trickle-ice-sip-04.txt   draft-ietf-mmusic-trickle-ice-sip-05.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: November 18, 2016 Unaffiliated Expires: February 10, 2017 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
May 17, 2016 August 9, 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-04 draft-ietf-mmusic-trickle-ice-sip-05
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 November 18, 2016. This Internet-Draft will expire on February 10, 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 28 skipping to change at page 2, line 28
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. Rationale - Why INFO? . . . . . . . . . . . . . . . . . . 5
3.2. Discovery issues . . . . . . . . . . . . . . . . . . . . 6 3.2. Discovery issues . . . . . . . . . . . . . . . . . . . . 6
3.3. Relationship with the Offer/Answer Model . . . . . . . . 7 3.3. Relationship with the Offer/Answer Model . . . . . . . . 7
4. Incremental Signalling of ICE candidates . . . . . . . . . . 9 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 9
4.1. Establishing the dialog . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Asserting dialog state through unreliable 4.1.2. Asserting dialog state through unreliable
Offer/Answer delivery . . . . . . . . . . . . . . . . 10 Offer/Answer delivery . . . . . . . . . . . . . . . . 10
4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 12 4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 12
4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 13 4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 13
4.2. Delivering candidates in INFO messages . . . . . . . . . 15 4.2. Delivering candidates in INFO messages . . . . . . . . . 15
5. Initial discovery of Trickle ICE support . . . . . . . . . . 18 5. Initial discovery of Trickle ICE support . . . . . . . . . . 18
5.1. Provisioning support for Trickle ICE . . . . . . . . . . 18 5.1. Provisioning support for Trickle ICE . . . . . . . . . . 18
5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 19 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 19
5.3. Trickle ICE discovery through other protocols . . . . . . 20 5.3. Trickle ICE discovery through other protocols . . . . . . 20
5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 20 5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 20
6. Considerations for RTP and RTCP multiplexing . . . . . . . . 22 6. Considerations for RTP and RTCP multiplexing . . . . . . . . 22
7. Considerations for Media Multiplexing . . . . . . . . . . . . 23 7. Considerations for Media Multiplexing . . . . . . . . . . . . 23
8. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 26 8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 26
8.1. Overall Description . . . . . . . . . . . . . . . . . . . 26 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 26
8.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 26
9. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Overall Description . . . . . . . . . . . . . . . . . . . 28 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Overall Description . . . . . . . . . . . . . . . . . . 28
9.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 28 10.2. Applicability . . . . . . . . . . . . . . . . . . . . . 28
9.4. Info Package Parameters . . . . . . . . . . . . . . . . . 28 10.3. Info Package Name . . . . . . . . . . . . . . . . . . . 28
9.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 28 10.4. Info Package Parameters . . . . . . . . . . . . . . . . 28
9.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 29 10.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 28
9.7. Info Package Usage Restrictions . . . . . . . . . . . . . 29 10.6. Info Message Body Parts . . . . . . . . . . . . . . . . 29
9.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 29 10.7. Info Package Usage Restrictions . . . . . . . . . . . . 29
9.9. Info Package Security Considerations . . . . . . . . . . 29 10.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10.9. Info Package Security Considerations . . . . . . . . . . 29
10.1. application/trickle-ice-sdpfrag MIME Type . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10.2. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 31 11.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 29
10.3. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 31 11.2. application/trickle-ice-sdpfrag MIME Type . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 11.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 32
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 11.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 32
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
14.1. Normative References . . . . . . . . . . . . . . . . . . 33 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . 35 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 15.1. Normative References . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . 36
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] (a.k.a. Vanilla ICE) describes a
mechanism for NAT traversal that consists of three main phases: a mechanism for NAT traversal that consists of three main phases: a
phase where an agent gathers a set of candidate transport addresses phase where an agent gathers a set of candidate transport addresses
(source IP address, port and transport protocol), a second phase (source IP address, port and transport protocol), a second phase
where these candidates are sent to a remote agent and this gathering where these candidates are sent to a remote agent and this gathering
procedure is repeated and, finally, a third phase where connectivity procedure is repeated and, finally, a third phase where connectivity
between all candidates in both sets is checked (connectivity checks). between all candidates in both sets is checked (connectivity checks).
Once these phases have been completed, and only then, can both agents Once these phases have been completed, and only then, can both agents
begin communication. According to the Vanilla ICE specification the begin communication. According to the Vanilla ICE specification the
three phases above happen consecutively, in a blocking way, which can three phases above happen consecutively, in a blocking way, which can
introduce undesirable latency during session establishment. introduce undesirable 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-ice-trickle] defines
defines generic semantics required for these ICE phases to happen 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.
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 Half Trickle and Full Trickle modes defined in [I-D.ietf-ice-trickle]
[I-D.ietf-mmusic-trickle-ice] are to be used by SIP User Agents (UAs) are to be used by SIP User Agents (UAs) depending on their
depending on their expectations for support of Trickle ICE by a expectations for support of Trickle ICE by a remote agent.
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.
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 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-mmusic-trickle-ice]. 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] The semantics that Vanilla ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]
defines for exchanging ICE candidates are exclusively based on use of defines for exchanging ICE candidates are exclusively based on use of
Offers and Answers as per [RFC3264] over the Session Description Offers and Answers as per [RFC3264] over the Session Description
Protocol (SDP) [RFC4566]. This specification extends these mechanism Protocol (SDP) [RFC4566]. This specification extends these mechanism
by allowing ICE candidates to also be sent in parallel to the Offer/ by allowing ICE candidates to also be sent in parallel to the Offer/
Answer negotiation or after the completion of Offer/Answer Answer negotiation or after the completion of Offer/Answer
skipping to change at page 7, line 8 skipping to change at page 7, line 8
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-ice-trickle] provides one way around this, by
this, by requiring first Offers to contain a complete set of ICE requiring first Offers to contain a complete set of ICE candidates
candidates and only using incremental provisioning for the rest of 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 for SIP [I-D.ietf-mmusic-ice-sip-sdp]. From the perspective of ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. From the perspective of
all SIP middle boxes and proxies, and with the exception of the all SIP middle boxes and proxies, and with the exception of the
actual INFO messages, signalling in general and Offer/Answer actual INFO messages, signaling in general and Offer/Answer exchanges
exchanges in particular would look the same way for Trickle ICE as in particular would look the same way for Trickle ICE as they would
they would for Vanilla ICE for SIP. 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 37 skipping to change at page 8, line 37
| 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. signaling.
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 signaling 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. Then, such INFO requests do
impact the state of Offer/Answer, nor do they have an impact on the not impact the state of the Offer/Answer transaction other than
version number in the "o=" line. In that regard they are actually providing additional candidates. Consequently, if a new offer is to
comparable to Peer Reflexive candidates that ICE agents can discover be send at some point in time it would include the candidates of the
during ICE processing. previous offer and the candidates that were trickled in the meantime.
The version number in the "o=" line of that new offer would need to
be incremented by 1 per the rules in [RFC3264].
4. Incremental Signalling 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-mmusic-trickle-ice] with the following additional SIP- [I-D.ietf-ice-trickle] with the following additional SIP-specific
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.
2. Trickle ICE agents MAY exchange additional ICE candidates using 2. Trickle ICE agents MAY exchange additional ICE candidates using
INFO requests within an existing invite dialog usage (including INFO requests within an existing INVITE dialog usage (including
an early dialog) as specified in [RFC6086]. The INFO messages an early dialog) as specified in [RFC6086]. The INFO messages
carry an Info-Package: trickle-ice. Trickle ICE agents MUST be carry an Info-Package: trickle-ice. Trickle ICE agents MUST be
prepared to receive INFO requests within that same dialog usage, prepared to receive INFO requests within that same dialog usage,
containing additional candidates or an indication for the end of containing additional candidates or an indication for the end of
such candidates such candidates
3. Trickle ICE agents MAY exchange additional ICE candidates before 3. Trickle ICE agents MAY exchange additional ICE candidates before
the Answerer has sent the Answer provided that an invite dialog the Answerer has sent the Answer provided that an invite dialog
usage is established at both Trickle ICE agents. Note that in usage is established at both Trickle ICE agents. Note that in
case of forking multiple early dialogs will exist. case of forking multiple early dialogs will exist.
skipping to change at page 15, line 38 skipping to change at page 15, line 38
|------------------------>| |------------------------>|
| | | |
Figure 8: A SIP UAC in a 3PCC scenario can also freely start Figure 8: A SIP UAC in a 3PCC scenario can also freely start
trickling as soon as it receives an unreliable provisional response. 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-ice-trickle]. 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 the Info The use of SIP INFO requests happens within the context of the Info
Package as defined Section 9. The MIME type for their payload MUST Package as defined Section 10. The MIME type for their payload MUST
be set to 'application/trickle-ice-sdpfrag' as defined in Section 8. be set to 'application/trickle-ice-sdpfrag' as defined in Section 9.
Since neither the "a=candidate" nor the "a=end-of-candidates" Since neither the "a=candidate" nor the "a=end-of-candidates"
attributes contain information that would allow correlating them to a attributes contain information that would allow correlating them to a
specific "m=" line, this is handled through the use of pseudo "m=" specific "m=" line, this is handled through the use of pseudo "m="
lines and identification tags in "a=mid:" attributes as defined in lines and identification tags in "a=mid:" attributes as defined in
[RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as
defined in [RFC4566], but provide no semantics other than indicating defined in [RFC4566], but provide no semantics other than indicating
to which "m=" line a candidate belongs. Consequently, the receiving to which "m=" line a candidate belongs. Consequently, the receiving
agent MUST ignore the remaining content of the pseudo m-line. This agent MUST ignore the remaining content of the pseudo m-line. This
skipping to change at page 17, line 6 skipping to change at page 17, line 6
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. INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:"
attributes that do not match those of the current ICE processing attributes that do not match those of the current ICE processing
session MUST be discarded. The "a=ice-pwd:" and "a=ice-ufrag:" session MUST be discarded.
attributes MUST appear at the same level as the ones in the Offer/
Answer exchange. In other words, if they were present as session- The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the
level attributes there, they will also appear at the beginning of all same level as the ones in the Offer/Answer exchange. In other words,
INFO message payloads, preceding all "a=mid:" attributes. If they if they were present as session-level attributes there, they will
were originally exchanged as media level attributes, potentially also appear at the beginning of all INFO message payloads, preceding
overriding session-level values, then they will also be included in all "a=mid:" attributes. If they were originally exchanged as media
INFO message payloads, following the corresponding "a=mid:" level attributes, potentially overriding session-level values, then
attribute. 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 signaled. This is necessary in order to more easily have signaled previously. This is necessary in order to more easily
avoid problems that would arise from unreliability. Mis-ordering can avoid problems that would arise from unreliable transports. Mis-
be detected through the CSeq: header field in the INFO request. ordering can be detected through the CSeq: header field in the INFO
request. As a consequence candidates cannot be removed unless an ICE
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, agents will then process the remaining, actually new candidates, the ICE agents will then receive and process the
candidates according to the rules described in remaining, actually new candidates according to the rules described
[I-D.ietf-mmusic-trickle-ice]. in [I-D.ietf-ice-trickle].
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: ...
skipping to change at page 18, line 29 skipping to change at page 18, line 29
a=end-of-candidates a=end-of-candidates
m=audio 9 RTP/AVP 0 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
5. Initial discovery of Trickle ICE support 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-ice-trickle] to indicate that in their Offers
Offers and Answers using the following attribute: "a=ice- and Answers using the following attribute: "a=ice-options:trickle".
options:trickle". This makes discovery fairly straightforward for This makes discovery fairly straightforward for Answerers or for
Answerers or for cases where Offers need to be generated within cases where Offers need to be generated within existing dialogs
existing dialogs (i.e., when sending re-INVITE requests). In both (i.e., when sending re-INVITE requests). In both scenarios prior SDP
scenarios prior SDP would have provided the necessary information. 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
skipping to change at page 19, line 16 skipping to change at page 19, 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 9.5 provides SIP UAs with a way of learning the defined in Section 10.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 9). response(s) for support of both GRUU and Trickle ICE (Figure 9).
skipping to change at page 20, line 23 skipping to change at page 20, line 23
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 or declare as out of scope] on a specific way to do this or declare as out of scope]
5.4. Fall-back to Half Trickle 5.4. Fall-back 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-ice-trickle]. With Half Trickle, agents initiate sessions
sessions the same way they would when using Vanilla ICE for SIP the same way they would when using Vanilla ICE for SIP
[I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually
sending an Offer, agents would first gather ICE candidates in a sending an Offer, agents would first gather ICE candidates in a
blocking way and then send them all in that Offer. The blocking blocking way and then send them all in that Offer. The blocking
nature of the process would likely imply that some amount of latency nature of the process would likely imply that some amount of latency
will be accumulated and it is advised that agents try to anticipate will be accumulated and it is advised that agents try to anticipate
it where possible, like for example, when user actions indicate a it where possible, like for example, when user actions indicate a
high likelihood for an imminent call (e.g., activity on a keypad or a high likelihood for an imminent call (e.g., activity on a keypad or a
phone going off-hook). phone going off-hook).
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 SIP endpoints and legacy [RFC3264] endpoints. both Vanilla ICE SIP endpoints and legacy [RFC3264] endpoints.
STUN/Turn STUN/TURN STUN/Turn STUN/TURN
Servers Alice Bob Servers Servers Alice Bob Servers
| | | | | | | |
|<--------------| | | |<--------------| | |
| | | | | | | |
| | | | | | | |
| Candidate | | | | Candidate | | |
| | | | | | | |
| | | | | | | |
| Discovery | | | | Discovery | | |
| | | | | | | |
| | | | | | | |
|-------------->| INVITE (Offer) | | |-------------->| INVITE (Offer) | |
| |---------------------------->| | | |---------------------------->| |
| | 183 (Answer) |-------------->| | | 183 (Answer) |-------------->|
| |<----------------------------| | | |<----------------------------| |
| | INFO (repeated candidates) | | | | INFO (repeated candidates) | |
| |---------------------------->| | | |---------------------------->| |
| | | | | | | |
| | INFO (more candidates) | Candidate | | | INFO (more candidates) | Candidate |
| |<----------------------------| | | |<----------------------------| |
| | Connectivity Checks | | | | Connectivity Checks | |
| |<===========================>| Discovery | | |<===========================>| Discovery |
| | INFO (more candidates) | | | | INFO (more candidates) | |
| |<----------------------------| | | |<----------------------------| |
| | Connectivity Checks |<--------------| | | Connectivity Checks |<--------------|
| |<===========================>| | | |<===========================>| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| |<----------------------------| | | |<----------------------------| |
| | | | | | | |
| | 5245 SIP re-INVITE | | | | 5245 SIP re-INVITE | |
| |---------------------------->| | | |---------------------------->| |
| | 200 OK | | | | 200 OK | |
| |<----------------------------| | | |<----------------------------| |
| | | | | | | |
| | | | | | | |
| |<======= MEDIA FLOWS =======>| | | |<======= MEDIA FLOWS =======>| |
| | | | | | | |
Figure 10: Example - A typical (Half) Trickle ICE exchange with SIP 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. Considerations for RTP and RTCP multiplexing 6. Considerations for RTP and RTCP multiplexing
skipping to change at page 24, line 15 skipping to change at page 24, line 15
ICE candidate exchange is already considered in section 11 of ICE candidate exchange is already considered in section 11 of
[I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are
still valid for Trickle ICE, however, trickling provides more still valid for Trickle ICE, however, trickling provides more
flexibility for the sequence of candidate exchange, especially in flexibility for the sequence of candidate exchange, especially in
Full Trickle mode. Full Trickle mode.
Except for bundle-only m-lines, a Half Trickle Offerer would have to Except for bundle-only m-lines, a Half Trickle Offerer would have to
send an offer with candidates for all bundled m-lines. The send an offer with candidates for all bundled m-lines. The
additional flexibility, however, allows a Full Trickle Offerer to additional flexibility, however, allows a Full Trickle Offerer to
initially send only candidates for the m-line with the suggested initially send only candidates for the m-line with the suggested
offerer BUNDLE address. Offerer BUNDLE address.
Latest on receipt of the answer, the Offerer will detect if BUNDLE is Latest on receipt of the answer, the Offerer will detect if BUNDLE is
supported and if the suggested offerer BUNDLE address was selected. supported and if the suggested Offerer BUNDLE address was selected.
In this case the Offerer does need to trickle further candidates for In this case the Offerer does not need to trickle further candidates
the remaining m-lines in a bundle. However, if BUNDLE is not for the remaining m-lines in a bundle. However, if BUNDLE is not
supported, the Full Trickle Offerer needs to gather and trickle supported, the Full Trickle Offerer needs to gather and trickle
candidates for the remaining m-lines as necessary. If the answerer candidates for the remaining m-lines as necessary. If the answerer
selects a Offerer BUNDLE address different from suggested Offerer selects a Offerer BUNDLE address different from suggested Offerer
BUNDLE address, the Full Trickle Offerer needs to gather and trickle BUNDLE address, the Full Trickle Offerer needs to gather and trickle
candidates for the m-line that carries the selected Offerer BUNDLE candidates for the m-line that carries the selected Offerer BUNDLE
address. address.
A Trickle answerer MAY include an "a=group: BUNDLE" attribute A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute
[I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle- [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle-
ice-sdpfrag body if it supports and uses bundling. When doing so, ice-sdpfrag body if it supports and uses bundling. When doing so,
the Answerer MUST include all identification-tags in the same order the Answerer MUST include all identification-tags in the same order
that is used or will be used in the Answer. that is used or will be used in the Answer.
Receipt of this attribute at the Offerer in an INFO request prior to Receipt of this attribute at the Offerer in an INFO request prior to
the Answer indicates that the Answerer supports and uses bundling. the Answer indicates that the Answerer supports and uses bundling.
The Offerer can use this information e.g. for stopping the gathering 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 of candidates for the remaining m-lines in a bundle and/or for
freeing corresponding resources. freeing corresponding resources.
skipping to change at page 26, line 6 skipping to change at page 26, line 6
m=audio 9 RTP/AVP 0 m=audio 9 RTP/AVP 0
a=mid:bar a=mid:bar
This INFO message indicates that the Answerer supports and uses Media This INFO message indicates that the Answerer supports and uses Media
Multiplexing as well. Note, that the second m-line shows the default Multiplexing as well. Note, that the second m-line shows the default
values as specified in section Section 4.2, e.g. media set 'audio' values as specified in section Section 4.2, e.g. media set 'audio'
although 'video' was offered. The receiving ICE agents needs to although 'video' was offered. The receiving ICE agents needs to
ignore these default values in the pseudo m-lines. ignore these default values in the pseudo m-lines.
The INFO message also indicates that the Answerer accepted the The INFO message also indicates that the Answerer accepted the
Suggested Bundle Address from the Offerer. This allows the Offerer suggested Offerer Bundle Address. This allows the Offerer to omit
to omit gathering of RTP and RTCP candidates for the other m-lines or gathering of RTP and RTCP candidates for the other m-lines or
releasing already gathered candidates. If the INFO message did not releasing already gathered candidates. If the INFO message did not
contain the a=group:BUNDLE attribute, the Offerer would have to contain the a=group:BUNDLE attribute, the Offerer would have to
gather RTP and RTCP candidates for the other m-lines unless it wants gather RTP and RTCP candidates for the other m-lines unless it wants
to wait until receipt of an Answer that eventually confirms support to wait until receipt of an Answer that eventually confirms support
or non-support for Media Multiplexing. or non-support for Media Multiplexing.
Independent of using Full Trickle or Half Trickle mode, the rules Independent of using Full Trickle or Half Trickle mode, the rules
from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offer and from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and
Answerer, when putting attributes in the application/trickle-ice- Answerer, when putting attributes in the application/trickle-ice-
sdpfrag body. sdpfrag body.
8. Content Type 'application/trickle-ice-sdpfrag' 8. SDP 'end-of-candidate' Attribute
8.1. Overall Description This section defines a new SDP media-level and session-level
attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' is a
property attribute [RFC4566], and hence has no value. By including
this attribute in an Offer or Answer the sending agent indicates that
it will not trickle further candidates. The detailed SDP Offer/
Answer procedures for the 'end-of-candidate' attribute are specified
in [I-D.ietf-ice-trickle].
Name: end-of-candidate
Value: N/A
Usage Level: media and session-level
Charset Dependent: no
Mux Category: IDENTICAL
Example: a=end-of-candidate
9. Content Type 'application/trickle-ice-sdpfrag'
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 that are
allowed based on the grammar defined in [RFC4566]. A valid body uses allowed based on the grammar defined in [RFC4566]. A valid body uses
only media descriptions and certain attributes that are needed and/or only media descriptions and certain attributes that are needed and/or
useful for trickling candidates. The content adheres to the useful for trickling candidates. The content adheres to the
following grammar. following grammar.
Like ordinary SDP 9.2. Grammar
8.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]. following ABNF [RFC5234]. It specifies the subset of existing SDP
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
session-level-fields = [bundle-group-attribute CRLF] session-level-fields = [bundle-group-attribute CRLF]
[ice-lite-attribute CRLF] [ice-lite-attribute CRLF]
ice-pwd-attribute CRLF ice-pwd-attribute CRLF
ice-ufrag-attribute CRLF ice-ufrag-attribute CRLF
[ice-options-attribute CRLF] [ice-options-attribute CRLF]
[end-of-candidates-attribute CRLF] [ice-pacing-attribute CRLF]
extension-attribute-fields [end-of-candidates-attribute CRLF]
; for future extensions extension-attribute-fields
; for future extensions
ice-lite-attribute = %s"a=" ice-lite ice-lite-attribute = %s"a=" ice-lite
ice-pwd-attribute = %s"a=" ice-pwd-att ice-pwd-attribute = %s"a=" ice-pwd-att
ice-ufrag-attribute = %s"a=" ice-ufrag-att ice-ufrag-attribute = %s"a=" ice-ufrag-att
ice-options-attribute = %s"a=" ice-options ice-pacing-attribute = %s"a=" ice-pacing-att
bundle-group-attribute = "a=group:" bundle-semantics ice-options-attribute = %s"a=" ice-options
*(SP identification-tag) bundle-group-attribute = "a=group:" bundle-semantics
bundle-semantics = "BUNDLE" *(SP identification-tag)
end-of-candidates-attribute = %s"a=" end-of-candidates-att bundle-semantics = "BUNDLE"
extension-attribute-fields = attribute-fields end-of-candidates-attribute = %s"a=" end-of-candidates
extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field pseudo-media-descriptions = *( media-field
trickle-ice-attribute-fields trickle-ice-attribute-fields
[extension-attribute-fields] ) [extension-attribute-fields] )
; for future extensions ; for future extensions
trickle-ice-attribute-fields = mid-attribute CRLF trickle-ice-attribute-fields = mid-attribute CRLF
["a=rtcp-mux" CRLF] ["a=rtcp-mux" CRLF]
["a=rtcp-mux-only" CRLF] ["a=rtcp-mux-only" CRLF]
*(candidate-attributes CRLF) *(candidate-attributes CRLF)
[remote-candidate-attribute CRLF] [ice-pwd-attribute CRLF]
[end-of-candidates-attribute CRLF] [ice-ufrag-attribute CRLF]
remote-candidate-attribute = %s"a=" remote-candidate-att [remote-candidate-attribute CRLF]
candidate-attributes = %s"a=" candidate-attribute [end-of-candidates-attribute CRLF]
remote-candidate-attribute = %s"a=" remote-candidate-att
candidate-attributes = %s"a=" candidate-attribute
end-of-candidates = %s"end-of-candidates"
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-
options, candidate-attribute remote-candidate-att from pacing-att, ice-options, candidate-attribute remote-candidate-att
[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] and end- ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The
of-candidates-att from [I-D.ietf-mmusic-trickle-ice]. The indicator indicator for case-sensitivity %s is defined in [RFC7405].
for case-sensitivity %s is defined in [RFC7405].
[NOTE: end-of-candidates-att currently lacks a formal definition in An Agent MUST ignore any received unknown extension-attribute-fields.
[I-D.ietf-mmusic-trickle-ice]]
9. Info Package 10. Info Package
9.1. Overall Description 10.1. 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.
9.2. Applicability 10.2. 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 signalling 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.
9.3. Info Package Name 10.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"
9.4. Info Package Parameters 10.4. Info Package Parameters
This document does not define any Info Package parameters. This document does not define any Info Package parameters.
9.5. SIP Option Tags 10.5. 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.
9.6. Info Message Body Parts 10.6. 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 8.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.
9.7. Info Package Usage Restrictions 10.7. Info Package Usage Restrictions
This document does not define any Info Package Usage Restrictions. This document does not define any Info Package Usage Restrictions.
9.8. Rate of INFO Requests 10.8. 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.
9.9. Info Package Security Considerations 10.9. Info Package Security Considerations
See section Section 11 See Section 12
10. 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.] document. Please replace "I-D.ietf-ice-trickle" with the RFC number
of that document.]
10.1. application/trickle-ice-sdpfrag MIME Type 11.1. SDP 'end-of-candidate' Attribute
This section defines a new SDP media-level and session-level
attribute [RFC4566] , 'end-of-candidate'. 'end-of-candidate' is a
property attribute [RFC4566] , and hence has no value.
Name: end-of-candidate
Value: N/A
Usage Level: media and session
Charset Dependent: no
Purpose: The sender indicates that it will not trickle
further candidates.
O/A Procedures: "I-D.ietf-ice-trickle" defines the detailed
SDP Offer/Answer procedures for
the 'end-of-candidate' attribute.
Mux Category: IDENTICAL
Reference: RFCXXXX
Example:
a=end-of-candidate
11.2. application/trickle-ice-sdpfrag MIME Type
Type name: application Type name: application
Subtype name: trickle-ice-sdpfrag Subtype name: trickle-ice-sdpfrag
Required parameters: None. Required parameters: None.
Optional parameters: None. Optional parameters: None.
Encoding considerations: Encoding considerations:
skipping to change at page 31, line 9 skipping to change at page 32, line 5
IETF MMUSIC working group mmusic@ietf.org IETF MMUSIC working group mmusic@ietf.org
Intended usage: Intended usage:
Trickle-ICE for SIP as specified in RFCXXXX. Trickle-ICE for SIP as specified in RFCXXXX.
Author/Change controller: Author/Change controller:
IETF MMUSIC working group mmusic@ietf.org IETF MMUSIC working group mmusic@ietf.org
10.2. SIP Info Package 'trickle-ice' 11.3. SIP Info Package 'trickle-ice'
This document defines a new SIP Info Package named 'trickle-ice' and This document defines a new SIP Info Package named 'trickle-ice' and
updates the Info Packages Registry with the following entry. updates the Info Packages Registry with the following entry.
+-------------+-----------+ +-------------+-----------+
| Name | Reference | | Name | Reference |
+-------------+-----------+ +-------------+-----------+
| trickle-ice | [RFCXXXX] | | trickle-ice | [RFCXXXX] |
| | | | | |
+-------------+-----------+ +-------------+-----------+
10.3. SIP Option Tag 'trickle-ice' 11.4. SIP Option Tag 'trickle-ice'
This specification registers a new SIP option tag 'trickle-ice' as This specification registers a new SIP option tag 'trickle-ice' as
per the guidelines in Section 27.1 of [RFC3261] and updates the per the guidelines in Section 27.1 of [RFC3261] and updates the
"Option Tags" section of the SIP Parameter Registry with the "Option Tags" section of the SIP Parameter Registry with the
following entry: following entry:
+-------------+---------------------------------------+-----------+ +-------------+-------------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+-------------+---------------------------------------+-----------+ +-------------+-------------------------------------+-----------+
| trickle-ice | This option tag is used to indicate | [RFCXXXX] | | trickle-ice | This option tag is used to indicate | [RFCXXXX] |
| | that a UA supports and understands | | | | that a UA supports and understands | |
| | Trickle-ICE. | | | | Trickle-ICE. | |
+-------------+---------------------------------------+-----------+ +-------------+-------------------------------------+-----------+
11. Security Considerations 12. Security Considerations
The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp],
[RFC6086], [I-D.ietf-mmusic-trickle-ice] apply. This document [RFC6086], [I-D.ietf-ice-trickle] apply. This document clarifies how
clarifies how the above specifications are used together for the above specifications are used together for trickling candidates
trickling candidates and does not create addtitional security risks. and does not create addtitional security risks.
12. Acknowledgements 13. Acknowledgements
The authors would like to thank Ayush Jain, Paul Kyzivat, Jonathan The authors would like to thank Ayush Jain, Paul Kyzivat, Jonathan
Lennox, Simon Perreault and Martin Thomson for reviewing and/or Lennox, Simon Perreault and Martin Thomson for reviewing and/or
making various suggestions for improvements and optimizations. making various suggestions for improvements and optimizations.
13. Change Log 14. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]. [RFC EDITOR NOTE: Please remove this section when publishing].
Changes from draft-ietf-mmusic-trickle-ice-sip-01 Changes from draft-ietf-mmusic-trickle-ice-sip-01
o Editorial Clean up o Editorial Clean up
o IANA Consideration added o IANA Consideration added
o Security Consideration added o Security Consideration added
skipping to change at page 33, line 25 skipping to change at page 34, line 18
o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic-
ice-sip-sdp ice-sip-sdp
o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic-
mux-exclusive, enahnced ABNF to support a=rtcp-mux-exclusive mux-exclusive, enahnced ABNF to support a=rtcp-mux-exclusive
o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for
the application/trickle-ice-sdpfrag body the application/trickle-ice-sdpfrag body
14. References Changes from draft-ietf-mmusic-trickle-ice-sip-04
14.1. Normative References o considered comments from Christer Holmberg
o corrected grammar for INFO package, such that ice-ufrag/pwd are
also allowed on media-level as specified in
[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
15. References
15.1. Normative References
[I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE)
Protocol", draft-ietf-ice-trickle-03 (work in progress),
July 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-08 (work in progress), March 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
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-04 (work in progress), April 2016. exclusive-10 (work in progress), August 2016.
[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-29 (work in progress), April 2016. negotiation-31 (work in progress), June 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-12 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-13
(work in progress), January 2016. (work in progress), June 2016.
[I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", draft-ietf-
mmusic-trickle-ice-02 (work in progress), January 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [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 35, line 24 skipping to change at page 36, line 29
[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, 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>.
14.2. Informative References 15.2. Informative References
[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,
 End of changes. 69 change blocks. 
217 lines changed or deleted 290 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/