idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-03.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 : ---------------------------------------------------------------------------- == 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 7 instances 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. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 2, 2015) is 3122 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: 'RFCXXXX' is mentioned on line 1273, but not defined == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-23 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 T. Stach 5 Expires: April 4, 2016 Unaffiliated 6 E. Marocco 7 Telecom Italia 8 C. Holmberg 9 Ericsson 10 October 2, 2015 12 A Session Initiation Protocol (SIP) usage for Trickle ICE 13 draft-ietf-mmusic-trickle-ice-sip-03 15 Abstract 17 The Interactive Connectivity Establishment (ICE) protocol describes a 18 Network Address Translator (NAT) traversal mechanism for UDP-based 19 multimedia sessions established with the Offer/Answer model. The ICE 20 extension for Incremental Provisioning of Candidates (Trickle ICE) 21 defines a mechanism that allows ICE agents to shorten session 22 establishment delays by making the candidate gathering and 23 connectivity checking phases of ICE non-blocking and by executing 24 them in parallel. 26 This document defines usage semantics for Trickle ICE with the 27 Session Initiation Protocol (SIP). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 4, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Rationale. Why INFO . . . . . . . . . . . . . . . . . . . 5 67 3.2. Discovery issues . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Relationship with the Offer/Answer Model . . . . . . . . 7 69 4. Incremental Signalling of ICE candidates . . . . . . . . . . 9 70 4.1. Establishing the dialog . . . . . . . . . . . . . . . . . 9 71 4.1.1. Asserting dialog state through reliable Offer/Answer 72 delivery . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1.2. Asserting dialog state through unreliable 74 Offer/Answer delivery . . . . . . . . . . . . . . . . 10 75 4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 12 76 4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 13 77 4.2. Delivering candidates in INFO messages . . . . . . . . . 15 78 5. Initial discovery of Trickle ICE support . . . . . . . . . . 18 79 5.1. Provisioning support for Trickle ICE . . . . . . . . . . 18 80 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 19 81 5.3. Trickle ICE discovery through other protocols . . . . . . 20 82 5.4. Fallback to Half Trickle . . . . . . . . . . . . . . . . 20 83 6. Considerations for RTP and RTCP multiplexing . . . . . . . . 22 84 7. Considerations for Media Multiplexing . . . . . . . . . . . . 23 85 8. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 25 86 8.1. Overall Description . . . . . . . . . . . . . . . . . . . 25 87 8.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 9. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 27 89 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 27 90 9.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 27 91 9.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 27 92 9.4. Info Package Parameters . . . . . . . . . . . . . . . . . 27 93 9.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 27 94 9.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 28 95 9.7. Info Package Usage Restrictions . . . . . . . . . . . . . 28 96 9.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 28 97 9.9. Info Package Security Considerations . . . . . . . . . . 28 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 99 10.1. application/trickle-ice-sdpfrag MIME Type . . . . . . . 28 100 10.2. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 30 101 10.3. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 30 102 11. Security Considerations . . . . . . . . . . . . . . . . . . . 30 103 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 104 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 107 14.2. Informative References . . . . . . . . . . . . . . . . . 33 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 110 1. Introduction 112 The Interactive Connectivity Establishment protocol [RFC5245] (a.k.a. 113 Vanilla ICE) describes a mechanism for NAT traversal that consists of 114 three main phases: a phase where an agent gathers a set of candidate 115 transport addresses (source IP address, port and transport protocol), 116 a second phase where these candidates are sent to a remote agent and 117 this gathering procedure is repeated and, finally, a third phase 118 where connectivity between all candidates in both sets is checked 119 (connectivity checks). Once these phases have been completed, and 120 only then, can both agents begin communication. According to the 121 Vanilla ICE specification the three phases above happen 122 consecutively, in a blocking way, which can introduce undesirable 123 latency during session establishment. 125 The Trickle ICE extension defined in [I-D.ietf-mmusic-trickle-ice] 126 defines generic semantics required for these ICE phases to happen 127 simultaneously, in a non-blocking way and hence speed up session 128 establishment. 130 This specification defines a usage of Trickle ICE with the Session 131 Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates 132 are to be incrementally exchanged with SIP INFO requests and how the 133 Half Trickle and Full Trickle modes defined in 134 [I-D.ietf-mmusic-trickle-ice] are to be used by SIP User Agents (UAs) 135 depending on their expectations for support of Trickle ICE by a 136 remote agent. 138 This document defines a new Info Package as specified in [RFC6086] 139 for use with Trickle ICE. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 This specification makes use of all terminology defined by the 148 protocol for Interactive Connectivity Establishment in [RFC5245] and 149 its Trickle ICE extension [I-D.ietf-mmusic-trickle-ice]. It is 150 assumed that the reader will be familiar with the terminology from 151 both of them. 153 3. Protocol Overview 155 The semantics that Vanilla ICE [RFC5245] defines for exchanging ICE 156 candidates are exclusively based on use of Offers and Answers as per 157 [RFC3264] over the Session Description Protocol (SDP) [RFC4566]. 158 This specification extends these mechanism by allowing ICE candidates 159 to also be sent in parallel to the Offer/Answer negotiation or after 160 the completion of Offer/Answer negotiation. This extension is done 161 through the use of SIP INFO messages and a newly defined Info Package 162 [RFC6086]. 164 Typically, in cases where Trickle ICE is fully supported, a candidate 165 exchange would happen along the following lines: The Offerer would 166 send an INVITE containing a subset of candidates and then wait for an 167 early dialog to be established. Once that happens, it will be able 168 to continue sending candidates through in INFO requests and within 169 the same dialog. 171 Similarly, an Answerer can start or continue "trickling" ICE 172 candidates using INFO messages within the dialog established by its 173 18x provisional response. Figure 1 shows such a sample exchange: 175 STUN/Turn STUN/TURN 176 Servers Alice Bob Servers 177 | | | | 178 | STUN Bi.Req. | INVITE (Offer) | | 179 |<--------------|------------------------>| | 180 | | 183 (Answer) | TURN Alloc Req | 181 | STUN Bi.Resp. |<------------------------|--------------->| 182 |-------------->| INFO/OK (SRFLX Cand.) | | 183 | |------------------------>| TURN Alloc Resp| 184 | | INFO/OK (Relay Cand.) |<---------------| 185 | |<------------------------| | 186 | | | | 187 | | More Cands & ConnChecks| | 188 | |<=======================>| | 189 | | | | 190 | | 200 OK | | 191 | |<------------------------| | 192 | | ACK | | 193 | |------------------------>| | 194 | | | | 195 | | 5245 SIP re-INVITE | | 196 | |------------------------>| | 197 | | 200 OK | | 198 | |<------------------------| | 199 | | ACK | | 200 | |------------------------>| | 201 | | | | 202 | |<===== MEDIA FLOWS =====>| | 203 | | | | 205 Figure 1: Sample Trickle ICE scenario with SIP 207 3.1. Rationale. Why INFO 209 The decision to use SIP INFO requests as a candidate transport method 210 is based primarily on their lightweight nature. Once a dialog has 211 been established, INFO messages can be exchanged both ways with no 212 restrictions on timing and frequency and no risk of collision. 214 On the other hand, using Offer/Answer and UPDATE requests, which from 215 an [RFC5245] perspective is the traditional way of transporting ICE 216 candidates, introduces the following complications: 218 Need for a non-blocking mechanism: [RFC3264] defines Offer/Answer 219 as a strictly sequential mechanism. There can only be a maximum 220 of one exchange at any point of time. Both sides cannot 221 simultaneously send Offers nor can they generate multiple Offers 222 prior to receiving an Answer. Using UPDATEs for candidate 223 transport would therefore imply the implementation of a candidate 224 pool at every agent where candidates can be stored until it is 225 once again that agent's "turn" to emit an Answer or a new Offer. 226 Such an approach would introduce non-negligible complexity for no 227 additional value. 229 Elevated risk of glare: The sequential nature of Offer/Answer also 230 makes it impossible for both sides to send Offers simultaneously. 231 What's worse is that there are no mechanisms in SIP to actually 232 prevent that. [RFC3261], where the situation of Offers crossing 233 on the wire is described as "glare", only defines a procedure for 234 addressing the issue after it has occurred. According to that 235 procedure both Offers are invalidated and both sides need to retry 236 the negotiation after a period between 0 and 4 seconds. The high 237 likelihood for glare to occur and the average two second backoff 238 intervals would imply Trickle ICE processing duration would not 239 only fail to improve but actually exceed those of Vanilla ICE. 241 INFO messages decouple the exchange of candidates from the Offer/ 242 Answer negotiation and are subject to none of the glare issues 243 described above, which makes them a very convenient and lightweight 244 mechanism for asynchronous delivery of candidates. 246 Using in-dialog INFO messages also provides a way of guaranteeing 247 that candidates are delivered end-to-end, between the same entities 248 that are actually in the process of initiating a session. The 249 alternative would have implied requiring support for Globally 250 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 251 adoption levels, would have constituted too strong of constraint to 252 the adoption of Trickle ICE. 254 3.2. Discovery issues 256 In order to benefit from Trickle ICE's full potential and reduce 257 session establishment latency to a minimum, Trickle ICE agents need 258 to generate SDP Offers and Answers that contain incomplete, 259 potentially empty sets of candidates. Such Offers and Answers can 260 only be handled meaningfully by agents that actually support 261 incremental candidate provisioning, which implies the need to confirm 262 such support before actually using it. 264 Contrary to other protocols, like XMPP [RFC6120], where "in advance" 265 capability discovery is widely implemented, the mechanisms that allow 266 this for SIP (i.e., a combination of UA Capabilities [RFC3840] and 267 GRUU [RFC5627]) have only seen low levels of adoption. This presents 268 an issue for Trickle ICE implementations as SIP UAs do not have an 269 obvious means of verifying that their peer will support incremental 270 candidate provisioning. 272 The Half Trickle mode of operation defined in the Trickle ICE 273 specification [I-D.ietf-mmusic-trickle-ice] provides one way around 274 this, by requiring first Offers to contain a complete set of ICE 275 candidates and only using incremental provisioning for the rest of 276 the sessions. 278 While using Half Trickle does provide a working solution it also 279 comes at the price of increased latency. Section 5 therefore makes 280 several alternative suggestions that enable SIP UAs to engage in Full 281 Trickle right from their first Offer: Section 5.1 discusses the use 282 of on-line provisioning as a means of allowing use of Trickle ICE for 283 all endpoints in controlled environments. Section 5.2 describes 284 anticipatory discovery for implementations that actually do support 285 GRUU and UA Capabilities and Section 5.4 discusses the implementation 286 and use of Half Trickle by SIP UAs where none of the above are an 287 option. 289 3.3. Relationship with the Offer/Answer Model 291 It is important to note that this specification does not require, 292 define, or even assume any mechanisms that would have an impact on 293 the Offer/Answer model beyond the way it is already used by Vanilla 294 ICE [RFC5245]. From the perspective of all SIP middle boxes and 295 proxies, and with the exception of the actual INFO messages, 296 signalling in general and Offer/Answer exchanges in particular would 297 look the same way for Trickle ICE as they would for Vanilla ICE. 299 +-------------------------------+ +-------------------------------+ 300 | Alice +--------------+ | | +--------------+ Bob | 301 | | Offer/Answer | | | | Offer/Answer | | 302 | +-------+ | Module | | | | Module | +-------+ | 303 | | ICE | +--------------+ | | +--------------+ | ICE | | 304 | | Agent | | | | | | Agent | | 305 | +-------+ | | | | +-------+ | 306 +-------------------------------+ +-------------------------------+ 307 | | | | 308 | | INVITE (Offer) | | 309 | |--------------------->| | 310 | | 183 (Answer) | | 311 | |<---------------------| | 312 | | | | 313 | | 314 | SIP INFO (more candidates) | 315 |----------------------------------------------------->| 316 | SIP INFO (more candidates) | 317 |<-----------------------------------------------------| 318 | | 319 | STUN Binding Requests/Responses | 320 |----------------------------------------------------->| 321 | STUN Binding Requests/Responses | 322 |<-----------------------------------------------------| 323 | | 324 | | | | 325 | | 5245 SIP re-INVITE | | 326 | |--------------------->| | 327 | | 200 OK | | 328 | |<---------------------| | 330 Figure 2: Distinguishing between Trickle ICE and traditional 331 signalling. 333 It is important to note that, as displayed on Figure 2, exchanging 334 candidates through SIP INFO messages are best represented as 335 signalling between ICE agents and not between the traditional SIP and 336 Offer/Answer modules of SIP User Agents. Such INFO requests do not 337 impact the state of Offer/Answer, nor do they have an impact on the 338 version number in the "o=" line. In that regard they are actually 339 comparable to Peer Reflexive candidates that ICE agents can discover 340 during ICE processing. 342 4. Incremental Signalling of ICE candidates 344 Trickle ICE agents will construct Offers and Answers as specified in 345 [I-D.ietf-mmusic-trickle-ice] with the following additional SIP- 346 specific additions: 348 1. Trickle ICE agents MUST indicate support for Trickle ICE by 349 including the option-tag 'trickle-ice' in a SIP Supported: header 350 field within all SIP INVITE requests and responses. 352 2. Trickle ICE agents MAY exchange additional ICE candidates using 353 INFO requests within an existing invite dialog usage (including 354 an early dialog) as specified in [RFC6086]. The INFO messages 355 carry an Info-Package: trickle-ice. Trickle ICE agents MUST be 356 prepared to receive INFO requests within that same dialog usage, 357 containing additional candidates or an indication for the end of 358 such candidates 360 3. Trickle ICE agents MAY exchange additional ICE candidates before 361 the Answerer has sent the Answer provided that an invite dialog 362 usage is established at both Trickle ICE agents. Note that in 363 case of forking multiple early dialogs will exist. 365 The following section provide further details on how Trickle ICE 366 agents establish the INVITE dialog usage such that they can trickle 367 candidates. 369 4.1. Establishing the dialog 371 In order for SIP UAs to be able to start trickling, the following two 372 conditions need to be satisfied: 374 o Trickle ICE support in the peer agent MUST be confirmed. 376 o The dialog at both sides MUST be in early or confirmed state. 378 Section 5 discusses in detail the various options for satisfying the 379 first of the above conditions. Regardless of those mechanisms 380 however, agents are certain to have a clear understanding of whether 381 their peers support trickle ICE once an Offer and an Answer have been 382 exchanged, which also allows for ICE processing to commence (see 383 Figure 3). 385 4.1.1. Asserting dialog state through reliable Offer/Answer delivery 386 Alice Bob 387 | | 388 | INVITE (Offer) | 389 |------------------------>| 390 | 183 (Answer) | 391 |<------------------------| 392 | PRACK/OK | 393 |------------------------>| 394 | | 395 +----------------------------------------+ 396 |Alice and Bob know that both can trickle| 397 |and know that the dialog is in the early| 398 |state. Send INFO! | 399 +----------------------------------------+ 400 | | 401 | INFO/OK (SRFLX Cand.) | 402 |------------------------>| 403 | INFO/OK (SRFLX Cand.) | 404 |<------------------------| 405 | | 407 Figure 3: SIP Offerer can freely trickle as soon as it receives an 408 Answer. 410 Satisfying both conditions is also relatively trivial for ICE agents 411 that have sent an Offer in an INVITE and that have received an Answer 412 in a reliable provisional response. It is guaranteed to have 413 confirmed support for Trickle ICE within the Answerer (or lack 414 thereof) and to have fully initialized the SIP dialog at both ends. 415 Offerers and Answerers in the above situation can therefore freely 416 commence trickling within the newly established dialog. 418 4.1.2. Asserting dialog state through unreliable Offer/Answer delivery 420 The situation is a bit more delicate for agents that have received an 421 Offer in an INVITE request and have sent an Answer in an unreliable 422 provisional response because, once the response has been sent, the 423 Answerer does no know when or if it has been received (Figure 4). 425 Alice Bob 426 | | 427 | INVITE (Offer) | 428 |------------------------>| 429 | 183 (Answer) | 430 |<------------------------| 431 | | 432 | +----------------------+ 433 | |Bob: I don't know if | 434 | |Alice got my 183 or if| 435 | |her dialog is already | 436 | |in the early state. | 437 | | Can I send INFO??? | 438 | +----------------------+ 439 | | 441 Figure 4: A SIP UA that sent an Answer in an unreliable provisional 442 response does not know if it was received and if the dialog at the 443 side of the Offerer has entered the early state 445 In order to clear this ambiguity as soon as possible, the answerer 446 needs to retransmit the provisional response with the exponential 447 backoff timers described in [RFC3262]. Retransmits MUST cease on 448 receipt of a INFO request or on transmission of the answer in a 2xx 449 response. This is similar to the procedure described in section 450 12.1.1 of [RFC5245] except that the STUN binding Request is replaced 451 by the INFO request. 453 The Offerer MUST send a Trickle ICE INFO request as soon as they 454 receive an SDP Answer in an unreliable provisional response. This 455 INFO message can repeat the candidates that were already provided in 456 the Offer (as would be the case when Half Trickle is performed or 457 when new candidates have not been learned since then) and/or they MAY 458 also deliver new candidates (if available). An end-of-candidates 459 indication MAY be included in case candidate discovery has ended in 460 the mean time. 462 As soon as an Answerer has received such an INFO request, the 463 Answerer has an indication that a dialog is well established at both 464 ends and MAY begin trickling (Figure 5). 466 Alice Bob 467 | | 468 | INVITE (Offer) | 469 |------------------------>| 470 | 183 (Answer) | 471 |<------------------------| 472 | INFO/OK (SRFLX Cand.) | 473 |------------------------>| 474 | | 475 | +----------------------+ 476 | |Bob: Now I know Alice| 477 | | is ready. Send INFO! | 478 | +----------------------+ 479 | INFO/OK (SRFLX Cand.) | 480 |<------------------------| 481 | | 482 | 200/ACK (Answer) | 483 |<------------------------| 485 Figure 5: A SIP UA that received an INFO request after sending an 486 unreliable provisional response knows that the dialog at the side of 487 the receiver has entered the early state 489 When sending the Answer in the 200 OK response, the Answerer MUST 490 repeat exactly the same Answer that was previously sent in the 491 unreliable provisional response in order to fulfill the corresponding 492 requirements in [RFC3264]. In other words, that Offerer needs to be 493 prepared to receive fewer candidates in that repeated Answer than 494 previously exchanged via trickling. 496 4.1.3. Initiating Trickle ICE without an SDP Answer 498 The possibility to convey arbitrary candidates in INFO message bodies 499 allows ICE agents to initiate trickling without actually sending an 500 Answer. Trickle ICE Agents MAY therefore respond to INVITEs with 501 provisional responses without an SDP Answer. Such provisional 502 responses serve for establishing an early dialog. 504 Agents that choose to establish the dialog in this way, MUST 505 retransmit these responses with the exponential backoff timers 506 described in [RFC3262]. Retransmits MUST cease on receipt of an INFO 507 request or on transmission of the answer in a 2xx response. This is 508 again similar to the procedure described in section 12.1.1 of 509 [RFC5245] except that an Answer is not yet provided. 511 Alice Bob 512 | | 513 | INVITE (Offer) | 514 |------------------------>| 515 | 183 (-) | 516 |<------------------------| 517 | INFO/OK (SRFLX Cand.) | 518 |------------------------>| 519 | | 520 | +----------------------+ 521 | |Bob: Now I know again| 522 | | that Alice is ready. | 523 | | Send INFO! | 524 | +----------------------+ 525 | INFO/OK (SRFLX Cand.) | 526 |<------------------------| 527 | 183 (Answer) opt. | 528 |<------------------------| 529 | INFO/OK (SRFLX Cand.) | 530 |<------------------------| 531 | 200/ACK (Answer) | 532 |<------------------------| 534 Figure 6: A SIP UA sends an unreliable provisional response without 535 an Answer for establishing an early dialog 537 When sending the Answer the agent MUST repeat all previously sent 538 candidates, if any, and MAY include all newly gathered candidates 539 since the last INFO request was sent. If that answer was sent in a 540 unreliable provisional response, the Answerers MUST repeat exactly 541 the same Answer in the 200 OK response in order to fulfill the 542 corresponding requirements in [RFC3264]. In other words, an Offerer 543 needs to be prepared to receive fewer candidates in that repeated 544 Answer than previously exchanged via trickling. 546 4.1.4. Considerations for 3PCC 548 Agents that have sent an Offer in a reliable provisional response and 549 that receive an Answer in a PRACK are also in a situation where 550 support for Trickle ICE is confirmed and the SIP dialog is guaranteed 551 to be in a state that would allow in-dialog INFO requests (see 552 Figure 7). 554 Alice Bob 555 | | 556 | INVITE | 557 |------------------------>| 558 | 183 (Offer) | 559 |<------------------------| 560 | PRACK (Answer) | 561 |------------------------>| 562 | | 563 | +----------------------+ 564 | |Bob: I know Alice can| 565 | |trickle and I know her| 566 | |dialog is in the early| 567 | |state. Send INFO! | 568 | +----------------------+ 569 | | 570 | INFO/OK (SRFLX Cand.) | 571 |<------------------------| 572 | | 573 | INFO/OK (SRFLX Cand.) | 574 |------------------------>| 575 | 200 OK/ACK | 576 |<------------------------| 578 Figure 7: A SIP Offerer in a 3PCC scenario can also freely start 579 trickling as soon as it receives an Answer. 581 Trickle Agents that send an Offer in a 200 OK and receive an Answer 582 in an ACK can still create a dialog and confirm support for Trickle 583 ICE by sending an unreliable provisional response similar to 584 Section 4.1.3. According to [RFC3261], this unreliable response MUST 585 NOT contain an Offer. 587 The Trickle Agent (at the UAS) retransmits the provisional response 588 with the exponential backoff timers described in [RFC3262]. 589 Retransmits MUST cease on receipt of a INFO request or on 590 transmission of the answer in a 2xx response. The peer Trickle Agent 591 (at the UAC) MUST send a Trickle ICE INFO request as soon as they 592 receive an unreliable provisional response (see Figure 8). 594 Alice Bob 595 | | 596 | INVITE | 597 |------------------------>| 598 | 183 (-) | 599 |<------------------------| 600 | INFO/OK (SRFLX Cand.) | 601 |------------------------>| 602 | | 603 | +-----------------------+ 604 | |Bob: I know Alice can | 605 | |trickle and I know her | 606 | |dialog is in the early | 607 | |state. | 608 | |INFO can be sent. | 609 | +-----------------------+ 610 | | 611 | INFO/OK (SRFLX Cand.) | 612 |<------------------------| 613 | | 614 | 200 (Offer) | 615 |<------------------------| 616 | ACK (Answer) | 617 |------------------------>| 618 | | 620 Figure 8: A SIP UAC in a 3PCC scenario can also freely start 621 trickling as soon as it receives an unreliable provisional response. 623 4.2. Delivering candidates in INFO messages 625 Whenever new ICE candidates become available for sending, agents 626 would encode them in "a=candidate" lines as described by 627 [I-D.ietf-mmusic-trickle-ice]. For example: 629 a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx 630 raddr 10.0.1.1 rport 8998 632 The use of SIP INFO requests happens within the context of the Info 633 Package as defined Section 9. The MIME type for their payload MUST 634 be set to 'application/trickle-ice-sdpfrag' as defined in Section 8. 636 Since neither the "a=candidate" nor the "a=end-of-candidates" 637 attributes contain information that would allow correlating them to a 638 specific "m=" line, this is handled through the use of pseudo "m=" 639 lines and identification tags in "a=mid:" attributes as defined in 641 [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as 642 defined in [RFC4566], but provide no semantics other than indicating 643 to which "m=" line a candidate belongs. Consequently, the receiving 644 agent MUST ignore the remaining content of the pseudo m-line. This 645 guarantees that the 'application/trickle-ice-sdpfrag' bodies do not 646 interfere with the Offer/Answer procedures as specified in [RFC3264]. 648 When sending the INFO request, the agent MAY, if already known to the 649 agent, include the same content into the pseudo m-line as for the 650 corresponding Offer or Answer. However, since Trickle-ICE might be 651 decoupled from the Offer/Answer negotiation this content might be 652 unknown to the agent. In this case, the agent MUST include the 653 following default values. 655 o The media is set to 'audio'. 657 o The port value is set to '9'. 659 o The proto value is set to 'RTP/AVP'. 661 o The fmt SHOULD appear only once and is set to '0' 663 Agents MUST include a pseudo "m=" line and an identification tag in a 664 "a=mid:" attribute for every "m=" line whose candidate list they 665 intend to update. Such "a=mid:" attributes MUST immediately precede 666 the list of candidates for that specific "m=" line. All 667 "a=candidate" or "a=end-of-candidates" attributes following an 668 "a=mid:" attribute, up until (and excluding) the next occurrence of 669 an "a=mid:" attribute, pertain to the "m=" line identified by that 670 identification tag. An "a=end-of-candidates" attribute, preceding 671 any "a=mid:" attributes, indicates the end of all trickling from that 672 agent, as opposed to end of trickling for a specific "m=" line, which 673 would be indicated by a media level "a=end-of-candidates" attribute. 675 The use of "a=mid:" attributes allows for a structure similar to the 676 one in SDP Offers and Answers where separate media-level and session- 677 level sections can be distinguished. In the current case, lines 678 preceding any "a=mid:" attributes are considered to be session-level. 679 Lines appearing in between or after "a=mid:" attributes will be 680 interpreted as media-level. 682 Note that while this specification uses the "a=mid:" attribute 683 from [RFC5888], it does not define any grouping semantics. 684 Consequently, using the "a=group:" attribute from that same 685 specification is neither needed nor used in Trickle ICE for SIP. 687 All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" 688 attributes that would allow mapping them to a specific ICE 689 generation. INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:" 690 attributes that do not match those of the current ICE processing 691 session MUST be discarded. The "a=ice-pwd:" and "a=ice-ufrag:" 692 attributes MUST appear at the same level as the ones in the Offer/ 693 Answer exchange. In other words, if they were present as sesssion- 694 level attributes there, they will also appear at the beginning of all 695 INFO message payloads, preceding all "a=mid:" attributes. If they 696 were originally exchanged as media level attributes, potentially 697 overriding session-level values, then they will also be included in 698 INFO message payloads, following the corresponding "a=mid:" 699 attribute. 701 In every INFO request agents MUST include all local candidates they 702 have previously signalled. This is necessary in order to more easily 703 avoid problems that would arise from unreliability. Misordering can 704 be detected through the CSeq: header field in the INFO request. 706 When receiving INFO requests carrying any candidates, agents will 707 therefore first identify and discard the SDP lines containing 708 candidates they have already received in previous INFO requests or in 709 the Offer/Answer exchange preceding them. Two candidates are 710 considered to be equal if their IP address port, transport and 711 component ID are the same. After identifying and discarding known 712 candidates, agents will then process the remaining, actually new 713 candidates according to the rules described in 714 [I-D.ietf-mmusic-trickle-ice]. 716 The following example shows the content of one sample candidate 717 delivering INFO request: 719 INFO sip:alice@example.com SIP/2.0 720 ... 721 Info-Package: trickle-ice 722 Content-type: application/sdp 723 Content-Disposition: Info-Package 724 Content-length: ... 726 a=ice-pwd:asd88fgpdd777uzjYhagZg 727 a=ice-ufrag:8hhY 728 m=audio 9 RTP/AVP 0 729 a=mid:1 730 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 731 a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx 732 raddr 10.0.1.1 rport 8998 733 a=end-of-candidates 734 m=audio 9 RTP/AVP 0 735 a=mid:2 736 a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx 737 raddr 10.0.1.1 rport 9000 738 a=end-of-candidates 740 5. Initial discovery of Trickle ICE support 742 SIP User Agents (UAs) that support and intend to use trickle ICE are 743 REQUIRED by [I-D.ietf-mmusic-trickle-ice] to indicate that in their 744 Offers and Answers using the following attribute: "a=ice- 745 options:trickle". This makes discovery fairly straightforward for 746 Answerers or for cases where Offers need to be generated within 747 existing dialogs (i.e., when sending re-INVITE requests). In both 748 scenarios prior SDP would have provided the necessary information. 750 Obviously, prior SDP is not available at the time a first Offer is 751 being constructed and it is therefore impossible for ICE agents to 752 determine support for incremental provisioning that way. The 753 following options are suggested as ways of addressing this issue. 755 5.1. Provisioning support for Trickle ICE 757 In certain situations it may be possible for integrators deploying 758 Trickle ICE to know in advance that some or all endpoints reachable 759 from within the deployment will support Trickle ICE. This is likely 760 to be the case, for example, for WebRTC clients that will always be 761 communicating with other WebRTC clients or known Session Border 762 Controllers (SBC) with support for this specification. 764 While the exact mechanism for allowing such provisioning is out of 765 scope here, this specification encourages trickle ICE implementations 766 to allow the option in the way they find most appropriate. 768 5.2. Trickle ICE discovery with GRUU 770 [RFC3840] provides a way for SIP user agents to query for support of 771 specific capabilities using, among others, OPTIONS requests. GRUU 772 support on the other hand allows SIP requests to be addressed to 773 specific UAs (as opposed to arbitrary instances of an address of 774 record). Combining the two and using the "trickle-ice" option tag 775 defined in Section 9.5 provides SIP UAs with a way of learning the 776 capabilities of specific US instances and then addressing them 777 directly with INVITE requests that require SIP support. 779 Such targeted trickling may happen in different ways. One option 780 would be for a SIP UA to learn the GRUU instance ID of a peer through 781 presence and to then query its capabilities direction with an OPTIONS 782 request. Alternately, it can also just send an OPTIONS request to 783 the AOR it intends to contact and then inspect the returned 784 response(s) for support of both GRUU and Trickle ICE (Figure 9). 786 Alice Bob 787 | | 788 | OPTIONS sip:b1@example.com SIP/2.0 | 789 |-------------------------------------------------->| 790 | | 791 | 200 OK | 792 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 793 | ;audio;video|;trickle-ice;... | 794 |<--------------------------------------------------| 795 | | 796 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 797 |-------------------------------------------------->| 798 | | 799 | 183 (Answer) | 800 |<--------------------------------------------------| 801 | INFO/OK (Trickling) | 802 |<------------------------------------------------->| 803 | | 804 | ... | 805 | | 807 Figure 9: Trickle ICE support discovery with OPTIONS and GRUU 809 Confirming support for Trickle ICE through [RFC3840] gives SIP UAs 810 the options to engage in Full Trickle negotiation (as opposed to the 811 more lengthy Half Trickle) from the very first Offer they send. 813 5.3. Trickle ICE discovery through other protocols 815 Protocols like XMPP [RFC6120] define advanced discovery mechanisms 816 that allow specific features to be queried priory to actually 817 attempting to use them. Solutions like [RFC7081] define ways of 818 using SIP and XMPP together which also provides a way for dual stack 819 SIP+XMPP endpoints to make use of such features and verify Trickle 820 ICE support for a specific SIP endpoint through XMPP. [TODO expand 821 on a specific way to do this or declare as out of scope] 823 5.4. Fallback to Half Trickle 825 In cases where none of the other mechanisms in this section are 826 acceptable, SIP UAs should use the Half Trickle mode defined in 827 [I-D.ietf-mmusic-trickle-ice]. With Half Trickle, agents initiate 828 sessions the same way they would when using Vanilla ICE [RFC5245]. 829 This means that, prior to actually sending an Offer, agents would 830 first gather ICE candidates in a blocking way and then send them all 831 in that Offer. The blocking nature of the process would likely imply 832 that some amount of latency will be accumulated and it is advised 833 that agents try to anticipate it where possible, like for example, 834 when user actions indicate a high likelyhood for an imminent call 835 (e.g., activity on a keypad or a phone going offhook). 837 Using Half Trickle would result in Offers that are compatible with 838 both Vanilla ICE and legacy [RFC3264] endpoints. 840 STUN/Turn STUN/TURN 841 Servers Alice Bob Servers 842 | | | | 843 |<--------------| | | 844 | | | | 845 | | | | 846 | Candidate | | | 847 | | | | 848 | | | | 849 | Discovery | | | 850 | | | | 851 | | | | 852 |-------------->| INVITE (Offer) | | 853 | |------------------------>| | 854 | | 183 (Answer) |-------------->| 855 | |<------------------------| | 856 | | | | 857 | | INFO (more candidates) | Candidate | 858 | |<------------------------| | 859 | | Connectivity Checks | | 860 | |<=======================>| Discovery | 861 | | INFO (more candidates) | | 862 | |<------------------------| | 863 | | Connectivity Checks |<--------------| 864 | |<=======================>| | 865 | | | | 866 | | 200 OK | | 867 | |<------------------------| | 868 | | | | 869 | | 5245 SIP re-INVITE | | 870 | |------------------------>| | 871 | | 200 OK | | 872 | |<------------------------| | 873 | | | | 874 | | | | 875 | |<===== MEDIA FLOWS =====>| | 876 | | | | 878 Figure 10: Example - A typical (Half) Trickle ICE exchange with SIP 880 It is worth reminding that once a single Offer or Answer had been 881 exchanged within a specific dialog, support for Trickle ICE will have 882 been determined. No further use of Half Trickle will therefore be 883 necessary within that same dialog and all subsequent exchanges can 884 use the Full Trickle mode of operation. 886 6. Considerations for RTP and RTCP multiplexing 888 The following consideration describe options for Trickle-ICE in order 889 to give some guidance to implementors on how trickling can be 890 optimized with respect to providing RTCP candidates. 892 Handling of RTP and RTCP multiplexing [RFC5761] is already considered 893 in sections 4.1.1.1, 4.3, and 5.7.1 of [RFC5245], respectively, as 894 well in [RFC5761] itself. These considerations are still valid for 895 Trickle ICE, however, trickling provides more flexibility for the 896 sequence of candidate exchange in case of RTCP multiplexing. 898 While a Half Trickle Offerer would have to send an offer compliant to 899 [RFC5245] and [RFC5761] including candidates for all components, this 900 flexibility allows a Full Trickle Offerer to initially send only RTP 901 candidates (component 1) if it assumes that RTCP multiplexing is 902 supported by the Answerer. A Full Trickle Offerer would need to 903 start gathering and trickling RTCP candidates (component 2) only 904 after having received an indication in the answer that the answerer 905 unexpectedly does not support RTCP multiplexing. 907 A Trickle answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in 908 the application/trickle-ice-sdpfrag body if it supports and uses RTP 909 and RTCP multiplexing. Receipt of this attribute at the Offerer in 910 an INFO request prior to the Answer indicates that the Answerer 911 supports and uses RTP and RTCP multiplexing. The Offerer can use 912 this information e.g. for stopping gathering of RTCP candidates and/ 913 or for freeing corresponding resources. 915 This behaviour is illustrated by the following example offer that 916 indicates support for RTP and RTCP multiplexing. 918 v=0 919 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 920 s= 921 c=IN IP4 atlanta.example.com 922 t=0 0 923 a=ice-pwd:777uzjYhagZgasd88fgpdd 924 a=ice-ufrag:Yhh8 925 m=audio 10000 RTP/AVP 0 926 a=mid:1 927 a=rtcp-mux 928 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 930 Once the dialog is established as described in section Section 4.1 931 the Answerer sends the following INFO message. 933 INFO sip:alice@example.com SIP/2.0 934 ... 935 Info-Package: trickle-ice 936 Content-type: application/sdp 937 Content-Disposition: Info-Package 938 Content-length: ... 940 a=ice-pwd:asd88fgpdd777uzjYhagZg 941 a=ice-ufrag:8hhY 942 m=audio 9 RTP/AVP 0 943 a=mid:1 944 a=rtcp-mux 945 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 947 This INFO message indicates that the Answerer supports and uses RTP 948 and RTCP multiplexing as well. This allows the Offerer to omit 949 gathering of RTCP candidates or releasing already gathered RTCP 950 candidates. If the INFO message did not contain the a=rtcp-mux 951 attribute, the Offerer would have to gather RTCP candidates unless it 952 wants to wait until receipt of an Answer that eventually confirms 953 support or non-support for RTP and RTCP multiplexing. 955 7. Considerations for Media Multiplexing 957 The following consideration describe options for Trickle-ICE in order 958 to give some guidance to implementors on how trickling can be 959 optimized with respect to providing candidates in case of Media 960 Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed 961 that the reader is familiar with 962 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 964 ICE candidate exchange is already considered in section 11 of 965 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are 966 still valid for Trickle ICE, however, trickling provides more 967 flexibility for the sequence of candidate exchange, especially in 968 Full Trickle mode. 970 Except for bundle-only m-lines, a Half Trickle Offerer would have to 971 send an offer with candidates for all bundled m-lines. The 972 additional flexibility, however, allows a Full Trickle Offerer to 973 initially send only candidates for the m-line with the suggested 974 offerer BUNDLE address. 976 Latest on receipt of the answer, the Offerer will detect if BUNDLE is 977 supported and if the suggested offerer BUNDLE address was selected. 978 In this case the Offerer does need to trickle further candidates for 979 the remaining m-lines in a bundle. However, if BUNDLE is not 980 supported, the Full Trickle Offerer needs to gather and trickle 981 candidates for the remaining m-lines as necessary. If the answerer 982 selects a Offerer BUNDLE address different from suggested Offerer 983 BUNDLE address, the Full Trickle Offerer needs to gather and trickle 984 candidates for the m-line that carries the selected Offerer BUNDLE 985 address. 987 A Trickle answerer MAY include an "a=group: BUNDLE" attribute 988 [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle- 989 ice-sdpfrag body if it supports and uses bundling. When doing so, 990 the Answerer MUST include all identification-tags in the same order 991 that is used or will be used in the Answer. 993 Receipt of this attribute at the Offerer in an INFO request prior to 994 the Answer indicates that the Answerer supports and uses bundling. 995 The Offerer can use this information e.g. for stopping the gathering 996 of candidates for the remaining m-lines in a bundle and/or for 997 freeing corresponding resources. 999 This behaviour is illustrated by the following example offer that 1000 indicates support for Media Multiplexing. 1002 v=0 1003 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1004 s= 1005 c=IN IP4 atlanta.example.com 1006 t=0 0 1007 a=group:BUNDLE foo bar 1008 a=ice-pwd:777uzjYhagZgasd88fgpdd 1009 a=ice-ufrag:Yhh8 1010 m=audio 10000 RTP/AVP 0 1011 a=mid:foo 1012 a=rtpmap:0 PCMU/8000 1013 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1014 m=video 10002 RTP/AVP 31 1015 a=mid:bar 1016 a=rtpmap:31 H261/90000 1017 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1019 Once the dialog is established as described in section Section 4.1 1020 the Answerer sends the following INFO message. 1022 INFO sip:alice@example.com SIP/2.0 1023 ... 1024 Info-Package: trickle-ice 1025 Content-type: application/sdp 1026 Content-Disposition: Info-Package 1027 Content-length: ... 1029 a=group:BUNDLE foo bar 1030 a=ice-pwd:asd88fgpdd777uzjYhagZg 1031 a=ice-ufrag:8hhY 1032 m=audio 9 RTP/AVP 0 1033 a=mid:1 1034 a=rtcp-mux 1035 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 1036 m=audio 9 RTP/AVP 0 1037 a=mid:bar 1039 This INFO message indicates that the Answerer supports and uses Media 1040 Multiplexing as well. Note, that the second m-line shows the default 1041 values as specified in section Section 4.2, e.g. media set 'audio' 1042 although 'video' was offered. The receiving ICE agents needs to 1043 ignore these default values in the pseudo m-lines. 1045 The INFO message also indicates that the Answerer accepted the 1046 Suggested Bundle Address from the Offerer. This allows the Offerer 1047 to omit gathering of RTP and RTCP candidates for the other m-lines or 1048 releasing already gathered candidates. If the INFO message did not 1049 contain the a=group:BUNDLE attribute, the Offerer would have to 1050 gather RTP and RTCP candidates for the other m-lines unless it wants 1051 to wait until receipt of an Answer that eventually confirms support 1052 or non-support for Media Multiplexing. 1054 8. Content Type 'application/trickle-ice-sdpfrag' 1056 8.1. Overall Description 1058 A application/trickle-ice-sdpfrag body is used by the Trickle-ICE 1059 Info Package. It uses a subset of the possible SDP lines that are 1060 allowed based on the grammar defined in [RFC4566]. A valid body uses 1061 only media descriptions and certain attributes that are needed and/or 1062 useful for trickling candidates. The content adheres to the 1063 following grammar. 1065 Like ordinary SDP 1067 8.2. Grammar 1069 The grammar of an 'application/trickle-ice-sdpfrag' body is based the 1070 following ABNF [RFC5234]. 1072 ; Syntax 1073 trickle-ice-sdpfrag = session-level-fields 1074 pseudo-media-descriptions 1075 session-level-fields = [bundle-group-attribute CRLF] 1076 [ice-lite-attribute CRLF] 1077 ice-pwd-attribute CRLF 1078 ice-ufrag-attribute CRLF 1079 [ice-options-attribute CRLF] 1080 [end-of-candidates-attribute CRLF] 1081 extension-attribute-fields 1082 ; for future extensions 1084 ice-lite-attribute = %s"a=" ice-lite 1085 ice-pwd-attribute = %s"a=" ice-pwd-att 1086 ice-ufrag-attribute = %s"a=" ice-ufrag-att 1087 ice-options-attribute = %s"a=" ice-options 1088 bundle-group-attribute = "a=group:" bundle-semantics 1089 *(SP identification-tag) 1090 bundle-semantics = "BUNDLE" 1091 end-of-candidates-attribute = %s"a=" end-of-candidates-att 1092 extension-attribute-fields = attribute-fields 1094 pseudo-media-descriptions = *( media-field 1095 trickle-ice-attribute-fields 1096 [extension-attribute-fields] ) 1097 ; for future extensions 1098 trickle-ice-attribute-fields = mid-attribute CRLF 1099 ["a=rtcp-mux" CRLF] 1100 *(candidate-attributes CRLF) 1101 [remote-candidate-attribute CRLF] 1102 [end-of-candidates-attribute CRLF] 1103 remote-candidate-attribute = %s"a=" remote-candidate-att 1104 candidate-attributes = %s"a=" candidate-attribute 1106 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- 1107 options, candidate-attribute remote-candidate-att from [RFC5245], 1108 identification-tag, mid-attribute ; from [RFC5888], media-field, 1109 attribute-fields from [RFC4566] and end-of-candidates-att from 1110 [I-D.ietf-mmusic-trickle-ice]. The indicator for case-sensitivity %s 1111 is defined in [RFC7405]. 1113 [NOTE: end-of-candidates-att currently lacks a formal definition in 1114 [I-D.ietf-mmusic-trickle-ice]] 1116 9. Info Package 1118 9.1. Overall Description 1120 This specification defines an Info Package for use by SIP user agents 1121 implementing Trickle ICE. INFO requests carry ICE candidates 1122 discovered after the peer user agents have confirmed mutual support 1123 for Trickle ICE. 1125 9.2. Applicability 1127 The purpose of the ICE protocol is to establish a media path in the 1128 presence of NAT and firewalls. The candidates are transported in 1129 INFO requests and are part of this establishment. 1131 Candidates sent by a Trickle ICE agent after the Offer, follow the 1132 same signalling path and reach the same entity as the Offer itself. 1133 While it is true that GRUUs can be used to achieve this, one of the 1134 goals of this specification is to allow operation of Trickle ICE in 1135 as many environments as possible including those without GRUU 1136 support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not 1137 satisfy this goal. 1139 9.3. Info Package Name 1141 This document defines a SIP Info Package as per [RFC6086]. The Info 1142 Package token name for this package is "trickle-ice" 1144 9.4. Info Package Parameters 1146 This document does not define any Info Package parameters. 1148 9.5. SIP Option Tags 1150 [RFC6086] allows Info Package specifications to define SIP option- 1151 tags. This specification extends the option-tag construct of the SIP 1152 grammar as follows: 1154 option-tag /= "trickle-ice" 1156 SIP entities that support this specification MUST place the 'trickle- 1157 ice' option-tag in a SIP Supported: header field within all SIP 1158 INVITE requests and responses. 1160 When responding to, or generating a SIP OPTIONS request a SIP entity 1161 MUST also include the 'trickle-ice' option-tag in a SIP Supported: 1162 header field. 1164 9.6. Info Message Body Parts 1166 Entities implementing this specification MUST include a payload of 1167 type 'application/trickle-ice-sdpfrag' as defined in Section 8.2 all 1168 SIP INFO requests. The payload is used to convey SDP encoded ICE 1169 candidates. 1171 9.7. Info Package Usage Restrictions 1173 This document does not define any Info Package Usage Restrictions. 1175 9.8. Rate of INFO Requests 1177 A Trickle ICE Agent with many network interfaces might create a high 1178 rate of INFO requests if every newly detected candidate is trickled 1179 individually without aggregation. Implementor that are concerned 1180 about loss of packets in such a case might consider aggregating ICE 1181 candidates and sending INFOS only at some configurable intervals. 1183 9.9. Info Package Security Considerations 1185 See section Section 11 1187 10. IANA Considerations 1189 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1190 document.] 1192 10.1. application/trickle-ice-sdpfrag MIME Type 1194 Type name: application 1196 Subtype name: trickle-ice-sdpfrag 1198 Required parameters: None. 1200 Optional parameters: None. 1202 Encoding considerations: 1204 SDP files are primarily UTF-8 format text. Although the 1205 initially defined content of a trickle-ice-sdpfrag body does 1206 only include ASCII characters, UTF-8 encoded content might be 1207 introduced via extension attributes. The "a=charset:" 1208 attribute may be used to signal the presence of other character 1209 sets in certain parts of a trickle-ice-sdpfrag body (see 1211 [RFC4566]). Arbitrary binary content cannot be directly 1212 represented in SDP or a trickle-ice-sdpfrag body. 1214 Security considerations: 1216 See [RFC4566]) and RFCXXXX 1218 Interoperability considerations: 1220 See RFCXXXX 1222 Published specification: 1224 See RFCXXXX 1226 Applications which use this media type: 1228 Voice over IP, video teleconferencing, streaming media, instant 1229 messaging, Trickle-ICE among others. 1231 Additional information: 1233 Magic number(s): none 1235 File extension(s): none 1237 Macintosh File Type Code(s): none 1239 Person and email address to contact for further information: 1241 IETF MMUSIC working group mmusic@ietf.org 1243 Intended usage: 1245 Trickle-ICE for SIP as specified in RFCXXXX. 1247 Author/Change controller: 1249 IETF MMUSIC working group mmusic@ietf.org 1251 10.2. SIP Info Package 'trickle-ice' 1253 This document defines a new SIP Info Package named 'trickle-ice' and 1254 updates the Info Packages Registry with the following entry. 1256 +-------------+-----------+ 1257 | Name | Reference | 1258 +-------------+-----------+ 1259 | trickle-ice | [RFCXXXX] | 1260 | | | 1261 +-------------+-----------+ 1263 10.3. SIP Option Tag 'trickle-ice' 1265 This specification registers a new SIP option tag 'trickle-ice' as 1266 per the guidelines in Section 27.1 of [RFC3261] and updates the 1267 "Option Tags" section of the SIP Parameter Registry with the 1268 following entry: 1270 +-------------+---------------------------------------+-----------+ 1271 | Name | Description | Reference | 1272 +-------------+---------------------------------------+-----------+ 1273 | trickle-ice | This option tag is used to indicate | [RFCXXXX] | 1274 | | that a UA supports and understands | | 1275 | | Trickle-ICE. | | 1276 +-------------+---------------------------------------+-----------+ 1278 11. Security Considerations 1280 The Security Considerations of [RFC5245], [RFC6086], 1281 [I-D.ietf-mmusic-trickle-ice] apply. This document clarifies how the 1282 above specifications are used together for trickling candidates and 1283 does not create addtitional security risks. 1285 12. Acknowledgements 1287 The authors would like to thank Paul Kyzivat, Jonathan Lennox, Simon 1288 Perreault and Martin Thomson for reviewing and/or making various 1289 suggestions for improvements and optimisations. 1291 13. Change Log 1293 [RFC EDITOR NOTE: Please remove this section when publishing]. 1295 Changes from draft-ietf-mmusic-trickle-ice-sip-01 1297 o Editorial Clean up 1299 o IANA Consideration added 1301 o Security Consideration added 1303 o RTCP and BUNDLE Consideration added with rules for including 1304 "a=rtcp-mux" and "a=group: BUNDLLE" attributes 1306 o 3PCC Consideration added 1308 o Clarified that 18x w/o answer is sufficient to create a dialog 1309 that allows for trickling to start 1311 o Added remaining Info Package definition sections as outlined in 1312 section 10 of [RFC6086] 1314 o Added definition of application/sdpfrag making draft-ivov-mmusic- 1315 sdpfrag obsolete 1317 o Added pseudo m-lines as additional separator in sdpfrag bodies for 1318 Trickle ICE 1320 o Added ABNF for sdp-frag bodies and Trickle-ICE package 1322 Changes from draft-ietf-mmusic-trickle-ice-sip-02 1324 o Removed definition of application/sdpfrag 1326 o Replaced with new type application/trickle-ice-sdpfrag 1328 o RTCP and BUNDLE Consideration enhanced with some examples 1330 o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to 1331 normative reference 1333 o Removed reference to 4566bis 1335 o Addressed review comment from Simon Perreault 1337 14. References 1339 14.1. Normative References 1341 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1342 Holmberg, C., Alvestrand, H., and C. Jennings, 1343 "Negotiating Media Multiplexing Using the Session 1344 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1345 negotiation-23 (work in progress), July 2015. 1347 [I-D.ietf-mmusic-trickle-ice] 1348 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 1349 Incremental Provisioning of Candidates for the Interactive 1350 Connectivity Establishment (ICE) Protocol", draft-ietf- 1351 mmusic-trickle-ice-02 (work in progress), January 2015. 1353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1354 Requirement Levels", BCP 14, RFC 2119, 1355 DOI 10.17487/RFC2119, March 1997, 1356 . 1358 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1359 A., Peterson, J., Sparks, R., Handley, M., and E. 1360 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1361 DOI 10.17487/RFC3261, June 2002, 1362 . 1364 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1365 Provisional Responses in Session Initiation Protocol 1366 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1367 . 1369 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1370 with Session Description Protocol (SDP)", RFC 3264, 1371 DOI 10.17487/RFC3264, June 2002, 1372 . 1374 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1375 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1376 July 2006, . 1378 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1379 Specifications: ABNF", STD 68, RFC 5234, 1380 DOI 10.17487/RFC5234, January 2008, 1381 . 1383 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1384 (ICE): A Protocol for Network Address Translator (NAT) 1385 Traversal for Offer/Answer Protocols", RFC 5245, 1386 DOI 10.17487/RFC5245, April 2010, 1387 . 1389 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1390 Control Packets on a Single Port", RFC 5761, 1391 DOI 10.17487/RFC5761, April 2010, 1392 . 1394 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1395 Protocol (SDP) Grouping Framework", RFC 5888, 1396 DOI 10.17487/RFC5888, June 2010, 1397 . 1399 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1400 Initiation Protocol (SIP) INFO Method and Package 1401 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1402 . 1404 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1405 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1406 . 1408 14.2. Informative References 1410 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1411 "Indicating User Agent Capabilities in the Session 1412 Initiation Protocol (SIP)", RFC 3840, 1413 DOI 10.17487/RFC3840, August 2004, 1414 . 1416 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1417 Agent URIs (GRUUs) in the Session Initiation Protocol 1418 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 1419 . 1421 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1422 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1423 March 2011, . 1425 [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: 1426 Combined Use of the Session Initiation Protocol (SIP) and 1427 the Extensible Messaging and Presence Protocol (XMPP)", 1428 RFC 7081, DOI 10.17487/RFC7081, November 2013, 1429 . 1431 Authors' Addresses 1433 Emil Ivov 1434 Jitsi 1435 Strasbourg 67000 1436 France 1438 Phone: +33 6 72 81 15 55 1439 Email: emcho@jitsi.org 1441 Thomas Stach 1442 Unaffiliated 1443 Vienna 1130 1444 Austria 1446 Email: thomass.stach@gmail.com 1448 Enrico Marocco 1449 Telecom Italia 1450 Via G. Reiss Romoli, 274 1451 Turin 10148 1452 Italy 1454 Email: enrico.marocco@telecomitalia.it 1456 Christer Holmberg 1457 Ericsson 1458 Hirsalantie 11 1459 Jorvas 02420 1460 Finland 1462 Email: christer.holmberg@ericsson.com