idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-07.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 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 (March 3, 2017) is 2601 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 1364, but not defined == Unused Reference: 'RFC7405' is defined on line 1567, but no explicit reference was found in the text == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-11 == Outdated reference: A later version (-21) exists of draft-ietf-ice-trickle-07 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-mux-exclusive-11 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-36 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 9 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: September 4, 2017 Unaffiliated 6 E. Marocco 7 Telecom Italia 8 C. Holmberg 9 Ericsson 10 March 3, 2017 12 A Session Initiation Protocol (SIP) usage for Trickle ICE 13 draft-ietf-mmusic-trickle-ice-sip-07 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 September 4, 2017. 46 Copyright Notice 48 Copyright (c) 2017 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. Discovery issues . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Relationship with the Offer/Answer Model . . . . . . . . 6 68 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 8 69 4.1. Establishing the dialog . . . . . . . . . . . . . . . . . 8 70 4.1.1. Asserting dialog state through reliable Offer/Answer 71 delivery . . . . . . . . . . . . . . . . . . . . . . 8 72 4.1.2. Asserting dialog state through unreliable 73 Offer/Answer delivery . . . . . . . . . . . . . . . . 9 74 4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 11 75 4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 12 76 4.2. Delivering candidates in INFO messages . . . . . . . . . 14 77 5. Initial discovery of Trickle ICE support . . . . . . . . . . 17 78 5.1. Provisioning support for Trickle ICE . . . . . . . . . . 17 79 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 18 80 5.3. Trickle ICE discovery through other protocols . . . . . . 19 81 5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 19 82 6. Considerations for RTP and RTCP multiplexing . . . . . . . . 21 83 7. Considerations for Media Multiplexing . . . . . . . . . . . . 22 84 8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 25 85 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 25 86 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 25 87 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 27 89 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 27 90 10.2. Overall Description . . . . . . . . . . . . . . . . . . 28 91 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 28 92 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 28 93 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 28 94 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 28 95 10.7. Info Message Body Parts . . . . . . . . . . . . . . . . 29 96 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 29 97 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 29 98 10.10. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 35 108 15.1. Normative References . . . . . . . . . . . . . . . . . . 35 109 15.2. Informative References . . . . . . . . . . . . . . . . . 37 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 112 1. Introduction 114 The Interactive Connectivity Establishment protocol 115 [I-D.ietf-mmusic-rfc5245bis] describes a mechanism for NAT traversal 116 that consists of three main phases: a phase where an agent gathers a 117 set of candidate transport addresses (source IP address, port and 118 transport protocol), a second phase where these candidates are sent 119 to a remote agent and this gathering procedure is repeated and, 120 finally, a third phase where connectivity between all candidates in 121 both sets is checked (connectivity checks). Once these phases have 122 been completed, and only then, can both agents begin communication. 123 According to [I-D.ietf-mmusic-rfc5245bis] the three phases above 124 happen consecutively, in a blocking way, which can introduce 125 undesirable latency during session establishment. 127 The Trickle ICE extension [I-D.ietf-ice-trickle] defines generic 128 semantics required for these ICE phases to happen simultaneously, in 129 a non-blocking way and hence speed up session establishment. 131 This specification defines a usage of Trickle ICE with the Session 132 Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates 133 are to be incrementally exchanged with SIP INFO requests and how the 134 Half Trickle and Full Trickle modes defined in [I-D.ietf-ice-trickle] 135 are to be used by SIP User Agents (UAs) depending on their 136 expectations for support of Trickle ICE by a 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-ice-trickle]. It is assumed that the reader will be 151 familiar with the terminology from both documents. 153 3. Protocol Overview 155 Using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the ICE 156 candidates are exchanged solely using SDP Offer/Answer as per 157 [RFC3264]. This specification defines an additional mechanism where 158 candidates can be exchanged using SIP INFO messages and a newly 159 defined Info Package [RFC6086]. This allows ICE candidates to also 160 be sent in parallel to an ongoing Offer/Answer negotiation and/or 161 after the completion of the Offer/Answer negotiation. 163 Typically, in cases where Trickle ICE is fully supported, the Offerer 164 would send an INVITE request containing a subset of candidates. Once 165 an early dialog is established the Offerer can continue sending 166 candidates in INFO requests within that dialog. 168 Similarly, an Answerer can send ICE candidates using INFO messages 169 within the dialog established by its 18x provisional response. 170 Figure 1 shows such a sample exchange: 172 STUN/Turn STUN/TURN 173 Servers Alice Bob Servers 174 | | | | 175 | STUN Bi.Req. | INVITE (Offer) | | 176 |<--------------|------------------------>| | 177 | | 183 (Answer) | TURN Alloc Req | 178 | STUN Bi.Resp. |<------------------------|--------------->| 179 |-------------->| INFO/OK (SRFLX Cand.) | | 180 | |------------------------>| TURN Alloc Resp| 181 | | INFO/OK (Relay Cand.) |<---------------| 182 | |<------------------------| | 183 | | | | 184 | | More Cands & ConnChecks| | 185 | |<=======================>| | 186 | | | | 187 | | 200 OK | | 188 | |<------------------------| | 189 | | ACK | | 190 | |------------------------>| | 191 | | | | 192 | | 5245 SIP re-INVITE | | 193 | |------------------------>| | 194 | | 200 OK | | 195 | |<------------------------| | 196 | | ACK | | 197 | |------------------------>| | 198 | | | | 199 | |<===== MEDIA FLOWS =====>| | 200 | | | | 202 Figure 1: Sample Trickle ICE scenario with SIP 204 3.1. Discovery issues 206 In order to benefit from Trickle ICE's full potential and reduce 207 session establishment latency to a minimum, Trickle ICE agents need 208 to generate SDP Offers and Answers that contain incomplete, 209 potentially empty sets of candidates. Such Offers and Answers can 210 only be handled meaningfully by agents that actually support 211 incremental candidate provisioning, which implies the need to confirm 212 such support before actually using it. 214 Contrary to other protocols, like XMPP [RFC6120], where "in advance" 215 capability discovery is widely implemented, the mechanisms that allow 216 this for SIP (i.e., a combination of UA Capabilities [RFC3840] and 217 GRUU [RFC5627]) have only seen low levels of adoption. This presents 218 an issue for Trickle ICE implementations as SIP UAs do not have an 219 obvious means of verifying that their peer will support incremental 220 candidate provisioning. 222 The Half Trickle mode of operation defined in the Trickle ICE 223 specification [I-D.ietf-ice-trickle] provides one way around this, by 224 requiring the first Offer to contain a complete set of local ICE 225 candidates and only using incremental provisioning of remote 226 candidates for the rest of the session. 228 While using Half Trickle does provide a working solution it also 229 comes at the price of increased latency. Section 5 therefore makes 230 several alternative suggestions that enable SIP UAs to engage in Full 231 Trickle right from their first Offer: Section 5.1 discusses the use 232 of on-line provisioning as a means of allowing use of Trickle ICE for 233 all endpoints in controlled environments. Section 5.2 describes 234 anticipatory discovery for implementations that actually do support 235 GRUU and UA Capabilities and Section 5.4 discusses the implementation 236 and use of Half Trickle by SIP UAs where none of the above are an 237 option. 239 3.2. Relationship with the Offer/Answer Model 241 From the perspective of all SIP middle boxes and proxies, and with 242 the exception of the actual INFO messages, signaling in general and 243 Offer/Answer exchanges in particular would look the same way for 244 Trickle ICE as they would for ICE for SIP 245 [I-D.ietf-mmusic-ice-sip-sdp]. 247 +-------------------------------+ +-------------------------------+ 248 | Alice +--------------+ | | +--------------+ Bob | 249 | | Offer/Answer | | | | Offer/Answer | | 250 | +-------+ | Module | | | | Module | +-------+ | 251 | | ICE | +--------------+ | | +--------------+ | ICE | | 252 | | Agent | | | | | | Agent | | 253 | +-------+ | | | | +-------+ | 254 +-------------------------------+ +-------------------------------+ 255 | | | | 256 | | INVITE (Offer) | | 257 | |--------------------->| | 258 | | 183 (Answer) | | 259 | |<---------------------| | 260 | | | | 261 | | 262 | SIP INFO (more candidates) | 263 |----------------------------------------------------->| 264 | SIP INFO (more candidates) | 265 |<-----------------------------------------------------| 266 | | 267 | STUN Binding Requests/Responses | 268 |----------------------------------------------------->| 269 | STUN Binding Requests/Responses | 270 |<-----------------------------------------------------| 271 | | 272 | | | | 273 | | 5245 SIP re-INVITE | | 274 | |--------------------->| | 275 | | 200 OK | | 276 | |<---------------------| | 278 Figure 2: Distinguishing between Trickle ICE and traditional 279 signaling. 281 From an architectural viewpoint, as displayed on Figure 2, exchanging 282 candidates through SIP INFO requests could be represented as 283 signaling between ICE agents and not between Offer/Answer modules of 284 SIP User Agents. Then, such INFO requests do not impact the state of 285 the Offer/Answer transaction other than providing additional 286 candidates. Consequently, INFO requests are not considered Offers or 287 Answers. Nevertheless, candidates that have been exchanged using 288 INFO SHALL be included in subsequent Offers or Answers. The version 289 number in the "o=" line of that subsequent offer would need to be 290 incremented by 1 per the rules in [RFC3264]. 292 4. Incremental Signaling of ICE candidates 294 Trickle ICE agents will construct Offers and Answers with ICE 295 descriptions compliant to [I-D.ietf-ice-trickle] and the following 296 additional SIP-specific additions: 298 1. Trickle ICE agents MUST indicate support for Trickle ICE by 299 including the option-tag 'trickle-ice' in a SIP Supported: header 300 field within all SIP INVITE requests and responses. 302 2. Trickle ICE agents MAY exchange additional ICE candidates using 303 INFO requests within an existing INVITE dialog usage (including 304 an early dialog) as specified in [RFC6086]. The INFO messages 305 carry an Info-Package: trickle-ice. Trickle ICE agents MUST be 306 prepared to receive INFO requests within that same dialog usage, 307 containing additional candidates or an indication for the end of 308 such candidates 310 3. Trickle ICE agents MAY exchange additional ICE candidates before 311 the Answerer has sent the Answer provided that an invite dialog 312 usage is established at both Trickle ICE agents. Note that in 313 case of forking multiple early dialogs will exist. 315 The following section provide further details on how Trickle ICE 316 agents establish the INVITE dialog usage such that they can trickle 317 candidates. 319 4.1. Establishing the dialog 321 In order for SIP UAs to be able to start trickling, the following two 322 conditions need to be satisfied: 324 o Trickle ICE support at the peer agent MUST be confirmed. 326 o The dialog at both peers MUST be in early or confirmed state. 328 Section 5 discusses in detail the various options for satisfying the 329 first of the above conditions. Regardless of those mechanisms 330 however, agents are certain to have a clear understanding of whether 331 their peers support trickle ICE once an Offer and an Answer have been 332 exchanged, which also allows for ICE processing to commence (see 333 Figure 3). 335 4.1.1. Asserting dialog state through reliable Offer/Answer delivery 336 Alice Bob 337 | | 338 | INVITE (Offer) | 339 |------------------------>| 340 | 183 (Answer) | 341 |<------------------------| 342 | PRACK/OK | 343 |------------------------>| 344 | | 345 +----------------------------------------+ 346 |Alice and Bob know that both can trickle| 347 |and know that the dialog is in the early| 348 |state. Send INFO! | 349 +----------------------------------------+ 350 | | 351 | INFO/OK (+SRFLX Cand.) | 352 |------------------------>| 353 | INFO/OK (+SRFLX Cand.) | 354 |<------------------------| 355 | | 357 Figure 3: SIP Offerer can freely trickle as soon as it receives an 358 Answer. 360 Satisfying both conditions is also relatively trivial for ICE agents 361 that have sent an Offer in an INVITE and that have received an Answer 362 in a reliable provisional response. It is guaranteed to have 363 confirmed support for Trickle ICE within the Answerer (or lack 364 thereof) and to have fully initialized the SIP dialog at both ends. 365 Offerers and Answerers in the above situation can therefore freely 366 commence trickling within the newly established dialog. 368 4.1.2. Asserting dialog state through unreliable Offer/Answer delivery 370 The situation is a bit more delicate for agents that have received an 371 Offer in an INVITE request and have sent an Answer in an unreliable 372 provisional response because, once the response has been sent, the 373 Answerer does not know when or if it has been received (Figure 4). 375 Alice Bob 376 | | 377 | INVITE (Offer) | 378 |------------------------>| 379 | 183 (Answer) | 380 |<------------------------| 381 | | 382 | +----------------------+ 383 | |Bob: I don't know if | 384 | |Alice got my 183 or if| 385 | |her dialog is already | 386 | |in the early state. | 387 | | Can I send INFO??? | 388 | +----------------------+ 389 | | 391 Figure 4: A SIP UA that sent an Answer in an unreliable provisional 392 response does not know if it was received and if the dialog at the 393 side of the Offerer has entered the early state 395 In order to clear this ambiguity as soon as possible, the answerer 396 needs to retransmit the provisional response with the exponential 397 back-off timers described in [RFC3262]. These retransmissions MUST 398 cease on receipt of a INFO request or on transmission of the answer 399 in a 2xx response. This is similar to the procedure described in 400 section 13.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN 401 binding Request is replaced by the INFO request. 403 The Offerer MUST send a Trickle ICE INFO request as soon as it 404 receives an SDP Answer in an unreliable provisional response. This 405 INFO message MUST repeat the candidates that were already provided in 406 the Offer (as would be the case when Half Trickle is performed or 407 when new candidates have not been learned since then) and/or they MAY 408 also deliver new candidates (if available). An end-of-candidates 409 indication MAY be included in case candidate discovery has ended in 410 the mean time. 412 As soon as an Answerer has received such an INFO request, the 413 Answerer has an indication that a dialog is established at both ends 414 and MAY begin trickling (Figure 5). 416 Note: The +SRFLX in Figure 5 indicates that additionally newly 417 learned server-reflexive candidates are included. 419 Alice Bob 420 | | 421 | INVITE (Offer) | 422 |------------------------>| 423 | 183 (Answer) | 424 |<------------------------| 425 | INFO/OK (+SRFLX Cand.) | 426 |------------------------>| 427 | | 428 | +----------------------+ 429 | |Bob: Now I know Alice| 430 | | is ready. Send INFO! | 431 | +----------------------+ 432 | INFO/OK (+SRFLX Cand.) | 433 |<------------------------| 434 | | 435 | 200/ACK (Answer) | 436 |<------------------------| 438 Figure 5: A SIP UA that received an INFO request after sending an 439 unreliable provisional response knows that the dialog at the side of 440 the receiver has entered the early state 442 When sending the Answer in the 200 OK response, the Answerer MUST 443 repeat exactly the same Answer that was previously sent in the 444 unreliable provisional response in order to fulfill the corresponding 445 requirements in [RFC3264]. In other words, that Offerer needs to be 446 prepared to receive a different number of candidates in that repeated 447 Answer than previously exchanged via trickling. 449 4.1.3. Initiating Trickle ICE without an SDP Answer 451 The possibility to convey arbitrary candidates in INFO message bodies 452 allows ICE agents to initiate trickling without actually sending an 453 Answer. Trickle ICE Agents MAY therefore respond to an INVITE 454 request with provisional responses without an SDP Answer. Such 455 provisional responses serve for establishing an early dialog. 457 Agents that choose to establish the dialog in this way, MUST 458 retransmit these responses with the exponential back-off timers 459 described in [RFC3262]. These retransmissions MUST cease on receipt 460 of an INFO request or on transmission of the answer in a 2xx 461 response. This is again similar to the procedure described in 462 section 12.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer 463 is not yet provided. 465 Note: The +SRFLX in Figure 6 indicates that additionally newly 466 learned server-reflexive candidates are included. 468 Alice Bob 469 | | 470 | INVITE (Offer) | 471 |------------------------>| 472 | 183 (-) | 473 |<------------------------| 474 | INFO/OK (SRFLX Cand.) | 475 |------------------------>| 476 | | 477 | +----------------------+ 478 | |Bob: Now I know again| 479 | | that Alice is ready. | 480 | | Send INFO! | 481 | +----------------------+ 482 | INFO/OK (SRFLX Cand.) | 483 |<------------------------| 484 | 183 (Answer) opt. | 485 |<------------------------| 486 | INFO/OK (SRFLX Cand.) | 487 |<------------------------| 488 | 200/ACK (Answer) | 489 |<------------------------| 491 Figure 6: A SIP UA sends an unreliable provisional response without 492 an Answer for establishing an early dialog 494 When sending the Answer the agent MUST repeat all currently known and 495 used candidates, if any, and MAY include all newly gathered 496 candidates since the last INFO request was sent. If that Answer was 497 sent in a unreliable provisional response, the Answerers MUST repeat 498 exactly the same Answer in the 200 OK response in order to fulfill 499 the corresponding requirements in [RFC3264]. In other words, an 500 Offerer needs to be prepared to receive fewer candidates in that 501 repeated Answer than previously exchanged via trickling. 503 4.1.4. Considerations for 3PCC 505 Agents that have sent an Offer in a reliable provisional response and 506 that receive an Answer in a PRACK are also in a situation where 507 support for Trickle ICE is confirmed and the SIP dialog is guaranteed 508 to be in a state that would allow in-dialog INFO requests (see 509 Figure 7). 511 Alice Bob 512 | | 513 | INVITE | 514 |------------------------>| 515 | 183 (Offer) | 516 |<------------------------| 517 | PRACK (Answer) | 518 |------------------------>| 519 | | 520 | +----------------------+ 521 | |Bob: I know Alice can| 522 | |trickle and I know her| 523 | |dialog is in the early| 524 | |state. Send INFO! | 525 | +----------------------+ 526 | | 527 | INFO/OK (SRFLX Cand.) | 528 |<------------------------| 529 | | 530 | INFO/OK (SRFLX Cand.) | 531 |------------------------>| 532 | 200 OK/ACK | 533 |<------------------------| 535 Figure 7: A SIP Offerer in a 3PCC scenario can also freely start 536 trickling as soon as it receives an Answer. 538 Trickle Agents that send an Offer in a 200 OK and receive an Answer 539 in an ACK can still create a dialog and confirm support for Trickle 540 ICE by sending an unreliable provisional response similar to 541 Section 4.1.3. According to [RFC3261], this unreliable response MUST 542 NOT contain an Offer. 544 The Trickle Agent (at the UAS) retransmits the provisional response 545 with the exponential back-off timers described in [RFC3262]. 546 Retransmits MUST cease on receipt of a INFO request or on 547 transmission of the answer in a 2xx response. The peer Trickle Agent 548 (at the UAC) MUST send a Trickle ICE INFO request as soon as they 549 receive an unreliable provisional response (see Figure 8). 551 Alice Bob 552 | | 553 | INVITE | 554 |------------------------>| 555 | 183 (-) | 556 |<------------------------| 557 | INFO/OK (SRFLX Cand.) | 558 |------------------------>| 559 | | 560 | +-----------------------+ 561 | |Bob: I know Alice can | 562 | |trickle and I know her | 563 | |dialog is in the early | 564 | |state. | 565 | |INFO can be sent. | 566 | +-----------------------+ 567 | | 568 | INFO/OK (SRFLX Cand.) | 569 |<------------------------| 570 | | 571 | 200 (Offer) | 572 |<------------------------| 573 | ACK (Answer) | 574 |------------------------>| 575 | | 577 Figure 8: A SIP UAC in a 3PCC scenario can also freely start 578 trickling as soon as it receives an unreliable provisional response. 580 4.2. Delivering candidates in INFO messages 582 Whenever new ICE candidates become available for sending, agents 583 would encode them in "a=candidate" lines as described by 584 [I-D.ietf-ice-trickle]. For example: 586 a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx 587 raddr 10.0.1.1 rport 8998 589 The use of SIP INFO requests happens within the context of the Info 590 Package as defined Section 10. The MIME type for their payload MUST 591 be set to 'application/trickle-ice-sdpfrag' as defined in Section 9. 593 Since neither the "a=candidate" nor the "a=end-of-candidates" 594 attributes contain information that would allow correlating them to a 595 specific "m=" line, this is handled through the use of pseudo "m=" 596 lines and identification tags in "a=mid:" attributes as defined in 598 [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as 599 defined in [RFC4566], but provide no semantics other than indicating 600 to which "m=" line a candidate belongs. Consequently, the receiving 601 agent MUST ignore the remaining content of the pseudo m-line. This 602 guarantees that the 'application/trickle-ice-sdpfrag' bodies do not 603 interfere with the Offer/Answer procedures as specified in [RFC3264]. 605 When sending the INFO request, the agent MAY, if already known to the 606 agent, include the same content into the pseudo m-line as for the 607 corresponding Offer or Answer. However, since Trickle-ICE might be 608 decoupled from the Offer/Answer negotiation this content might be 609 unknown to the agent. In this case, the agent MUST include the 610 following default values. 612 o The media is set to 'audio'. 614 o The port value is set to '9'. 616 o The proto value is set to 'RTP/AVP'. 618 o The fmt SHOULD appear only once and is set to '0' 620 Agents MUST include a pseudo "m=" line and an identification tag in a 621 "a=mid:" attribute for every "m=" line whose candidate list they 622 intend to update. Such "a=mid:" attributes MUST immediately precede 623 the list of candidates for that specific "m=" line. All 624 "a=candidate" or "a=end-of-candidates" attributes following an 625 "a=mid:" attribute, up until (and excluding) the next occurrence of 626 an "a=mid:" attribute, pertain to the "m=" line identified by that 627 identification tag. An "a=end-of-candidates" attribute, preceding 628 any "a=mid:" attributes, indicates the end of all trickling from that 629 agent, as opposed to end of trickling for a specific "m=" line, which 630 would be indicated by a media level "a=end-of-candidates" attribute. 632 The use of "a=mid:" attributes allows for a structure similar to the 633 one in SDP Offers and Answers where separate media-level and session- 634 level sections can be distinguished. In the current case, lines 635 preceding any "a=mid:" attributes are considered to be session-level. 636 Lines appearing in between or after "a=mid:" attributes will be 637 interpreted as media-level. 639 Note that while this specification uses the "a=mid:" attribute 640 from [RFC5888], it does not define any grouping semantics. 641 Consequently, using the "a=group:" attribute from that same 642 specification is neither needed nor used in Trickle ICE for SIP. 644 All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" 645 attributes that would allow mapping them to a specific ICE 646 generation. An agent MUST discard any received INFO requests 647 containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not 648 match those of the current ICE Negotiation Session. 650 The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the 651 same level as the ones in the Offer/Answer exchange. In other words, 652 if they were present as session-level attributes, they will also 653 appear at the beginning of all INFO message payloads, i.e. preceding 654 all "a=mid:" attributes. If they were originally exchanged as media 655 level attributes, potentially overriding session-level values, then 656 they will also be included in INFO message payloads, following the 657 corresponding "a=mid:" attribute. 659 Since the agent is not fully aware of the state of the ICE 660 Negotiation Session at its peer it MUST include all currently known 661 and used local candidates in every INFO request. I.e. all candidates 662 that were previously sent under the same combination of "a=ice-pwd:" 663 and "a=ice-ufrag:" need to be repeated. Although repeating all 664 candidates creates some overhead, it also allows easier handling of 665 problems that could arise from unreliable transports, like e.g. loss 666 of messages and reordering, which can be detected through the CSeq: 667 header field in the INFO request. 669 When receiving INFO requests carrying any candidates, agents will 670 therefore first identify and discard the attribute lines containing 671 candidates they have already received in previous INFO requests or in 672 the Offer/Answer exchange preceding them. Two candidates are 673 considered to be equal if their IP address port, transport and 674 component ID are the same. After identifying and discarding known 675 candidates, the ICE agents will then process the remaining, actually 676 new candidates according to the rules described in 677 [I-D.ietf-ice-trickle]. 679 Note: At the time of writing this specification there were ongoing 680 discussions if a functionality for removing already exchanged 681 candidates would be useful. Such a functionality is out of the scope 682 of this specification and most likely needs to be signaled by means 683 of a yet to be defined ICE extension, although it could in principle 684 be achieved quite easily, e.g. without anticipating any solution by 685 simply omitting a previously sent candidate from a subsequent INFO 686 message. However, if an implementation according to this 687 specification receives such an INFO message with a missing candidate 688 it MAY treat that as an exceptional case. Implementing appropriate 689 recovery procedures at the receiving side is RECOMMENDED for this 690 situation. Ignoring that a candidate was missing might be a sensible 691 strategy. 693 The following example shows the content of one sample candidate 694 delivering INFO request: 696 INFO sip:alice@example.com SIP/2.0 697 ... 698 Info-Package: trickle-ice 699 Content-type: application/sdp 700 Content-Disposition: Info-Package 701 Content-length: ... 703 a=ice-pwd:asd88fgpdd777uzjYhagZg 704 a=ice-ufrag:8hhY 705 m=audio 9 RTP/AVP 0 706 a=mid:1 707 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 708 a=candidate:2 1 UDP 1658497328 203.0.113.3 5000 typ srflx 709 raddr 10.0.1.1 rport 8998 710 a=end-of-candidates 711 m=audio 9 RTP/AVP 0 712 a=mid:2 713 a=candidate:2 1 UDP 1658497328 203.0.113.3 5002 typ srflx 714 raddr 10.0.1.1 rport 9000 715 a=end-of-candidates 717 5. Initial discovery of Trickle ICE support 719 SIP User Agents (UAs) that support and intend to use trickle ICE are 720 REQUIRED by [I-D.ietf-ice-trickle] to indicate that in their Offers 721 and Answers using the following attribute: "a=ice-options:trickle". 722 This makes discovery fairly straightforward for Answerers or for 723 cases where Offers need to be generated within existing dialogs 724 (i.e., when sending re-INVITE requests). In both scenarios prior SDP 725 would have provided the necessary information. 727 Obviously, prior SDP is not available at the time a first Offer is 728 being constructed and it is therefore impossible for ICE agents to 729 determine support for incremental provisioning that way. The 730 following options are suggested as ways of addressing this issue. 732 5.1. Provisioning support for Trickle ICE 734 In certain situations it may be possible for integrators deploying 735 Trickle ICE to know in advance that some or all endpoints reachable 736 from within the deployment will support Trickle ICE. This is likely 737 to be the case, for example, for WebRTC clients that will always be 738 communicating with other WebRTC clients or known Session Border 739 Controllers (SBC) with support for this specification. 741 While the exact mechanism for allowing such provisioning is out of 742 scope here, this specification encourages trickle ICE implementations 743 to allow the option in the way they find most appropriate. 745 5.2. Trickle ICE discovery with GRUU 747 [RFC3840] provides a way for SIP user agents to query for support of 748 specific capabilities using, among others, OPTIONS requests. GRUU 749 support on the other hand allows SIP requests to be addressed to 750 specific UAs (as opposed to arbitrary instances of an address of 751 record). Combining the two and using the "trickle-ice" option tag 752 defined in Section 10.6 provides SIP UAs with a way of learning the 753 capabilities of specific US instances and then addressing them 754 directly with INVITE requests that require SIP support. 756 Such targeted trickling may happen in different ways. One option 757 would be for a SIP UA to learn the GRUU instance ID of a peer through 758 presence and to then query its capabilities direction with an OPTIONS 759 request. Alternately, it can also just send an OPTIONS request to 760 the AOR it intends to contact and then inspect the returned 761 response(s) for support of both GRUU and Trickle ICE (Figure 9). 763 Alice Bob 764 | | 765 | OPTIONS sip:b1@example.com SIP/2.0 | 766 |-------------------------------------------------->| 767 | | 768 | 200 OK | 769 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 770 | ;audio;video|;trickle-ice;... | 771 |<--------------------------------------------------| 772 | | 773 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 774 |-------------------------------------------------->| 775 | | 776 | 183 (Answer) | 777 |<--------------------------------------------------| 778 | INFO/OK (Trickling) | 779 |<------------------------------------------------->| 780 | | 781 | ... | 782 | | 784 Figure 9: Trickle ICE support discovery with OPTIONS and GRUU 786 Confirming support for Trickle ICE through [RFC3840] gives SIP UAs 787 the options to engage in Full Trickle negotiation (as opposed to the 788 more lengthy Half Trickle) from the very first Offer they send. 790 5.3. Trickle ICE discovery through other protocols 792 Protocols like XMPP [RFC6120] define advanced discovery mechanisms 793 that allow specific features to be queried priory to actually 794 attempting to use them. Solutions like [RFC7081] define ways of 795 using SIP and XMPP together which also provides a way for dual stack 796 SIP+XMPP endpoints to make use of such features and verify Trickle 797 ICE support for a specific SIP endpoint through XMPP. [TODO expand 798 on a specific way to do this or declare as out of scope] 800 5.4. Fall-back to Half Trickle 802 In cases where none of the other mechanisms in this section are 803 acceptable, SIP UAs should use the Half Trickle mode defined in 804 [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions 805 the same way they would when using Vanilla ICE for SIP 806 [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually 807 sending an Offer, agents would first gather ICE candidates in a 808 blocking way and then send them all in that Offer. The blocking 809 nature of the process would likely imply that some amount of latency 810 will be accumulated and it is advised that agents try to anticipate 811 it where possible, like for example, when user actions indicate a 812 high likelihood for an imminent call (e.g., activity on a keypad or a 813 phone going off-hook). 815 Using Half Trickle would result in Offers that are compatible with 816 both Vanilla ICE SIP endpoints and legacy [RFC3264] endpoints. 818 STUN/Turn STUN/TURN 819 Servers Alice Bob Servers 820 | | | | 821 |<--------------| | | 822 | | | | 823 | | | | 824 | Candidate | | | 825 | | | | 826 | | | | 827 | Discovery | | | 828 | | | | 829 | | | | 830 |-------------->| INVITE (Offer) | | 831 | |---------------------------->| | 832 | | 183 (Answer) |-------------->| 833 | |<----------------------------| | 834 | | INFO (repeated candidates) | | 835 | |---------------------------->| | 836 | | | | 837 | | INFO (more candidates) | Candidate | 838 | |<----------------------------| | 839 | | Connectivity Checks | | 840 | |<===========================>| Discovery | 841 | | INFO (more candidates) | | 842 | |<----------------------------| | 843 | | Connectivity Checks |<--------------| 844 | |<===========================>| | 845 | | | | 846 | | 200 OK | | 847 | |<----------------------------| | 848 | | | | 849 | | 5245 SIP re-INVITE | | 850 | |---------------------------->| | 851 | | 200 OK | | 852 | |<----------------------------| | 853 | | | | 854 | | | | 855 | |<======= MEDIA FLOWS =======>| | 856 | | | | 858 Figure 10: Example - A typical (Half) Trickle ICE exchange with SIP 860 It is worth reminding that once a single Offer or Answer had been 861 exchanged within a specific dialog, support for Trickle ICE will have 862 been determined. No further use of Half Trickle will therefore be 863 necessary within that same dialog and all subsequent exchanges can 864 use the Full Trickle mode of operation. 866 6. Considerations for RTP and RTCP multiplexing 868 The following consideration describe options for Trickle-ICE in order 869 to give some guidance to implementors on how trickling can be 870 optimized with respect to providing RTCP candidates. 872 Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" 873 attribute for RTP/RTCP multiplexing [RFC5761] is already considered 874 in section 4.2. of [I-D.ietf-mmusic-ice-sip-sdp], respectively, as 875 well in [RFC5761] itself. These considerations are still valid for 876 Trickle ICE, however, trickling provides more flexibility for the 877 sequence of candidate exchange in case of RTCP multiplexing. 879 If the Offerer supports RTP/RTCP multiplexing exclusively as 880 specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that 881 document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" 882 and the "a=rtcp-mux" attributes. 884 While a Half Trickle Offerer would have to send an offer compliant to 885 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for 886 all components, this flexibility allows a Full Trickle Offerer to 887 initially send only RTP candidates (component 1) if it assumes that 888 RTCP multiplexing is supported by the Answerer. A Full Trickle 889 Offerer would need to start gathering and trickling RTCP candidates 890 (component 2) only after having received an indication in the answer 891 that the answerer unexpectedly does not support RTCP multiplexing. 893 A Trickle answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in 894 the application/trickle-ice-sdpfrag body it supports and uses RTP and 895 RTCP multiplexing. Trickle answerer MUST follow the guidance on the 896 usage of the "a=rtcp" attribute as given in 897 [I-D.ietf-mmusic-ice-sip-sdp] and Receipt of this attribute at the 898 Offerer in an INFO request prior to the Answer indicates that the 899 Answerer supports and uses RTP and RTCP multiplexing. The Offerer 900 can use this information e.g. for stopping gathering of RTCP 901 candidates and/or for freeing corresponding resources. 903 This behavior is illustrated by the following example offer that 904 indicates support for RTP and RTCP multiplexing. 906 v=0 907 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 908 s= 909 c=IN IP4 atlanta.example.com 910 t=0 0 911 a=ice-pwd:777uzjYhagZgasd88fgpdd 912 a=ice-ufrag:Yhh8 913 m=audio 10000 RTP/AVP 0 914 a=mid:1 915 a=rtcp-mux 916 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 918 Once the dialog is established as described in section Section 4.1 919 the Answerer sends the following INFO message. 921 INFO sip:alice@example.com SIP/2.0 922 ... 923 Info-Package: trickle-ice 924 Content-type: application/sdp 925 Content-Disposition: Info-Package 926 Content-length: ... 928 a=ice-pwd:asd88fgpdd777uzjYhagZg 929 a=ice-ufrag:8hhY 930 m=audio 9 RTP/AVP 0 931 a=mid:1 932 a=rtcp-mux 933 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 935 This INFO message indicates that the Answerer supports and uses RTP 936 and RTCP multiplexing as well. This allows the Offerer to omit 937 gathering of RTCP candidates or releasing already gathered RTCP 938 candidates. If the INFO message did not contain the a=rtcp-mux 939 attribute, the Offerer would have to gather RTCP candidates unless it 940 wants to wait until receipt of an Answer that eventually confirms 941 support or non-support for RTP and RTCP multiplexing. 943 7. Considerations for Media Multiplexing 945 The following consideration describe options for Trickle-ICE in order 946 to give some guidance to implementors on how trickling can be 947 optimized with respect to providing candidates in case of Media 948 Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed 949 that the reader is familiar with 950 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 952 ICE candidate exchange is already considered in section 11 of 953 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are 954 still valid for Trickle ICE, however, trickling provides more 955 flexibility for the sequence of candidate exchange, especially in 956 Full Trickle mode. 958 Except for bundle-only m-lines, a Half Trickle Offerer would have to 959 send an offer with candidates for all bundled m-lines. The 960 additional flexibility, however, allows a Full Trickle Offerer to 961 initially send only candidates for the m-line with the suggested 962 Offerer BUNDLE address. 964 Latest on receipt of the answer, the Offerer will detect if BUNDLE is 965 supported and if the suggested Offerer BUNDLE address was selected. 966 In this case the Offerer does not need to trickle further candidates 967 for the remaining m-lines in a bundle. However, if BUNDLE is not 968 supported, the Full Trickle Offerer needs to gather and trickle 969 candidates for the remaining m-lines as necessary. If the answerer 970 selects a Offerer BUNDLE address different from suggested Offerer 971 BUNDLE address, the Full Trickle Offerer needs to gather and trickle 972 candidates for the m-line that carries the selected Offerer BUNDLE 973 address. 975 A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute 976 [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle- 977 ice-sdpfrag body if it supports and uses bundling. When doing so, 978 the Answerer MUST include all identification-tags in the same order 979 that is used or will be used in the Answer. 981 Receipt of this attribute at the Offerer in an INFO request prior to 982 the Answer indicates that the Answerer supports and uses bundling. 983 The Offerer can use this information e.g. for stopping the gathering 984 of candidates for the remaining m-lines in a bundle and/or for 985 freeing corresponding resources. 987 This behaviour is illustrated by the following example offer that 988 indicates support for Media Multiplexing. 990 v=0 991 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 992 s= 993 c=IN IP4 atlanta.example.com 994 t=0 0 995 a=group:BUNDLE foo bar 996 a=ice-pwd:777uzjYhagZgasd88fgpdd 997 a=ice-ufrag:Yhh8 998 m=audio 10000 RTP/AVP 0 999 a=mid:foo 1000 a=rtpmap:0 PCMU/8000 1001 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1002 m=video 10002 RTP/AVP 31 1003 a=mid:bar 1004 a=rtpmap:31 H261/90000 1005 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1007 Once the dialog is established as described in section Section 4.1 1008 the Answerer sends the following INFO message. 1010 INFO sip:alice@example.com SIP/2.0 1011 ... 1012 Info-Package: trickle-ice 1013 Content-type: application/sdp 1014 Content-Disposition: Info-Package 1015 Content-length: ... 1017 a=group:BUNDLE foo bar 1018 a=ice-pwd:asd88fgpdd777uzjYhagZg 1019 a=ice-ufrag:8hhY 1020 m=audio 9 RTP/AVP 0 1021 a=mid:1 1022 a=rtcp-mux 1023 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 1024 m=audio 9 RTP/AVP 0 1025 a=mid:bar 1027 This INFO message indicates that the Answerer supports and uses Media 1028 Multiplexing as well. Note, that the second m-line shows the default 1029 values as specified in section Section 4.2, e.g. media set 'audio' 1030 although 'video' was offered. The receiving ICE agents needs to 1031 ignore these default values in the pseudo m-lines. 1033 The INFO message also indicates that the Answerer accepted the 1034 suggested Offerer Bundle Address. This allows the Offerer to omit 1035 gathering of RTP and RTCP candidates for the other m-lines or 1036 releasing already gathered candidates. If the INFO message did not 1037 contain the a=group:BUNDLE attribute, the Offerer would have to 1038 gather RTP and RTCP candidates for the other m-lines unless it wants 1039 to wait until receipt of an Answer that eventually confirms support 1040 or non-support for Media Multiplexing. 1042 Independent of using Full Trickle or Half Trickle mode, the rules 1043 from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and 1044 Answerer, when putting attributes in the application/trickle-ice- 1045 sdpfrag body. 1047 8. SDP 'end-of-candidate' Attribute 1049 This section defines a new SDP media-level and session-level 1050 attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' is a 1051 property attribute [RFC4566], and hence has no value. By including 1052 this attribute in an Offer or Answer the sending agent indicates that 1053 it will not trickle further candidates. The detailed SDP Offer/ 1054 Answer procedures for the 'end-of-candidate' attribute are specified 1055 in [I-D.ietf-ice-trickle]. 1057 Name: end-of-candidate 1059 Value: N/A 1061 Usage Level: media and session-level 1063 Charset Dependent: no 1065 Mux Category: IDENTICAL 1067 Example: a=end-of-candidate 1069 9. Content Type 'application/trickle-ice-sdpfrag' 1071 9.1. Overall Description 1073 A application/trickle-ice-sdpfrag body is used by the Trickle-ICE 1074 Info Package. It uses a subset of the possible SDP lines as defined 1075 by the grammar defined in [RFC4566]. A valid body uses only media 1076 descriptions and certain attributes that are needed and/or useful for 1077 trickling candidates. The content adheres to the following grammar. 1079 9.2. Grammar 1081 The grammar of an 'application/trickle-ice-sdpfrag' body is based the 1082 following ABNF [RFC5234]. It specifies the subset of existing SDP 1083 attributes, that are needed or useful for trickling candidates. 1085 ; Syntax 1086 trickle-ice-sdpfrag = session-level-fields 1087 pseudo-media-descriptions 1088 session-level-fields = [bundle-group-attribute CRLF] 1089 [ice-lite-attribute CRLF] 1090 ice-pwd-attribute CRLF 1091 ice-ufrag-attribute CRLF 1092 [ice-options-attribute CRLF] 1093 [ice-pacing-attribute CRLF] 1094 [end-of-candidates-attribute CRLF] 1095 extension-attribute-fields 1096 ; for future extensions 1098 ice-lite-attribute = %s"a=" ice-lite 1099 ice-pwd-attribute = %s"a=" ice-pwd-att 1100 ice-ufrag-attribute = %s"a=" ice-ufrag-att 1101 ice-pacing-attribute = %s"a=" ice-pacing-att 1102 ice-options-attribute = %s"a=" ice-options 1103 bundle-group-attribute = "a=group:" bundle-semantics 1104 *(SP identification-tag) 1105 bundle-semantics = "BUNDLE" 1106 end-of-candidates-attribute = %s"a=" end-of-candidates 1107 extension-attribute-fields = attribute-fields 1109 pseudo-media-descriptions = *( media-field 1110 trickle-ice-attribute-fields 1111 [extension-attribute-fields] ) 1112 ; for future extensions 1113 trickle-ice-attribute-fields = mid-attribute CRLF 1114 ["a=rtcp-mux" CRLF] 1115 ["a=rtcp-mux-only" CRLF] 1116 *(candidate-attributes CRLF) 1117 [ice-pwd-attribute CRLF] 1118 [ice-ufrag-attribute CRLF] 1119 [remote-candidate-attribute CRLF] 1120 [end-of-candidates-attribute CRLF] 1121 remote-candidate-attribute = %s"a=" remote-candidate-att 1122 candidate-attributes = %s"a=" candidate-attribute 1123 end-of-candidates = %s"end-of-candidates" 1125 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- 1126 pacing-att, ice-options, candidate-attribute remote-candidate-att 1127 from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute 1128 ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The 1129 indicator for case-sensitivity %s is defined in [RFC7405]. 1131 An Agent MUST ignore any received unknown extension-attribute-fields. 1133 10. Info Package 1135 10.1. Rationale - Why INFO? 1137 The decision to use SIP INFO requests as a candidate transport method 1138 is based primarily on their lightweight nature. Once a dialog has 1139 been established, INFO messages can be exchanged both ways with no 1140 restrictions on timing and frequency and no risk of collision. 1142 On the other hand, using Offer/Answer and UPDATE requests [RFC3311] 1143 introduces the following complications: 1145 Blocking of messages: [RFC3264] defines Offer/Answer as a strictly 1146 sequential mechanism. There can only be a maximum of one exchange 1147 at any point of time. Both sides cannot simultaneously send 1148 Offers nor can they generate multiple Offers prior to receiving an 1149 Answer. Using UPDATE requests for candidate transport would 1150 therefore imply the implementation of a candidate pool at every 1151 agent where candidates can be stored until it is once again that 1152 agent's "turn" to emit an Answer or a new Offer. Such an approach 1153 would introduce non-negligible complexity for no additional value. 1155 Elevated risk of glare: The sequential nature of Offer/Answer also 1156 makes it impossible for both sides to send Offers simultaneously. 1157 What's worse is that there are no mechanisms in SIP to actually 1158 prevent that. [RFC3261], where the situation of Offers crossing 1159 on the wire is described as "glare", only defines a procedure for 1160 addressing the issue after it has occurred. According to that 1161 procedure both Offers are invalidated and both sides need to retry 1162 the negotiation after a period between 0 and 4 seconds. The high 1163 likelihood for glare to occur and the average two second back-off 1164 intervals would imply Trickle ICE processing duration would not 1165 only fail to improve but actually exceed those of Vanilla ICE. 1167 INFO messages decouple the exchange of candidates from the Offer/ 1168 Answer negotiation and are subject to none of the glare issues 1169 described above, which makes them a very convenient and lightweight 1170 mechanism for asynchronous delivery of candidates. 1172 Using in-dialog INFO messages also provides a way of guaranteeing 1173 that candidates are delivered end-to-end, between the same entities 1174 that are actually in the process of initiating a session. Out-of- 1175 dialog alternatives would have implied requiring support for Globally 1176 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 1177 adoption levels, would have constituted too strong of constraint to 1178 the adoption of Trickle ICE. 1180 10.2. Overall Description 1182 This specification defines an Info Package for use by SIP user agents 1183 implementing Trickle ICE. INFO requests carry ICE candidates 1184 discovered after the peer user agents have confirmed mutual support 1185 for Trickle ICE. 1187 10.3. Applicability 1189 The purpose of the ICE protocol is to establish a media path in the 1190 presence of NAT and firewalls. The candidates are transported in 1191 INFO requests and are part of this establishment. 1193 Candidates sent by a Trickle ICE agent after the Offer, follow the 1194 same signaling path and reach the same entity as the Offer itself. 1195 While it is true that GRUUs can be used to achieve this, one of the 1196 goals of this specification is to allow operation of Trickle ICE in 1197 as many environments as possible including those without GRUU 1198 support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not 1199 satisfy this goal. 1201 10.4. Info Package Name 1203 This document defines a SIP Info Package as per [RFC6086]. The Info 1204 Package token name for this package is "trickle-ice" 1206 10.5. Info Package Parameters 1208 This document does not define any Info Package parameters. 1210 10.6. SIP Option Tags 1212 [RFC6086] allows Info Package specifications to define SIP option- 1213 tags. This specification extends the option-tag construct of the SIP 1214 grammar as follows: 1216 option-tag /= "trickle-ice" 1218 SIP entities that support this specification MUST place the 'trickle- 1219 ice' option-tag in a SIP Supported: header field within all SIP 1220 INVITE requests and responses. 1222 When responding to, or generating a SIP OPTIONS request a SIP entity 1223 MUST also include the 'trickle-ice' option-tag in a SIP Supported: 1224 header field. 1226 10.7. Info Message Body Parts 1228 Entities implementing this specification MUST include a payload of 1229 type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 all 1230 SIP INFO requests. The payload is used to convey SDP encoded ICE 1231 candidates. 1233 10.8. Info Package Usage Restrictions 1235 This document does not define any Info Package Usage Restrictions. 1237 10.9. Rate of INFO Requests 1239 A Trickle ICE Agent with many network interfaces might create a high 1240 rate of INFO requests if every newly detected candidate is trickled 1241 individually without aggregation. Implementor that are concerned 1242 about loss of packets in such a case might consider aggregating ICE 1243 candidates and sending INFOS only at some configurable intervals. 1245 10.10. Info Package Security Considerations 1247 See Section 12 1249 11. IANA Considerations 1251 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1252 document. Please replace "I-D.ietf-ice-trickle" with the RFC number 1253 of that document.] 1255 11.1. SDP 'end-of-candidate' Attribute 1257 This section defines a new SDP media-level and session-level 1258 attribute [RFC4566] , 'end-of-candidate'. 'end-of-candidate' is a 1259 property attribute [RFC4566] , and hence has no value. 1261 Name: end-of-candidate 1263 Value: N/A 1265 Usage Level: media and session 1267 Charset Dependent: no 1269 Purpose: The sender indicates that it will not trickle 1270 further candidates. 1272 O/A Procedures: "I-D.ietf-ice-trickle" defines the detailed 1273 SDP Offer/Answer procedures for 1274 the 'end-of-candidate' attribute. 1276 Mux Category: IDENTICAL 1278 Reference: RFCXXXX 1280 Example: 1282 a=end-of-candidate 1284 11.2. application/trickle-ice-sdpfrag MIME Type 1286 Type name: application 1288 Subtype name: trickle-ice-sdpfrag 1290 Required parameters: None. 1292 Optional parameters: None. 1294 Encoding considerations: 1296 SDP files are primarily UTF-8 format text. Although the 1297 initially defined content of a trickle-ice-sdpfrag body does 1298 only include ASCII characters, UTF-8 encoded content might be 1299 introduced via extension attributes. The "a=charset:" 1300 attribute may be used to signal the presence of other character 1301 sets in certain parts of a trickle-ice-sdpfrag body (see 1302 [RFC4566]). Arbitrary binary content cannot be directly 1303 represented in SDP or a trickle-ice-sdpfrag body. 1305 Security considerations: 1307 See [RFC4566]) and RFCXXXX 1309 Interoperability considerations: 1311 See RFCXXXX 1313 Published specification: 1315 See RFCXXXX 1317 Applications which use this media type: 1319 Voice over IP, video teleconferencing, streaming media, instant 1320 messaging, Trickle-ICE among others. 1322 Additional information: 1324 Magic number(s): none 1326 File extension(s): none 1328 Macintosh File Type Code(s): none 1330 Person and email address to contact for further information: 1332 IETF MMUSIC working group mmusic@ietf.org 1334 Intended usage: 1336 Trickle-ICE for SIP as specified in RFCXXXX. 1338 Author/Change controller: 1340 IETF MMUSIC working group mmusic@ietf.org 1342 11.3. SIP Info Package 'trickle-ice' 1344 This document defines a new SIP Info Package named 'trickle-ice' and 1345 updates the Info Packages Registry with the following entry. 1347 +-------------+-----------+ 1348 | Name | Reference | 1349 +-------------+-----------+ 1350 | trickle-ice | [RFCXXXX] | 1351 | | | 1352 +-------------+-----------+ 1354 11.4. SIP Option Tag 'trickle-ice' 1356 This specification registers a new SIP option tag 'trickle-ice' as 1357 per the guidelines in Section 27.1 of [RFC3261] and updates the 1358 "Option Tags" section of the SIP Parameter Registry with the 1359 following entry: 1361 +-------------+-------------------------------------+-----------+ 1362 | Name | Description | Reference | 1363 +-------------+-------------------------------------+-----------+ 1364 | trickle-ice | This option tag is used to indicate | [RFCXXXX] | 1365 | | that a UA supports and understands | | 1366 | | Trickle-ICE. | | 1367 +-------------+-------------------------------------+-----------+ 1369 12. Security Considerations 1371 The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], 1372 [RFC6086], [I-D.ietf-ice-trickle] apply. This document clarifies how 1373 the above specifications are used together for trickling candidates 1374 and does not create addtitional security risks. 1376 13. Acknowledgements 1378 The authors would like to thank Ayush Jain, Paul Kyzivat, Jonathan 1379 Lennox, Simon Perreault and Martin Thomson for reviewing and/or 1380 making various suggestions for improvements and optimizations. 1382 14. Change Log 1384 [RFC EDITOR NOTE: Please remove this section when publishing]. 1386 Changes from draft-ietf-mmusic-trickle-ice-sip-01 1388 o Editorial Clean up 1390 o IANA Consideration added 1392 o Security Consideration added 1394 o RTCP and BUNDLE Consideration added with rules for including 1395 "a=rtcp-mux" and "a=group: BUNDLLE" attributes 1397 o 3PCC Consideration added 1399 o Clarified that 18x w/o answer is sufficient to create a dialog 1400 that allows for trickling to start 1402 o Added remaining Info Package definition sections as outlined in 1403 section 10 of [RFC6086] 1405 o Added definition of application/sdpfrag making draft-ivov-mmusic- 1406 sdpfrag obsolete 1408 o Added pseudo m-lines as additional separator in sdpfrag bodies for 1409 Trickle ICE 1411 o Added ABNF for sdp-frag bodies and Trickle-ICE package 1413 Changes from draft-ietf-mmusic-trickle-ice-sip-02 1415 o Removed definition of application/sdpfrag 1417 o Replaced with new type application/trickle-ice-sdpfrag 1419 o RTCP and BUNDLE Consideration enhanced with some examples 1421 o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to 1422 normative reference 1424 o Removed reference to 4566bis 1426 o Addressed review comment from Simon Perreault 1428 Changes from draft-ietf-mmusic-trickle-ice-sip-03 1429 o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis 1430 and draft-ietf-mmusic-ice-sip-sdp 1432 o Corrected Figure 10, credits to Ayush Jain for finding the bug 1434 o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- 1435 ice-sip-sdp 1437 o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- 1438 mux-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive 1440 o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for 1441 the application/trickle-ice-sdpfrag body 1443 Changes from draft-ietf-mmusic-trickle-ice-sip-04 1445 o considered comments from Christer Holmberg 1447 o corrected grammar for INFO package, such that ice-ufrag/pwd are 1448 also allowed on media-level as specified in 1449 [I-D.ietf-mmusic-ice-sip-sdp] 1451 o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] 1453 o Added formal definition for the end-of-candidates attribute 1455 Changes from draft-ietf-mmusic-trickle-ice-sip-05 1457 o considered further comments from Christer Holmberg 1459 o editorial comments on section 3 addressed 1461 o moved section 3.1 to section 10.1 and applied some edits 1463 o replaced the term "previously sent candidates" with "currently 1464 known and used candidates". 1466 Changes from draft-ietf-mmusic-trickle-ice-sip-06 1468 o editorial fixes 1470 o additional text on the content of the INFO messages. 1472 o recommendation on what to do if a previously sent candidate is 1473 unexpectedly missing in a subsequent INFO 1475 o terminology alignment with draft-ietf-ice-trickle-07 1477 15. References 1479 15.1. Normative References 1481 [I-D.ietf-ice-trickle] 1482 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 1483 "Trickle ICE: Incremental Provisioning of Candidates for 1484 the Interactive Connectivity Establishment (ICE) 1485 Protocol", draft-ietf-ice-trickle-07 (work in progress), 1486 February 2017. 1488 [I-D.ietf-mmusic-ice-sip-sdp] 1489 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using 1490 Interactive Connectivity Establishment (ICE) with Session 1491 Description Protocol (SDP) offer/answer and Session 1492 Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- 1493 sdp-11 (work in progress), January 2017. 1495 [I-D.ietf-mmusic-mux-exclusive] 1496 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 1497 Multiplexing using SDP", draft-ietf-mmusic-mux- 1498 exclusive-11 (work in progress), February 2017. 1500 [I-D.ietf-mmusic-rfc5245bis] 1501 Keranen, A. and J. Rosenberg, "Interactive Connectivity 1502 Establishment (ICE): A Protocol for Network Address 1503 Translator (NAT) Traversal", draft-ietf-mmusic- 1504 rfc5245bis-05 (work in progress), September 2015. 1506 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1507 Holmberg, C., Alvestrand, H., and C. Jennings, 1508 "Negotiating Media Multiplexing Using the Session 1509 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1510 negotiation-36 (work in progress), October 2016. 1512 [I-D.ietf-mmusic-sdp-mux-attributes] 1513 Nandakumar, S., "A Framework for SDP Attributes when 1514 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1515 (work in progress), December 2016. 1517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1518 Requirement Levels", BCP 14, RFC 2119, 1519 DOI 10.17487/RFC2119, March 1997, 1520 . 1522 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1523 A., Peterson, J., Sparks, R., Handley, M., and E. 1524 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1525 DOI 10.17487/RFC3261, June 2002, 1526 . 1528 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1529 Provisional Responses in Session Initiation Protocol 1530 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1531 . 1533 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1534 with Session Description Protocol (SDP)", RFC 3264, 1535 DOI 10.17487/RFC3264, June 2002, 1536 . 1538 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1539 in Session Description Protocol (SDP)", RFC 3605, 1540 DOI 10.17487/RFC3605, October 2003, 1541 . 1543 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1544 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1545 July 2006, . 1547 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1548 Specifications: ABNF", STD 68, RFC 5234, 1549 DOI 10.17487/RFC5234, January 2008, 1550 . 1552 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1553 Control Packets on a Single Port", RFC 5761, 1554 DOI 10.17487/RFC5761, April 2010, 1555 . 1557 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1558 Protocol (SDP) Grouping Framework", RFC 5888, 1559 DOI 10.17487/RFC5888, June 2010, 1560 . 1562 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1563 Initiation Protocol (SIP) INFO Method and Package 1564 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1565 . 1567 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1568 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1569 . 1571 15.2. Informative References 1573 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1574 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1575 2002, . 1577 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1578 "Indicating User Agent Capabilities in the Session 1579 Initiation Protocol (SIP)", RFC 3840, 1580 DOI 10.17487/RFC3840, August 2004, 1581 . 1583 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1584 Agent URIs (GRUUs) in the Session Initiation Protocol 1585 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 1586 . 1588 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1589 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1590 March 2011, . 1592 [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: 1593 Combined Use of the Session Initiation Protocol (SIP) and 1594 the Extensible Messaging and Presence Protocol (XMPP)", 1595 RFC 7081, DOI 10.17487/RFC7081, November 2013, 1596 . 1598 Authors' Addresses 1600 Emil Ivov 1601 Jitsi 1602 Strasbourg 67000 1603 France 1605 Phone: +33 6 72 81 15 55 1606 Email: emcho@jitsi.org 1608 Thomas Stach 1609 Unaffiliated 1610 Vienna 1130 1611 Austria 1613 Email: thomass.stach@gmail.com 1614 Enrico Marocco 1615 Telecom Italia 1616 Via G. Reiss Romoli, 274 1617 Turin 10148 1618 Italy 1620 Email: enrico.marocco@telecomitalia.it 1622 Christer Holmberg 1623 Ericsson 1624 Hirsalantie 11 1625 Jorvas 02420 1626 Finland 1628 Email: christer.holmberg@ericsson.com