Network Working Group E. Ivov Internet-Draft Jitsi Intended status: Standards Track E. Marocco Expires: August 3, 2013 Telecom Italia C. Holmberg Ericsson January 30, 2013 A Session Initiation Protocol (SIP) usage for Trickle ICE draft-ivov-mmusic-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 3, 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 3, 2013 [Page 1] Internet-Draft Trickle ICE for SIP January 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 3, 2013 [Page 2] Internet-Draft Trickle ICE for SIP January 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 3, 2013 [Page 3] Internet-Draft Trickle ICE for SIP January 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 3, 2013 [Page 4] Internet-Draft Trickle ICE for SIP January 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 3, 2013 [Page 5] Internet-Draft Trickle ICE for SIP January 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 3, 2013 [Page 6] Internet-Draft Trickle ICE for SIP January 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 3, 2013 [Page 7] Internet-Draft Trickle ICE for SIP January 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 3, 2013 [Page 8] Internet-Draft Trickle ICE for SIP January 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 3, 2013 [Page 9]