Internet DRAFT - draft-ivov-dispatch-trickle-ice-sip
draft-ivov-dispatch-trickle-ice-sip
Network Working Group E. Ivov
Internet-Draft Jitsi
Intended status: Standards Track E. Marocco
Expires: August 11, 2013 Telecom Italia
C. Holmberg
Ericsson
February 7, 2013
A Session Initiation Protocol (SIP) usage for Trickle ICE
draft-ivov-dispatch-trickle-ice-sip-00
Abstract
The Interactive Connectivity Establishment (ICE) protocol describes a
Network Address Translator (NAT) traversal for UDP-based multimedia
sessions established with the offer/answer model. The ICE extension
for Incremental Provisioning of Candidates (Trickle ICE) defines a
mechanism that allows ICE agents to shorten session establishment
delays by making the candidate gathering and connectivity checking
phases of ICE non-blocking.
This document defines usage semantics for Trickle ICE with SIP.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Ivov, et al. Expires August 11, 2013 [Page 1]
Internet-Draft Trickle ICE for SIP February 2013
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Half vs Full Trickle . . . . . . . . . . . . . . . . . . . . . 3
4. Encoding and Sending Candidate Information . . . . . . . . . . 4
5. Info Package . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Overall Description . . . . . . . . . . . . . . . . . . . . 5
5.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . 5
5.3. INFO Package Name . . . . . . . . . . . . . . . . . . . . . 5
5.4. INFO Package Parameters . . . . . . . . . . . . . . . . . . 5
5.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . . . 5
5.6. INFO Message Body Parts . . . . . . . . . . . . . . . . . . 5
6. Example Flows . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Ivov, et al. Expires August 11, 2013 [Page 2]
Internet-Draft Trickle ICE for SIP February 2013
1. Introduction
The vanilla specification of the Interactive Connectivity
Establishment (vanilla ICE) protocol [RFC5245] describes a mechanism
for NAT traversal that consists of three main phases: a phase where
an agent gathers a set of candidate 5-tuples (source IP address and
port, destination IP address and port and a transport protocol), a
second phase where these candidates are sent to a remote agent and
this gathering is repeated and then a third phase where connectivity
between all candidates in both sets is checked (connectivity checks).
Only then can both agents begin communication, provided of course
that ICE processing has successfully completed. According to that
specification the three phases above happen consecutively, in a
blocking way, which may lead to undesirable latency during session
establishment.
The trickle ICE extension defined in [I-D.ivov-mmusic-trickle-ice]
defines generic semantics required for these ICE phases to happen
simultaneously, in a non-blocking way and hence speed up session
establishment.
This specification defines a usage of trickle ICE with the Session
Initiation Protocol (SIP). In describes how and when SIP agents use
the full and half trickle modes of operation, how they encode
additional candidates and how they exchange them through use of SIP
INFO requests.
This document also defines a new Info Package for use with Trickle
ICE.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This specification makes use of all terminology defined by the
protocol for Interactive Connectivity Establishment in [RFC5245] and
its Trickle ICE extension [I-D.ivov-mmusic-trickle-ice]. It is
assumed that the reader will be familiar with the terminology from
both of them.
3. Half vs Full Trickle
Trickle ICE defines a mode of operation called "half trickle". With
half trickle the first offer in a session contains all candidates and
Ivov, et al. Expires August 11, 2013 [Page 3]
Internet-Draft Trickle ICE for SIP February 2013
subsequent trickling occurs from the offerer in this first offer/
answer negotiation. Half trickle offers can hence be processed by
both vanilla and trickle ICE agents, which offers an interesting
advantage in cases where support for trickle cannot be verified prior
to sending an offer.
Unless agents are running within controlled environments or using
GRUU, this would be the case with SIP. In spite of mechanisms such
as the one defined in [RFC3840], a SIP UA cannot rely on consecutive
requests reaching the same destination. An OPTIONS request querying
capabilities can hence be routed to and answered by one entity and a
subsequent INVITE by a completely different one.
For all these reasons SIP UAs implementing trickle ICE SHOULD always
perform half trickle, unless that behaviour is specifically
overridden by configuration (which could be the case in controlled
environments where every agent supports trickle ICE).
[TODO maybe define a way for GRUU supporting agents to do full
trickle]
4. Encoding and Sending Candidate Information
Trickled candidates and end-of-candidates indications sent by trickle
ICE SIP UAs are transported as payload in SIP INFO requests sent
within the already established dialog. Such payloads are encoded in
an SDP format as specified in [I-D.ivov-mmusic-trickle-ice].
Since neither the "a=candidate" nor the "a=end-of-candidates" lines
contain information matching them to a stream, this is handled
through the use of MID [RFC3388] as follows:
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/sdp
Content-Disposition: Info-Package
Content-length: ...
a=mid:1
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx
a=m-line-id:2
a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx
a=end-of-candidates
Ivov, et al. Expires August 11, 2013 [Page 4]
Internet-Draft Trickle ICE for SIP February 2013
5. Info Package
5.1. Overall Description
This specification defines an INFO package meant for use by SIP user
agents implementing Trickle ICE. Typically INFO requests would carry
ICE candidates discovered after the user agent has sent or received a
trickle-ice offer.
5.2. Applicability
The purpose of the ICE protocol is to establish a media path. The
candidates that this specification transports in INFO requests are
part of this establishment. There is hence no way for them to be
transported through the not yet existing media path.
Candidates sent by a trickle ICE agent after the offer, are meant to
follow the same signalling path and reach the same entity as the
offer itself. While it is true that GRUUs can be used to achieve
this, one of the goals of this specification is to allow operation of
trickle ICE in as many environments as possible including those with
no GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would
not satisfy this goal.
5.3. INFO Package Name
This document defines a SIP INFO Package as per [RFC6086]. The INFO
Package token name for this package is "trickle-ice"
5.4. INFO Package Parameters
This document does not define any INFO package parameters.
5.5. SIP Option-Tags
[RFC6086] allows Info Package specifications to define SIP option-
tags. This document therefore stipulates that SIP entities that
support trickle ICE and this specification MUST place the 'trickle-
ice' option-tag in a SIP Supported header field.
When responding to, or generating a SIP OPTIONS request a SIP entity
MUST also include the 'trickle-ice' option-tag in a SIP Supported
header field.
5.6. INFO Message Body Parts
Entities implementing this specification MUST include SDP encoded ICE
candidates in all SIP INFO requests. The MIME type for the payload
Ivov, et al. Expires August 11, 2013 [Page 5]
Internet-Draft Trickle ICE for SIP February 2013
MUST be of type 'application/sdp' as defined in Section 4 and
[I-D.ivov-mmusic-trickle-ice].
6. Example Flows
A typical successful (half) trickle ICE exchange with SIP would look
this way:
STUN/Turn STUN/TURN
Servers Alice Bob Servers
| | | |
|<--------------| | |
| | | |
| | | |
| Candidate | | |
| | | |
| | | |
| Discovery | | |
| | | |
| | | |
|-------------->| INVITE (Offer) | |
| |------------------------>| |
| | 180 (Answer) |-------------->|
| |<------------------------| |
| | | |
| | INFO (more candidates) | Candidate |
| |<------------------------| |
| | Connectivity Checks | |
| |<=======================>| Discovery |
| | INFO (more candidates) | |
| |<------------------------| |
| | Connectivity Checks |<--------------|
| |<=======================>| |
| | | |
| | 200 OK | |
| |<------------------------| |
| | | |
| | 5245 SIP re-INVITE | |
| |------------------------>| |
| | 200 OK | |
| |<------------------------| |
| | | |
| | | |
| |<===== MEDIA FLOWS =====>| |
| | | |
Ivov, et al. Expires August 11, 2013 [Page 6]
Internet-Draft Trickle ICE for SIP February 2013
Figure 1: Example
7. Security Considerations
[TODO]
8. Acknowledgements
[TODO]
9. References
9.1. Normative References
[I-D.ivov-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol",
draft-ivov-mmusic-trickle-ice-00 (work in progress),
January 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
Initiation Protocol (SIP) INFO Method and Package
Framework", RFC 6086, January 2011.
9.2. Informative References
[I-D.keranen-mmusic-ice-address-selection]
Keraenen, A. and J. Arkko, "Update on Candidate Address
Selection for Interactive Connectivity Establishment
Ivov, et al. Expires August 11, 2013 [Page 7]
Internet-Draft Trickle ICE for SIP February 2013
(ICE)", draft-keranen-mmusic-ice-address-selection-01
(work in progress), July 2012.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[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,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
Appendix A. Open issues
At the time of writing of this document the authors have no clear
view on how and if the following list of issues should be address
here:
1. Should we allow for full trickle if support can be verified
automatically and confirmed for a gruu with [RFC3840].
2. Can we pick between MID and stream indices for stream
identification.
Ivov, et al. Expires August 11, 2013 [Page 8]
Internet-Draft Trickle ICE for SIP February 2013
Authors' Addresses
Emil Ivov
Jitsi
Strasbourg 67000
France
Phone: +33 6 72 81 15 55
Email: emcho@jitsi.org
Enrico Marocco
Telecom Italia
Via G. Reiss Romoli, 274
Turin 10148
Italy
Email: enrico.marocco@telecomitalia.it
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Ivov, et al. Expires August 11, 2013 [Page 9]
