idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-04.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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == 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 (May 17, 2016) is 2899 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 1295, but not defined == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-08 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-mux-exclusive-04 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-29 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-12 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 8 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: November 18, 2016 Unaffiliated 6 E. Marocco 7 Telecom Italia 8 C. Holmberg 9 Ericsson 10 May 17, 2016 12 A Session Initiation Protocol (SIP) usage for Trickle ICE 13 draft-ietf-mmusic-trickle-ice-sip-04 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 November 18, 2016. 46 Copyright Notice 48 Copyright (c) 2016 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. Fall-back 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' . . . . . . . 26 86 8.1. Overall Description . . . . . . . . . . . . . . . . . . . 26 87 8.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 9. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 28 89 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 28 90 9.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 28 91 9.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 28 92 9.4. Info Package Parameters . . . . . . . . . . . . . . . . . 28 93 9.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 28 94 9.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 29 95 9.7. Info Package Usage Restrictions . . . . . . . . . . . . . 29 96 9.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 29 97 9.9. Info Package Security Considerations . . . . . . . . . . 29 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 99 10.1. application/trickle-ice-sdpfrag MIME Type . . . . . . . 29 100 10.2. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 31 101 10.3. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 31 102 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 103 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 104 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 106 14.1. Normative References . . . . . . . . . . . . . . . . . . 33 107 14.2. Informative References . . . . . . . . . . . . . . . . . 35 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 110 1. Introduction 112 The Interactive Connectivity Establishment protocol 113 [I-D.ietf-mmusic-rfc5245bis] (a.k.a. Vanilla ICE) describes a 114 mechanism for NAT traversal that consists of three main phases: a 115 phase where an agent gathers a set of candidate transport addresses 116 (source IP address, port and transport protocol), a second phase 117 where these candidates are sent to a remote agent and this gathering 118 procedure is repeated and, finally, a third phase where connectivity 119 between all candidates in both sets is checked (connectivity checks). 120 Once these phases have been completed, and only then, can both agents 121 begin communication. According to the Vanilla ICE specification the 122 three phases above happen consecutively, in a blocking way, which can 123 introduce undesirable 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 149 [I-D.ietf-mmusic-rfc5245bis] and its Trickle ICE extension 150 [I-D.ietf-mmusic-trickle-ice]. It is assumed that the reader will be 151 familiar with the terminology from both of them. 153 3. Protocol Overview 155 The semantics that Vanilla ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp] 156 defines for exchanging ICE candidates are exclusively based on use of 157 Offers and Answers as per [RFC3264] over the Session Description 158 Protocol (SDP) [RFC4566]. This specification extends these mechanism 159 by allowing ICE candidates to also be sent in parallel to the Offer/ 160 Answer negotiation or after the completion of Offer/Answer 161 negotiation. This extension is done through the use of SIP INFO 162 messages and a newly defined Info Package [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 [I-D.ietf-mmusic-ice-sip-sdp] perspective is the traditional way 216 of transporting ICE candidates, introduces the following 217 complications: 219 Need for a non-blocking mechanism: [RFC3264] defines Offer/Answer 220 as a strictly sequential mechanism. There can only be a maximum 221 of one exchange at any point of time. Both sides cannot 222 simultaneously send Offers nor can they generate multiple Offers 223 prior to receiving an Answer. Using UPDATEs for candidate 224 transport would therefore imply the implementation of a candidate 225 pool at every agent where candidates can be stored until it is 226 once again that agent's "turn" to emit an Answer or a new Offer. 227 Such an approach would introduce non-negligible complexity for no 228 additional value. 230 Elevated risk of glare: The sequential nature of Offer/Answer also 231 makes it impossible for both sides to send Offers simultaneously. 232 What's worse is that there are no mechanisms in SIP to actually 233 prevent that. [RFC3261], where the situation of Offers crossing 234 on the wire is described as "glare", only defines a procedure for 235 addressing the issue after it has occurred. According to that 236 procedure both Offers are invalidated and both sides need to retry 237 the negotiation after a period between 0 and 4 seconds. The high 238 likelihood for glare to occur and the average two second back-off 239 intervals would imply Trickle ICE processing duration would not 240 only fail to improve but actually exceed those of Vanilla ICE. 242 INFO messages decouple the exchange of candidates from the Offer/ 243 Answer negotiation and are subject to none of the glare issues 244 described above, which makes them a very convenient and lightweight 245 mechanism for asynchronous delivery of candidates. 247 Using in-dialog INFO messages also provides a way of guaranteeing 248 that candidates are delivered end-to-end, between the same entities 249 that are actually in the process of initiating a session. The 250 alternative would have implied requiring support for Globally 251 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 252 adoption levels, would have constituted too strong of constraint to 253 the adoption of Trickle ICE. 255 3.2. Discovery issues 257 In order to benefit from Trickle ICE's full potential and reduce 258 session establishment latency to a minimum, Trickle ICE agents need 259 to generate SDP Offers and Answers that contain incomplete, 260 potentially empty sets of candidates. Such Offers and Answers can 261 only be handled meaningfully by agents that actually support 262 incremental candidate provisioning, which implies the need to confirm 263 such support before actually using it. 265 Contrary to other protocols, like XMPP [RFC6120], where "in advance" 266 capability discovery is widely implemented, the mechanisms that allow 267 this for SIP (i.e., a combination of UA Capabilities [RFC3840] and 268 GRUU [RFC5627]) have only seen low levels of adoption. This presents 269 an issue for Trickle ICE implementations as SIP UAs do not have an 270 obvious means of verifying that their peer will support incremental 271 candidate provisioning. 273 The Half Trickle mode of operation defined in the Trickle ICE 274 specification [I-D.ietf-mmusic-trickle-ice] provides one way around 275 this, by requiring first Offers to contain a complete set of ICE 276 candidates and only using incremental provisioning for the rest of 277 the sessions. 279 While using Half Trickle does provide a working solution it also 280 comes at the price of increased latency. Section 5 therefore makes 281 several alternative suggestions that enable SIP UAs to engage in Full 282 Trickle right from their first Offer: Section 5.1 discusses the use 283 of on-line provisioning as a means of allowing use of Trickle ICE for 284 all endpoints in controlled environments. Section 5.2 describes 285 anticipatory discovery for implementations that actually do support 286 GRUU and UA Capabilities and Section 5.4 discusses the implementation 287 and use of Half Trickle by SIP UAs where none of the above are an 288 option. 290 3.3. Relationship with the Offer/Answer Model 292 It is important to note that this specification does not require, 293 define, or even assume any mechanisms that would have an impact on 294 the Offer/Answer model beyond the way it is already used by Vanilla 295 ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. From the perspective of 296 all SIP middle boxes and proxies, and with the exception of the 297 actual INFO messages, signalling in general and Offer/Answer 298 exchanges in particular would look the same way for Trickle ICE as 299 they would for Vanilla ICE for SIP. 301 +-------------------------------+ +-------------------------------+ 302 | Alice +--------------+ | | +--------------+ Bob | 303 | | Offer/Answer | | | | Offer/Answer | | 304 | +-------+ | Module | | | | Module | +-------+ | 305 | | ICE | +--------------+ | | +--------------+ | ICE | | 306 | | Agent | | | | | | Agent | | 307 | +-------+ | | | | +-------+ | 308 +-------------------------------+ +-------------------------------+ 309 | | | | 310 | | INVITE (Offer) | | 311 | |--------------------->| | 312 | | 183 (Answer) | | 313 | |<---------------------| | 314 | | | | 315 | | 316 | SIP INFO (more candidates) | 317 |----------------------------------------------------->| 318 | SIP INFO (more candidates) | 319 |<-----------------------------------------------------| 320 | | 321 | STUN Binding Requests/Responses | 322 |----------------------------------------------------->| 323 | STUN Binding Requests/Responses | 324 |<-----------------------------------------------------| 325 | | 326 | | | | 327 | | 5245 SIP re-INVITE | | 328 | |--------------------->| | 329 | | 200 OK | | 330 | |<---------------------| | 332 Figure 2: Distinguishing between Trickle ICE and traditional 333 signalling. 335 It is important to note that, as displayed on Figure 2, exchanging 336 candidates through SIP INFO messages are best represented as 337 signalling between ICE agents and not between the traditional SIP and 338 Offer/Answer modules of SIP User Agents. Such INFO requests do not 339 impact the state of Offer/Answer, nor do they have an impact on the 340 version number in the "o=" line. In that regard they are actually 341 comparable to Peer Reflexive candidates that ICE agents can discover 342 during ICE processing. 344 4. Incremental Signalling of ICE candidates 346 Trickle ICE agents will construct Offers and Answers as specified in 347 [I-D.ietf-mmusic-trickle-ice] with the following additional SIP- 348 specific additions: 350 1. Trickle ICE agents MUST indicate support for Trickle ICE by 351 including the option-tag 'trickle-ice' in a SIP Supported: header 352 field within all SIP INVITE requests and responses. 354 2. Trickle ICE agents MAY exchange additional ICE candidates using 355 INFO requests within an existing invite dialog usage (including 356 an early dialog) as specified in [RFC6086]. The INFO messages 357 carry an Info-Package: trickle-ice. Trickle ICE agents MUST be 358 prepared to receive INFO requests within that same dialog usage, 359 containing additional candidates or an indication for the end of 360 such candidates 362 3. Trickle ICE agents MAY exchange additional ICE candidates before 363 the Answerer has sent the Answer provided that an invite dialog 364 usage is established at both Trickle ICE agents. Note that in 365 case of forking multiple early dialogs will exist. 367 The following section provide further details on how Trickle ICE 368 agents establish the INVITE dialog usage such that they can trickle 369 candidates. 371 4.1. Establishing the dialog 373 In order for SIP UAs to be able to start trickling, the following two 374 conditions need to be satisfied: 376 o Trickle ICE support in the peer agent MUST be confirmed. 378 o The dialog at both sides MUST be in early or confirmed state. 380 Section 5 discusses in detail the various options for satisfying the 381 first of the above conditions. Regardless of those mechanisms 382 however, agents are certain to have a clear understanding of whether 383 their peers support trickle ICE once an Offer and an Answer have been 384 exchanged, which also allows for ICE processing to commence (see 385 Figure 3). 387 4.1.1. Asserting dialog state through reliable Offer/Answer delivery 388 Alice Bob 389 | | 390 | INVITE (Offer) | 391 |------------------------>| 392 | 183 (Answer) | 393 |<------------------------| 394 | PRACK/OK | 395 |------------------------>| 396 | | 397 +----------------------------------------+ 398 |Alice and Bob know that both can trickle| 399 |and know that the dialog is in the early| 400 |state. Send INFO! | 401 +----------------------------------------+ 402 | | 403 | INFO/OK (+SRFLX Cand.) | 404 |------------------------>| 405 | INFO/OK (+SRFLX Cand.) | 406 |<------------------------| 407 | | 409 Figure 3: SIP Offerer can freely trickle as soon as it receives an 410 Answer. 412 Satisfying both conditions is also relatively trivial for ICE agents 413 that have sent an Offer in an INVITE and that have received an Answer 414 in a reliable provisional response. It is guaranteed to have 415 confirmed support for Trickle ICE within the Answerer (or lack 416 thereof) and to have fully initialized the SIP dialog at both ends. 417 Offerers and Answerers in the above situation can therefore freely 418 commence trickling within the newly established dialog. 420 4.1.2. Asserting dialog state through unreliable Offer/Answer delivery 422 The situation is a bit more delicate for agents that have received an 423 Offer in an INVITE request and have sent an Answer in an unreliable 424 provisional response because, once the response has been sent, the 425 Answerer does no know when or if it has been received (Figure 4). 427 Alice Bob 428 | | 429 | INVITE (Offer) | 430 |------------------------>| 431 | 183 (Answer) | 432 |<------------------------| 433 | | 434 | +----------------------+ 435 | |Bob: I don't know if | 436 | |Alice got my 183 or if| 437 | |her dialog is already | 438 | |in the early state. | 439 | | Can I send INFO??? | 440 | +----------------------+ 441 | | 443 Figure 4: A SIP UA that sent an Answer in an unreliable provisional 444 response does not know if it was received and if the dialog at the 445 side of the Offerer has entered the early state 447 In order to clear this ambiguity as soon as possible, the answerer 448 needs to retransmit the provisional response with the exponential 449 back-off timers described in [RFC3262]. Retransmits MUST cease on 450 receipt of a INFO request or on transmission of the answer in a 2xx 451 response. This is similar to the procedure described in section 452 13.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding 453 Request is replaced by the INFO request. 455 The Offerer MUST send a Trickle ICE INFO request as soon as it 456 receives an SDP Answer in an unreliable provisional response. This 457 INFO message MUST repeat the candidates that were already provided in 458 the Offer (as would be the case when Half Trickle is performed or 459 when new candidates have not been learned since then) and/or they MAY 460 also deliver new candidates (if available). An end-of-candidates 461 indication MAY be included in case candidate discovery has ended in 462 the mean time. 464 As soon as an Answerer has received such an INFO request, the 465 Answerer has an indication that a dialog is well established at both 466 ends and MAY begin trickling (Figure 5). Note: The +SRFLX in 467 Figure 5 indicates that additionally newly learned server-reflexive 468 candidates are includes. 470 Alice Bob 471 | | 472 | INVITE (Offer) | 473 |------------------------>| 474 | 183 (Answer) | 475 |<------------------------| 476 | INFO/OK (+SRFLX Cand.) | 477 |------------------------>| 478 | | 479 | +----------------------+ 480 | |Bob: Now I know Alice| 481 | | is ready. Send INFO! | 482 | +----------------------+ 483 | INFO/OK (+SRFLX Cand.) | 484 |<------------------------| 485 | | 486 | 200/ACK (Answer) | 487 |<------------------------| 489 Figure 5: A SIP UA that received an INFO request after sending an 490 unreliable provisional response knows that the dialog at the side of 491 the receiver has entered the early state 493 When sending the Answer in the 200 OK response, the Answerer MUST 494 repeat exactly the same Answer that was previously sent in the 495 unreliable provisional response in order to fulfill the corresponding 496 requirements in [RFC3264]. In other words, that Offerer needs to be 497 prepared to receive fewer candidates in that repeated Answer than 498 previously exchanged via trickling. 500 4.1.3. Initiating Trickle ICE without an SDP Answer 502 The possibility to convey arbitrary candidates in INFO message bodies 503 allows ICE agents to initiate trickling without actually sending an 504 Answer. Trickle ICE Agents MAY therefore respond to INVITEs with 505 provisional responses without an SDP Answer. Such provisional 506 responses serve for establishing an early dialog. 508 Agents that choose to establish the dialog in this way, MUST 509 retransmit these responses with the exponential back-off timers 510 described in [RFC3262]. Retransmits MUST cease on receipt of an INFO 511 request or on transmission of the answer in a 2xx response. This is 512 again similar to the procedure described in section 12.1.1 of 513 [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is not yet 514 provided. 516 Alice Bob 517 | | 518 | INVITE (Offer) | 519 |------------------------>| 520 | 183 (-) | 521 |<------------------------| 522 | INFO/OK (SRFLX Cand.) | 523 |------------------------>| 524 | | 525 | +----------------------+ 526 | |Bob: Now I know again| 527 | | that Alice is ready. | 528 | | Send INFO! | 529 | +----------------------+ 530 | INFO/OK (SRFLX Cand.) | 531 |<------------------------| 532 | 183 (Answer) opt. | 533 |<------------------------| 534 | INFO/OK (SRFLX Cand.) | 535 |<------------------------| 536 | 200/ACK (Answer) | 537 |<------------------------| 539 Figure 6: A SIP UA sends an unreliable provisional response without 540 an Answer for establishing an early dialog 542 When sending the Answer the agent MUST repeat all previously sent 543 candidates, if any, and MAY include all newly gathered candidates 544 since the last INFO request was sent. If that answer was sent in a 545 unreliable provisional response, the Answerers MUST repeat exactly 546 the same Answer in the 200 OK response in order to fulfill the 547 corresponding requirements in [RFC3264]. In other words, an Offerer 548 needs to be prepared to receive fewer candidates in that repeated 549 Answer than previously exchanged via trickling. 551 4.1.4. Considerations for 3PCC 553 Agents that have sent an Offer in a reliable provisional response and 554 that receive an Answer in a PRACK are also in a situation where 555 support for Trickle ICE is confirmed and the SIP dialog is guaranteed 556 to be in a state that would allow in-dialog INFO requests (see 557 Figure 7). 559 Alice Bob 560 | | 561 | INVITE | 562 |------------------------>| 563 | 183 (Offer) | 564 |<------------------------| 565 | PRACK (Answer) | 566 |------------------------>| 567 | | 568 | +----------------------+ 569 | |Bob: I know Alice can| 570 | |trickle and I know her| 571 | |dialog is in the early| 572 | |state. Send INFO! | 573 | +----------------------+ 574 | | 575 | INFO/OK (SRFLX Cand.) | 576 |<------------------------| 577 | | 578 | INFO/OK (SRFLX Cand.) | 579 |------------------------>| 580 | 200 OK/ACK | 581 |<------------------------| 583 Figure 7: A SIP Offerer in a 3PCC scenario can also freely start 584 trickling as soon as it receives an Answer. 586 Trickle Agents that send an Offer in a 200 OK and receive an Answer 587 in an ACK can still create a dialog and confirm support for Trickle 588 ICE by sending an unreliable provisional response similar to 589 Section 4.1.3. According to [RFC3261], this unreliable response MUST 590 NOT contain an Offer. 592 The Trickle Agent (at the UAS) retransmits the provisional response 593 with the exponential back-off timers described in [RFC3262]. 594 Retransmits MUST cease on receipt of a INFO request or on 595 transmission of the answer in a 2xx response. The peer Trickle Agent 596 (at the UAC) MUST send a Trickle ICE INFO request as soon as they 597 receive an unreliable provisional response (see Figure 8). 599 Alice Bob 600 | | 601 | INVITE | 602 |------------------------>| 603 | 183 (-) | 604 |<------------------------| 605 | INFO/OK (SRFLX Cand.) | 606 |------------------------>| 607 | | 608 | +-----------------------+ 609 | |Bob: I know Alice can | 610 | |trickle and I know her | 611 | |dialog is in the early | 612 | |state. | 613 | |INFO can be sent. | 614 | +-----------------------+ 615 | | 616 | INFO/OK (SRFLX Cand.) | 617 |<------------------------| 618 | | 619 | 200 (Offer) | 620 |<------------------------| 621 | ACK (Answer) | 622 |------------------------>| 623 | | 625 Figure 8: A SIP UAC in a 3PCC scenario can also freely start 626 trickling as soon as it receives an unreliable provisional response. 628 4.2. Delivering candidates in INFO messages 630 Whenever new ICE candidates become available for sending, agents 631 would encode them in "a=candidate" lines as described by 632 [I-D.ietf-mmusic-trickle-ice]. For example: 634 a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx 635 raddr 10.0.1.1 rport 8998 637 The use of SIP INFO requests happens within the context of the Info 638 Package as defined Section 9. The MIME type for their payload MUST 639 be set to 'application/trickle-ice-sdpfrag' as defined in Section 8. 641 Since neither the "a=candidate" nor the "a=end-of-candidates" 642 attributes contain information that would allow correlating them to a 643 specific "m=" line, this is handled through the use of pseudo "m=" 644 lines and identification tags in "a=mid:" attributes as defined in 646 [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as 647 defined in [RFC4566], but provide no semantics other than indicating 648 to which "m=" line a candidate belongs. Consequently, the receiving 649 agent MUST ignore the remaining content of the pseudo m-line. This 650 guarantees that the 'application/trickle-ice-sdpfrag' bodies do not 651 interfere with the Offer/Answer procedures as specified in [RFC3264]. 653 When sending the INFO request, the agent MAY, if already known to the 654 agent, include the same content into the pseudo m-line as for the 655 corresponding Offer or Answer. However, since Trickle-ICE might be 656 decoupled from the Offer/Answer negotiation this content might be 657 unknown to the agent. In this case, the agent MUST include the 658 following default values. 660 o The media is set to 'audio'. 662 o The port value is set to '9'. 664 o The proto value is set to 'RTP/AVP'. 666 o The fmt SHOULD appear only once and is set to '0' 668 Agents MUST include a pseudo "m=" line and an identification tag in a 669 "a=mid:" attribute for every "m=" line whose candidate list they 670 intend to update. Such "a=mid:" attributes MUST immediately precede 671 the list of candidates for that specific "m=" line. All 672 "a=candidate" or "a=end-of-candidates" attributes following an 673 "a=mid:" attribute, up until (and excluding) the next occurrence of 674 an "a=mid:" attribute, pertain to the "m=" line identified by that 675 identification tag. An "a=end-of-candidates" attribute, preceding 676 any "a=mid:" attributes, indicates the end of all trickling from that 677 agent, as opposed to end of trickling for a specific "m=" line, which 678 would be indicated by a media level "a=end-of-candidates" attribute. 680 The use of "a=mid:" attributes allows for a structure similar to the 681 one in SDP Offers and Answers where separate media-level and session- 682 level sections can be distinguished. In the current case, lines 683 preceding any "a=mid:" attributes are considered to be session-level. 684 Lines appearing in between or after "a=mid:" attributes will be 685 interpreted as media-level. 687 Note that while this specification uses the "a=mid:" attribute 688 from [RFC5888], it does not define any grouping semantics. 689 Consequently, using the "a=group:" attribute from that same 690 specification is neither needed nor used in Trickle ICE for SIP. 692 All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" 693 attributes that would allow mapping them to a specific ICE 694 generation. INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:" 695 attributes that do not match those of the current ICE processing 696 session MUST be discarded. The "a=ice-pwd:" and "a=ice-ufrag:" 697 attributes MUST appear at the same level as the ones in the Offer/ 698 Answer exchange. In other words, if they were present as session- 699 level attributes there, they will also appear at the beginning of all 700 INFO message payloads, preceding all "a=mid:" attributes. If they 701 were originally exchanged as media level attributes, potentially 702 overriding session-level values, then they will also be included in 703 INFO message payloads, following the corresponding "a=mid:" 704 attribute. 706 In every INFO request agents MUST include all local candidates they 707 have previously signaled. This is necessary in order to more easily 708 avoid problems that would arise from unreliability. Mis-ordering can 709 be detected through the CSeq: header field in the INFO request. 711 When receiving INFO requests carrying any candidates, agents will 712 therefore first identify and discard the SDP lines containing 713 candidates they have already received in previous INFO requests or in 714 the Offer/Answer exchange preceding them. Two candidates are 715 considered to be equal if their IP address port, transport and 716 component ID are the same. After identifying and discarding known 717 candidates, agents will then process the remaining, actually new 718 candidates according to the rules described in 719 [I-D.ietf-mmusic-trickle-ice]. 721 The following example shows the content of one sample candidate 722 delivering INFO request: 724 INFO sip:alice@example.com SIP/2.0 725 ... 726 Info-Package: trickle-ice 727 Content-type: application/sdp 728 Content-Disposition: Info-Package 729 Content-length: ... 731 a=ice-pwd:asd88fgpdd777uzjYhagZg 732 a=ice-ufrag:8hhY 733 m=audio 9 RTP/AVP 0 734 a=mid:1 735 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 736 a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx 737 raddr 10.0.1.1 rport 8998 738 a=end-of-candidates 739 m=audio 9 RTP/AVP 0 740 a=mid:2 741 a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx 742 raddr 10.0.1.1 rport 9000 743 a=end-of-candidates 745 5. Initial discovery of Trickle ICE support 747 SIP User Agents (UAs) that support and intend to use trickle ICE are 748 REQUIRED by [I-D.ietf-mmusic-trickle-ice] to indicate that in their 749 Offers and Answers using the following attribute: "a=ice- 750 options:trickle". This makes discovery fairly straightforward for 751 Answerers or for cases where Offers need to be generated within 752 existing dialogs (i.e., when sending re-INVITE requests). In both 753 scenarios prior SDP would have provided the necessary information. 755 Obviously, prior SDP is not available at the time a first Offer is 756 being constructed and it is therefore impossible for ICE agents to 757 determine support for incremental provisioning that way. The 758 following options are suggested as ways of addressing this issue. 760 5.1. Provisioning support for Trickle ICE 762 In certain situations it may be possible for integrators deploying 763 Trickle ICE to know in advance that some or all endpoints reachable 764 from within the deployment will support Trickle ICE. This is likely 765 to be the case, for example, for WebRTC clients that will always be 766 communicating with other WebRTC clients or known Session Border 767 Controllers (SBC) with support for this specification. 769 While the exact mechanism for allowing such provisioning is out of 770 scope here, this specification encourages trickle ICE implementations 771 to allow the option in the way they find most appropriate. 773 5.2. Trickle ICE discovery with GRUU 775 [RFC3840] provides a way for SIP user agents to query for support of 776 specific capabilities using, among others, OPTIONS requests. GRUU 777 support on the other hand allows SIP requests to be addressed to 778 specific UAs (as opposed to arbitrary instances of an address of 779 record). Combining the two and using the "trickle-ice" option tag 780 defined in Section 9.5 provides SIP UAs with a way of learning the 781 capabilities of specific US instances and then addressing them 782 directly with INVITE requests that require SIP support. 784 Such targeted trickling may happen in different ways. One option 785 would be for a SIP UA to learn the GRUU instance ID of a peer through 786 presence and to then query its capabilities direction with an OPTIONS 787 request. Alternately, it can also just send an OPTIONS request to 788 the AOR it intends to contact and then inspect the returned 789 response(s) for support of both GRUU and Trickle ICE (Figure 9). 791 Alice Bob 792 | | 793 | OPTIONS sip:b1@example.com SIP/2.0 | 794 |-------------------------------------------------->| 795 | | 796 | 200 OK | 797 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 798 | ;audio;video|;trickle-ice;... | 799 |<--------------------------------------------------| 800 | | 801 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 802 |-------------------------------------------------->| 803 | | 804 | 183 (Answer) | 805 |<--------------------------------------------------| 806 | INFO/OK (Trickling) | 807 |<------------------------------------------------->| 808 | | 809 | ... | 810 | | 812 Figure 9: Trickle ICE support discovery with OPTIONS and GRUU 814 Confirming support for Trickle ICE through [RFC3840] gives SIP UAs 815 the options to engage in Full Trickle negotiation (as opposed to the 816 more lengthy Half Trickle) from the very first Offer they send. 818 5.3. Trickle ICE discovery through other protocols 820 Protocols like XMPP [RFC6120] define advanced discovery mechanisms 821 that allow specific features to be queried priory to actually 822 attempting to use them. Solutions like [RFC7081] define ways of 823 using SIP and XMPP together which also provides a way for dual stack 824 SIP+XMPP endpoints to make use of such features and verify Trickle 825 ICE support for a specific SIP endpoint through XMPP. [TODO expand 826 on a specific way to do this or declare as out of scope] 828 5.4. Fall-back to Half Trickle 830 In cases where none of the other mechanisms in this section are 831 acceptable, SIP UAs should use the Half Trickle mode defined in 832 [I-D.ietf-mmusic-trickle-ice]. With Half Trickle, agents initiate 833 sessions the same way they would when using Vanilla ICE for SIP 834 [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually 835 sending an Offer, agents would first gather ICE candidates in a 836 blocking way and then send them all in that Offer. The blocking 837 nature of the process would likely imply that some amount of latency 838 will be accumulated and it is advised that agents try to anticipate 839 it where possible, like for example, when user actions indicate a 840 high likelihood for an imminent call (e.g., activity on a keypad or a 841 phone going off-hook). 843 Using Half Trickle would result in Offers that are compatible with 844 both Vanilla ICE SIP endpoints and legacy [RFC3264] endpoints. 846 STUN/Turn STUN/TURN 847 Servers Alice Bob Servers 848 | | | | 849 |<--------------| | | 850 | | | | 851 | | | | 852 | Candidate | | | 853 | | | | 854 | | | | 855 | Discovery | | | 856 | | | | 857 | | | | 858 |-------------->| INVITE (Offer) | | 859 | |---------------------------->| | 860 | | 183 (Answer) |-------------->| 861 | |<----------------------------| | 862 | | INFO (repeated candidates) | | 863 | |---------------------------->| | 864 | | | | 865 | | INFO (more candidates) | Candidate | 866 | |<----------------------------| | 867 | | Connectivity Checks | | 868 | |<===========================>| Discovery | 869 | | INFO (more candidates) | | 870 | |<----------------------------| | 871 | | Connectivity Checks |<--------------| 872 | |<===========================>| | 873 | | | | 874 | | 200 OK | | 875 | |<----------------------------| | 876 | | | | 877 | | 5245 SIP re-INVITE | | 878 | |---------------------------->| | 879 | | 200 OK | | 880 | |<----------------------------| | 881 | | | | 882 | | | | 883 | |<======= MEDIA FLOWS =======>| | 884 | | | | 886 Figure 10: Example - A typical (Half) Trickle ICE exchange with SIP 888 It is worth reminding that once a single Offer or Answer had been 889 exchanged within a specific dialog, support for Trickle ICE will have 890 been determined. No further use of Half Trickle will therefore be 891 necessary within that same dialog and all subsequent exchanges can 892 use the Full Trickle mode of operation. 894 6. Considerations for RTP and RTCP multiplexing 896 The following consideration describe options for Trickle-ICE in order 897 to give some guidance to implementors on how trickling can be 898 optimized with respect to providing RTCP candidates. 900 Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" 901 attribute for RTP/RTCP multiplexing [RFC5761] is already considered 902 in section 4.2. of [I-D.ietf-mmusic-ice-sip-sdp], respectively, as 903 well in [RFC5761] itself. These considerations are still valid for 904 Trickle ICE, however, trickling provides more flexibility for the 905 sequence of candidate exchange in case of RTCP multiplexing. 907 If the Offerer supports RTP/RTCP multiplexing exclusively as 908 specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that 909 document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" 910 and the "a=rtcp-mux" attributes. 912 While a Half Trickle Offerer would have to send an offer compliant to 913 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for 914 all components, this flexibility allows a Full Trickle Offerer to 915 initially send only RTP candidates (component 1) if it assumes that 916 RTCP multiplexing is supported by the Answerer. A Full Trickle 917 Offerer would need to start gathering and trickling RTCP candidates 918 (component 2) only after having received an indication in the answer 919 that the answerer unexpectedly does not support RTCP multiplexing. 921 A Trickle answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in 922 the application/trickle-ice-sdpfrag body it supports and uses RTP and 923 RTCP multiplexing. Trickle answerer MUST follow the guidance on the 924 usage of the "a=rtcp" attribute as given in 925 [I-D.ietf-mmusic-ice-sip-sdp] and Receipt of this attribute at the 926 Offerer in an INFO request prior to the Answer indicates that the 927 Answerer supports and uses RTP and RTCP multiplexing. The Offerer 928 can use this information e.g. for stopping gathering of RTCP 929 candidates and/or for freeing corresponding resources. 931 This behavior is illustrated by the following example offer that 932 indicates support for RTP and RTCP multiplexing. 934 v=0 935 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 936 s= 937 c=IN IP4 atlanta.example.com 938 t=0 0 939 a=ice-pwd:777uzjYhagZgasd88fgpdd 940 a=ice-ufrag:Yhh8 941 m=audio 10000 RTP/AVP 0 942 a=mid:1 943 a=rtcp-mux 944 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 946 Once the dialog is established as described in section Section 4.1 947 the Answerer sends the following INFO message. 949 INFO sip:alice@example.com SIP/2.0 950 ... 951 Info-Package: trickle-ice 952 Content-type: application/sdp 953 Content-Disposition: Info-Package 954 Content-length: ... 956 a=ice-pwd:asd88fgpdd777uzjYhagZg 957 a=ice-ufrag:8hhY 958 m=audio 9 RTP/AVP 0 959 a=mid:1 960 a=rtcp-mux 961 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 963 This INFO message indicates that the Answerer supports and uses RTP 964 and RTCP multiplexing as well. This allows the Offerer to omit 965 gathering of RTCP candidates or releasing already gathered RTCP 966 candidates. If the INFO message did not contain the a=rtcp-mux 967 attribute, the Offerer would have to gather RTCP candidates unless it 968 wants to wait until receipt of an Answer that eventually confirms 969 support or non-support for RTP and RTCP multiplexing. 971 7. Considerations for Media Multiplexing 973 The following consideration describe options for Trickle-ICE in order 974 to give some guidance to implementors on how trickling can be 975 optimized with respect to providing candidates in case of Media 976 Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed 977 that the reader is familiar with 978 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 980 ICE candidate exchange is already considered in section 11 of 981 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are 982 still valid for Trickle ICE, however, trickling provides more 983 flexibility for the sequence of candidate exchange, especially in 984 Full Trickle mode. 986 Except for bundle-only m-lines, a Half Trickle Offerer would have to 987 send an offer with candidates for all bundled m-lines. The 988 additional flexibility, however, allows a Full Trickle Offerer to 989 initially send only candidates for the m-line with the suggested 990 offerer BUNDLE address. 992 Latest on receipt of the answer, the Offerer will detect if BUNDLE is 993 supported and if the suggested offerer BUNDLE address was selected. 994 In this case the Offerer does need to trickle further candidates for 995 the remaining m-lines in a bundle. However, if BUNDLE is not 996 supported, the Full Trickle Offerer needs to gather and trickle 997 candidates for the remaining m-lines as necessary. If the answerer 998 selects a Offerer BUNDLE address different from suggested Offerer 999 BUNDLE address, the Full Trickle Offerer needs to gather and trickle 1000 candidates for the m-line that carries the selected Offerer BUNDLE 1001 address. 1003 A Trickle answerer MAY include an "a=group: BUNDLE" attribute 1004 [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle- 1005 ice-sdpfrag body if it supports and uses bundling. When doing so, 1006 the Answerer MUST include all identification-tags in the same order 1007 that is used or will be used in the Answer. 1009 Receipt of this attribute at the Offerer in an INFO request prior to 1010 the Answer indicates that the Answerer supports and uses bundling. 1011 The Offerer can use this information e.g. for stopping the gathering 1012 of candidates for the remaining m-lines in a bundle and/or for 1013 freeing corresponding resources. 1015 This behaviour is illustrated by the following example offer that 1016 indicates support for Media Multiplexing. 1018 v=0 1019 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1020 s= 1021 c=IN IP4 atlanta.example.com 1022 t=0 0 1023 a=group:BUNDLE foo bar 1024 a=ice-pwd:777uzjYhagZgasd88fgpdd 1025 a=ice-ufrag:Yhh8 1026 m=audio 10000 RTP/AVP 0 1027 a=mid:foo 1028 a=rtpmap:0 PCMU/8000 1029 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1030 m=video 10002 RTP/AVP 31 1031 a=mid:bar 1032 a=rtpmap:31 H261/90000 1033 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1035 Once the dialog is established as described in section Section 4.1 1036 the Answerer sends the following INFO message. 1038 INFO sip:alice@example.com SIP/2.0 1039 ... 1040 Info-Package: trickle-ice 1041 Content-type: application/sdp 1042 Content-Disposition: Info-Package 1043 Content-length: ... 1045 a=group:BUNDLE foo bar 1046 a=ice-pwd:asd88fgpdd777uzjYhagZg 1047 a=ice-ufrag:8hhY 1048 m=audio 9 RTP/AVP 0 1049 a=mid:1 1050 a=rtcp-mux 1051 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 1052 m=audio 9 RTP/AVP 0 1053 a=mid:bar 1055 This INFO message indicates that the Answerer supports and uses Media 1056 Multiplexing as well. Note, that the second m-line shows the default 1057 values as specified in section Section 4.2, e.g. media set 'audio' 1058 although 'video' was offered. The receiving ICE agents needs to 1059 ignore these default values in the pseudo m-lines. 1061 The INFO message also indicates that the Answerer accepted the 1062 Suggested Bundle Address from the Offerer. This allows the Offerer 1063 to omit gathering of RTP and RTCP candidates for the other m-lines or 1064 releasing already gathered candidates. If the INFO message did not 1065 contain the a=group:BUNDLE attribute, the Offerer would have to 1066 gather RTP and RTCP candidates for the other m-lines unless it wants 1067 to wait until receipt of an Answer that eventually confirms support 1068 or non-support for Media Multiplexing. 1070 Independent of using Full Trickle or Half Trickle mode, the rules 1071 from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offer and 1072 Answerer, when putting attributes in the application/trickle-ice- 1073 sdpfrag body. 1075 8. Content Type 'application/trickle-ice-sdpfrag' 1077 8.1. Overall Description 1079 A application/trickle-ice-sdpfrag body is used by the Trickle-ICE 1080 Info Package. It uses a subset of the possible SDP lines that are 1081 allowed based on the grammar defined in [RFC4566]. A valid body uses 1082 only media descriptions and certain attributes that are needed and/or 1083 useful for trickling candidates. The content adheres to the 1084 following grammar. 1086 Like ordinary SDP 1088 8.2. Grammar 1090 The grammar of an 'application/trickle-ice-sdpfrag' body is based the 1091 following ABNF [RFC5234]. 1093 ; Syntax 1094 trickle-ice-sdpfrag = session-level-fields 1095 pseudo-media-descriptions 1096 session-level-fields = [bundle-group-attribute CRLF] 1097 [ice-lite-attribute CRLF] 1098 ice-pwd-attribute CRLF 1099 ice-ufrag-attribute CRLF 1100 [ice-options-attribute CRLF] 1101 [end-of-candidates-attribute CRLF] 1102 extension-attribute-fields 1103 ; for future extensions 1105 ice-lite-attribute = %s"a=" ice-lite 1106 ice-pwd-attribute = %s"a=" ice-pwd-att 1107 ice-ufrag-attribute = %s"a=" ice-ufrag-att 1108 ice-options-attribute = %s"a=" ice-options 1109 bundle-group-attribute = "a=group:" bundle-semantics 1110 *(SP identification-tag) 1111 bundle-semantics = "BUNDLE" 1112 end-of-candidates-attribute = %s"a=" end-of-candidates-att 1113 extension-attribute-fields = attribute-fields 1115 pseudo-media-descriptions = *( media-field 1116 trickle-ice-attribute-fields 1117 [extension-attribute-fields] ) 1118 ; for future extensions 1119 trickle-ice-attribute-fields = mid-attribute CRLF 1120 ["a=rtcp-mux" CRLF] 1121 ["a=rtcp-mux-only" CRLF] 1122 *(candidate-attributes CRLF) 1123 [remote-candidate-attribute CRLF] 1124 [end-of-candidates-attribute CRLF] 1125 remote-candidate-attribute = %s"a=" remote-candidate-att 1126 candidate-attributes = %s"a=" candidate-attribute 1128 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- 1129 options, candidate-attribute remote-candidate-att from 1130 [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute ; 1131 from [RFC5888], media-field, attribute-fields from [RFC4566] and end- 1132 of-candidates-att from [I-D.ietf-mmusic-trickle-ice]. The indicator 1133 for case-sensitivity %s is defined in [RFC7405]. 1135 [NOTE: end-of-candidates-att currently lacks a formal definition in 1136 [I-D.ietf-mmusic-trickle-ice]] 1138 9. Info Package 1140 9.1. Overall Description 1142 This specification defines an Info Package for use by SIP user agents 1143 implementing Trickle ICE. INFO requests carry ICE candidates 1144 discovered after the peer user agents have confirmed mutual support 1145 for Trickle ICE. 1147 9.2. Applicability 1149 The purpose of the ICE protocol is to establish a media path in the 1150 presence of NAT and firewalls. The candidates are transported in 1151 INFO requests and are part of this establishment. 1153 Candidates sent by a Trickle ICE agent after the Offer, follow the 1154 same signalling path and reach the same entity as the Offer itself. 1155 While it is true that GRUUs can be used to achieve this, one of the 1156 goals of this specification is to allow operation of Trickle ICE in 1157 as many environments as possible including those without GRUU 1158 support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not 1159 satisfy this goal. 1161 9.3. Info Package Name 1163 This document defines a SIP Info Package as per [RFC6086]. The Info 1164 Package token name for this package is "trickle-ice" 1166 9.4. Info Package Parameters 1168 This document does not define any Info Package parameters. 1170 9.5. SIP Option Tags 1172 [RFC6086] allows Info Package specifications to define SIP option- 1173 tags. This specification extends the option-tag construct of the SIP 1174 grammar as follows: 1176 option-tag /= "trickle-ice" 1178 SIP entities that support this specification MUST place the 'trickle- 1179 ice' option-tag in a SIP Supported: header field within all SIP 1180 INVITE requests and responses. 1182 When responding to, or generating a SIP OPTIONS request a SIP entity 1183 MUST also include the 'trickle-ice' option-tag in a SIP Supported: 1184 header field. 1186 9.6. Info Message Body Parts 1188 Entities implementing this specification MUST include a payload of 1189 type 'application/trickle-ice-sdpfrag' as defined in Section 8.2 all 1190 SIP INFO requests. The payload is used to convey SDP encoded ICE 1191 candidates. 1193 9.7. Info Package Usage Restrictions 1195 This document does not define any Info Package Usage Restrictions. 1197 9.8. Rate of INFO Requests 1199 A Trickle ICE Agent with many network interfaces might create a high 1200 rate of INFO requests if every newly detected candidate is trickled 1201 individually without aggregation. Implementor that are concerned 1202 about loss of packets in such a case might consider aggregating ICE 1203 candidates and sending INFOS only at some configurable intervals. 1205 9.9. Info Package Security Considerations 1207 See section Section 11 1209 10. IANA Considerations 1211 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1212 document.] 1214 10.1. application/trickle-ice-sdpfrag MIME Type 1216 Type name: application 1218 Subtype name: trickle-ice-sdpfrag 1220 Required parameters: None. 1222 Optional parameters: None. 1224 Encoding considerations: 1226 SDP files are primarily UTF-8 format text. Although the 1227 initially defined content of a trickle-ice-sdpfrag body does 1228 only include ASCII characters, UTF-8 encoded content might be 1229 introduced via extension attributes. The "a=charset:" 1230 attribute may be used to signal the presence of other character 1231 sets in certain parts of a trickle-ice-sdpfrag body (see 1233 [RFC4566]). Arbitrary binary content cannot be directly 1234 represented in SDP or a trickle-ice-sdpfrag body. 1236 Security considerations: 1238 See [RFC4566]) and RFCXXXX 1240 Interoperability considerations: 1242 See RFCXXXX 1244 Published specification: 1246 See RFCXXXX 1248 Applications which use this media type: 1250 Voice over IP, video teleconferencing, streaming media, instant 1251 messaging, Trickle-ICE among others. 1253 Additional information: 1255 Magic number(s): none 1257 File extension(s): none 1259 Macintosh File Type Code(s): none 1261 Person and email address to contact for further information: 1263 IETF MMUSIC working group mmusic@ietf.org 1265 Intended usage: 1267 Trickle-ICE for SIP as specified in RFCXXXX. 1269 Author/Change controller: 1271 IETF MMUSIC working group mmusic@ietf.org 1273 10.2. SIP Info Package 'trickle-ice' 1275 This document defines a new SIP Info Package named 'trickle-ice' and 1276 updates the Info Packages Registry with the following entry. 1278 +-------------+-----------+ 1279 | Name | Reference | 1280 +-------------+-----------+ 1281 | trickle-ice | [RFCXXXX] | 1282 | | | 1283 +-------------+-----------+ 1285 10.3. SIP Option Tag 'trickle-ice' 1287 This specification registers a new SIP option tag 'trickle-ice' as 1288 per the guidelines in Section 27.1 of [RFC3261] and updates the 1289 "Option Tags" section of the SIP Parameter Registry with the 1290 following entry: 1292 +-------------+---------------------------------------+-----------+ 1293 | Name | Description | Reference | 1294 +-------------+---------------------------------------+-----------+ 1295 | trickle-ice | This option tag is used to indicate | [RFCXXXX] | 1296 | | that a UA supports and understands | | 1297 | | Trickle-ICE. | | 1298 +-------------+---------------------------------------+-----------+ 1300 11. Security Considerations 1302 The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], 1303 [RFC6086], [I-D.ietf-mmusic-trickle-ice] apply. This document 1304 clarifies how the above specifications are used together for 1305 trickling candidates and does not create addtitional security risks. 1307 12. Acknowledgements 1309 The authors would like to thank Ayush Jain, Paul Kyzivat, Jonathan 1310 Lennox, Simon Perreault and Martin Thomson for reviewing and/or 1311 making various suggestions for improvements and optimizations. 1313 13. Change Log 1315 [RFC EDITOR NOTE: Please remove this section when publishing]. 1317 Changes from draft-ietf-mmusic-trickle-ice-sip-01 1319 o Editorial Clean up 1321 o IANA Consideration added 1323 o Security Consideration added 1325 o RTCP and BUNDLE Consideration added with rules for including 1326 "a=rtcp-mux" and "a=group: BUNDLLE" attributes 1328 o 3PCC Consideration added 1330 o Clarified that 18x w/o answer is sufficient to create a dialog 1331 that allows for trickling to start 1333 o Added remaining Info Package definition sections as outlined in 1334 section 10 of [RFC6086] 1336 o Added definition of application/sdpfrag making draft-ivov-mmusic- 1337 sdpfrag obsolete 1339 o Added pseudo m-lines as additional separator in sdpfrag bodies for 1340 Trickle ICE 1342 o Added ABNF for sdp-frag bodies and Trickle-ICE package 1344 Changes from draft-ietf-mmusic-trickle-ice-sip-02 1346 o Removed definition of application/sdpfrag 1348 o Replaced with new type application/trickle-ice-sdpfrag 1350 o RTCP and BUNDLE Consideration enhanced with some examples 1352 o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to 1353 normative reference 1355 o Removed reference to 4566bis 1357 o Addressed review comment from Simon Perreault 1359 Changes from draft-ietf-mmusic-trickle-ice-sip-03 1361 o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis 1362 and draft-ietf-mmusic-ice-sip-sdp 1364 o Corrected Figure 10, credits to Ayush Jain for finding the bug 1366 o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- 1367 ice-sip-sdp 1369 o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- 1370 mux-exclusive, enahnced ABNF to support a=rtcp-mux-exclusive 1372 o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for 1373 the application/trickle-ice-sdpfrag body 1375 14. References 1377 14.1. Normative References 1379 [I-D.ietf-mmusic-ice-sip-sdp] 1380 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using 1381 Interactive Connectivity Establishment (ICE) with Session 1382 Description Protocol (SDP) offer/answer and Session 1383 Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- 1384 sdp-08 (work in progress), March 2016. 1386 [I-D.ietf-mmusic-mux-exclusive] 1387 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 1388 Multiplexing using SDP", draft-ietf-mmusic-mux- 1389 exclusive-04 (work in progress), April 2016. 1391 [I-D.ietf-mmusic-rfc5245bis] 1392 Keranen, A. and J. Rosenberg, "Interactive Connectivity 1393 Establishment (ICE): A Protocol for Network Address 1394 Translator (NAT) Traversal", draft-ietf-mmusic- 1395 rfc5245bis-05 (work in progress), September 2015. 1397 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1398 Holmberg, C., Alvestrand, H., and C. Jennings, 1399 "Negotiating Media Multiplexing Using the Session 1400 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1401 negotiation-29 (work in progress), April 2016. 1403 [I-D.ietf-mmusic-sdp-mux-attributes] 1404 Nandakumar, S., "A Framework for SDP Attributes when 1405 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 1406 (work in progress), January 2016. 1408 [I-D.ietf-mmusic-trickle-ice] 1409 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 1410 Incremental Provisioning of Candidates for the Interactive 1411 Connectivity Establishment (ICE) Protocol", draft-ietf- 1412 mmusic-trickle-ice-02 (work in progress), January 2015. 1414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1415 Requirement Levels", BCP 14, RFC 2119, 1416 DOI 10.17487/RFC2119, March 1997, 1417 . 1419 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1420 A., Peterson, J., Sparks, R., Handley, M., and E. 1421 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1422 DOI 10.17487/RFC3261, June 2002, 1423 . 1425 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1426 Provisional Responses in Session Initiation Protocol 1427 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1428 . 1430 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1431 with Session Description Protocol (SDP)", RFC 3264, 1432 DOI 10.17487/RFC3264, June 2002, 1433 . 1435 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1436 in Session Description Protocol (SDP)", RFC 3605, 1437 DOI 10.17487/RFC3605, October 2003, 1438 . 1440 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1441 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1442 July 2006, . 1444 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1445 Specifications: ABNF", STD 68, RFC 5234, 1446 DOI 10.17487/RFC5234, January 2008, 1447 . 1449 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1450 Control Packets on a Single Port", RFC 5761, 1451 DOI 10.17487/RFC5761, April 2010, 1452 . 1454 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1455 Protocol (SDP) Grouping Framework", RFC 5888, 1456 DOI 10.17487/RFC5888, June 2010, 1457 . 1459 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1460 Initiation Protocol (SIP) INFO Method and Package 1461 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1462 . 1464 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1465 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1466 . 1468 14.2. Informative References 1470 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1471 "Indicating User Agent Capabilities in the Session 1472 Initiation Protocol (SIP)", RFC 3840, 1473 DOI 10.17487/RFC3840, August 2004, 1474 . 1476 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1477 Agent URIs (GRUUs) in the Session Initiation Protocol 1478 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 1479 . 1481 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1482 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1483 March 2011, . 1485 [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: 1486 Combined Use of the Session Initiation Protocol (SIP) and 1487 the Extensible Messaging and Presence Protocol (XMPP)", 1488 RFC 7081, DOI 10.17487/RFC7081, November 2013, 1489 . 1491 Authors' Addresses 1492 Emil Ivov 1493 Jitsi 1494 Strasbourg 67000 1495 France 1497 Phone: +33 6 72 81 15 55 1498 Email: emcho@jitsi.org 1500 Thomas Stach 1501 Unaffiliated 1502 Vienna 1130 1503 Austria 1505 Email: thomass.stach@gmail.com 1507 Enrico Marocco 1508 Telecom Italia 1509 Via G. Reiss Romoli, 274 1510 Turin 10148 1511 Italy 1513 Email: enrico.marocco@telecomitalia.it 1515 Christer Holmberg 1516 Ericsson 1517 Hirsalantie 11 1518 Jorvas 02420 1519 Finland 1521 Email: christer.holmberg@ericsson.com