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