idnits 2.17.1 draft-ivov-mmusic-trickle-ice-sip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2013) is 3846 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TODO' is mentioned on line 273, but not defined == Unused Reference: 'RFC3264' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'I-D.keranen-mmusic-ice-address-selection' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'RFC4787' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC5766' is defined on line 337, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft Jitsi 4 Intended status: Standards Track E. Marocco 5 Expires: April 17, 2014 Telecom Italia 6 C. Holmberg 7 Ericsson 8 October 14, 2013 10 A Session Initiation Protocol (SIP) usage for Trickle ICE 11 draft-ivov-mmusic-trickle-ice-sip-01 13 Abstract 15 The Interactive Connectivity Establishment (ICE) protocol describes a 16 Network Address Translator (NAT) traversal for UDP-based multimedia 17 sessions established with the offer/answer model. The ICE extension 18 for Incremental Provisioning of Candidates (Trickle ICE) defines a 19 mechanism that allows ICE agents to shorten session establishment 20 delays by making the candidate gathering and connectivity checking 21 phases of ICE non-blocking. 23 This document defines usage semantics for Trickle ICE with SIP. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 17, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Half vs Full Trickle . . . . . . . . . . . . . . . . . . . . 3 62 4. Encoding and Sending Candidate Information . . . . . . . . . 4 63 5. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1. Overall Description . . . . . . . . . . . . . . . . . . . 4 65 5.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 66 5.3. INFO Package Name . . . . . . . . . . . . . . . . . . . . 5 67 5.4. INFO Package Parameters . . . . . . . . . . . . . . . . . 5 68 5.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . . 5 69 5.6. INFO Message Body Parts . . . . . . . . . . . . . . . . . 5 70 6. Example Flows . . . . . . . . . . . . . . . . . . . . . . . . 5 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 9.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 The vanilla specification of the Interactive Connectivity 82 Establishment (vanilla ICE) protocol [RFC5245] describes a mechanism 83 for NAT traversal that consists of three main phases: a phase where 84 an agent gathers a set of candidate 5-tuples (source IP address and 85 port, destination IP address and port and a transport protocol), a 86 second phase where these candidates are sent to a remote agent and 87 this gathering is repeated and then a third phase where connectivity 88 between all candidates in both sets is checked (connectivity checks). 89 Only then can both agents begin communication, provided of course 90 that ICE processing has successfully completed. According to that 91 specification the three phases above happen consecutively, in a 92 blocking way, which may lead to undesirable latency during session 93 establishment. 95 The trickle ICE extension defined in [I-D.ivov-mmusic-trickle-ice] 96 defines generic semantics required for these ICE phases to happen 97 simultaneously, in a non-blocking way and hence speed up session 98 establishment. 100 This specification defines a usage of trickle ICE with the Session 101 Initiation Protocol (SIP). In describes how and when SIP agents use 102 the full and half trickle modes of operation, how they encode 103 additional candidates and how they exchange them through use of SIP 104 INFO requests. 106 This document also defines a new Info Package for use with Trickle 107 ICE. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 This specification makes use of all terminology defined by the 116 protocol for Interactive Connectivity Establishment in [RFC5245] and 117 its Trickle ICE extension [I-D.ivov-mmusic-trickle-ice]. It is 118 assumed that the reader will be familiar with the terminology from 119 both of them. 121 3. Half vs Full Trickle 123 Trickle ICE defines a mode of operation called "half trickle". With 124 half trickle the first offer in a session contains all candidates and 125 subsequent trickling occurs from the offerer in this first offer/ 126 answer negotiation. Half trickle offers can hence be processed by 127 both vanilla and trickle ICE agents, which offers an interesting 128 advantage in cases where support for trickle cannot be verified prior 129 to sending an offer. 131 Unless agents are running within controlled environments or using 132 GRUU, this would be the case with SIP. In spite of mechanisms such 133 as the one defined in [RFC3840], a SIP UA cannot rely on consecutive 134 requests reaching the same destination. An OPTIONS request querying 135 capabilities can hence be routed to and answered by one entity and a 136 subsequent INVITE by a completely different one. 138 For all these reasons SIP UAs implementing trickle ICE SHOULD always 139 perform half trickle, unless that behaviour is specifically 140 overridden by configuration (which could be the case in controlled 141 environments where every agent supports trickle ICE). 143 [TODO maybe define a way for GRUU supporting agents to do full 144 trickle] 146 4. Encoding and Sending Candidate Information 148 Trickled candidates and end-of-candidates indications sent by trickle 149 ICE SIP UAs are transported as payload in SIP INFO requests sent 150 within the already established dialog. Such payloads are encoded in 151 an SDP format as specified in [I-D.ivov-mmusic-trickle-ice]. 153 Since neither the "a=candidate" nor the "a=end-of-candidates" lines 154 contain information matching them to a stream, this is handled 155 through the use of MID [RFC3388] as follows: 157 INFO sip:alice@example.com SIP/2.0 158 ... 159 Info-Package: trickle-ice 160 Content-type: application/sdp 161 Content-Disposition: Info-Package 162 Content-length: ... 164 a=mid:1 165 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 166 a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx 167 a=m-line-id:2 168 a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx 169 a=end-of-candidates 171 5. Info Package 173 5.1. Overall Description 175 This specification defines an INFO package meant for use by SIP user 176 agents implementing Trickle ICE. Typically INFO requests would carry 177 ICE candidates discovered after the user agent has sent or received a 178 trickle-ice offer. 180 5.2. Applicability 182 The purpose of the ICE protocol is to establish a media path. The 183 candidates that this specification transports in INFO requests are 184 part of this establishment. There is hence no way for them to be 185 transported through the not yet existing media path. 187 Candidates sent by a trickle ICE agent after the offer, are meant to 188 follow the same signalling path and reach the same entity as the 189 offer itself. While it is true that GRUUs can be used to achieve 190 this, one of the goals of this specification is to allow operation of 191 trickle ICE in as many environments as possible including those with 192 no GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would 193 not satisfy this goal. 195 5.3. INFO Package Name 197 This document defines a SIP INFO Package as per [RFC6086]. The INFO 198 Package token name for this package is "trickle-ice" 200 5.4. INFO Package Parameters 202 This document does not define any INFO package parameters. 204 5.5. SIP Option-Tags 206 [RFC6086] allows Info Package specifications to define SIP option- 207 tags. This document therefore stipulates that SIP entities that 208 support trickle ICE and this specification MUST place the 'trickle- 209 ice' option-tag in a SIP Supported header field. 211 When responding to, or generating a SIP OPTIONS request a SIP entity 212 MUST also include the 'trickle-ice' option-tag in a SIP Supported 213 header field. 215 5.6. INFO Message Body Parts 217 Entities implementing this specification MUST include SDP encoded ICE 218 candidates in all SIP INFO requests. The MIME type for the payload 219 MUST be of type 'application/sdp' as defined in Section 4 and 220 [I-D.ivov-mmusic-trickle-ice]. 222 6. Example Flows 224 A typical successful (half) trickle ICE exchange with SIP would look 225 this way: 227 STUN/Turn STUN/TURN 228 Servers Alice Bob Servers 229 | | | | 230 |<--------------| | | 231 | | | | 232 | | | | 233 | Candidate | | | 234 | | | | 235 | | | | 236 | Discovery | | | 237 | | | | 238 | | | | 239 |-------------->| INVITE (Offer) | | 240 | |------------------------>| | 241 | | 180 (Answer) |-------------->| 242 | |<------------------------| | 243 | | | | 244 | | INFO (more candidates) | Candidate | 245 | |<------------------------| | 246 | | Connectivity Checks | | 247 | |<=======================>| Discovery | 248 | | INFO (more candidates) | | 249 | |<------------------------| | 250 | | Connectivity Checks |<--------------| 251 | |<=======================>| | 252 | | | | 253 | | 200 OK | | 254 | |<------------------------| | 255 | | | | 256 | | 5245 SIP re-INVITE | | 257 | |------------------------>| | 258 | | 200 OK | | 259 | |<------------------------| | 260 | | | | 261 | | | | 262 | |<===== MEDIA FLOWS =====>| | 263 | | | | 265 Figure 1: Example 267 7. Security Considerations 269 [TODO] 271 8. Acknowledgements 273 [TODO] 275 9. References 277 9.1. Normative References 279 [I-D.ivov-mmusic-trickle-ice] 280 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 281 Incremental Provisioning of Candidates for the Interactive 282 Connectivity Establishment (ICE) Protocol", draft-ivov- 283 mmusic-trickle-ice-01 (work in progress), March 2013. 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 289 with Session Description Protocol (SDP)", RFC 3264, June 290 2002. 292 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 293 Description Protocol", RFC 4566, July 2006. 295 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 296 (ICE): A Protocol for Network Address Translator (NAT) 297 Traversal for Offer/Answer Protocols", RFC 5245, April 298 2010. 300 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 301 Initiation Protocol (SIP) INFO Method and Package 302 Framework", RFC 6086, January 2011. 304 9.2. Informative References 306 [I-D.keranen-mmusic-ice-address-selection] 307 Keraenen, A. and J. Arkko, "Update on Candidate Address 308 Selection for Interactive Connectivity Establishment 309 (ICE)", draft-keranen-mmusic-ice-address-selection-01 310 (work in progress), July 2012. 312 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 313 E. Lear, "Address Allocation for Private Internets", BCP 314 5, RFC 1918, February 1996. 316 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 317 A., Peterson, J., Sparks, R., Handley, M., and E. 318 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 319 June 2002. 321 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 322 Schulzrinne, "Grouping of Media Lines in the Session 323 Description Protocol (SDP)", RFC 3388, December 2002. 325 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 326 "Indicating User Agent Capabilities in the Session 327 Initiation Protocol (SIP)", RFC 3840, August 2004. 329 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 330 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 331 RFC 4787, January 2007. 333 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 334 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 335 October 2008. 337 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 338 Relays around NAT (TURN): Relay Extensions to Session 339 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 341 Appendix A. Open issues 343 At the time of writing of this document the authors have no clear 344 view on how and if the following list of issues should be address 345 here: 347 1. Should we allow for full trickle if support can be verified 348 automatically and confirmed for a gruu with [RFC3840]. 350 2. Can we pick between MID and stream indices for stream 351 identification. 353 Authors' Addresses 355 Emil Ivov 356 Jitsi 357 Strasbourg 67000 358 France 360 Phone: +33 6 72 81 15 55 361 Email: emcho@jitsi.org 363 Enrico Marocco 364 Telecom Italia 365 Via G. Reiss Romoli, 274 366 Turin 10148 367 Italy 369 Email: enrico.marocco@telecomitalia.it 371 Christer Holmberg 372 Ericsson 373 Hirsalantie 11 374 Jorvas 02420 375 Finland 377 Email: christer.holmberg@ericsson.com