draft-ietf-mmusic-trickle-ice-sip-00.txt   draft-ietf-mmusic-trickle-ice-sip-01.txt 
Network Working Group E. Ivov Network Working Group E. Ivov
Internet-Draft Jitsi Internet-Draft Jitsi
Intended status: Standards Track E. Marocco Intended status: Standards Track E. Marocco
Expires: January 25, 2015 Telecom Italia Expires: July 19, 2015 Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
July 24, 2014 January 15, 2015
A Session Initiation Protocol (SIP) usage for Trickle ICE A Session Initiation Protocol (SIP) usage for Trickle ICE
draft-ietf-mmusic-trickle-ice-sip-00 draft-ietf-mmusic-trickle-ice-sip-01
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 43 skipping to change at page 1, line 43
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 January 25, 2015. This Internet-Draft will expire on July 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 26 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Rationale. Why INFO . . . . . . . . . . . . . . . . . . . 4 3.1. Rationale. Why INFO . . . . . . . . . . . . . . . . . . . 4
3.2. Discovery issues . . . . . . . . . . . . . . . . . . . . 5 3.2. Discovery issues . . . . . . . . . . . . . . . . . . . . 5
3.3. Relationship with the Offer/Answer Model . . . . . . . . 6 3.3. Relationship with the Offer/Answer Model . . . . . . . . 6
4. Incremental signalling of ICE candidates . . . . . . . . . . 8 4. Incremental signalling of ICE candidates . . . . . . . . . . 8
4.1. Asserting Offer/Answer delivery and dialog state . . . . 8 4.1. Asserting Offer/Answer delivery and dialog state . . . . 8
4.2. Delivering candidates in INFO messages . . . . . . . . . 12 4.2. Delivering candidates in INFO messages . . . . . . . . . 12
4.3. Initiating trickle ICE without an SDP Answer . . . . . . 14
5. Initial discovery of trickle ICE support . . . . . . . . . . 14 5. Initial discovery of trickle ICE support . . . . . . . . . . 14
5.1. Provisioning support for trickle ICE . . . . . . . . . . 14 5.1. Provisioning support for trickle ICE . . . . . . . . . . 15
5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 15 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 15
5.3. Trickle ICE discovery through other protocols . . . . . . 16 5.3. Trickle ICE discovery through other protocols . . . . . . 16
5.4. Fallback to half trickle . . . . . . . . . . . . . . . . 16 5.4. Fallback to half trickle . . . . . . . . . . . . . . . . 16
6. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Overall Description . . . . . . . . . . . . . . . . . . . 18 6.1. Overall Description . . . . . . . . . . . . . . . . . . . 19
6.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 18 6.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 19
6.4. Info Package Parameters . . . . . . . . . . . . . . . . . 18 6.4. Info Package Parameters . . . . . . . . . . . . . . . . . 19
6.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . . 18 6.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . . 19
6.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 19 6.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The vanilla specification of the Interactive Connectivity The vanilla specification of the Interactive Connectivity
Establishment (vanilla ICE) protocol [RFC5245] describes a mechanism Establishment (vanilla ICE) protocol [RFC5245] describes a mechanism
for NAT traversal that consists of three main phases: a phase where for NAT traversal that consists of three main phases: a phase where
an agent gathers a set of candidate transport addresses (source IP an agent gathers a set of candidate transport addresses (source IP
address, port and transport protocol), a second phase where these address, port and transport protocol), a second phase where these
candidates are sent to a remote agent and this gathering procedure is candidates are sent to a remote agent and this gathering procedure is
repeated and, finally, a third phase where connectivity between all repeated and, finally, a third phase where connectivity between all
skipping to change at page 8, line 37 skipping to change at page 8, line 37
additional candidates or end-of-candidates indications. Such INFO additional candidates or end-of-candidates indications. Such INFO
requests MUST be sent within that same dialog. This is necessary so requests MUST be sent within that same dialog. This is necessary so
that the candidates from these INFO messages could be delivered to that the candidates from these INFO messages could be delivered to
the same entities that initiated the session. the same entities that initiated the session.
4.1. Asserting Offer/Answer delivery and dialog state 4.1. Asserting Offer/Answer delivery and dialog state
In order for SIP UAs to be able to start trickling, the following two In order for SIP UAs to be able to start trickling, the following two
conditions need to be satisfied: conditions need to be satisfied:
o ICE support in the peer agent MUST be confirmed. o Trickle ICE support in the peer agent MUST be confirmed.
o The SIP dialog at both sides MUST be at least in the early state. o The SIP dialog at both sides MUST be at least in the early state.
Section 5 discusses in detail the various options for satisfying the Section 5 discusses in detail the various options for satisfying the
first of the above conditions. Regardless of those mechanisms first of the above conditions. Regardless of those mechanisms
however, agents are certain to have a clear understanding of whether however, agents are certain to have a clear understanding of whether
their peers support trickle ICE once an offer and and an answer have their peers support trickle ICE once an offer and and an answer have
been exchanged, which needs to happen anyway for ICE processing to been exchanged, which needs to happen anyway for ICE processing to
commence (see Figure 3). commence (see Figure 3).
skipping to change at page 12, line 48 skipping to change at page 12, line 48
The use of SIP INFO requests happens within the context of an Info The use of SIP INFO requests happens within the context of an Info
Package specifically defined for the purpose (Section 6). Package specifically defined for the purpose (Section 6).
Such INFO requests MUST be sent within the existing SIP dialog. The Such INFO requests MUST be sent within the existing SIP dialog. The
MIME type for their payload MUST be set to 'application/sdpfrag' as MIME type for their payload MUST be set to 'application/sdpfrag' as
defined in [I-D.ivov-dispatch-sdpfrag]. defined in [I-D.ivov-dispatch-sdpfrag].
Since neither the "a=candidate" nor the "a=end-of-candidates" lines Since neither the "a=candidate" nor the "a=end-of-candidates" lines
contain information that would allow correlating them to a specific contain information that would allow correlating them to a specific
"m=" line, this is handled through the use of MID [RFC3388]. Agents "m=" line, this is handled through the use of MID [RFC5588]. Agents
MUST include the corresponding "a=mid" line for every "m=" line whose MUST include the corresponding "a=mid" line for every "m=" line whose
candidate list they intend to update. Such "a=mid" lines MUST candidate list they intend to update. Such "a=mid" lines MUST
immediately precede the list of candidates for that specific "m=" immediately precede the list of candidates for that specific "m="
line. All "a=candidate" or "a=end-of-candidates" lines following an line. All "a=candidate" or "a=end-of-candidates" lines following an
"a=mid" line, up until (and excluding) the next occurrence of an "a=mid" line, up until (and excluding) the next occurrence of an
"a=mid" line, pertain the the "m=" line identified by that MID. "a=mid" line, pertain the the "m=" line identified by that MID.
"a=end-of-candidates" lines preceding any "a=mid" lines indicate end "a=end-of-candidates" lines preceding any "a=mid" lines indicate end
of all trickling from that agent (as opposed to end of trickling for of all trickling from that agent (as opposed to end of trickling for
a specific "m=" line. a specific "m=" line, which would be indicated by a media level
"a=end-of-candidates" line).
The use of "a=mid" lines allows for a structure similar to the one in The use of "a=mid" lines allows for a structure similar to the one in
SDP offers and answers where one can distinguish separate media-level SDP offers and answers where one can distinguish separate media-level
and session-level sections. In the current case lines preceding any and session-level sections. In the current case lines preceding any
"a=mid" lines are considered to be session-level. Lines appearing in "a=mid" lines are considered to be session-level. Lines appearing in
between or after "a=mid" lines will be interpreted as media-level. between or after "a=mid" lines will be interpreted as media-level.
Note that while this specification uses the a=mid: attribute from
[RFC5588], it does not define any grouping semantics.
Consequently, using the a=group: attribute from that same
specification is neither needed nor used in trickle ICE for SIP.
All INFO requests MUST carry the "ice-pwd" and "ice-ufrag" attributes All INFO requests MUST carry the "ice-pwd" and "ice-ufrag" attributes
that would allow mapping them to a specific ICE generation. INFO that would allow mapping them to a specific ICE generation. INFO
requests containing ice-ufrag and ice-pwd values that do not match requests containing ice-ufrag and ice-pwd values that do not match
those of the current ICE processing session MUST be discarded. The those of the current ICE processing session MUST be discarded. The
"ice-pwd" and "ice-ufrag" attributes MUST appear at the same level as "ice-pwd" and "ice-ufrag" attributes MUST appear at the same level as
the ones in the Offer/Answer exchange. In other words, if they were the ones in the Offer/Answer exchange. In other words, if they were
present as sesssion-level attributes there, they will also appear at present as sesssion-level attributes there, they will also appear at
the beginning of all INFO message payloads, preceding all "a=mid" the beginning of all INFO message payloads, preceding all "a=mid"
lines. If they were originally exchanged as media level attributes, lines. If they were originally exchanged as media level attributes,
potentially overriding session-level values, then they will also be potentially overriding session-level values, then they will also be
skipping to change at page 14, line 23 skipping to change at page 14, line 26
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
a=mid:1 a=mid:1
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx
raddr 10.0.1.1 rport 8998 raddr 10.0.1.1 rport 8998
a=mid:2 a=mid:2
a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx
raddr 10.0.1.1 rport 9000 raddr 10.0.1.1 rport 9000
a=end-of-candidates a=end-of-candidates
4.3. Initiating trickle ICE without an SDP Answer
The possibility to convey arbitrary SDP fragments in SIP message
bodies [I-D.ivov-dispatch-sdpfrag] allows ICE agents to initiate
trickling without actually sending an answer. Trickle ICE answerers
MAY therefore respond to INVITEs with provisional responses that only
contain the information necessary for ICE processing to begin.
Agents that choose to do so, need to send in these responses all ICE-
related session level information that would have otherwise been
present in an SDP answer. At the very least these responses MUST
include the "ice-options" attribute for "trickle" and all other ICE
options they support.
The "ice-ufrag" and "ice-pwd" options MUST also be present in all 183
responses and they MAY appear as either session or media level
attributes.
5. Initial discovery of trickle ICE support 5. Initial discovery of trickle ICE support
SIP User Agents (UAs) that support and intend to use trickle ICE are SIP User Agents (UAs) that support and intend to use trickle ICE are
REQUIRED by [I-D.ietf-mmusic-trickle-ice] to indicate that in their REQUIRED by [I-D.ietf-mmusic-trickle-ice] to indicate that in their
offers and answers using the following attribute: "a=ice- offers and answers using the following attribute: "a=ice-
options:trickle". This makes discovery fairly straightforward for options:trickle". This makes discovery fairly straightforward for
answerers or for cases where offers need to be generated within answerers or for cases where offers need to be generated within
existing dialogs (i.e., when sending re-INVITE requests). In both existing dialogs (i.e., when sending re-INVITE requests). In both
scenarios prior SDP would have provided the necessary information. scenarios prior SDP would have provided the necessary information.
skipping to change at page 19, line 20 skipping to change at page 20, line 20
[I-D.ietf-mmusic-trickle-ice]. [I-D.ietf-mmusic-trickle-ice].
7. Security Considerations 7. Security Considerations
[TODO] [TODO]
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Thomas Stach for suggesting the INFO The authors would like to thank Thomas Stach for suggesting the INFO
acknowledgements used in the specification as a way of avoiding acknowledgements used in the specification as a way of avoiding
making PRACKs mandatory, Paul Kyzivat and Jonathan Lennox for making making PRACKs mandatory, Paul Kyzivat and Jonathan Lennox and Thomas
various suggestions for improvements and optimisations. Stach for making various other suggestions for improvements and
optimisations.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-mmusic-trickle-ice] [I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", draft-ietf- Connectivity Establishment (ICE) Protocol", draft-ietf-
mmusic-trickle-ice-01 (work in progress), February 2014. mmusic-trickle-ice-01 (work in progress), February 2014.
skipping to change at page 20, line 22 skipping to change at page 21, line 26
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
Initiation Protocol (SIP) INFO Method and Package Initiation Protocol (SIP) INFO Method and Package
Framework", RFC 6086, January 2011. Framework", RFC 6086, January 2011.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, March 2011.
9.2. Informative References 9.2. Informative References
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC5588] Williams, N., "Generic Security Service Application
Program Interface (GSS-API) Extension for Storing
Delegated Credentials", RFC 5588, July 2009.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (SIP)", RFC 5627, October 2009.
[RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX:
Combined Use of the Session Initiation Protocol (SIP) and Combined Use of the Session Initiation Protocol (SIP) and
the Extensible Messaging and Presence Protocol (XMPP)", the Extensible Messaging and Presence Protocol (XMPP)",
RFC 7081, November 2013. RFC 7081, November 2013.
Authors' Addresses Authors' Addresses
 End of changes. 16 change blocks. 
28 lines changed or deleted 54 lines changed or added

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