idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2727 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 1341, but not defined == Unused Reference: 'RFC7405' is defined on line 1533, 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-04 == 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-36 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-14 ** 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: May 4, 2017 Unaffiliated 6 E. Marocco 7 Telecom Italia 8 C. Holmberg 9 Ericsson 10 October 31, 2016 12 A Session Initiation Protocol (SIP) usage for Trickle ICE 13 draft-ietf-mmusic-trickle-ice-sip-06 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 May 4, 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. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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] 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 of them. 153 3. Protocol Overview 155 Using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the ICE 156 candidates are exchanged using SDP Offer/Answer as per [RFC3264]. 157 This specification defines an additional mechanism where candidates 158 can be exchanged using SIP INFO messages and a newly defined Info 159 Package [RFC6086]. This allows ICE candidates to also be sent in 160 parallel to an ongoing Offer/Answer negotiation and/or after the 161 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 first Offers to contain a complete set of ICE candidates 225 and only using incremental provisioning for the rest of the sessions. 227 While using Half Trickle does provide a working solution it also 228 comes at the price of increased latency. Section 5 therefore makes 229 several alternative suggestions that enable SIP UAs to engage in Full 230 Trickle right from their first Offer: Section 5.1 discusses the use 231 of on-line provisioning as a means of allowing use of Trickle ICE for 232 all endpoints in controlled environments. Section 5.2 describes 233 anticipatory discovery for implementations that actually do support 234 GRUU and UA Capabilities and Section 5.4 discusses the implementation 235 and use of Half Trickle by SIP UAs where none of the above are an 236 option. 238 3.2. Relationship with the Offer/Answer Model 240 From the perspective of all SIP middle boxes and proxies, and with 241 the exception of the actual INFO messages, signaling in general and 242 Offer/Answer exchanges in particular would look the same way for 243 Trickle ICE as they would for ICE for SIP 244 [I-D.ietf-mmusic-ice-sip-sdp]. 246 +-------------------------------+ +-------------------------------+ 247 | Alice +--------------+ | | +--------------+ Bob | 248 | | Offer/Answer | | | | Offer/Answer | | 249 | +-------+ | Module | | | | Module | +-------+ | 250 | | ICE | +--------------+ | | +--------------+ | ICE | | 251 | | Agent | | | | | | Agent | | 252 | +-------+ | | | | +-------+ | 253 +-------------------------------+ +-------------------------------+ 254 | | | | 255 | | INVITE (Offer) | | 256 | |--------------------->| | 257 | | 183 (Answer) | | 258 | |<---------------------| | 259 | | | | 260 | | 261 | SIP INFO (more candidates) | 262 |----------------------------------------------------->| 263 | SIP INFO (more candidates) | 264 |<-----------------------------------------------------| 265 | | 266 | STUN Binding Requests/Responses | 267 |----------------------------------------------------->| 268 | STUN Binding Requests/Responses | 269 |<-----------------------------------------------------| 270 | | 271 | | | | 272 | | 5245 SIP re-INVITE | | 273 | |--------------------->| | 274 | | 200 OK | | 275 | |<---------------------| | 277 Figure 2: Distinguishing between Trickle ICE and traditional 278 signaling. 280 From an architectural viewpoint, as displayed on Figure 2, exchanging 281 candidates through SIP INFO requests could be represented as 282 signaling between ICE agents and not between Offer/Answer modules of 283 SIP User Agents. Then, such INFO requests do not impact the state of 284 the Offer/Answer transaction other than providing additional 285 candidates. Consequently, INFO requests are not considered Offers or 286 Answers. Nevertheless, candidates that have been exchanged using 287 INFO SHALL be included in subsequent Offers or Answers. The version 288 number in the "o=" line of that subsequent offer would need to be 289 incremented by 1 per the rules in [RFC3264]. 291 4. Incremental Signaling of ICE candidates 293 Trickle ICE agents will construct Offers and Answers as specified in 294 [I-D.ietf-ice-trickle] with the following additional SIP-specific 295 additions: 297 1. Trickle ICE agents MUST indicate support for Trickle ICE by 298 including the option-tag 'trickle-ice' in a SIP Supported: header 299 field within all SIP INVITE requests and responses. 301 2. Trickle ICE agents MAY exchange additional ICE candidates using 302 INFO requests within an existing INVITE dialog usage (including 303 an early dialog) as specified in [RFC6086]. The INFO messages 304 carry an Info-Package: trickle-ice. Trickle ICE agents MUST be 305 prepared to receive INFO requests within that same dialog usage, 306 containing additional candidates or an indication for the end of 307 such candidates 309 3. Trickle ICE agents MAY exchange additional ICE candidates before 310 the Answerer has sent the Answer provided that an invite dialog 311 usage is established at both Trickle ICE agents. Note that in 312 case of forking multiple early dialogs will exist. 314 The following section provide further details on how Trickle ICE 315 agents establish the INVITE dialog usage such that they can trickle 316 candidates. 318 4.1. Establishing the dialog 320 In order for SIP UAs to be able to start trickling, the following two 321 conditions need to be satisfied: 323 o Trickle ICE support in the peer agent MUST be confirmed. 325 o The dialog at both sides MUST be in early or confirmed state. 327 Section 5 discusses in detail the various options for satisfying the 328 first of the above conditions. Regardless of those mechanisms 329 however, agents are certain to have a clear understanding of whether 330 their peers support trickle ICE once an Offer and an Answer have been 331 exchanged, which also allows for ICE processing to commence (see 332 Figure 3). 334 4.1.1. Asserting dialog state through reliable Offer/Answer delivery 335 Alice Bob 336 | | 337 | INVITE (Offer) | 338 |------------------------>| 339 | 183 (Answer) | 340 |<------------------------| 341 | PRACK/OK | 342 |------------------------>| 343 | | 344 +----------------------------------------+ 345 |Alice and Bob know that both can trickle| 346 |and know that the dialog is in the early| 347 |state. Send INFO! | 348 +----------------------------------------+ 349 | | 350 | INFO/OK (+SRFLX Cand.) | 351 |------------------------>| 352 | INFO/OK (+SRFLX Cand.) | 353 |<------------------------| 354 | | 356 Figure 3: SIP Offerer can freely trickle as soon as it receives an 357 Answer. 359 Satisfying both conditions is also relatively trivial for ICE agents 360 that have sent an Offer in an INVITE and that have received an Answer 361 in a reliable provisional response. It is guaranteed to have 362 confirmed support for Trickle ICE within the Answerer (or lack 363 thereof) and to have fully initialized the SIP dialog at both ends. 364 Offerers and Answerers in the above situation can therefore freely 365 commence trickling within the newly established dialog. 367 4.1.2. Asserting dialog state through unreliable Offer/Answer delivery 369 The situation is a bit more delicate for agents that have received an 370 Offer in an INVITE request and have sent an Answer in an unreliable 371 provisional response because, once the response has been sent, the 372 Answerer does no know when or if it has been received (Figure 4). 374 Alice Bob 375 | | 376 | INVITE (Offer) | 377 |------------------------>| 378 | 183 (Answer) | 379 |<------------------------| 380 | | 381 | +----------------------+ 382 | |Bob: I don't know if | 383 | |Alice got my 183 or if| 384 | |her dialog is already | 385 | |in the early state. | 386 | | Can I send INFO??? | 387 | +----------------------+ 388 | | 390 Figure 4: A SIP UA that sent an Answer in an unreliable provisional 391 response does not know if it was received and if the dialog at the 392 side of the Offerer has entered the early state 394 In order to clear this ambiguity as soon as possible, the answerer 395 needs to retransmit the provisional response with the exponential 396 back-off timers described in [RFC3262]. Retransmits MUST cease on 397 receipt of a INFO request or on transmission of the answer in a 2xx 398 response. This is similar to the procedure described in section 399 13.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding 400 Request is replaced by the INFO request. 402 The Offerer MUST send a Trickle ICE INFO request as soon as it 403 receives an SDP Answer in an unreliable provisional response. This 404 INFO message MUST repeat the candidates that were already provided in 405 the Offer (as would be the case when Half Trickle is performed or 406 when new candidates have not been learned since then) and/or they MAY 407 also deliver new candidates (if available). An end-of-candidates 408 indication MAY be included in case candidate discovery has ended in 409 the mean time. 411 As soon as an Answerer has received such an INFO request, the 412 Answerer has an indication that a dialog is well established at both 413 ends and MAY begin trickling (Figure 5). Note: The +SRFLX in 414 Figure 5 indicates that additionally newly learned server-reflexive 415 candidates are includes. 417 Alice Bob 418 | | 419 | INVITE (Offer) | 420 |------------------------>| 421 | 183 (Answer) | 422 |<------------------------| 423 | INFO/OK (+SRFLX Cand.) | 424 |------------------------>| 425 | | 426 | +----------------------+ 427 | |Bob: Now I know Alice| 428 | | is ready. Send INFO! | 429 | +----------------------+ 430 | INFO/OK (+SRFLX Cand.) | 431 |<------------------------| 432 | | 433 | 200/ACK (Answer) | 434 |<------------------------| 436 Figure 5: A SIP UA that received an INFO request after sending an 437 unreliable provisional response knows that the dialog at the side of 438 the receiver has entered the early state 440 When sending the Answer in the 200 OK response, the Answerer MUST 441 repeat exactly the same Answer that was previously sent in the 442 unreliable provisional response in order to fulfill the corresponding 443 requirements in [RFC3264]. In other words, that Offerer needs to be 444 prepared to receive fewer candidates in that repeated Answer than 445 previously exchanged via trickling. 447 4.1.3. Initiating Trickle ICE without an SDP Answer 449 The possibility to convey arbitrary candidates in INFO message bodies 450 allows ICE agents to initiate trickling without actually sending an 451 Answer. Trickle ICE Agents MAY therefore respond to INVITEs with 452 provisional responses without an SDP Answer. Such provisional 453 responses serve for establishing an early dialog. 455 Agents that choose to establish the dialog in this way, MUST 456 retransmit these responses with the exponential back-off timers 457 described in [RFC3262]. Retransmits MUST cease on receipt of an INFO 458 request or on transmission of the answer in a 2xx response. This is 459 again similar to the procedure described in section 12.1.1 of 460 [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is not yet 461 provided. 463 Alice Bob 464 | | 465 | INVITE (Offer) | 466 |------------------------>| 467 | 183 (-) | 468 |<------------------------| 469 | INFO/OK (SRFLX Cand.) | 470 |------------------------>| 471 | | 472 | +----------------------+ 473 | |Bob: Now I know again| 474 | | that Alice is ready. | 475 | | Send INFO! | 476 | +----------------------+ 477 | INFO/OK (SRFLX Cand.) | 478 |<------------------------| 479 | 183 (Answer) opt. | 480 |<------------------------| 481 | INFO/OK (SRFLX Cand.) | 482 |<------------------------| 483 | 200/ACK (Answer) | 484 |<------------------------| 486 Figure 6: A SIP UA sends an unreliable provisional response without 487 an Answer for establishing an early dialog 489 When sending the Answer the agent MUST repeat all currently known and 490 used candidates, if any, and MAY include all newly gathered 491 candidates since the last INFO request was sent. If that Answer was 492 sent in a unreliable provisional response, the Answerers MUST repeat 493 exactly the same Answer in the 200 OK response in order to fulfill 494 the corresponding requirements in [RFC3264]. In other words, an 495 Offerer needs to be prepared to receive fewer candidates in that 496 repeated Answer than previously exchanged via trickling. 498 4.1.4. Considerations for 3PCC 500 Agents that have sent an Offer in a reliable provisional response and 501 that receive an Answer in a PRACK are also in a situation where 502 support for Trickle ICE is confirmed and the SIP dialog is guaranteed 503 to be in a state that would allow in-dialog INFO requests (see 504 Figure 7). 506 Alice Bob 507 | | 508 | INVITE | 509 |------------------------>| 510 | 183 (Offer) | 511 |<------------------------| 512 | PRACK (Answer) | 513 |------------------------>| 514 | | 515 | +----------------------+ 516 | |Bob: I know Alice can| 517 | |trickle and I know her| 518 | |dialog is in the early| 519 | |state. Send INFO! | 520 | +----------------------+ 521 | | 522 | INFO/OK (SRFLX Cand.) | 523 |<------------------------| 524 | | 525 | INFO/OK (SRFLX Cand.) | 526 |------------------------>| 527 | 200 OK/ACK | 528 |<------------------------| 530 Figure 7: A SIP Offerer in a 3PCC scenario can also freely start 531 trickling as soon as it receives an Answer. 533 Trickle Agents that send an Offer in a 200 OK and receive an Answer 534 in an ACK can still create a dialog and confirm support for Trickle 535 ICE by sending an unreliable provisional response similar to 536 Section 4.1.3. According to [RFC3261], this unreliable response MUST 537 NOT contain an Offer. 539 The Trickle Agent (at the UAS) retransmits the provisional response 540 with the exponential back-off timers described in [RFC3262]. 541 Retransmits MUST cease on receipt of a INFO request or on 542 transmission of the answer in a 2xx response. The peer Trickle Agent 543 (at the UAC) MUST send a Trickle ICE INFO request as soon as they 544 receive an unreliable provisional response (see Figure 8). 546 Alice Bob 547 | | 548 | INVITE | 549 |------------------------>| 550 | 183 (-) | 551 |<------------------------| 552 | INFO/OK (SRFLX Cand.) | 553 |------------------------>| 554 | | 555 | +-----------------------+ 556 | |Bob: I know Alice can | 557 | |trickle and I know her | 558 | |dialog is in the early | 559 | |state. | 560 | |INFO can be sent. | 561 | +-----------------------+ 562 | | 563 | INFO/OK (SRFLX Cand.) | 564 |<------------------------| 565 | | 566 | 200 (Offer) | 567 |<------------------------| 568 | ACK (Answer) | 569 |------------------------>| 570 | | 572 Figure 8: A SIP UAC in a 3PCC scenario can also freely start 573 trickling as soon as it receives an unreliable provisional response. 575 4.2. Delivering candidates in INFO messages 577 Whenever new ICE candidates become available for sending, agents 578 would encode them in "a=candidate" lines as described by 579 [I-D.ietf-ice-trickle]. For example: 581 a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx 582 raddr 10.0.1.1 rport 8998 584 The use of SIP INFO requests happens within the context of the Info 585 Package as defined Section 10. The MIME type for their payload MUST 586 be set to 'application/trickle-ice-sdpfrag' as defined in Section 9. 588 Since neither the "a=candidate" nor the "a=end-of-candidates" 589 attributes contain information that would allow correlating them to a 590 specific "m=" line, this is handled through the use of pseudo "m=" 591 lines and identification tags in "a=mid:" attributes as defined in 593 [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as 594 defined in [RFC4566], but provide no semantics other than indicating 595 to which "m=" line a candidate belongs. Consequently, the receiving 596 agent MUST ignore the remaining content of the pseudo m-line. This 597 guarantees that the 'application/trickle-ice-sdpfrag' bodies do not 598 interfere with the Offer/Answer procedures as specified in [RFC3264]. 600 When sending the INFO request, the agent MAY, if already known to the 601 agent, include the same content into the pseudo m-line as for the 602 corresponding Offer or Answer. However, since Trickle-ICE might be 603 decoupled from the Offer/Answer negotiation this content might be 604 unknown to the agent. In this case, the agent MUST include the 605 following default values. 607 o The media is set to 'audio'. 609 o The port value is set to '9'. 611 o The proto value is set to 'RTP/AVP'. 613 o The fmt SHOULD appear only once and is set to '0' 615 Agents MUST include a pseudo "m=" line and an identification tag in a 616 "a=mid:" attribute for every "m=" line whose candidate list they 617 intend to update. Such "a=mid:" attributes MUST immediately precede 618 the list of candidates for that specific "m=" line. All 619 "a=candidate" or "a=end-of-candidates" attributes following an 620 "a=mid:" attribute, up until (and excluding) the next occurrence of 621 an "a=mid:" attribute, pertain to the "m=" line identified by that 622 identification tag. An "a=end-of-candidates" attribute, preceding 623 any "a=mid:" attributes, indicates the end of all trickling from that 624 agent, as opposed to end of trickling for a specific "m=" line, which 625 would be indicated by a media level "a=end-of-candidates" attribute. 627 The use of "a=mid:" attributes allows for a structure similar to the 628 one in SDP Offers and Answers where separate media-level and session- 629 level sections can be distinguished. In the current case, lines 630 preceding any "a=mid:" attributes are considered to be session-level. 631 Lines appearing in between or after "a=mid:" attributes will be 632 interpreted as media-level. 634 Note that while this specification uses the "a=mid:" attribute 635 from [RFC5888], it does not define any grouping semantics. 636 Consequently, using the "a=group:" attribute from that same 637 specification is neither needed nor used in Trickle ICE for SIP. 639 All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" 640 attributes that would allow mapping them to a specific ICE 641 generation. An agent MUST discard any received INFO requests 642 containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not 643 match those of the current ICE processing session. 645 The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the 646 same level as the ones in the Offer/Answer exchange. In other words, 647 if they were present as session-level attributes there, they will 648 also appear at the beginning of all INFO message payloads, preceding 649 all "a=mid:" attributes. If they were originally exchanged as media 650 level attributes, potentially overriding session-level values, then 651 they will also be included in INFO message payloads, following the 652 corresponding "a=mid:" attribute. 654 In every INFO request agents MUST include all currently known and 655 used local candidates. This allows easier handling of problems that 656 could arise from unreliable transports, like e.g. loss of messages 657 and reordering. Mis-ordering can be detected through the CSeq: 658 header field in the INFO request. 660 When receiving INFO requests carrying any candidates, agents will 661 therefore first identify and discard the SDP lines containing 662 candidates they have already received in previous INFO requests or in 663 the Offer/Answer exchange preceding them. Two candidates are 664 considered to be equal if their IP address port, transport and 665 component ID are the same. After identifying and discarding known 666 candidates, the ICE agents will then receive and process the 667 remaining, actually new candidates according to the rules described 668 in [I-D.ietf-ice-trickle]. 670 The following example shows the content of one sample candidate 671 delivering INFO request: 673 INFO sip:alice@example.com SIP/2.0 674 ... 675 Info-Package: trickle-ice 676 Content-type: application/sdp 677 Content-Disposition: Info-Package 678 Content-length: ... 680 a=ice-pwd:asd88fgpdd777uzjYhagZg 681 a=ice-ufrag:8hhY 682 m=audio 9 RTP/AVP 0 683 a=mid:1 684 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 685 a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx 686 raddr 10.0.1.1 rport 8998 687 a=end-of-candidates 688 m=audio 9 RTP/AVP 0 689 a=mid:2 690 a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx 691 raddr 10.0.1.1 rport 9000 692 a=end-of-candidates 694 5. Initial discovery of Trickle ICE support 696 SIP User Agents (UAs) that support and intend to use trickle ICE are 697 REQUIRED by [I-D.ietf-ice-trickle] to indicate that in their Offers 698 and Answers using the following attribute: "a=ice-options:trickle". 699 This makes discovery fairly straightforward for Answerers or for 700 cases where Offers need to be generated within existing dialogs 701 (i.e., when sending re-INVITE requests). In both scenarios prior SDP 702 would have provided the necessary information. 704 Obviously, prior SDP is not available at the time a first Offer is 705 being constructed and it is therefore impossible for ICE agents to 706 determine support for incremental provisioning that way. The 707 following options are suggested as ways of addressing this issue. 709 5.1. Provisioning support for Trickle ICE 711 In certain situations it may be possible for integrators deploying 712 Trickle ICE to know in advance that some or all endpoints reachable 713 from within the deployment will support Trickle ICE. This is likely 714 to be the case, for example, for WebRTC clients that will always be 715 communicating with other WebRTC clients or known Session Border 716 Controllers (SBC) with support for this specification. 718 While the exact mechanism for allowing such provisioning is out of 719 scope here, this specification encourages trickle ICE implementations 720 to allow the option in the way they find most appropriate. 722 5.2. Trickle ICE discovery with GRUU 724 [RFC3840] provides a way for SIP user agents to query for support of 725 specific capabilities using, among others, OPTIONS requests. GRUU 726 support on the other hand allows SIP requests to be addressed to 727 specific UAs (as opposed to arbitrary instances of an address of 728 record). Combining the two and using the "trickle-ice" option tag 729 defined in Section 10.6 provides SIP UAs with a way of learning the 730 capabilities of specific US instances and then addressing them 731 directly with INVITE requests that require SIP support. 733 Such targeted trickling may happen in different ways. One option 734 would be for a SIP UA to learn the GRUU instance ID of a peer through 735 presence and to then query its capabilities direction with an OPTIONS 736 request. Alternately, it can also just send an OPTIONS request to 737 the AOR it intends to contact and then inspect the returned 738 response(s) for support of both GRUU and Trickle ICE (Figure 9). 740 Alice Bob 741 | | 742 | OPTIONS sip:b1@example.com SIP/2.0 | 743 |-------------------------------------------------->| 744 | | 745 | 200 OK | 746 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 747 | ;audio;video|;trickle-ice;... | 748 |<--------------------------------------------------| 749 | | 750 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 751 |-------------------------------------------------->| 752 | | 753 | 183 (Answer) | 754 |<--------------------------------------------------| 755 | INFO/OK (Trickling) | 756 |<------------------------------------------------->| 757 | | 758 | ... | 759 | | 761 Figure 9: Trickle ICE support discovery with OPTIONS and GRUU 763 Confirming support for Trickle ICE through [RFC3840] gives SIP UAs 764 the options to engage in Full Trickle negotiation (as opposed to the 765 more lengthy Half Trickle) from the very first Offer they send. 767 5.3. Trickle ICE discovery through other protocols 769 Protocols like XMPP [RFC6120] define advanced discovery mechanisms 770 that allow specific features to be queried priory to actually 771 attempting to use them. Solutions like [RFC7081] define ways of 772 using SIP and XMPP together which also provides a way for dual stack 773 SIP+XMPP endpoints to make use of such features and verify Trickle 774 ICE support for a specific SIP endpoint through XMPP. [TODO expand 775 on a specific way to do this or declare as out of scope] 777 5.4. Fall-back to Half Trickle 779 In cases where none of the other mechanisms in this section are 780 acceptable, SIP UAs should use the Half Trickle mode defined in 781 [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions 782 the same way they would when using Vanilla ICE for SIP 783 [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually 784 sending an Offer, agents would first gather ICE candidates in a 785 blocking way and then send them all in that Offer. The blocking 786 nature of the process would likely imply that some amount of latency 787 will be accumulated and it is advised that agents try to anticipate 788 it where possible, like for example, when user actions indicate a 789 high likelihood for an imminent call (e.g., activity on a keypad or a 790 phone going off-hook). 792 Using Half Trickle would result in Offers that are compatible with 793 both Vanilla ICE SIP endpoints and legacy [RFC3264] endpoints. 795 STUN/Turn STUN/TURN 796 Servers Alice Bob Servers 797 | | | | 798 |<--------------| | | 799 | | | | 800 | | | | 801 | Candidate | | | 802 | | | | 803 | | | | 804 | Discovery | | | 805 | | | | 806 | | | | 807 |-------------->| INVITE (Offer) | | 808 | |---------------------------->| | 809 | | 183 (Answer) |-------------->| 810 | |<----------------------------| | 811 | | INFO (repeated candidates) | | 812 | |---------------------------->| | 813 | | | | 814 | | INFO (more candidates) | Candidate | 815 | |<----------------------------| | 816 | | Connectivity Checks | | 817 | |<===========================>| Discovery | 818 | | INFO (more candidates) | | 819 | |<----------------------------| | 820 | | Connectivity Checks |<--------------| 821 | |<===========================>| | 822 | | | | 823 | | 200 OK | | 824 | |<----------------------------| | 825 | | | | 826 | | 5245 SIP re-INVITE | | 827 | |---------------------------->| | 828 | | 200 OK | | 829 | |<----------------------------| | 830 | | | | 831 | | | | 832 | |<======= MEDIA FLOWS =======>| | 833 | | | | 835 Figure 10: Example - A typical (Half) Trickle ICE exchange with SIP 837 It is worth reminding that once a single Offer or Answer had been 838 exchanged within a specific dialog, support for Trickle ICE will have 839 been determined. No further use of Half Trickle will therefore be 840 necessary within that same dialog and all subsequent exchanges can 841 use the Full Trickle mode of operation. 843 6. Considerations for RTP and RTCP multiplexing 845 The following consideration describe options for Trickle-ICE in order 846 to give some guidance to implementors on how trickling can be 847 optimized with respect to providing RTCP candidates. 849 Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" 850 attribute for RTP/RTCP multiplexing [RFC5761] is already considered 851 in section 4.2. of [I-D.ietf-mmusic-ice-sip-sdp], respectively, as 852 well in [RFC5761] itself. These considerations are still valid for 853 Trickle ICE, however, trickling provides more flexibility for the 854 sequence of candidate exchange in case of RTCP multiplexing. 856 If the Offerer supports RTP/RTCP multiplexing exclusively as 857 specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that 858 document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" 859 and the "a=rtcp-mux" attributes. 861 While a Half Trickle Offerer would have to send an offer compliant to 862 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for 863 all components, this flexibility allows a Full Trickle Offerer to 864 initially send only RTP candidates (component 1) if it assumes that 865 RTCP multiplexing is supported by the Answerer. A Full Trickle 866 Offerer would need to start gathering and trickling RTCP candidates 867 (component 2) only after having received an indication in the answer 868 that the answerer unexpectedly does not support RTCP multiplexing. 870 A Trickle answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in 871 the application/trickle-ice-sdpfrag body it supports and uses RTP and 872 RTCP multiplexing. Trickle answerer MUST follow the guidance on the 873 usage of the "a=rtcp" attribute as given in 874 [I-D.ietf-mmusic-ice-sip-sdp] and Receipt of this attribute at the 875 Offerer in an INFO request prior to the Answer indicates that the 876 Answerer supports and uses RTP and RTCP multiplexing. The Offerer 877 can use this information e.g. for stopping gathering of RTCP 878 candidates and/or for freeing corresponding resources. 880 This behavior is illustrated by the following example offer that 881 indicates support for RTP and RTCP multiplexing. 883 v=0 884 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 885 s= 886 c=IN IP4 atlanta.example.com 887 t=0 0 888 a=ice-pwd:777uzjYhagZgasd88fgpdd 889 a=ice-ufrag:Yhh8 890 m=audio 10000 RTP/AVP 0 891 a=mid:1 892 a=rtcp-mux 893 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 895 Once the dialog is established as described in section Section 4.1 896 the Answerer sends the following INFO message. 898 INFO sip:alice@example.com SIP/2.0 899 ... 900 Info-Package: trickle-ice 901 Content-type: application/sdp 902 Content-Disposition: Info-Package 903 Content-length: ... 905 a=ice-pwd:asd88fgpdd777uzjYhagZg 906 a=ice-ufrag:8hhY 907 m=audio 9 RTP/AVP 0 908 a=mid:1 909 a=rtcp-mux 910 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 912 This INFO message indicates that the Answerer supports and uses RTP 913 and RTCP multiplexing as well. This allows the Offerer to omit 914 gathering of RTCP candidates or releasing already gathered RTCP 915 candidates. If the INFO message did not contain the a=rtcp-mux 916 attribute, the Offerer would have to gather RTCP candidates unless it 917 wants to wait until receipt of an Answer that eventually confirms 918 support or non-support for RTP and RTCP multiplexing. 920 7. Considerations for Media Multiplexing 922 The following consideration describe options for Trickle-ICE in order 923 to give some guidance to implementors on how trickling can be 924 optimized with respect to providing candidates in case of Media 925 Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed 926 that the reader is familiar with 927 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 929 ICE candidate exchange is already considered in section 11 of 930 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are 931 still valid for Trickle ICE, however, trickling provides more 932 flexibility for the sequence of candidate exchange, especially in 933 Full Trickle mode. 935 Except for bundle-only m-lines, a Half Trickle Offerer would have to 936 send an offer with candidates for all bundled m-lines. The 937 additional flexibility, however, allows a Full Trickle Offerer to 938 initially send only candidates for the m-line with the suggested 939 Offerer BUNDLE address. 941 Latest on receipt of the answer, the Offerer will detect if BUNDLE is 942 supported and if the suggested Offerer BUNDLE address was selected. 943 In this case the Offerer does not need to trickle further candidates 944 for the remaining m-lines in a bundle. However, if BUNDLE is not 945 supported, the Full Trickle Offerer needs to gather and trickle 946 candidates for the remaining m-lines as necessary. If the answerer 947 selects a Offerer BUNDLE address different from suggested Offerer 948 BUNDLE address, the Full Trickle Offerer needs to gather and trickle 949 candidates for the m-line that carries the selected Offerer BUNDLE 950 address. 952 A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute 953 [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle- 954 ice-sdpfrag body if it supports and uses bundling. When doing so, 955 the Answerer MUST include all identification-tags in the same order 956 that is used or will be used in the Answer. 958 Receipt of this attribute at the Offerer in an INFO request prior to 959 the Answer indicates that the Answerer supports and uses bundling. 960 The Offerer can use this information e.g. for stopping the gathering 961 of candidates for the remaining m-lines in a bundle and/or for 962 freeing corresponding resources. 964 This behaviour is illustrated by the following example offer that 965 indicates support for Media Multiplexing. 967 v=0 968 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 969 s= 970 c=IN IP4 atlanta.example.com 971 t=0 0 972 a=group:BUNDLE foo bar 973 a=ice-pwd:777uzjYhagZgasd88fgpdd 974 a=ice-ufrag:Yhh8 975 m=audio 10000 RTP/AVP 0 976 a=mid:foo 977 a=rtpmap:0 PCMU/8000 978 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 979 m=video 10002 RTP/AVP 31 980 a=mid:bar 981 a=rtpmap:31 H261/90000 982 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 984 Once the dialog is established as described in section Section 4.1 985 the Answerer sends the following INFO message. 987 INFO sip:alice@example.com SIP/2.0 988 ... 989 Info-Package: trickle-ice 990 Content-type: application/sdp 991 Content-Disposition: Info-Package 992 Content-length: ... 994 a=group:BUNDLE foo bar 995 a=ice-pwd:asd88fgpdd777uzjYhagZg 996 a=ice-ufrag:8hhY 997 m=audio 9 RTP/AVP 0 998 a=mid:1 999 a=rtcp-mux 1000 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 1001 m=audio 9 RTP/AVP 0 1002 a=mid:bar 1004 This INFO message indicates that the Answerer supports and uses Media 1005 Multiplexing as well. Note, that the second m-line shows the default 1006 values as specified in section Section 4.2, e.g. media set 'audio' 1007 although 'video' was offered. The receiving ICE agents needs to 1008 ignore these default values in the pseudo m-lines. 1010 The INFO message also indicates that the Answerer accepted the 1011 suggested Offerer Bundle Address. This allows the Offerer to omit 1012 gathering of RTP and RTCP candidates for the other m-lines or 1013 releasing already gathered candidates. If the INFO message did not 1014 contain the a=group:BUNDLE attribute, the Offerer would have to 1015 gather RTP and RTCP candidates for the other m-lines unless it wants 1016 to wait until receipt of an Answer that eventually confirms support 1017 or non-support for Media Multiplexing. 1019 Independent of using Full Trickle or Half Trickle mode, the rules 1020 from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and 1021 Answerer, when putting attributes in the application/trickle-ice- 1022 sdpfrag body. 1024 8. SDP 'end-of-candidate' Attribute 1026 This section defines a new SDP media-level and session-level 1027 attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' is a 1028 property attribute [RFC4566], and hence has no value. By including 1029 this attribute in an Offer or Answer the sending agent indicates that 1030 it will not trickle further candidates. The detailed SDP Offer/ 1031 Answer procedures for the 'end-of-candidate' attribute are specified 1032 in [I-D.ietf-ice-trickle]. 1034 Name: end-of-candidate 1036 Value: N/A 1038 Usage Level: media and session-level 1040 Charset Dependent: no 1042 Mux Category: IDENTICAL 1044 Example: a=end-of-candidate 1046 9. Content Type 'application/trickle-ice-sdpfrag' 1048 9.1. Overall Description 1050 A application/trickle-ice-sdpfrag body is used by the Trickle-ICE 1051 Info Package. It uses a subset of the possible SDP lines as defined 1052 by the grammar defined in [RFC4566]. A valid body uses only media 1053 descriptions and certain attributes that are needed and/or useful for 1054 trickling candidates. The content adheres to the following grammar. 1056 9.2. Grammar 1058 The grammar of an 'application/trickle-ice-sdpfrag' body is based the 1059 following ABNF [RFC5234]. It specifies the subset of existing SDP 1060 attributes, that are needed or useful for trickling candidates. 1062 ; Syntax 1063 trickle-ice-sdpfrag = session-level-fields 1064 pseudo-media-descriptions 1065 session-level-fields = [bundle-group-attribute CRLF] 1066 [ice-lite-attribute CRLF] 1067 ice-pwd-attribute CRLF 1068 ice-ufrag-attribute CRLF 1069 [ice-options-attribute CRLF] 1070 [ice-pacing-attribute CRLF] 1071 [end-of-candidates-attribute CRLF] 1072 extension-attribute-fields 1073 ; for future extensions 1075 ice-lite-attribute = %s"a=" ice-lite 1076 ice-pwd-attribute = %s"a=" ice-pwd-att 1077 ice-ufrag-attribute = %s"a=" ice-ufrag-att 1078 ice-pacing-attribute = %s"a=" ice-pacing-att 1079 ice-options-attribute = %s"a=" ice-options 1080 bundle-group-attribute = "a=group:" bundle-semantics 1081 *(SP identification-tag) 1082 bundle-semantics = "BUNDLE" 1083 end-of-candidates-attribute = %s"a=" end-of-candidates 1084 extension-attribute-fields = attribute-fields 1086 pseudo-media-descriptions = *( media-field 1087 trickle-ice-attribute-fields 1088 [extension-attribute-fields] ) 1089 ; for future extensions 1090 trickle-ice-attribute-fields = mid-attribute CRLF 1091 ["a=rtcp-mux" CRLF] 1092 ["a=rtcp-mux-only" CRLF] 1093 *(candidate-attributes CRLF) 1094 [ice-pwd-attribute CRLF] 1095 [ice-ufrag-attribute CRLF] 1096 [remote-candidate-attribute CRLF] 1097 [end-of-candidates-attribute CRLF] 1098 remote-candidate-attribute = %s"a=" remote-candidate-att 1099 candidate-attributes = %s"a=" candidate-attribute 1100 end-of-candidates = %s"end-of-candidates" 1102 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- 1103 pacing-att, ice-options, candidate-attribute remote-candidate-att 1104 from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute 1105 ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The 1106 indicator for case-sensitivity %s is defined in [RFC7405]. 1108 An Agent MUST ignore any received unknown extension-attribute-fields. 1110 10. Info Package 1112 10.1. Rationale - Why INFO? 1114 The decision to use SIP INFO requests as a candidate transport method 1115 is based primarily on their lightweight nature. Once a dialog has 1116 been established, INFO messages can be exchanged both ways with no 1117 restrictions on timing and frequency and no risk of collision. 1119 On the other hand, using Offer/Answer and UPDATE requests [RFC3311] 1120 introduces the following complications: 1122 Blocking of messages: [RFC3264] defines Offer/Answer as a strictly 1123 sequential mechanism. There can only be a maximum of one exchange 1124 at any point of time. Both sides cannot simultaneously send 1125 Offers nor can they generate multiple Offers prior to receiving an 1126 Answer. Using UPDATE requests for candidate transport would 1127 therefore imply the implementation of a candidate pool at every 1128 agent where candidates can be stored until it is once again that 1129 agent's "turn" to emit an Answer or a new Offer. Such an approach 1130 would introduce non-negligible complexity for no additional value. 1132 Elevated risk of glare: The sequential nature of Offer/Answer also 1133 makes it impossible for both sides to send Offers simultaneously. 1134 What's worse is that there are no mechanisms in SIP to actually 1135 prevent that. [RFC3261], where the situation of Offers crossing 1136 on the wire is described as "glare", only defines a procedure for 1137 addressing the issue after it has occurred. According to that 1138 procedure both Offers are invalidated and both sides need to retry 1139 the negotiation after a period between 0 and 4 seconds. The high 1140 likelihood for glare to occur and the average two second back-off 1141 intervals would imply Trickle ICE processing duration would not 1142 only fail to improve but actually exceed those of Vanilla ICE. 1144 INFO messages decouple the exchange of candidates from the Offer/ 1145 Answer negotiation and are subject to none of the glare issues 1146 described above, which makes them a very convenient and lightweight 1147 mechanism for asynchronous delivery of candidates. 1149 Using in-dialog INFO messages also provides a way of guaranteeing 1150 that candidates are delivered end-to-end, between the same entities 1151 that are actually in the process of initiating a session. Out-of- 1152 dialog alternatives would have implied requiring support for Globally 1153 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 1154 adoption levels, would have constituted too strong of constraint to 1155 the adoption of Trickle ICE. 1157 10.2. Overall Description 1159 This specification defines an Info Package for use by SIP user agents 1160 implementing Trickle ICE. INFO requests carry ICE candidates 1161 discovered after the peer user agents have confirmed mutual support 1162 for Trickle ICE. 1164 10.3. Applicability 1166 The purpose of the ICE protocol is to establish a media path in the 1167 presence of NAT and firewalls. The candidates are transported in 1168 INFO requests and are part of this establishment. 1170 Candidates sent by a Trickle ICE agent after the Offer, follow the 1171 same signaling path and reach the same entity as the Offer itself. 1172 While it is true that GRUUs can be used to achieve this, one of the 1173 goals of this specification is to allow operation of Trickle ICE in 1174 as many environments as possible including those without GRUU 1175 support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not 1176 satisfy this goal. 1178 10.4. Info Package Name 1180 This document defines a SIP Info Package as per [RFC6086]. The Info 1181 Package token name for this package is "trickle-ice" 1183 10.5. Info Package Parameters 1185 This document does not define any Info Package parameters. 1187 10.6. SIP Option Tags 1189 [RFC6086] allows Info Package specifications to define SIP option- 1190 tags. This specification extends the option-tag construct of the SIP 1191 grammar as follows: 1193 option-tag /= "trickle-ice" 1195 SIP entities that support this specification MUST place the 'trickle- 1196 ice' option-tag in a SIP Supported: header field within all SIP 1197 INVITE requests and responses. 1199 When responding to, or generating a SIP OPTIONS request a SIP entity 1200 MUST also include the 'trickle-ice' option-tag in a SIP Supported: 1201 header field. 1203 10.7. Info Message Body Parts 1205 Entities implementing this specification MUST include a payload of 1206 type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 all 1207 SIP INFO requests. The payload is used to convey SDP encoded ICE 1208 candidates. 1210 10.8. Info Package Usage Restrictions 1212 This document does not define any Info Package Usage Restrictions. 1214 10.9. Rate of INFO Requests 1216 A Trickle ICE Agent with many network interfaces might create a high 1217 rate of INFO requests if every newly detected candidate is trickled 1218 individually without aggregation. Implementor that are concerned 1219 about loss of packets in such a case might consider aggregating ICE 1220 candidates and sending INFOS only at some configurable intervals. 1222 10.10. Info Package Security Considerations 1224 See Section 12 1226 11. IANA Considerations 1228 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1229 document. Please replace "I-D.ietf-ice-trickle" with the RFC number 1230 of that document.] 1232 11.1. SDP 'end-of-candidate' Attribute 1234 This section defines a new SDP media-level and session-level 1235 attribute [RFC4566] , 'end-of-candidate'. 'end-of-candidate' is a 1236 property attribute [RFC4566] , and hence has no value. 1238 Name: end-of-candidate 1240 Value: N/A 1242 Usage Level: media and session 1244 Charset Dependent: no 1246 Purpose: The sender indicates that it will not trickle 1247 further candidates. 1249 O/A Procedures: "I-D.ietf-ice-trickle" defines the detailed 1250 SDP Offer/Answer procedures for 1251 the 'end-of-candidate' attribute. 1253 Mux Category: IDENTICAL 1255 Reference: RFCXXXX 1257 Example: 1259 a=end-of-candidate 1261 11.2. application/trickle-ice-sdpfrag MIME Type 1263 Type name: application 1265 Subtype name: trickle-ice-sdpfrag 1267 Required parameters: None. 1269 Optional parameters: None. 1271 Encoding considerations: 1273 SDP files are primarily UTF-8 format text. Although the 1274 initially defined content of a trickle-ice-sdpfrag body does 1275 only include ASCII characters, UTF-8 encoded content might be 1276 introduced via extension attributes. The "a=charset:" 1277 attribute may be used to signal the presence of other character 1278 sets in certain parts of a trickle-ice-sdpfrag body (see 1279 [RFC4566]). Arbitrary binary content cannot be directly 1280 represented in SDP or a trickle-ice-sdpfrag body. 1282 Security considerations: 1284 See [RFC4566]) and RFCXXXX 1286 Interoperability considerations: 1288 See RFCXXXX 1290 Published specification: 1292 See RFCXXXX 1294 Applications which use this media type: 1296 Voice over IP, video teleconferencing, streaming media, instant 1297 messaging, Trickle-ICE among others. 1299 Additional information: 1301 Magic number(s): none 1303 File extension(s): none 1305 Macintosh File Type Code(s): none 1307 Person and email address to contact for further information: 1309 IETF MMUSIC working group mmusic@ietf.org 1311 Intended usage: 1313 Trickle-ICE for SIP as specified in RFCXXXX. 1315 Author/Change controller: 1317 IETF MMUSIC working group mmusic@ietf.org 1319 11.3. SIP Info Package 'trickle-ice' 1321 This document defines a new SIP Info Package named 'trickle-ice' and 1322 updates the Info Packages Registry with the following entry. 1324 +-------------+-----------+ 1325 | Name | Reference | 1326 +-------------+-----------+ 1327 | trickle-ice | [RFCXXXX] | 1328 | | | 1329 +-------------+-----------+ 1331 11.4. SIP Option Tag 'trickle-ice' 1333 This specification registers a new SIP option tag 'trickle-ice' as 1334 per the guidelines in Section 27.1 of [RFC3261] and updates the 1335 "Option Tags" section of the SIP Parameter Registry with the 1336 following entry: 1338 +-------------+-------------------------------------+-----------+ 1339 | Name | Description | Reference | 1340 +-------------+-------------------------------------+-----------+ 1341 | trickle-ice | This option tag is used to indicate | [RFCXXXX] | 1342 | | that a UA supports and understands | | 1343 | | Trickle-ICE. | | 1344 +-------------+-------------------------------------+-----------+ 1346 12. Security Considerations 1348 The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], 1349 [RFC6086], [I-D.ietf-ice-trickle] apply. This document clarifies how 1350 the above specifications are used together for trickling candidates 1351 and does not create addtitional security risks. 1353 13. Acknowledgements 1355 The authors would like to thank Ayush Jain, Paul Kyzivat, Jonathan 1356 Lennox, Simon Perreault and Martin Thomson for reviewing and/or 1357 making various suggestions for improvements and optimizations. 1359 14. Change Log 1361 [RFC EDITOR NOTE: Please remove this section when publishing]. 1363 Changes from draft-ietf-mmusic-trickle-ice-sip-01 1365 o Editorial Clean up 1367 o IANA Consideration added 1369 o Security Consideration added 1371 o RTCP and BUNDLE Consideration added with rules for including 1372 "a=rtcp-mux" and "a=group: BUNDLLE" attributes 1374 o 3PCC Consideration added 1376 o Clarified that 18x w/o answer is sufficient to create a dialog 1377 that allows for trickling to start 1379 o Added remaining Info Package definition sections as outlined in 1380 section 10 of [RFC6086] 1382 o Added definition of application/sdpfrag making draft-ivov-mmusic- 1383 sdpfrag obsolete 1385 o Added pseudo m-lines as additional separator in sdpfrag bodies for 1386 Trickle ICE 1388 o Added ABNF for sdp-frag bodies and Trickle-ICE package 1390 Changes from draft-ietf-mmusic-trickle-ice-sip-02 1392 o Removed definition of application/sdpfrag 1394 o Replaced with new type application/trickle-ice-sdpfrag 1396 o RTCP and BUNDLE Consideration enhanced with some examples 1398 o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to 1399 normative reference 1401 o Removed reference to 4566bis 1403 o Addressed review comment from Simon Perreault 1405 Changes from draft-ietf-mmusic-trickle-ice-sip-03 1406 o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis 1407 and draft-ietf-mmusic-ice-sip-sdp 1409 o Corrected Figure 10, credits to Ayush Jain for finding the bug 1411 o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- 1412 ice-sip-sdp 1414 o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- 1415 mux-exclusive, enahnced ABNF to support a=rtcp-mux-exclusive 1417 o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for 1418 the application/trickle-ice-sdpfrag body 1420 Changes from draft-ietf-mmusic-trickle-ice-sip-04 1422 o considered comments from Christer Holmberg 1424 o corrected grammar for INFO package, such that ice-ufrag/pwd are 1425 also allowed on media-level as specified in 1426 [I-D.ietf-mmusic-ice-sip-sdp] 1428 o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] 1430 o Added formal definition for the end-of-candidates attribute 1432 Changes from draft-ietf-mmusic-trickle-ice-sip-05 1434 o considered further comments from Christer Holmberg 1436 o editorial comments on section 3 addressed 1438 o moved section 3.1 to section 10.1 and applied some edits 1440 o replaced the term "previously sent candidates" with "currently 1441 known and used candidates". 1443 15. References 1445 15.1. Normative References 1447 [I-D.ietf-ice-trickle] 1448 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 1449 "Trickle ICE: Incremental Provisioning of Candidates for 1450 the Interactive Connectivity Establishment (ICE) 1451 Protocol", draft-ietf-ice-trickle-04 (work in progress), 1452 September 2016. 1454 [I-D.ietf-mmusic-ice-sip-sdp] 1455 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using 1456 Interactive Connectivity Establishment (ICE) with Session 1457 Description Protocol (SDP) offer/answer and Session 1458 Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- 1459 sdp-10 (work in progress), July 2016. 1461 [I-D.ietf-mmusic-mux-exclusive] 1462 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 1463 Multiplexing using SDP", draft-ietf-mmusic-mux- 1464 exclusive-10 (work in progress), August 2016. 1466 [I-D.ietf-mmusic-rfc5245bis] 1467 Keranen, A. and J. Rosenberg, "Interactive Connectivity 1468 Establishment (ICE): A Protocol for Network Address 1469 Translator (NAT) Traversal", draft-ietf-mmusic- 1470 rfc5245bis-05 (work in progress), September 2015. 1472 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1473 Holmberg, C., Alvestrand, H., and C. Jennings, 1474 "Negotiating Media Multiplexing Using the Session 1475 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1476 negotiation-36 (work in progress), October 2016. 1478 [I-D.ietf-mmusic-sdp-mux-attributes] 1479 Nandakumar, S., "A Framework for SDP Attributes when 1480 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14 1481 (work in progress), September 2016. 1483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1484 Requirement Levels", BCP 14, RFC 2119, 1485 DOI 10.17487/RFC2119, March 1997, 1486 . 1488 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1489 A., Peterson, J., Sparks, R., Handley, M., and E. 1490 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1491 DOI 10.17487/RFC3261, June 2002, 1492 . 1494 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1495 Provisional Responses in Session Initiation Protocol 1496 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1497 . 1499 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1500 with Session Description Protocol (SDP)", RFC 3264, 1501 DOI 10.17487/RFC3264, June 2002, 1502 . 1504 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1505 in Session Description Protocol (SDP)", RFC 3605, 1506 DOI 10.17487/RFC3605, October 2003, 1507 . 1509 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1510 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1511 July 2006, . 1513 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1514 Specifications: ABNF", STD 68, RFC 5234, 1515 DOI 10.17487/RFC5234, January 2008, 1516 . 1518 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1519 Control Packets on a Single Port", RFC 5761, 1520 DOI 10.17487/RFC5761, April 2010, 1521 . 1523 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1524 Protocol (SDP) Grouping Framework", RFC 5888, 1525 DOI 10.17487/RFC5888, June 2010, 1526 . 1528 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1529 Initiation Protocol (SIP) INFO Method and Package 1530 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1531 . 1533 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1534 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1535 . 1537 15.2. Informative References 1539 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1540 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1541 2002, . 1543 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1544 "Indicating User Agent Capabilities in the Session 1545 Initiation Protocol (SIP)", RFC 3840, 1546 DOI 10.17487/RFC3840, August 2004, 1547 . 1549 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1550 Agent URIs (GRUUs) in the Session Initiation Protocol 1551 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 1552 . 1554 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1555 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1556 March 2011, . 1558 [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: 1559 Combined Use of the Session Initiation Protocol (SIP) and 1560 the Extensible Messaging and Presence Protocol (XMPP)", 1561 RFC 7081, DOI 10.17487/RFC7081, November 2013, 1562 . 1564 Authors' Addresses 1566 Emil Ivov 1567 Jitsi 1568 Strasbourg 67000 1569 France 1571 Phone: +33 6 72 81 15 55 1572 Email: emcho@jitsi.org 1574 Thomas Stach 1575 Unaffiliated 1576 Vienna 1130 1577 Austria 1579 Email: thomass.stach@gmail.com 1581 Enrico Marocco 1582 Telecom Italia 1583 Via G. Reiss Romoli, 274 1584 Turin 10148 1585 Italy 1587 Email: enrico.marocco@telecomitalia.it 1588 Christer Holmberg 1589 Ericsson 1590 Hirsalantie 11 1591 Jorvas 02420 1592 Finland 1594 Email: christer.holmberg@ericsson.com