idnits 2.17.1 draft-ivov-mmusic-trickle-ice-sip-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == 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 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. -- 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 (June 17, 2014) is 3600 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: 'TODO' is mentioned on line 773, but not defined == Outdated reference: A later version (-02) exists of draft-ietf-mmusic-trickle-ice-01 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 E. Marocco 5 Expires: December 19, 2014 Telecom Italia 6 C. Holmberg 7 Ericsson 8 June 17, 2014 10 A Session Initiation Protocol (SIP) usage for Trickle ICE 11 draft-ivov-mmusic-trickle-ice-sip-02 13 Abstract 15 The Interactive Connectivity Establishment (ICE) protocol describes a 16 Network Address Translator (NAT) traversal mechanism for UDP-based 17 multimedia sessions established with the offer/answer model. The ICE 18 extension for Incremental Provisioning of Candidates (Trickle ICE) 19 defines a mechanism that allows ICE agents to shorten session 20 establishment delays by making the candidate gathering and 21 connectivity checking phases of ICE non-blocking and by executing 22 them in parallel. 24 This document defines usage semantics for Trickle ICE with the 25 Session Initiation Protocol (SIP). 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 19, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Rationale. Why INFO . . . . . . . . . . . . . . . . . . . 4 65 3.2. Discovery issues . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Relationship with the Offer/Answer Model . . . . . . . . 6 67 4. Incremental signalling of ICE candidates . . . . . . . . . . 8 68 4.1. Asserting Offer/Answer delivery and dialog state . . . . 8 69 4.2. Delivering candidates in INFO messages . . . . . . . . . 12 70 5. Initial discovery of trickle ICE support . . . . . . . . . . 14 71 5.1. Provisioning support for trickle ICE . . . . . . . . . . 14 72 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 15 73 5.3. Trickle ICE discovery through other protocols . . . . . . 16 74 5.4. Fallback to half trickle . . . . . . . . . . . . . . . . 16 75 6. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 18 76 6.1. Overall Description . . . . . . . . . . . . . . . . . . . 18 77 6.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 18 78 6.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 18 79 6.4. Info Package Parameters . . . . . . . . . . . . . . . . . 18 80 6.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . . 18 81 6.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 19 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 86 9.2. Informative References . . . . . . . . . . . . . . . . . 20 87 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction 92 The vanilla specification of the Interactive Connectivity 93 Establishment (vanilla ICE) protocol [RFC5245] describes a mechanism 94 for NAT traversal that consists of three main phases: a phase where 95 an agent gathers a set of candidate transport addresses (source IP 96 address, port and transport protocol), a second phase where these 97 candidates are sent to a remote agent and this gathering procedure is 98 repeated and, finally, a third phase where connectivity between all 99 candidates in both sets is checked (connectivity checks). Once these 100 phases have been completed, and only then, can both agents begin 101 communication. According to the Vanilla ICE specification the three 102 phases above happen consecutively, in a blocking way, which may lead 103 to undesirable latency during session establishment. 105 The trickle ICE extension defined in [I-D.ietf-mmusic-trickle-ice] 106 defines generic semantics required for these ICE phases to happen 107 simultaneously, in a non-blocking way and hence speed up session 108 establishment. 110 The present specification defines a usage of trickle ICE with the 111 Session Initiation Protocol (SIP). It describes how ICE candidates 112 are to be incrementally exchanged with SIP INFO requests and how the 113 half and full-trickle modes defined in [I-D.ietf-mmusic-trickle-ice] 114 are to be used by SIP User Agents (UAs) depending on their 115 expectations for support of trickle ICE by a remote agent. 117 This document defines a new Info Package [RFC6086] for use with 118 Trickle ICE. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 This specification makes use of all terminology defined by the 127 protocol for Interactive Connectivity Establishment in [RFC5245] and 128 its Trickle ICE extension [I-D.ietf-mmusic-trickle-ice]. It is 129 assumed that the reader will be familiar with the terminology from 130 both of them. 132 3. Protocol Overview 134 The semantics that vanilla ICE [RFC5245] defines for exchanging ICE 135 candidates are exclusively based on use of Offers and Answers as per 136 [RFC3264] over the Session Description Protocol (SDP) [RFC4566]. 137 This specification extends these mechanism by allowing ICE candidates 138 to also be sent after the completion of Offer/Answer negotiation, 139 through the use of SIP INFO messages and a newly defined Info Package 140 [RFC6086]. 142 Specifically, in cases where trickle ICE is fully supported, a 143 typical exchange would happen along the following lines: The offerer 144 would send an INVITE containing a subset of candidates and then wait 145 for an early dialog to be established. Once that happens, it will be 146 able to continue sending candidates through in INFO requests and 147 within the same dialog. 149 Similarly, once it has sent an answer (though not earlier) an 150 answerer can continue "trickling" ICE candidates using INFO messages 151 within the dialog established by its 18x provisional response. 152 Figure 1 shows such a sample exchange: 154 STUN/Turn STUN/TURN 155 Servers Alice Bob Servers 156 | | | | 157 | STUN Bi.Req. | INVITE (Offer) | | 158 |<--------------|------------------------>| | 159 | | 183 (Answer) | TURN Alloc Req | 160 | STUN Bi.Resp. |<------------------------|--------------->| 161 |-------------->| INFO/OK (SRFLX Cand.) | | 162 | |------------------------>| TURN Alloc Resp| 163 | | INFO/OK (Relay Cand.) |<---------------| 164 | |<------------------------| | 165 | | | | 166 | | More Cands & ConnChecks| | 167 | |<=======================>| | 168 | | | | 169 | | 200 OK | | 170 | |<------------------------| | 171 | | ACK | | 172 | |------------------------>| | 173 | | | | 174 | | 5245 SIP re-INVITE | | 175 | |------------------------>| | 176 | | 200 OK | | 177 | |<------------------------| | 178 | | ACK | | 179 | |------------------------>| | 180 | | | | 181 | |<===== MEDIA FLOWS =====>| | 182 | | | | 184 Figure 1: Sample trickle ICE scenario with SIP 186 3.1. Rationale. Why INFO 188 The decision to use SIP INFO requests as a candidate transport method 189 is based primarily on their lightweight nature. Once a dialog has 190 been established, INFO messages can be exchanged both ways with no 191 restrictions on timing and frequency and no risk of collision. 193 On the other hand, using offer/answer and UPDATE requests, which from 194 an [RFC5245] perspective is the traditional way of transporting ICE 195 candidates, introduces the following complications: 197 Need for a turn-based mechanism: [RFC3264] defines Offer/Answer as 198 a strictly sequential mechanism. There can only be a maximum of 199 one exchange at any point of time. Both sides cannot 200 simultaneously send offers nor can they generate multiple offers 201 prior to receiving an answer. Using UPDATEs for candidate 202 transport would therefore imply the implementation of a candidate 203 pool at every agent where candidates can be stored until it is 204 once again that agent's "turn" to emit an answer or a new offer. 205 Such an approach would introduce non-negligible complexity for no 206 additional value. 208 Elevated risk of glare: The sequential nature of Offer/Answer also 209 makes it impossible for both sides to send offers simultaneously. 210 What's worse is that there are no mechanisms in SIP to actually 211 prevent that. [RFC3261], where the situation of offers crossing 212 on the wire is described as "glare", only defines a procedure for 213 addressing the issue after it has occurred. According to that 214 procedure both offers are invalidated and both sides need to retry 215 the negotiation after a period between 0 and 4 seconds. The high 216 likelihood for glare to occur and the average two second backoff 217 intervals would imply trickle ICE processing duration would not 218 only fail to improve but actually exceed those of vanilla ICE. 220 INFO messages have no impact on the Offer/Answer negotiation and are 221 subject to none of the glare issues described above, which makes them 222 a very convenient and lightweight mechanism for asynchronous delivery 223 of candidates. 225 Using in-dialog INFO messages also provides a way of guaranteeing 226 that candidates are delivered end-to-end, between the same entities 227 that are actually in the process of initiating a session. The 228 alternative would have implied requiring support for Globally 229 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 230 adoption levels, would have constituted too strong of constraint to 231 the adoption of trickle ICE. 233 3.2. Discovery issues 235 In order for to benefit from trickle ICE's full potential and reduce 236 session establishment latency to a minimum, trickle ICE agents need 237 to generate SDP offers and answers that contain incomplete, 238 potentially empty sets of candidates. Such offers and answers can 239 only be handled meaningfully by agents that actually support 240 incremental candidate provisioning, which implies the need to confirm 241 such support before actually using it. 243 Contrary to other protocols, like XMPP [RFC6120], where "in advance" 244 capability discovery is widely implemented, the mechanisms that allow 245 this for sip (i.e., a combination of UA Capabilities [RFC3840] and 246 GRUU [RFC5627]) have only seen low levels of adoption. This presents 247 an issue for trickle ICE implementations as SIP UAs do not have an 248 obvious means of verifying that their peer will support incremental 249 candidate provisioning. 251 The "half trickle" mode of operation defined in the trickle ICE 252 specification [I-D.ietf-mmusic-trickle-ice] provides one way around 253 this, by requiring first offers to contain a complete set of ICE 254 candidates and only using incremental provisioning for the rest of 255 the sessions. 257 While using "half trickle" does provide a working solution it also 258 comes at the price of increased latency. Section 5 therefore makes 259 several alternative suggestions that enable SIP UAs to engage in full 260 trickle right from their first offer: Section 5.1 discusses the use 261 of on-line provisioning as a means of allowing use of trickle ICE for 262 all endpoints in controlled environments. Section 5.2 describes 263 anticipatory discovery for implementations that actually do support 264 GRUU and UA Capabilities and Section 5.4 discusses the implementation 265 and use of "half trickle" by SIP UAs where none of the above are an 266 option. 268 3.3. Relationship with the Offer/Answer Model 270 It is important to note that this specification does not require, 271 define, or even assume any mechanisms that would have an impact on 272 the Offer/Answer model beyond the way it is already used by vanilla 273 ICE [RFC5245]. From the perspective of all SIP middle boxes and 274 proxies, and with the exception of the actual INFO messages, 275 signalling in general and Offer/Answer exchanges in particular would 276 look the same way for trickle as they would for vanilla ICE. 278 +-------------------------------+ +-------------------------------+ 279 | Alice +--------------+ | | +--------------+ Bob | 280 | | Offer/Answer | | | | Offer/Answer | | 281 | +-------+ | Module | | | | Module | +-------+ | 282 | | ICE | +--------------+ | | +--------------+ | ICE | | 283 | | Agent | | | | | | Agent | | 284 | +-------+ | | | | +-------+ | 285 +-------------------------------+ +-------------------------------+ 286 | | | | 287 | | INVITE (Offer) | | 288 | |--------------------->| | 289 | | 183 (Answer) | | 290 | |<---------------------| | 291 | | | | 292 | | 293 | SIP INFO (more candidates) | 294 |----------------------------------------------------->| 295 | SIP INFO (more candidates) | 296 |<-----------------------------------------------------| 297 | | 298 | STUN Binding Requests/Responses | 299 |----------------------------------------------------->| 300 | STUN Binding Requests/Responses | 301 |<-----------------------------------------------------| 302 | | 303 | | | | 304 | | 5245 SIP re-INVITE | | 305 | |--------------------->| | 306 | | 200 OK | | 307 | |<---------------------| | 309 Figure 2: Distinguishing between trickle ICE and traditional 310 signalling. 312 It is important to note that, as displayed on Figure 2, exchanging 313 candidates through SIP INFO messages are best represented as 314 signalling between ICE agents and not between the traditional SIP and 315 Offer/Answer modules of SIP User Agents. Such INFO requests do not 316 impact the state of Offer/Answer, nor do they have an impact on the 317 version number in the "o=" line. In that regard they are actually 318 comparable to Peer Reflexive candidates that ICE agents can discover 319 during ICE processing. 321 4. Incremental signalling of ICE candidates 323 Trickle ICE agents will construct offers and answers the same way a 324 [RFC5245] compatible agent would, with the following two main 325 differences: 327 o First, all offers and answers sent by the trickle ICE capable 328 agents MUST indicate support for trickle ICE through the "trickle" 329 ice-options tag defined in [I-D.ietf-mmusic-trickle-ice]: 331 a=ice-options:trickle 333 o Second, offers and answers may contain all, some, or no ICE 334 candidates at all. 336 Once an agent has sent an offer or an answer indicating support for 337 trickle ICE, it MUST be prepared to receive SIP INFO requests within 338 that same dialog, containing additional candidates or an indication 339 for the end of such candidates. 341 Similarly, as soon as a SIP UA has established a dialog (including an 342 early state one) it MAY begin sending INFO requests containing 343 additional candidates or end-of-candidates indications. Such INFO 344 requests MUST be sent within that same dialog. This is necessary so 345 that the candidates from these INFO messages could be delivered to 346 the same entities that initiated the session. 348 4.1. Asserting Offer/Answer delivery and dialog state 350 In order for SIP UAs to be able to start trickling, the following two 351 conditions need to be satisfied: 353 o ICE support in the peer agent MUST be confirmed. 355 o The SIP dialog at both sides MUST be at least in the early state. 357 Section 5 discusses in detail the various options for satisfying the 358 first of the above conditions. Regardless of those mechanisms 359 however, agents are certain to have a clear understanding of whether 360 their peers support trickle ICE once an offer and and an answer have 361 been exchanged, which needs to happen anyway for ICE processing to 362 commence (see Figure 3). 364 Alice Bob 365 | | 366 | INVITE (Offer) | 367 |------------------------>| 368 | 183 (Answer) | 369 |<------------------------| 370 | | 371 +----------------------+ | 372 |Alice: I know Bob can| | 373 |trickle and I know his| | 374 |dialog is in the early| | 375 |state. Send INFO! | | 376 +----------------------+ | 377 | | 378 | INFO/OK (SRFLX Cand.) | 379 |------------------------>| 380 | | 382 Figure 3: SIP Offerer can freely trickle as soon as it receives an 383 answer. 385 Satisfying both conditions is also relatively trivial for ICE agents 386 that have sent an offer in an INVITE and that have received an 387 answer. Regardless of how that answer was delivered, it is 388 guaranteed to have confirmed support for trickle ICE within the 389 answerer (or lack thereof) and to have fully initialized the SIP 390 dialog at both ends. Offerers in the above situation can therefore 391 freely commence trickling within the newly established dialog (see 392 Figure 4). 394 Alice Bob 395 | | 396 | INVITE | 397 |------------------------>| 398 | 183 (Offer) | 399 |<------------------------| 400 | PRACK (Answer) | 401 |------------------------>| 402 | | 403 | +----------------------+ 404 | |Bob: I know Alice can| 405 | |trickle and I know her| 406 | |dialog is in the early| 407 | |state. Send INFO! | 408 | +----------------------+ 409 | | 410 | INFO/OK (SRFLX Cand.) | 411 |<------------------------| 412 | | 414 Figure 4: A SIP Offerer in a 3PCC scenario can also freely start 415 trickling as soon as it receives an answer. 417 Agents that have sent an offer in a reliable provisional response or 418 in a 200 OK and that receive an answer in a PRACK or in an ACK are 419 also in a similar situation because, by the time the offer and the 420 answer are exchanged, support for trickle ICE will be confirmed and 421 the SIP dialog is guaranteed to be in a state that would allow in- 422 dialog INFO requests. 424 The situation is a bit more delicate for agents that have received an 425 offer in an INVITE request and have sent an answer in an unreliable 426 provisional response because, once the response has been sent, there 427 is no way for the answerer to know when or if it has been received 428 (Figure 5). 430 Alice Bob 431 | | 432 | INVITE (Offer) | 433 |------------------------>| 434 | 183 (Answer) | 435 |<------------------------| 436 | | 437 | +----------------------+ 438 | |Bob: I don't know if | 439 | |Alice got my 183 or if| 440 | |her dialog is already | 441 | |in the early state. | 442 | | Can I send INFO??? | 443 | +----------------------+ 444 | | 446 Figure 5: A SIP UA that has answer-ed in an unreliable provisional 447 response cannot know exactly when it is received and when the dialog 448 at the side of the receiver has entered the early state 450 In order to clear this ambiguity as soon as possible, trickle ICE SIP 451 UAs MUST send a trickle ICE INFO request as soon as they receive an 452 SDP Answer in an unreliable provisional response. This INFO message 453 can only contain the candidates that were already provided in the 454 offer (as would be the case when half trickle is performed or when no 455 new candidates have been learned since then) or they can also deliver 456 new information, such as new candidates (if available) or an end-of- 457 candidates indication in case candidate discovery has ended in the 458 mean time. 460 As soon as answerers have received such INFO requests, they would 461 have an indication that a dialog is well established at both ends and 462 they MAY begin trickling (Figure 6). 464 Alice Bob 465 | | 466 | INVITE (Offer) | 467 |------------------------>| 468 | 183 (Answer) | 469 |<------------------------| 470 | INFO/OK (SRFLX Cand.) | 471 |------------------------>| 472 | | 473 | +----------------------+ 474 | |Bob: Now I know Alice| 475 | | is ready. Send INFO! | 476 | +----------------------+ 477 | INFO/OK (SRFLX Cand.) | 478 |<------------------------| 479 | | 481 Figure 6: A SIP UA that has answer-ed in an unreliable provisional 482 response cannot know exactly when it is received and when the dialog 483 at the side of the receiver has entered the early state 485 Obviously, if PRACK [RFC3262] requests are supported and used, there 486 is no need for the above as the PRACKs themselves would provide 487 sufficient indication for the state of the dialog. 489 4.2. Delivering candidates in INFO messages 491 Whenever new ICE candidates become available for sending, agents 492 would encode them in "a=candidate" lines as described by 493 [I-D.ietf-mmusic-trickle-ice]. For example: 495 a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx 496 raddr 10.0.1.1 rport 8998 498 The use of SIP INFO requests happens within the context of an Info 499 Package specifically defined for the purpose (Section 6). 501 Such INFO requests MUST be sent within the existing SIP dialog. The 502 MIME type for their payload MUST be set to 'application/sdpfrag' as 503 defined in [I-D.ivov-dispatch-sdpfrag]. 505 Since neither the "a=candidate" nor the "a=end-of-candidates" lines 506 contain information that would allow correlating them to a specific 507 "m=" line, this is handled through the use of MID [RFC3388]. Agents 508 MUST include the corresponding "a=mid" line for every "m=" line whose 509 candidate list they intend to update. Such "a=mid" lines MUST 510 immediately precede the list of candidates for that specific "m=" 511 line. All "a=candidate" or "a=end-of-candidates" lines following an 512 "a=mid" line, up until (and excluding) the next occurrence of an 513 "a=mid" line, pertain the the "m=" line identified by that MID. 514 "a=end-of-candidates" lines preceding any "a=mid" lines indicate end 515 of all trickling from that agent (as opposed to end of trickling for 516 a specific "m=" line. 518 The use of "a=mid" lines allows for a structure similar to the one in 519 SDP offers and answers where one can distinguish separate media-level 520 and session-level sections. In the current case lines preceding any 521 "a=mid" lines are considered to be session-level. Lines appearing in 522 between or after "a=mid" lines will be interpreted as media-level. 524 All INFO requests MUST carry the "ice-pwd" and "ice-ufrag" attributes 525 that would allow mapping them to a specific ICE generation. INFO 526 requests containing ice-ufrag and ice-pwd values that do not match 527 those of the current ICE processing session MUST be discarded. The 528 "ice-pwd" and "ice-ufrag" attributes MUST appear at the same level as 529 the ones in the Offer/Answer exchange. In other words, if they were 530 present as sesssion-level attributes there, they will also appear at 531 the beginning of all INFO message payloads, preceding all "a=mid" 532 lines. If they were originally exchanged as media level attributes, 533 potentially overriding session-level values, then they will also be 534 included in INFO message payloads, following the corresponding 535 "a=mid' line. 537 In every INFO request agents MUST include all local candidates they 538 have previously signalled. This is necessary in order to more easily 539 avoid problems that would arise from misordering and unreliability. 541 When receiving INFO requests carrying any candidates, agents will 542 therefore first identify and discard the SDP lines containing 543 candidates they have already received in previous INFO requests or in 544 the Offer/Answer exchange preceding them. Two candidates are 545 considered to be equal if their IP address port, transport and 546 component ID are the same. After identifying and discarding known 547 candidates, agents will then process them remaining ones (the actual 548 new candidates) according to the rules described in 549 [I-D.ietf-mmusic-trickle-ice]. 551 The following example shows the content of one sample candidate 552 delivering INFO request: 554 INFO sip:alice@example.com SIP/2.0 555 ... 556 Info-Package: trickle-ice 557 Content-type: application/sdp 558 Content-Disposition: Info-Package 559 Content-length: ... 561 a=ice-pwd:asd88fgpdd777uzjYhagZg 562 a=ice-ufrag:8hhY 563 a=mid:1 564 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 565 a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx 566 raddr 10.0.1.1 rport 8998 567 a=mid:2 568 a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx 569 raddr 10.0.1.1 rport 9000 570 a=end-of-candidates 572 5. Initial discovery of trickle ICE support 574 SIP User Agents (UAs) that support and intend to use trickle ICE are 575 REQUIRED by [I-D.ietf-mmusic-trickle-ice] to indicate that in their 576 offers and answers using the following attribute: "a=ice- 577 options:trickle". This makes discovery fairly straightforward for 578 answerers or for cases where offers need to be generated within 579 existing dialogs (i.e., when sending re-INVITE requests). In both 580 scenarios prior SDP would have provided the necessary information. 582 Obviously, prior SDP is not available at the time a first offer is 583 being constructed and it is therefore impossible for ICE agents to 584 determine support for incremental provisioning that way. The 585 following options are suggested as ways of addressing this issue. 587 5.1. Provisioning support for trickle ICE 589 In certain situations it may be possible for integrators deploying 590 trickle ICE to know in advance that some or all endpoints reachable 591 from within the deployment will support trickle ICE. This is likely 592 to be the case, for example, for WebRTC clients that will always be 593 communicating with other WebRTC clients or known Session Border 594 Controllers (SBC) with support for this specification. 596 While the exact mechanism for allowing such provisioning is out of 597 scope here, this specification encourages trickle ICE implementations 598 to allow the option in the way they find most appropriate. 600 5.2. Trickle ICE discovery with GRUU 602 [RFC3840] provides a way for SIP user agents to query for support of 603 specific capabilities using, among others, OPTIONS requests. GRUU 604 support on the other hand allows SIP requests to be addressed to 605 specific UAs (as opposed to arbitrary instances of an address of 606 record). Combining the two and using the "trickle-ice" option tag 607 defined in Section 6.5 provides SIP UAs with a way of learning the 608 capabilities of specific US instances and then addressing them 609 directly with INVITE requests that require SIP support. 611 Such targeted trickling may happen in different ways. One option 612 would be for a SIP UA to learn the GRUU instance ID of a peer through 613 presence and to then query its capabilities direction with an OPTIONS 614 request. Alternately, it can also just send an OPTIONS request to 615 the AOR it intends to contact and then inspect the returned 616 response(s) for support of both GRUU and trickle ICE (Figure 7). 618 Alice Bob 619 | | 620 | OPTIONS sip:b1@example.com SIP/2.0 | 621 |-------------------------------------------------->| 622 | | 623 | 200 OK | 624 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 625 | ;audio;video|;trickle-ice;... | 626 |<--------------------------------------------------| 627 | | 628 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 629 |-------------------------------------------------->| 630 | | 631 | 183 (Answer) | 632 |<--------------------------------------------------| 633 | INFO/OK (Trickling) | 634 |<------------------------------------------------->| 635 | | 636 | ... | 637 | | 639 Figure 7: Trickle ICE support discovery with OPTIONS and GRUU 641 Confirming support for trickle ICE through [RFC3840] gives SIP UAs 642 the options to engage in full trickle negotiation (as opposed to the 643 more lengthy half-trickle) from the very first offer they send. 645 5.3. Trickle ICE discovery through other protocols 647 Protocols like XMPP [RFC6120] define advanced discovery mechanisms 648 that allow specific features to be queried priory to actually 649 attempting to use them. Solutions like [RFC7081] define ways of 650 using SIP and XMPP together which also provides a way for dual stack 651 SIP+XMPP endpoints to make use of such features and verify trickle 652 ICE support for a specific SIP endpoint through XMPP. [TODO expand 653 on a specific way to do this] 655 5.4. Fallback to half trickle 657 In cases where none of the other mechanisms in this section are 658 acceptable, SIP UAs should use the "half trickle" mode defined in 659 [I-D.ietf-mmusic-trickle-ice]. With half trickle, agents initiate 660 sessions the same way they would when using vanilla ICE [RFC5245]. 661 This means that, prior to actually sending an offer, agents would 662 first gather ICE candidates in a blocking way and then send them all 663 in that offer. The blocking nature of the process would likely imply 664 that some amount of latency will be accumulated and it is advised 665 that agents try to anticipate it where possible, like for example, 666 when user actions indicate a high likelyhood for an imminent call 667 (e.g., activity on a keypad or a phone going offhook). 669 Using half trickle would result in offers that are compatible with 670 both vanilla ICE and legacy [RFC3264] endpoints both. 672 A typical (half) trickle ICE exchange with SIP would look this way: 674 STUN/Turn STUN/TURN 675 Servers Alice Bob Servers 676 | | | | 677 |<--------------| | | 678 | | | | 679 | | | | 680 | Candidate | | | 681 | | | | 682 | | | | 683 | Discovery | | | 684 | | | | 685 | | | | 686 |-------------->| INVITE (Offer) | | 687 | |------------------------>| | 688 | | 183 (Answer) |-------------->| 689 | |<------------------------| | 690 | | | | 691 | | INFO (more candidates) | Candidate | 692 | |<------------------------| | 693 | | Connectivity Checks | | 694 | |<=======================>| Discovery | 695 | | INFO (more candidates) | | 696 | |<------------------------| | 697 | | Connectivity Checks |<--------------| 698 | |<=======================>| | 699 | | | | 700 | | 200 OK | | 701 | |<------------------------| | 702 | | | | 703 | | 5245 SIP re-INVITE | | 704 | |------------------------>| | 705 | | 200 OK | | 706 | |<------------------------| | 707 | | | | 708 | | | | 709 | |<===== MEDIA FLOWS =====>| | 710 | | | | 712 Figure 8: Example 714 It is worth reminding that once a single offer or answer had been 715 exchanged within a specific dialog, support for trickle ICE will have 716 been determined. No further use of half trickle will therefore be 717 necessary within that same dialog and all subsequent exchanges can 718 use the full trickle mode of operation. 720 6. Info Package 722 6.1. Overall Description 724 This specification defines an Info Package meant for use by SIP user 725 agents implementing Trickle ICE. Typically INFO requests would carry 726 ICE candidates discovered after the user agent has sent or received a 727 trickle-ice offer. 729 6.2. Applicability 731 The purpose of the ICE protocol is to establish a media path. The 732 candidates that this specification transports in INFO requests are 733 part of this establishment. There is hence no way for them to be 734 transported through the not yet existing media path. 736 Candidates sent by a trickle ICE agent after the offer, are meant to 737 follow the same signalling path and reach the same entity as the 738 offer itself. While it is true that GRUUs can be used to achieve 739 this, one of the goals of this specification is to allow operation of 740 trickle ICE in as many environments as possible including those with 741 no GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would 742 not satisfy this goal. 744 6.3. Info Package Name 746 This document defines a SIP Info Package as per [RFC6086]. The Info 747 Package token name for this package is "trickle-ice" 749 6.4. Info Package Parameters 751 This document does not define any Info package parameters. 753 6.5. SIP Option-Tags 755 [RFC6086] allows Info Package specifications to define SIP option- 756 tags. This document therefore stipulates that SIP entities that 757 support trickle ICE and this specification MUST place the 'trickle- 758 ice' option-tag in a SIP Supported header field. 760 When responding to, or generating a SIP OPTIONS request a SIP entity 761 MUST also include the 'trickle-ice' option-tag in a SIP Supported 762 header field. 764 6.6. Info Message Body Parts 766 Entities implementing this specification MUST include SDP encoded ICE 767 candidates in all SIP INFO requests. The MIME type for the payload 768 MUST be of type 'application/sdp' as defined in Section 4.2 and 769 [I-D.ietf-mmusic-trickle-ice]. 771 7. Security Considerations 773 [TODO] 775 8. Acknowledgements 777 The authors would like to thank Thomas Stack for suggesting the INFO 778 acknowledgements used in the specification as a way of avoiding 779 making PRACKs mandatory, Paul Kyzivat and Jonathan Lennox for making 780 various suggestions for improvements and optimisations. 782 9. References 784 9.1. Normative References 786 [I-D.ietf-mmusic-trickle-ice] 787 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 788 Incremental Provisioning of Candidates for the Interactive 789 Connectivity Establishment (ICE) Protocol", draft-ietf- 790 mmusic-trickle-ice-01 (work in progress), February 2014. 792 [I-D.ivov-dispatch-sdpfrag] 793 Ivov, E. and A. Roach, "Internet Media Type application/ 794 sdpfrag", draft-ivov-dispatch-sdpfrag-03 (work in 795 progress), October 2013. 797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, March 1997. 800 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 801 A., Peterson, J., Sparks, R., Handley, M., and E. 802 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 803 June 2002. 805 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 806 Provisional Responses in Session Initiation Protocol 807 (SIP)", RFC 3262, June 2002. 809 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 810 with Session Description Protocol (SDP)", RFC 3264, June 811 2002. 813 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 814 Description Protocol", RFC 4566, July 2006. 816 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 817 (ICE): A Protocol for Network Address Translator (NAT) 818 Traversal for Offer/Answer Protocols", RFC 5245, April 819 2010. 821 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 822 Initiation Protocol (SIP) INFO Method and Package 823 Framework", RFC 6086, January 2011. 825 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 826 Protocol (XMPP): Core", RFC 6120, March 2011. 828 9.2. Informative References 830 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 831 Schulzrinne, "Grouping of Media Lines in the Session 832 Description Protocol (SDP)", RFC 3388, December 2002. 834 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 835 "Indicating User Agent Capabilities in the Session 836 Initiation Protocol (SIP)", RFC 3840, August 2004. 838 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 839 Agent URIs (GRUUs) in the Session Initiation Protocol 840 (SIP)", RFC 5627, October 2009. 842 [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: 843 Combined Use of the Session Initiation Protocol (SIP) and 844 the Extensible Messaging and Presence Protocol (XMPP)", 845 RFC 7081, November 2013. 847 Appendix A. Open issues 849 At the time of writing of this document the authors have no clear 850 view on how and if the following list of issues should be address 851 here: 853 1. Should we allow for full trickle if support can be verified 854 automatically and confirmed for a gruu with [RFC3840]. 856 2. Can we pick between MID and stream indices for stream 857 identification. 859 Authors' Addresses 861 Emil Ivov 862 Jitsi 863 Strasbourg 67000 864 France 866 Phone: +33 6 72 81 15 55 867 Email: emcho@jitsi.org 869 Enrico Marocco 870 Telecom Italia 871 Via G. Reiss Romoli, 274 872 Turin 10148 873 Italy 875 Email: enrico.marocco@telecomitalia.it 877 Christer Holmberg 878 Ericsson 879 Hirsalantie 11 880 Jorvas 02420 881 Finland 883 Email: christer.holmberg@ericsson.com