idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-05.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 (August 9, 2016) is 2816 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 1354, but not defined == Unused Reference: 'RFC7405' is defined on line 1535, but no explicit reference was found in the text == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-10 == Outdated reference: A later version (-21) exists of draft-ietf-ice-trickle-03 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-mux-exclusive-10 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-31 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-13 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 10 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: February 10, 2017 Unaffiliated 6 E. Marocco 7 Telecom Italia 8 C. Holmberg 9 Ericsson 10 August 9, 2016 12 A Session Initiation Protocol (SIP) usage for Trickle ICE 13 draft-ietf-mmusic-trickle-ice-sip-05 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 February 10, 2017. 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 Signaling 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. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 26 86 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 26 87 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 26 88 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 28 90 10.1. Overall Description . . . . . . . . . . . . . . . . . . 28 91 10.2. Applicability . . . . . . . . . . . . . . . . . . . . . 28 92 10.3. Info Package Name . . . . . . . . . . . . . . . . . . . 28 93 10.4. Info Package Parameters . . . . . . . . . . . . . . . . 28 94 10.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 28 95 10.6. Info Message Body Parts . . . . . . . . . . . . . . . . 29 96 10.7. Info Package Usage Restrictions . . . . . . . . . . . . 29 97 10.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . 29 98 10.9. Info Package Security Considerations . . . . . . . . . . 29 99 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 100 11.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 29 101 11.2. application/trickle-ice-sdpfrag MIME Type . . . . . . . 30 102 11.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 32 103 11.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 32 104 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 105 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 106 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 33 107 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 108 15.1. Normative References . . . . . . . . . . . . . . . . . . 34 109 15.2. Informative References . . . . . . . . . . . . . . . . . 36 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 112 1. Introduction 114 The Interactive Connectivity Establishment protocol 115 [I-D.ietf-mmusic-rfc5245bis] (a.k.a. Vanilla ICE) describes a 116 mechanism for NAT traversal that consists of three main phases: a 117 phase where an agent gathers a set of candidate transport addresses 118 (source IP address, port and transport protocol), a second phase 119 where these candidates are sent to a remote agent and this gathering 120 procedure is repeated and, finally, a third phase where connectivity 121 between all candidates in both sets is checked (connectivity checks). 122 Once these phases have been completed, and only then, can both agents 123 begin communication. According to the Vanilla ICE specification the 124 three phases above happen consecutively, in a blocking way, which can 125 introduce undesirable latency during session establishment. 127 The Trickle ICE extension defined in [I-D.ietf-ice-trickle] defines 128 generic semantics required for these ICE phases to happen 129 simultaneously, in a non-blocking way and hence speed up session 130 establishment. 132 This specification defines a usage of Trickle ICE with the Session 133 Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates 134 are to be incrementally exchanged with SIP INFO requests and how the 135 Half Trickle and Full Trickle modes defined in [I-D.ietf-ice-trickle] 136 are to be used by SIP User Agents (UAs) depending on their 137 expectations for support of Trickle ICE by a remote agent. 139 This document defines a new Info Package as specified in [RFC6086] 140 for use with Trickle ICE. 142 2. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 This specification makes use of all terminology defined by the 149 protocol for Interactive Connectivity Establishment in 150 [I-D.ietf-mmusic-rfc5245bis] and its Trickle ICE extension 151 [I-D.ietf-ice-trickle]. It is assumed that the reader will be 152 familiar with the terminology from both of them. 154 3. Protocol Overview 156 The semantics that Vanilla ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp] 157 defines for exchanging ICE candidates are exclusively based on use of 158 Offers and Answers as per [RFC3264] over the Session Description 159 Protocol (SDP) [RFC4566]. This specification extends these mechanism 160 by allowing ICE candidates to also be sent in parallel to the Offer/ 161 Answer negotiation or after the completion of Offer/Answer 162 negotiation. This extension is done through the use of SIP INFO 163 messages and a newly defined Info Package [RFC6086]. 165 Typically, in cases where Trickle ICE is fully supported, a candidate 166 exchange would happen along the following lines: The Offerer would 167 send an INVITE containing a subset of candidates and then wait for an 168 early dialog to be established. Once that happens, it will be able 169 to continue sending candidates through in INFO requests and within 170 the same dialog. 172 Similarly, an Answerer can start or continue "trickling" ICE 173 candidates using INFO messages within the dialog established by its 174 18x provisional response. Figure 1 shows such a sample exchange: 176 STUN/Turn STUN/TURN 177 Servers Alice Bob Servers 178 | | | | 179 | STUN Bi.Req. | INVITE (Offer) | | 180 |<--------------|------------------------>| | 181 | | 183 (Answer) | TURN Alloc Req | 182 | STUN Bi.Resp. |<------------------------|--------------->| 183 |-------------->| INFO/OK (SRFLX Cand.) | | 184 | |------------------------>| TURN Alloc Resp| 185 | | INFO/OK (Relay Cand.) |<---------------| 186 | |<------------------------| | 187 | | | | 188 | | More Cands & ConnChecks| | 189 | |<=======================>| | 190 | | | | 191 | | 200 OK | | 192 | |<------------------------| | 193 | | ACK | | 194 | |------------------------>| | 195 | | | | 196 | | 5245 SIP re-INVITE | | 197 | |------------------------>| | 198 | | 200 OK | | 199 | |<------------------------| | 200 | | ACK | | 201 | |------------------------>| | 202 | | | | 203 | |<===== MEDIA FLOWS =====>| | 204 | | | | 206 Figure 1: Sample Trickle ICE scenario with SIP 208 3.1. Rationale - Why INFO? 210 The decision to use SIP INFO requests as a candidate transport method 211 is based primarily on their lightweight nature. Once a dialog has 212 been established, INFO messages can be exchanged both ways with no 213 restrictions on timing and frequency and no risk of collision. 215 On the other hand, using Offer/Answer and UPDATE requests, which from 216 an [I-D.ietf-mmusic-ice-sip-sdp] perspective is the traditional way 217 of transporting ICE candidates, introduces the following 218 complications: 220 Need for a non-blocking mechanism: [RFC3264] defines Offer/Answer 221 as a strictly sequential mechanism. There can only be a maximum 222 of one exchange at any point of time. Both sides cannot 223 simultaneously send Offers nor can they generate multiple Offers 224 prior to receiving an Answer. Using UPDATEs for candidate 225 transport would therefore imply the implementation of a candidate 226 pool at every agent where candidates can be stored until it is 227 once again that agent's "turn" to emit an Answer or a new Offer. 228 Such an approach would introduce non-negligible complexity for no 229 additional value. 231 Elevated risk of glare: The sequential nature of Offer/Answer also 232 makes it impossible for both sides to send Offers simultaneously. 233 What's worse is that there are no mechanisms in SIP to actually 234 prevent that. [RFC3261], where the situation of Offers crossing 235 on the wire is described as "glare", only defines a procedure for 236 addressing the issue after it has occurred. According to that 237 procedure both Offers are invalidated and both sides need to retry 238 the negotiation after a period between 0 and 4 seconds. The high 239 likelihood for glare to occur and the average two second back-off 240 intervals would imply Trickle ICE processing duration would not 241 only fail to improve but actually exceed those of Vanilla ICE. 243 INFO messages decouple the exchange of candidates from the Offer/ 244 Answer negotiation and are subject to none of the glare issues 245 described above, which makes them a very convenient and lightweight 246 mechanism for asynchronous delivery of candidates. 248 Using in-dialog INFO messages also provides a way of guaranteeing 249 that candidates are delivered end-to-end, between the same entities 250 that are actually in the process of initiating a session. The 251 alternative would have implied requiring support for Globally 252 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 253 adoption levels, would have constituted too strong of constraint to 254 the adoption of Trickle ICE. 256 3.2. Discovery issues 258 In order to benefit from Trickle ICE's full potential and reduce 259 session establishment latency to a minimum, Trickle ICE agents need 260 to generate SDP Offers and Answers that contain incomplete, 261 potentially empty sets of candidates. Such Offers and Answers can 262 only be handled meaningfully by agents that actually support 263 incremental candidate provisioning, which implies the need to confirm 264 such support before actually using it. 266 Contrary to other protocols, like XMPP [RFC6120], where "in advance" 267 capability discovery is widely implemented, the mechanisms that allow 268 this for SIP (i.e., a combination of UA Capabilities [RFC3840] and 269 GRUU [RFC5627]) have only seen low levels of adoption. This presents 270 an issue for Trickle ICE implementations as SIP UAs do not have an 271 obvious means of verifying that their peer will support incremental 272 candidate provisioning. 274 The Half Trickle mode of operation defined in the Trickle ICE 275 specification [I-D.ietf-ice-trickle] provides one way around this, by 276 requiring first Offers to contain a complete set of ICE candidates 277 and only using incremental provisioning for the rest of 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, signaling in general and Offer/Answer exchanges 298 in particular would look the same way for Trickle ICE as they would 299 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 signaling. 335 It is important to note that, as displayed on Figure 2, exchanging 336 candidates through SIP INFO messages are best represented as 337 signaling between ICE agents and not between the traditional SIP and 338 Offer/Answer modules of SIP User Agents. Then, such INFO requests do 339 not impact the state of the Offer/Answer transaction other than 340 providing additional candidates. Consequently, if a new offer is to 341 be send at some point in time it would include the candidates of the 342 previous offer and the candidates that were trickled in the meantime. 343 The version number in the "o=" line of that new offer would need to 344 be incremented by 1 per the rules in [RFC3264]. 346 4. Incremental Signaling of ICE candidates 348 Trickle ICE agents will construct Offers and Answers as specified in 349 [I-D.ietf-ice-trickle] with the following additional SIP-specific 350 additions: 352 1. Trickle ICE agents MUST indicate support for Trickle ICE by 353 including the option-tag 'trickle-ice' in a SIP Supported: header 354 field within all SIP INVITE requests and responses. 356 2. Trickle ICE agents MAY exchange additional ICE candidates using 357 INFO requests within an existing INVITE dialog usage (including 358 an early dialog) as specified in [RFC6086]. The INFO messages 359 carry an Info-Package: trickle-ice. Trickle ICE agents MUST be 360 prepared to receive INFO requests within that same dialog usage, 361 containing additional candidates or an indication for the end of 362 such candidates 364 3. Trickle ICE agents MAY exchange additional ICE candidates before 365 the Answerer has sent the Answer provided that an invite dialog 366 usage is established at both Trickle ICE agents. Note that in 367 case of forking multiple early dialogs will exist. 369 The following section provide further details on how Trickle ICE 370 agents establish the INVITE dialog usage such that they can trickle 371 candidates. 373 4.1. Establishing the dialog 375 In order for SIP UAs to be able to start trickling, the following two 376 conditions need to be satisfied: 378 o Trickle ICE support in the peer agent MUST be confirmed. 380 o The dialog at both sides MUST be in early or confirmed state. 382 Section 5 discusses in detail the various options for satisfying the 383 first of the above conditions. Regardless of those mechanisms 384 however, agents are certain to have a clear understanding of whether 385 their peers support trickle ICE once an Offer and an Answer have been 386 exchanged, which also allows for ICE processing to commence (see 387 Figure 3). 389 4.1.1. Asserting dialog state through reliable Offer/Answer delivery 390 Alice Bob 391 | | 392 | INVITE (Offer) | 393 |------------------------>| 394 | 183 (Answer) | 395 |<------------------------| 396 | PRACK/OK | 397 |------------------------>| 398 | | 399 +----------------------------------------+ 400 |Alice and Bob know that both can trickle| 401 |and know that the dialog is in the early| 402 |state. Send INFO! | 403 +----------------------------------------+ 404 | | 405 | INFO/OK (+SRFLX Cand.) | 406 |------------------------>| 407 | INFO/OK (+SRFLX Cand.) | 408 |<------------------------| 409 | | 411 Figure 3: SIP Offerer can freely trickle as soon as it receives an 412 Answer. 414 Satisfying both conditions is also relatively trivial for ICE agents 415 that have sent an Offer in an INVITE and that have received an Answer 416 in a reliable provisional response. It is guaranteed to have 417 confirmed support for Trickle ICE within the Answerer (or lack 418 thereof) and to have fully initialized the SIP dialog at both ends. 419 Offerers and Answerers in the above situation can therefore freely 420 commence trickling within the newly established dialog. 422 4.1.2. Asserting dialog state through unreliable Offer/Answer delivery 424 The situation is a bit more delicate for agents that have received an 425 Offer in an INVITE request and have sent an Answer in an unreliable 426 provisional response because, once the response has been sent, the 427 Answerer does no know when or if it has been received (Figure 4). 429 Alice Bob 430 | | 431 | INVITE (Offer) | 432 |------------------------>| 433 | 183 (Answer) | 434 |<------------------------| 435 | | 436 | +----------------------+ 437 | |Bob: I don't know if | 438 | |Alice got my 183 or if| 439 | |her dialog is already | 440 | |in the early state. | 441 | | Can I send INFO??? | 442 | +----------------------+ 443 | | 445 Figure 4: A SIP UA that sent an Answer in an unreliable provisional 446 response does not know if it was received and if the dialog at the 447 side of the Offerer has entered the early state 449 In order to clear this ambiguity as soon as possible, the answerer 450 needs to retransmit the provisional response with the exponential 451 back-off timers described in [RFC3262]. Retransmits MUST cease on 452 receipt of a INFO request or on transmission of the answer in a 2xx 453 response. This is similar to the procedure described in section 454 13.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding 455 Request is replaced by the INFO request. 457 The Offerer MUST send a Trickle ICE INFO request as soon as it 458 receives an SDP Answer in an unreliable provisional response. This 459 INFO message MUST repeat the candidates that were already provided in 460 the Offer (as would be the case when Half Trickle is performed or 461 when new candidates have not been learned since then) and/or they MAY 462 also deliver new candidates (if available). An end-of-candidates 463 indication MAY be included in case candidate discovery has ended in 464 the mean time. 466 As soon as an Answerer has received such an INFO request, the 467 Answerer has an indication that a dialog is well established at both 468 ends and MAY begin trickling (Figure 5). Note: The +SRFLX in 469 Figure 5 indicates that additionally newly learned server-reflexive 470 candidates are includes. 472 Alice Bob 473 | | 474 | INVITE (Offer) | 475 |------------------------>| 476 | 183 (Answer) | 477 |<------------------------| 478 | INFO/OK (+SRFLX Cand.) | 479 |------------------------>| 480 | | 481 | +----------------------+ 482 | |Bob: Now I know Alice| 483 | | is ready. Send INFO! | 484 | +----------------------+ 485 | INFO/OK (+SRFLX Cand.) | 486 |<------------------------| 487 | | 488 | 200/ACK (Answer) | 489 |<------------------------| 491 Figure 5: A SIP UA that received an INFO request after sending an 492 unreliable provisional response knows that the dialog at the side of 493 the receiver has entered the early state 495 When sending the Answer in the 200 OK response, the Answerer MUST 496 repeat exactly the same Answer that was previously sent in the 497 unreliable provisional response in order to fulfill the corresponding 498 requirements in [RFC3264]. In other words, that Offerer needs to be 499 prepared to receive fewer candidates in that repeated Answer than 500 previously exchanged via trickling. 502 4.1.3. Initiating Trickle ICE without an SDP Answer 504 The possibility to convey arbitrary candidates in INFO message bodies 505 allows ICE agents to initiate trickling without actually sending an 506 Answer. Trickle ICE Agents MAY therefore respond to INVITEs with 507 provisional responses without an SDP Answer. Such provisional 508 responses serve for establishing an early dialog. 510 Agents that choose to establish the dialog in this way, MUST 511 retransmit these responses with the exponential back-off timers 512 described in [RFC3262]. Retransmits MUST cease on receipt of an INFO 513 request or on transmission of the answer in a 2xx response. This is 514 again similar to the procedure described in section 12.1.1 of 515 [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is not yet 516 provided. 518 Alice Bob 519 | | 520 | INVITE (Offer) | 521 |------------------------>| 522 | 183 (-) | 523 |<------------------------| 524 | INFO/OK (SRFLX Cand.) | 525 |------------------------>| 526 | | 527 | +----------------------+ 528 | |Bob: Now I know again| 529 | | that Alice is ready. | 530 | | Send INFO! | 531 | +----------------------+ 532 | INFO/OK (SRFLX Cand.) | 533 |<------------------------| 534 | 183 (Answer) opt. | 535 |<------------------------| 536 | INFO/OK (SRFLX Cand.) | 537 |<------------------------| 538 | 200/ACK (Answer) | 539 |<------------------------| 541 Figure 6: A SIP UA sends an unreliable provisional response without 542 an Answer for establishing an early dialog 544 When sending the Answer the agent MUST repeat all previously sent 545 candidates, if any, and MAY include all newly gathered candidates 546 since the last INFO request was sent. If that answer was sent in a 547 unreliable provisional response, the Answerers MUST repeat exactly 548 the same Answer in the 200 OK response in order to fulfill the 549 corresponding requirements in [RFC3264]. In other words, an Offerer 550 needs to be prepared to receive fewer candidates in that repeated 551 Answer than previously exchanged via trickling. 553 4.1.4. Considerations for 3PCC 555 Agents that have sent an Offer in a reliable provisional response and 556 that receive an Answer in a PRACK are also in a situation where 557 support for Trickle ICE is confirmed and the SIP dialog is guaranteed 558 to be in a state that would allow in-dialog INFO requests (see 559 Figure 7). 561 Alice Bob 562 | | 563 | INVITE | 564 |------------------------>| 565 | 183 (Offer) | 566 |<------------------------| 567 | PRACK (Answer) | 568 |------------------------>| 569 | | 570 | +----------------------+ 571 | |Bob: I know Alice can| 572 | |trickle and I know her| 573 | |dialog is in the early| 574 | |state. Send INFO! | 575 | +----------------------+ 576 | | 577 | INFO/OK (SRFLX Cand.) | 578 |<------------------------| 579 | | 580 | INFO/OK (SRFLX Cand.) | 581 |------------------------>| 582 | 200 OK/ACK | 583 |<------------------------| 585 Figure 7: A SIP Offerer in a 3PCC scenario can also freely start 586 trickling as soon as it receives an Answer. 588 Trickle Agents that send an Offer in a 200 OK and receive an Answer 589 in an ACK can still create a dialog and confirm support for Trickle 590 ICE by sending an unreliable provisional response similar to 591 Section 4.1.3. According to [RFC3261], this unreliable response MUST 592 NOT contain an Offer. 594 The Trickle Agent (at the UAS) retransmits the provisional response 595 with the exponential back-off timers described in [RFC3262]. 596 Retransmits MUST cease on receipt of a INFO request or on 597 transmission of the answer in a 2xx response. The peer Trickle Agent 598 (at the UAC) MUST send a Trickle ICE INFO request as soon as they 599 receive an unreliable provisional response (see Figure 8). 601 Alice Bob 602 | | 603 | INVITE | 604 |------------------------>| 605 | 183 (-) | 606 |<------------------------| 607 | INFO/OK (SRFLX Cand.) | 608 |------------------------>| 609 | | 610 | +-----------------------+ 611 | |Bob: I know Alice can | 612 | |trickle and I know her | 613 | |dialog is in the early | 614 | |state. | 615 | |INFO can be sent. | 616 | +-----------------------+ 617 | | 618 | INFO/OK (SRFLX Cand.) | 619 |<------------------------| 620 | | 621 | 200 (Offer) | 622 |<------------------------| 623 | ACK (Answer) | 624 |------------------------>| 625 | | 627 Figure 8: A SIP UAC in a 3PCC scenario can also freely start 628 trickling as soon as it receives an unreliable provisional response. 630 4.2. Delivering candidates in INFO messages 632 Whenever new ICE candidates become available for sending, agents 633 would encode them in "a=candidate" lines as described by 634 [I-D.ietf-ice-trickle]. For example: 636 a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx 637 raddr 10.0.1.1 rport 8998 639 The use of SIP INFO requests happens within the context of the Info 640 Package as defined Section 10. The MIME type for their payload MUST 641 be set to 'application/trickle-ice-sdpfrag' as defined in Section 9. 643 Since neither the "a=candidate" nor the "a=end-of-candidates" 644 attributes contain information that would allow correlating them to a 645 specific "m=" line, this is handled through the use of pseudo "m=" 646 lines and identification tags in "a=mid:" attributes as defined in 648 [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as 649 defined in [RFC4566], but provide no semantics other than indicating 650 to which "m=" line a candidate belongs. Consequently, the receiving 651 agent MUST ignore the remaining content of the pseudo m-line. This 652 guarantees that the 'application/trickle-ice-sdpfrag' bodies do not 653 interfere with the Offer/Answer procedures as specified in [RFC3264]. 655 When sending the INFO request, the agent MAY, if already known to the 656 agent, include the same content into the pseudo m-line as for the 657 corresponding Offer or Answer. However, since Trickle-ICE might be 658 decoupled from the Offer/Answer negotiation this content might be 659 unknown to the agent. In this case, the agent MUST include the 660 following default values. 662 o The media is set to 'audio'. 664 o The port value is set to '9'. 666 o The proto value is set to 'RTP/AVP'. 668 o The fmt SHOULD appear only once and is set to '0' 670 Agents MUST include a pseudo "m=" line and an identification tag in a 671 "a=mid:" attribute for every "m=" line whose candidate list they 672 intend to update. Such "a=mid:" attributes MUST immediately precede 673 the list of candidates for that specific "m=" line. All 674 "a=candidate" or "a=end-of-candidates" attributes following an 675 "a=mid:" attribute, up until (and excluding) the next occurrence of 676 an "a=mid:" attribute, pertain to the "m=" line identified by that 677 identification tag. An "a=end-of-candidates" attribute, preceding 678 any "a=mid:" attributes, indicates the end of all trickling from that 679 agent, as opposed to end of trickling for a specific "m=" line, which 680 would be indicated by a media level "a=end-of-candidates" attribute. 682 The use of "a=mid:" attributes allows for a structure similar to the 683 one in SDP Offers and Answers where separate media-level and session- 684 level sections can be distinguished. In the current case, lines 685 preceding any "a=mid:" attributes are considered to be session-level. 686 Lines appearing in between or after "a=mid:" attributes will be 687 interpreted as media-level. 689 Note that while this specification uses the "a=mid:" attribute 690 from [RFC5888], it does not define any grouping semantics. 691 Consequently, using the "a=group:" attribute from that same 692 specification is neither needed nor used in Trickle ICE for SIP. 694 All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" 695 attributes that would allow mapping them to a specific ICE 696 generation. INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:" 697 attributes that do not match those of the current ICE processing 698 session MUST be discarded. 700 The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the 701 same level as the ones in the Offer/Answer exchange. In other words, 702 if they were present as session-level attributes there, they will 703 also appear at the beginning of all INFO message payloads, preceding 704 all "a=mid:" attributes. If they were originally exchanged as media 705 level attributes, potentially overriding session-level values, then 706 they will also be included in INFO message payloads, following the 707 corresponding "a=mid:" attribute. 709 In every INFO request agents MUST include all local candidates they 710 have signaled previously. This is necessary in order to more easily 711 avoid problems that would arise from unreliable transports. Mis- 712 ordering can be detected through the CSeq: header field in the INFO 713 request. As a consequence candidates cannot be removed unless an ICE 714 restart is performed. Note that extension might be specified in the 715 future that enable such removal without a restart. 717 When receiving INFO requests carrying any candidates, agents will 718 therefore first identify and discard the SDP lines containing 719 candidates they have already received in previous INFO requests or in 720 the Offer/Answer exchange preceding them. Two candidates are 721 considered to be equal if their IP address port, transport and 722 component ID are the same. After identifying and discarding known 723 candidates, the ICE agents will then receive and process the 724 remaining, actually new candidates according to the rules described 725 in [I-D.ietf-ice-trickle]. 727 The following example shows the content of one sample candidate 728 delivering INFO request: 730 INFO sip:alice@example.com SIP/2.0 731 ... 732 Info-Package: trickle-ice 733 Content-type: application/sdp 734 Content-Disposition: Info-Package 735 Content-length: ... 737 a=ice-pwd:asd88fgpdd777uzjYhagZg 738 a=ice-ufrag:8hhY 739 m=audio 9 RTP/AVP 0 740 a=mid:1 741 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 742 a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx 743 raddr 10.0.1.1 rport 8998 744 a=end-of-candidates 745 m=audio 9 RTP/AVP 0 746 a=mid:2 747 a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx 748 raddr 10.0.1.1 rport 9000 749 a=end-of-candidates 751 5. Initial discovery of Trickle ICE support 753 SIP User Agents (UAs) that support and intend to use trickle ICE are 754 REQUIRED by [I-D.ietf-ice-trickle] to indicate that in their Offers 755 and Answers using the following attribute: "a=ice-options:trickle". 756 This makes discovery fairly straightforward for Answerers or for 757 cases where Offers need to be generated within existing dialogs 758 (i.e., when sending re-INVITE requests). In both scenarios prior SDP 759 would have provided the necessary information. 761 Obviously, prior SDP is not available at the time a first Offer is 762 being constructed and it is therefore impossible for ICE agents to 763 determine support for incremental provisioning that way. The 764 following options are suggested as ways of addressing this issue. 766 5.1. Provisioning support for Trickle ICE 768 In certain situations it may be possible for integrators deploying 769 Trickle ICE to know in advance that some or all endpoints reachable 770 from within the deployment will support Trickle ICE. This is likely 771 to be the case, for example, for WebRTC clients that will always be 772 communicating with other WebRTC clients or known Session Border 773 Controllers (SBC) with support for this specification. 775 While the exact mechanism for allowing such provisioning is out of 776 scope here, this specification encourages trickle ICE implementations 777 to allow the option in the way they find most appropriate. 779 5.2. Trickle ICE discovery with GRUU 781 [RFC3840] provides a way for SIP user agents to query for support of 782 specific capabilities using, among others, OPTIONS requests. GRUU 783 support on the other hand allows SIP requests to be addressed to 784 specific UAs (as opposed to arbitrary instances of an address of 785 record). Combining the two and using the "trickle-ice" option tag 786 defined in Section 10.5 provides SIP UAs with a way of learning the 787 capabilities of specific US instances and then addressing them 788 directly with INVITE requests that require SIP support. 790 Such targeted trickling may happen in different ways. One option 791 would be for a SIP UA to learn the GRUU instance ID of a peer through 792 presence and to then query its capabilities direction with an OPTIONS 793 request. Alternately, it can also just send an OPTIONS request to 794 the AOR it intends to contact and then inspect the returned 795 response(s) for support of both GRUU and Trickle ICE (Figure 9). 797 Alice Bob 798 | | 799 | OPTIONS sip:b1@example.com SIP/2.0 | 800 |-------------------------------------------------->| 801 | | 802 | 200 OK | 803 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 804 | ;audio;video|;trickle-ice;... | 805 |<--------------------------------------------------| 806 | | 807 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 808 |-------------------------------------------------->| 809 | | 810 | 183 (Answer) | 811 |<--------------------------------------------------| 812 | INFO/OK (Trickling) | 813 |<------------------------------------------------->| 814 | | 815 | ... | 816 | | 818 Figure 9: Trickle ICE support discovery with OPTIONS and GRUU 820 Confirming support for Trickle ICE through [RFC3840] gives SIP UAs 821 the options to engage in Full Trickle negotiation (as opposed to the 822 more lengthy Half Trickle) from the very first Offer they send. 824 5.3. Trickle ICE discovery through other protocols 826 Protocols like XMPP [RFC6120] define advanced discovery mechanisms 827 that allow specific features to be queried priory to actually 828 attempting to use them. Solutions like [RFC7081] define ways of 829 using SIP and XMPP together which also provides a way for dual stack 830 SIP+XMPP endpoints to make use of such features and verify Trickle 831 ICE support for a specific SIP endpoint through XMPP. [TODO expand 832 on a specific way to do this or declare as out of scope] 834 5.4. Fall-back to Half Trickle 836 In cases where none of the other mechanisms in this section are 837 acceptable, SIP UAs should use the Half Trickle mode defined in 838 [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions 839 the same way they would when using Vanilla ICE for SIP 840 [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually 841 sending an Offer, agents would first gather ICE candidates in a 842 blocking way and then send them all in that Offer. The blocking 843 nature of the process would likely imply that some amount of latency 844 will be accumulated and it is advised that agents try to anticipate 845 it where possible, like for example, when user actions indicate a 846 high likelihood for an imminent call (e.g., activity on a keypad or a 847 phone going off-hook). 849 Using Half Trickle would result in Offers that are compatible with 850 both Vanilla ICE SIP endpoints and legacy [RFC3264] endpoints. 852 STUN/Turn STUN/TURN 853 Servers Alice Bob Servers 854 | | | | 855 |<--------------| | | 856 | | | | 857 | | | | 858 | Candidate | | | 859 | | | | 860 | | | | 861 | Discovery | | | 862 | | | | 863 | | | | 864 |-------------->| INVITE (Offer) | | 865 | |---------------------------->| | 866 | | 183 (Answer) |-------------->| 867 | |<----------------------------| | 868 | | INFO (repeated candidates) | | 869 | |---------------------------->| | 870 | | | | 871 | | INFO (more candidates) | Candidate | 872 | |<----------------------------| | 873 | | Connectivity Checks | | 874 | |<===========================>| Discovery | 875 | | INFO (more candidates) | | 876 | |<----------------------------| | 877 | | Connectivity Checks |<--------------| 878 | |<===========================>| | 879 | | | | 880 | | 200 OK | | 881 | |<----------------------------| | 882 | | | | 883 | | 5245 SIP re-INVITE | | 884 | |---------------------------->| | 885 | | 200 OK | | 886 | |<----------------------------| | 887 | | | | 888 | | | | 889 | |<======= MEDIA FLOWS =======>| | 890 | | | | 892 Figure 10: Example - A typical (Half) Trickle ICE exchange with SIP 894 It is worth reminding that once a single Offer or Answer had been 895 exchanged within a specific dialog, support for Trickle ICE will have 896 been determined. No further use of Half Trickle will therefore be 897 necessary within that same dialog and all subsequent exchanges can 898 use the Full Trickle mode of operation. 900 6. Considerations for RTP and RTCP multiplexing 902 The following consideration describe options for Trickle-ICE in order 903 to give some guidance to implementors on how trickling can be 904 optimized with respect to providing RTCP candidates. 906 Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" 907 attribute for RTP/RTCP multiplexing [RFC5761] is already considered 908 in section 4.2. of [I-D.ietf-mmusic-ice-sip-sdp], respectively, as 909 well in [RFC5761] itself. These considerations are still valid for 910 Trickle ICE, however, trickling provides more flexibility for the 911 sequence of candidate exchange in case of RTCP multiplexing. 913 If the Offerer supports RTP/RTCP multiplexing exclusively as 914 specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that 915 document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" 916 and the "a=rtcp-mux" attributes. 918 While a Half Trickle Offerer would have to send an offer compliant to 919 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for 920 all components, this flexibility allows a Full Trickle Offerer to 921 initially send only RTP candidates (component 1) if it assumes that 922 RTCP multiplexing is supported by the Answerer. A Full Trickle 923 Offerer would need to start gathering and trickling RTCP candidates 924 (component 2) only after having received an indication in the answer 925 that the answerer unexpectedly does not support RTCP multiplexing. 927 A Trickle answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in 928 the application/trickle-ice-sdpfrag body it supports and uses RTP and 929 RTCP multiplexing. Trickle answerer MUST follow the guidance on the 930 usage of the "a=rtcp" attribute as given in 931 [I-D.ietf-mmusic-ice-sip-sdp] and Receipt of this attribute at the 932 Offerer in an INFO request prior to the Answer indicates that the 933 Answerer supports and uses RTP and RTCP multiplexing. The Offerer 934 can use this information e.g. for stopping gathering of RTCP 935 candidates and/or for freeing corresponding resources. 937 This behavior is illustrated by the following example offer that 938 indicates support for RTP and RTCP multiplexing. 940 v=0 941 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 942 s= 943 c=IN IP4 atlanta.example.com 944 t=0 0 945 a=ice-pwd:777uzjYhagZgasd88fgpdd 946 a=ice-ufrag:Yhh8 947 m=audio 10000 RTP/AVP 0 948 a=mid:1 949 a=rtcp-mux 950 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 952 Once the dialog is established as described in section Section 4.1 953 the Answerer sends the following INFO message. 955 INFO sip:alice@example.com SIP/2.0 956 ... 957 Info-Package: trickle-ice 958 Content-type: application/sdp 959 Content-Disposition: Info-Package 960 Content-length: ... 962 a=ice-pwd:asd88fgpdd777uzjYhagZg 963 a=ice-ufrag:8hhY 964 m=audio 9 RTP/AVP 0 965 a=mid:1 966 a=rtcp-mux 967 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 969 This INFO message indicates that the Answerer supports and uses RTP 970 and RTCP multiplexing as well. This allows the Offerer to omit 971 gathering of RTCP candidates or releasing already gathered RTCP 972 candidates. If the INFO message did not contain the a=rtcp-mux 973 attribute, the Offerer would have to gather RTCP candidates unless it 974 wants to wait until receipt of an Answer that eventually confirms 975 support or non-support for RTP and RTCP multiplexing. 977 7. Considerations for Media Multiplexing 979 The following consideration describe options for Trickle-ICE in order 980 to give some guidance to implementors on how trickling can be 981 optimized with respect to providing candidates in case of Media 982 Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed 983 that the reader is familiar with 984 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 986 ICE candidate exchange is already considered in section 11 of 987 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are 988 still valid for Trickle ICE, however, trickling provides more 989 flexibility for the sequence of candidate exchange, especially in 990 Full Trickle mode. 992 Except for bundle-only m-lines, a Half Trickle Offerer would have to 993 send an offer with candidates for all bundled m-lines. The 994 additional flexibility, however, allows a Full Trickle Offerer to 995 initially send only candidates for the m-line with the suggested 996 Offerer BUNDLE address. 998 Latest on receipt of the answer, the Offerer will detect if BUNDLE is 999 supported and if the suggested Offerer BUNDLE address was selected. 1000 In this case the Offerer does not need to trickle further candidates 1001 for the remaining m-lines in a bundle. However, if BUNDLE is not 1002 supported, the Full Trickle Offerer needs to gather and trickle 1003 candidates for the remaining m-lines as necessary. If the answerer 1004 selects a Offerer BUNDLE address different from suggested Offerer 1005 BUNDLE address, the Full Trickle Offerer needs to gather and trickle 1006 candidates for the m-line that carries the selected Offerer BUNDLE 1007 address. 1009 A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute 1010 [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle- 1011 ice-sdpfrag body if it supports and uses bundling. When doing so, 1012 the Answerer MUST include all identification-tags in the same order 1013 that is used or will be used in the Answer. 1015 Receipt of this attribute at the Offerer in an INFO request prior to 1016 the Answer indicates that the Answerer supports and uses bundling. 1017 The Offerer can use this information e.g. for stopping the gathering 1018 of candidates for the remaining m-lines in a bundle and/or for 1019 freeing corresponding resources. 1021 This behaviour is illustrated by the following example offer that 1022 indicates support for Media Multiplexing. 1024 v=0 1025 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1026 s= 1027 c=IN IP4 atlanta.example.com 1028 t=0 0 1029 a=group:BUNDLE foo bar 1030 a=ice-pwd:777uzjYhagZgasd88fgpdd 1031 a=ice-ufrag:Yhh8 1032 m=audio 10000 RTP/AVP 0 1033 a=mid:foo 1034 a=rtpmap:0 PCMU/8000 1035 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1036 m=video 10002 RTP/AVP 31 1037 a=mid:bar 1038 a=rtpmap:31 H261/90000 1039 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1041 Once the dialog is established as described in section Section 4.1 1042 the Answerer sends the following INFO message. 1044 INFO sip:alice@example.com SIP/2.0 1045 ... 1046 Info-Package: trickle-ice 1047 Content-type: application/sdp 1048 Content-Disposition: Info-Package 1049 Content-length: ... 1051 a=group:BUNDLE foo bar 1052 a=ice-pwd:asd88fgpdd777uzjYhagZg 1053 a=ice-ufrag:8hhY 1054 m=audio 9 RTP/AVP 0 1055 a=mid:1 1056 a=rtcp-mux 1057 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 1058 m=audio 9 RTP/AVP 0 1059 a=mid:bar 1061 This INFO message indicates that the Answerer supports and uses Media 1062 Multiplexing as well. Note, that the second m-line shows the default 1063 values as specified in section Section 4.2, e.g. media set 'audio' 1064 although 'video' was offered. The receiving ICE agents needs to 1065 ignore these default values in the pseudo m-lines. 1067 The INFO message also indicates that the Answerer accepted the 1068 suggested Offerer Bundle Address. This allows the Offerer to omit 1069 gathering of RTP and RTCP candidates for the other m-lines or 1070 releasing already gathered candidates. If the INFO message did not 1071 contain the a=group:BUNDLE attribute, the Offerer would have to 1072 gather RTP and RTCP candidates for the other m-lines unless it wants 1073 to wait until receipt of an Answer that eventually confirms support 1074 or non-support for Media Multiplexing. 1076 Independent of using Full Trickle or Half Trickle mode, the rules 1077 from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and 1078 Answerer, when putting attributes in the application/trickle-ice- 1079 sdpfrag body. 1081 8. SDP 'end-of-candidate' Attribute 1083 This section defines a new SDP media-level and session-level 1084 attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' is a 1085 property attribute [RFC4566], and hence has no value. By including 1086 this attribute in an Offer or Answer the sending agent indicates that 1087 it will not trickle further candidates. The detailed SDP Offer/ 1088 Answer procedures for the 'end-of-candidate' attribute are specified 1089 in [I-D.ietf-ice-trickle]. 1091 Name: end-of-candidate 1093 Value: N/A 1095 Usage Level: media and session-level 1097 Charset Dependent: no 1099 Mux Category: IDENTICAL 1101 Example: a=end-of-candidate 1103 9. Content Type 'application/trickle-ice-sdpfrag' 1105 9.1. Overall Description 1107 A application/trickle-ice-sdpfrag body is used by the Trickle-ICE 1108 Info Package. It uses a subset of the possible SDP lines that are 1109 allowed based on the grammar defined in [RFC4566]. A valid body uses 1110 only media descriptions and certain attributes that are needed and/or 1111 useful for trickling candidates. The content adheres to the 1112 following grammar. 1114 9.2. Grammar 1116 The grammar of an 'application/trickle-ice-sdpfrag' body is based the 1117 following ABNF [RFC5234]. It specifies the subset of existing SDP 1118 attributes, that are needed or useful for trickling candidates. 1120 ; Syntax 1121 trickle-ice-sdpfrag = session-level-fields 1122 pseudo-media-descriptions 1123 session-level-fields = [bundle-group-attribute CRLF] 1124 [ice-lite-attribute CRLF] 1125 ice-pwd-attribute CRLF 1126 ice-ufrag-attribute CRLF 1127 [ice-options-attribute CRLF] 1128 [ice-pacing-attribute CRLF] 1129 [end-of-candidates-attribute CRLF] 1130 extension-attribute-fields 1131 ; for future extensions 1133 ice-lite-attribute = %s"a=" ice-lite 1134 ice-pwd-attribute = %s"a=" ice-pwd-att 1135 ice-ufrag-attribute = %s"a=" ice-ufrag-att 1136 ice-pacing-attribute = %s"a=" ice-pacing-att 1137 ice-options-attribute = %s"a=" ice-options 1138 bundle-group-attribute = "a=group:" bundle-semantics 1139 *(SP identification-tag) 1140 bundle-semantics = "BUNDLE" 1141 end-of-candidates-attribute = %s"a=" end-of-candidates 1142 extension-attribute-fields = attribute-fields 1144 pseudo-media-descriptions = *( media-field 1145 trickle-ice-attribute-fields 1146 [extension-attribute-fields] ) 1147 ; for future extensions 1148 trickle-ice-attribute-fields = mid-attribute CRLF 1149 ["a=rtcp-mux" CRLF] 1150 ["a=rtcp-mux-only" CRLF] 1151 *(candidate-attributes CRLF) 1152 [ice-pwd-attribute CRLF] 1153 [ice-ufrag-attribute CRLF] 1154 [remote-candidate-attribute CRLF] 1155 [end-of-candidates-attribute CRLF] 1156 remote-candidate-attribute = %s"a=" remote-candidate-att 1157 candidate-attributes = %s"a=" candidate-attribute 1158 end-of-candidates = %s"end-of-candidates" 1160 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- 1161 pacing-att, ice-options, candidate-attribute remote-candidate-att 1162 from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute 1163 ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The 1164 indicator for case-sensitivity %s is defined in [RFC7405]. 1166 An Agent MUST ignore any received unknown extension-attribute-fields. 1168 10. Info Package 1170 10.1. Overall Description 1172 This specification defines an Info Package for use by SIP user agents 1173 implementing Trickle ICE. INFO requests carry ICE candidates 1174 discovered after the peer user agents have confirmed mutual support 1175 for Trickle ICE. 1177 10.2. Applicability 1179 The purpose of the ICE protocol is to establish a media path in the 1180 presence of NAT and firewalls. The candidates are transported in 1181 INFO requests and are part of this establishment. 1183 Candidates sent by a Trickle ICE agent after the Offer, follow the 1184 same signaling path and reach the same entity as the Offer itself. 1185 While it is true that GRUUs can be used to achieve this, one of the 1186 goals of this specification is to allow operation of Trickle ICE in 1187 as many environments as possible including those without GRUU 1188 support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not 1189 satisfy this goal. 1191 10.3. Info Package Name 1193 This document defines a SIP Info Package as per [RFC6086]. The Info 1194 Package token name for this package is "trickle-ice" 1196 10.4. Info Package Parameters 1198 This document does not define any Info Package parameters. 1200 10.5. SIP Option Tags 1202 [RFC6086] allows Info Package specifications to define SIP option- 1203 tags. This specification extends the option-tag construct of the SIP 1204 grammar as follows: 1206 option-tag /= "trickle-ice" 1208 SIP entities that support this specification MUST place the 'trickle- 1209 ice' option-tag in a SIP Supported: header field within all SIP 1210 INVITE requests and responses. 1212 When responding to, or generating a SIP OPTIONS request a SIP entity 1213 MUST also include the 'trickle-ice' option-tag in a SIP Supported: 1214 header field. 1216 10.6. Info Message Body Parts 1218 Entities implementing this specification MUST include a payload of 1219 type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 all 1220 SIP INFO requests. The payload is used to convey SDP encoded ICE 1221 candidates. 1223 10.7. Info Package Usage Restrictions 1225 This document does not define any Info Package Usage Restrictions. 1227 10.8. Rate of INFO Requests 1229 A Trickle ICE Agent with many network interfaces might create a high 1230 rate of INFO requests if every newly detected candidate is trickled 1231 individually without aggregation. Implementor that are concerned 1232 about loss of packets in such a case might consider aggregating ICE 1233 candidates and sending INFOS only at some configurable intervals. 1235 10.9. Info Package Security Considerations 1237 See Section 12 1239 11. IANA Considerations 1241 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1242 document. Please replace "I-D.ietf-ice-trickle" with the RFC number 1243 of that document.] 1245 11.1. SDP 'end-of-candidate' Attribute 1247 This section defines a new SDP media-level and session-level 1248 attribute [RFC4566] , 'end-of-candidate'. 'end-of-candidate' is a 1249 property attribute [RFC4566] , and hence has no value. 1251 Name: end-of-candidate 1253 Value: N/A 1255 Usage Level: media and session 1257 Charset Dependent: no 1259 Purpose: The sender indicates that it will not trickle 1260 further candidates. 1262 O/A Procedures: "I-D.ietf-ice-trickle" defines the detailed 1263 SDP Offer/Answer procedures for 1264 the 'end-of-candidate' attribute. 1266 Mux Category: IDENTICAL 1268 Reference: RFCXXXX 1270 Example: 1272 a=end-of-candidate 1274 11.2. application/trickle-ice-sdpfrag MIME Type 1276 Type name: application 1278 Subtype name: trickle-ice-sdpfrag 1280 Required parameters: None. 1282 Optional parameters: None. 1284 Encoding considerations: 1286 SDP files are primarily UTF-8 format text. Although the 1287 initially defined content of a trickle-ice-sdpfrag body does 1288 only include ASCII characters, UTF-8 encoded content might be 1289 introduced via extension attributes. The "a=charset:" 1290 attribute may be used to signal the presence of other character 1291 sets in certain parts of a trickle-ice-sdpfrag body (see 1292 [RFC4566]). Arbitrary binary content cannot be directly 1293 represented in SDP or a trickle-ice-sdpfrag body. 1295 Security considerations: 1297 See [RFC4566]) and RFCXXXX 1299 Interoperability considerations: 1301 See RFCXXXX 1303 Published specification: 1305 See RFCXXXX 1307 Applications which use this media type: 1309 Voice over IP, video teleconferencing, streaming media, instant 1310 messaging, Trickle-ICE among others. 1312 Additional information: 1314 Magic number(s): none 1316 File extension(s): none 1318 Macintosh File Type Code(s): none 1320 Person and email address to contact for further information: 1322 IETF MMUSIC working group mmusic@ietf.org 1324 Intended usage: 1326 Trickle-ICE for SIP as specified in RFCXXXX. 1328 Author/Change controller: 1330 IETF MMUSIC working group mmusic@ietf.org 1332 11.3. SIP Info Package 'trickle-ice' 1334 This document defines a new SIP Info Package named 'trickle-ice' and 1335 updates the Info Packages Registry with the following entry. 1337 +-------------+-----------+ 1338 | Name | Reference | 1339 +-------------+-----------+ 1340 | trickle-ice | [RFCXXXX] | 1341 | | | 1342 +-------------+-----------+ 1344 11.4. SIP Option Tag 'trickle-ice' 1346 This specification registers a new SIP option tag 'trickle-ice' as 1347 per the guidelines in Section 27.1 of [RFC3261] and updates the 1348 "Option Tags" section of the SIP Parameter Registry with the 1349 following entry: 1351 +-------------+-------------------------------------+-----------+ 1352 | Name | Description | Reference | 1353 +-------------+-------------------------------------+-----------+ 1354 | trickle-ice | This option tag is used to indicate | [RFCXXXX] | 1355 | | that a UA supports and understands | | 1356 | | Trickle-ICE. | | 1357 +-------------+-------------------------------------+-----------+ 1359 12. Security Considerations 1361 The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], 1362 [RFC6086], [I-D.ietf-ice-trickle] apply. This document clarifies how 1363 the above specifications are used together for trickling candidates 1364 and does not create addtitional security risks. 1366 13. Acknowledgements 1368 The authors would like to thank Ayush Jain, Paul Kyzivat, Jonathan 1369 Lennox, Simon Perreault and Martin Thomson for reviewing and/or 1370 making various suggestions for improvements and optimizations. 1372 14. Change Log 1374 [RFC EDITOR NOTE: Please remove this section when publishing]. 1376 Changes from draft-ietf-mmusic-trickle-ice-sip-01 1378 o Editorial Clean up 1380 o IANA Consideration added 1382 o Security Consideration added 1384 o RTCP and BUNDLE Consideration added with rules for including 1385 "a=rtcp-mux" and "a=group: BUNDLLE" attributes 1387 o 3PCC Consideration added 1389 o Clarified that 18x w/o answer is sufficient to create a dialog 1390 that allows for trickling to start 1392 o Added remaining Info Package definition sections as outlined in 1393 section 10 of [RFC6086] 1395 o Added definition of application/sdpfrag making draft-ivov-mmusic- 1396 sdpfrag obsolete 1398 o Added pseudo m-lines as additional separator in sdpfrag bodies for 1399 Trickle ICE 1401 o Added ABNF for sdp-frag bodies and Trickle-ICE package 1403 Changes from draft-ietf-mmusic-trickle-ice-sip-02 1405 o Removed definition of application/sdpfrag 1407 o Replaced with new type application/trickle-ice-sdpfrag 1409 o RTCP and BUNDLE Consideration enhanced with some examples 1411 o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to 1412 normative reference 1414 o Removed reference to 4566bis 1416 o Addressed review comment from Simon Perreault 1418 Changes from draft-ietf-mmusic-trickle-ice-sip-03 1419 o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis 1420 and draft-ietf-mmusic-ice-sip-sdp 1422 o Corrected Figure 10, credits to Ayush Jain for finding the bug 1424 o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- 1425 ice-sip-sdp 1427 o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- 1428 mux-exclusive, enahnced ABNF to support a=rtcp-mux-exclusive 1430 o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for 1431 the application/trickle-ice-sdpfrag body 1433 Changes from draft-ietf-mmusic-trickle-ice-sip-04 1435 o considered comments from Christer Holmberg 1437 o corrected grammar for INFO package, such that ice-ufrag/pwd are 1438 also allowed on media-level as specified in 1439 [I-D.ietf-mmusic-ice-sip-sdp] 1441 o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] 1443 o Added formal definition for the end-of-candidates attribute 1445 15. References 1447 15.1. Normative References 1449 [I-D.ietf-ice-trickle] 1450 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 1451 "Trickle ICE: Incremental Provisioning of Candidates for 1452 the Interactive Connectivity Establishment (ICE) 1453 Protocol", draft-ietf-ice-trickle-03 (work in progress), 1454 July 2016. 1456 [I-D.ietf-mmusic-ice-sip-sdp] 1457 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using 1458 Interactive Connectivity Establishment (ICE) with Session 1459 Description Protocol (SDP) offer/answer and Session 1460 Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- 1461 sdp-10 (work in progress), July 2016. 1463 [I-D.ietf-mmusic-mux-exclusive] 1464 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 1465 Multiplexing using SDP", draft-ietf-mmusic-mux- 1466 exclusive-10 (work in progress), August 2016. 1468 [I-D.ietf-mmusic-rfc5245bis] 1469 Keranen, A. and J. Rosenberg, "Interactive Connectivity 1470 Establishment (ICE): A Protocol for Network Address 1471 Translator (NAT) Traversal", draft-ietf-mmusic- 1472 rfc5245bis-05 (work in progress), September 2015. 1474 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1475 Holmberg, C., Alvestrand, H., and C. Jennings, 1476 "Negotiating Media Multiplexing Using the Session 1477 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1478 negotiation-31 (work in progress), June 2016. 1480 [I-D.ietf-mmusic-sdp-mux-attributes] 1481 Nandakumar, S., "A Framework for SDP Attributes when 1482 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-13 1483 (work in progress), June 2016. 1485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1486 Requirement Levels", BCP 14, RFC 2119, 1487 DOI 10.17487/RFC2119, March 1997, 1488 . 1490 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1491 A., Peterson, J., Sparks, R., Handley, M., and E. 1492 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1493 DOI 10.17487/RFC3261, June 2002, 1494 . 1496 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1497 Provisional Responses in Session Initiation Protocol 1498 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1499 . 1501 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1502 with Session Description Protocol (SDP)", RFC 3264, 1503 DOI 10.17487/RFC3264, June 2002, 1504 . 1506 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1507 in Session Description Protocol (SDP)", RFC 3605, 1508 DOI 10.17487/RFC3605, October 2003, 1509 . 1511 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1512 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1513 July 2006, . 1515 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1516 Specifications: ABNF", STD 68, RFC 5234, 1517 DOI 10.17487/RFC5234, January 2008, 1518 . 1520 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1521 Control Packets on a Single Port", RFC 5761, 1522 DOI 10.17487/RFC5761, April 2010, 1523 . 1525 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1526 Protocol (SDP) Grouping Framework", RFC 5888, 1527 DOI 10.17487/RFC5888, June 2010, 1528 . 1530 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1531 Initiation Protocol (SIP) INFO Method and Package 1532 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1533 . 1535 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1536 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1537 . 1539 15.2. Informative References 1541 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1542 "Indicating User Agent Capabilities in the Session 1543 Initiation Protocol (SIP)", RFC 3840, 1544 DOI 10.17487/RFC3840, August 2004, 1545 . 1547 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1548 Agent URIs (GRUUs) in the Session Initiation Protocol 1549 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 1550 . 1552 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1553 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1554 March 2011, . 1556 [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: 1557 Combined Use of the Session Initiation Protocol (SIP) and 1558 the Extensible Messaging and Presence Protocol (XMPP)", 1559 RFC 7081, DOI 10.17487/RFC7081, November 2013, 1560 . 1562 Authors' Addresses 1564 Emil Ivov 1565 Jitsi 1566 Strasbourg 67000 1567 France 1569 Phone: +33 6 72 81 15 55 1570 Email: emcho@jitsi.org 1572 Thomas Stach 1573 Unaffiliated 1574 Vienna 1130 1575 Austria 1577 Email: thomass.stach@gmail.com 1579 Enrico Marocco 1580 Telecom Italia 1581 Via G. Reiss Romoli, 274 1582 Turin 10148 1583 Italy 1585 Email: enrico.marocco@telecomitalia.it 1587 Christer Holmberg 1588 Ericsson 1589 Hirsalantie 11 1590 Jorvas 02420 1591 Finland 1593 Email: christer.holmberg@ericsson.com