idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-00.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 (July 24, 2014) is 3556 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 772, 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: January 25, 2015 Telecom Italia 6 C. Holmberg 7 Ericsson 8 July 24, 2014 10 A Session Initiation Protocol (SIP) usage for Trickle ICE 11 draft-ietf-mmusic-trickle-ice-sip-00 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 January 25, 2015. 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 89 1. Introduction 91 The vanilla specification of the Interactive Connectivity 92 Establishment (vanilla ICE) protocol [RFC5245] describes a mechanism 93 for NAT traversal that consists of three main phases: a phase where 94 an agent gathers a set of candidate transport addresses (source IP 95 address, port and transport protocol), a second phase where these 96 candidates are sent to a remote agent and this gathering procedure is 97 repeated and, finally, a third phase where connectivity between all 98 candidates in both sets is checked (connectivity checks). Once these 99 phases have been completed, and only then, can both agents begin 100 communication. According to the Vanilla ICE specification the three 101 phases above happen consecutively, in a blocking way, which may lead 102 to undesirable latency during session establishment. 104 The trickle ICE extension defined in [I-D.ietf-mmusic-trickle-ice] 105 defines generic semantics required for these ICE phases to happen 106 simultaneously, in a non-blocking way and hence speed up session 107 establishment. 109 The present specification defines a usage of trickle ICE with the 110 Session Initiation Protocol (SIP). It describes how ICE candidates 111 are to be incrementally exchanged with SIP INFO requests and how the 112 half and full-trickle modes defined in [I-D.ietf-mmusic-trickle-ice] 113 are to be used by SIP User Agents (UAs) depending on their 114 expectations for support of trickle ICE by a remote agent. 116 This document defines a new Info Package [RFC6086] for use with 117 Trickle ICE. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 This specification makes use of all terminology defined by the 126 protocol for Interactive Connectivity Establishment in [RFC5245] and 127 its Trickle ICE extension [I-D.ietf-mmusic-trickle-ice]. It is 128 assumed that the reader will be familiar with the terminology from 129 both of them. 131 3. Protocol Overview 133 The semantics that vanilla ICE [RFC5245] defines for exchanging ICE 134 candidates are exclusively based on use of Offers and Answers as per 135 [RFC3264] over the Session Description Protocol (SDP) [RFC4566]. 136 This specification extends these mechanism by allowing ICE candidates 137 to also be sent after the completion of Offer/Answer negotiation, 138 through the use of SIP INFO messages and a newly defined Info Package 139 [RFC6086]. 141 Specifically, in cases where trickle ICE is fully supported, a 142 typical exchange would happen along the following lines: The offerer 143 would send an INVITE containing a subset of candidates and then wait 144 for an early dialog to be established. Once that happens, it will be 145 able to continue sending candidates through in INFO requests and 146 within the same dialog. 148 Similarly, once it has sent an answer (though not earlier) an 149 answerer can continue "trickling" ICE candidates using INFO messages 150 within the dialog established by its 18x provisional response. 151 Figure 1 shows such a sample exchange: 153 STUN/Turn STUN/TURN 154 Servers Alice Bob Servers 155 | | | | 156 | STUN Bi.Req. | INVITE (Offer) | | 157 |<--------------|------------------------>| | 158 | | 183 (Answer) | TURN Alloc Req | 159 | STUN Bi.Resp. |<------------------------|--------------->| 160 |-------------->| INFO/OK (SRFLX Cand.) | | 161 | |------------------------>| TURN Alloc Resp| 162 | | INFO/OK (Relay Cand.) |<---------------| 163 | |<------------------------| | 164 | | | | 165 | | More Cands & ConnChecks| | 166 | |<=======================>| | 167 | | | | 168 | | 200 OK | | 169 | |<------------------------| | 170 | | ACK | | 171 | |------------------------>| | 172 | | | | 173 | | 5245 SIP re-INVITE | | 174 | |------------------------>| | 175 | | 200 OK | | 176 | |<------------------------| | 177 | | ACK | | 178 | |------------------------>| | 179 | | | | 180 | |<===== MEDIA FLOWS =====>| | 181 | | | | 183 Figure 1: Sample trickle ICE scenario with SIP 185 3.1. Rationale. Why INFO 187 The decision to use SIP INFO requests as a candidate transport method 188 is based primarily on their lightweight nature. Once a dialog has 189 been established, INFO messages can be exchanged both ways with no 190 restrictions on timing and frequency and no risk of collision. 192 On the other hand, using offer/answer and UPDATE requests, which from 193 an [RFC5245] perspective is the traditional way of transporting ICE 194 candidates, introduces the following complications: 196 Need for a turn-based mechanism: [RFC3264] defines Offer/Answer as 197 a strictly sequential mechanism. There can only be a maximum of 198 one exchange at any point of time. Both sides cannot 199 simultaneously send offers nor can they generate multiple offers 200 prior to receiving an answer. Using UPDATEs for candidate 201 transport would therefore imply the implementation of a candidate 202 pool at every agent where candidates can be stored until it is 203 once again that agent's "turn" to emit an answer or a new offer. 204 Such an approach would introduce non-negligible complexity for no 205 additional value. 207 Elevated risk of glare: The sequential nature of Offer/Answer also 208 makes it impossible for both sides to send offers simultaneously. 209 What's worse is that there are no mechanisms in SIP to actually 210 prevent that. [RFC3261], where the situation of offers crossing 211 on the wire is described as "glare", only defines a procedure for 212 addressing the issue after it has occurred. According to that 213 procedure both offers are invalidated and both sides need to retry 214 the negotiation after a period between 0 and 4 seconds. The high 215 likelihood for glare to occur and the average two second backoff 216 intervals would imply trickle ICE processing duration would not 217 only fail to improve but actually exceed those of vanilla ICE. 219 INFO messages have no impact on the Offer/Answer negotiation and are 220 subject to none of the glare issues described above, which makes them 221 a very convenient and lightweight mechanism for asynchronous delivery 222 of candidates. 224 Using in-dialog INFO messages also provides a way of guaranteeing 225 that candidates are delivered end-to-end, between the same entities 226 that are actually in the process of initiating a session. The 227 alternative would have implied requiring support for Globally 228 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 229 adoption levels, would have constituted too strong of constraint to 230 the adoption of trickle ICE. 232 3.2. Discovery issues 234 In order for to benefit from trickle ICE's full potential and reduce 235 session establishment latency to a minimum, trickle ICE agents need 236 to generate SDP offers and answers that contain incomplete, 237 potentially empty sets of candidates. Such offers and answers can 238 only be handled meaningfully by agents that actually support 239 incremental candidate provisioning, which implies the need to confirm 240 such support before actually using it. 242 Contrary to other protocols, like XMPP [RFC6120], where "in advance" 243 capability discovery is widely implemented, the mechanisms that allow 244 this for sip (i.e., a combination of UA Capabilities [RFC3840] and 245 GRUU [RFC5627]) have only seen low levels of adoption. This presents 246 an issue for trickle ICE implementations as SIP UAs do not have an 247 obvious means of verifying that their peer will support incremental 248 candidate provisioning. 250 The "half trickle" mode of operation defined in the trickle ICE 251 specification [I-D.ietf-mmusic-trickle-ice] provides one way around 252 this, by requiring first offers to contain a complete set of ICE 253 candidates and only using incremental provisioning for the rest of 254 the sessions. 256 While using "half trickle" does provide a working solution it also 257 comes at the price of increased latency. Section 5 therefore makes 258 several alternative suggestions that enable SIP UAs to engage in full 259 trickle right from their first offer: Section 5.1 discusses the use 260 of on-line provisioning as a means of allowing use of trickle ICE for 261 all endpoints in controlled environments. Section 5.2 describes 262 anticipatory discovery for implementations that actually do support 263 GRUU and UA Capabilities and Section 5.4 discusses the implementation 264 and use of "half trickle" by SIP UAs where none of the above are an 265 option. 267 3.3. Relationship with the Offer/Answer Model 269 It is important to note that this specification does not require, 270 define, or even assume any mechanisms that would have an impact on 271 the Offer/Answer model beyond the way it is already used by vanilla 272 ICE [RFC5245]. From the perspective of all SIP middle boxes and 273 proxies, and with the exception of the actual INFO messages, 274 signalling in general and Offer/Answer exchanges in particular would 275 look the same way for trickle as they would for vanilla ICE. 277 +-------------------------------+ +-------------------------------+ 278 | Alice +--------------+ | | +--------------+ Bob | 279 | | Offer/Answer | | | | Offer/Answer | | 280 | +-------+ | Module | | | | Module | +-------+ | 281 | | ICE | +--------------+ | | +--------------+ | ICE | | 282 | | Agent | | | | | | Agent | | 283 | +-------+ | | | | +-------+ | 284 +-------------------------------+ +-------------------------------+ 285 | | | | 286 | | INVITE (Offer) | | 287 | |--------------------->| | 288 | | 183 (Answer) | | 289 | |<---------------------| | 290 | | | | 291 | | 292 | SIP INFO (more candidates) | 293 |----------------------------------------------------->| 294 | SIP INFO (more candidates) | 295 |<-----------------------------------------------------| 296 | | 297 | STUN Binding Requests/Responses | 298 |----------------------------------------------------->| 299 | STUN Binding Requests/Responses | 300 |<-----------------------------------------------------| 301 | | 302 | | | | 303 | | 5245 SIP re-INVITE | | 304 | |--------------------->| | 305 | | 200 OK | | 306 | |<---------------------| | 308 Figure 2: Distinguishing between trickle ICE and traditional 309 signalling. 311 It is important to note that, as displayed on Figure 2, exchanging 312 candidates through SIP INFO messages are best represented as 313 signalling between ICE agents and not between the traditional SIP and 314 Offer/Answer modules of SIP User Agents. Such INFO requests do not 315 impact the state of Offer/Answer, nor do they have an impact on the 316 version number in the "o=" line. In that regard they are actually 317 comparable to Peer Reflexive candidates that ICE agents can discover 318 during ICE processing. 320 4. Incremental signalling of ICE candidates 322 Trickle ICE agents will construct offers and answers the same way a 323 [RFC5245] compatible agent would, with the following two main 324 differences: 326 o First, all offers and answers sent by the trickle ICE capable 327 agents MUST indicate support for trickle ICE through the "trickle" 328 ice-options tag defined in [I-D.ietf-mmusic-trickle-ice]: 330 a=ice-options:trickle 332 o Second, offers and answers may contain all, some, or no ICE 333 candidates at all. 335 Once an agent has sent an offer or an answer indicating support for 336 trickle ICE, it MUST be prepared to receive SIP INFO requests within 337 that same dialog, containing additional candidates or an indication 338 for the end of such candidates. 340 Similarly, as soon as a SIP UA has established a dialog (including an 341 early state one) it MAY begin sending INFO requests containing 342 additional candidates or end-of-candidates indications. Such INFO 343 requests MUST be sent within that same dialog. This is necessary so 344 that the candidates from these INFO messages could be delivered to 345 the same entities that initiated the session. 347 4.1. Asserting Offer/Answer delivery and dialog state 349 In order for SIP UAs to be able to start trickling, the following two 350 conditions need to be satisfied: 352 o ICE support in the peer agent MUST be confirmed. 354 o The SIP dialog at both sides MUST be at least in the early state. 356 Section 5 discusses in detail the various options for satisfying the 357 first of the above conditions. Regardless of those mechanisms 358 however, agents are certain to have a clear understanding of whether 359 their peers support trickle ICE once an offer and and an answer have 360 been exchanged, which needs to happen anyway for ICE processing to 361 commence (see Figure 3). 363 Alice Bob 364 | | 365 | INVITE (Offer) | 366 |------------------------>| 367 | 183 (Answer) | 368 |<------------------------| 369 | | 370 +----------------------+ | 371 |Alice: I know Bob can| | 372 |trickle and I know his| | 373 |dialog is in the early| | 374 |state. Send INFO! | | 375 +----------------------+ | 376 | | 377 | INFO/OK (SRFLX Cand.) | 378 |------------------------>| 379 | | 381 Figure 3: SIP Offerer can freely trickle as soon as it receives an 382 answer. 384 Satisfying both conditions is also relatively trivial for ICE agents 385 that have sent an offer in an INVITE and that have received an 386 answer. Regardless of how that answer was delivered, it is 387 guaranteed to have confirmed support for trickle ICE within the 388 answerer (or lack thereof) and to have fully initialized the SIP 389 dialog at both ends. Offerers in the above situation can therefore 390 freely commence trickling within the newly established dialog (see 391 Figure 4). 393 Alice Bob 394 | | 395 | INVITE | 396 |------------------------>| 397 | 183 (Offer) | 398 |<------------------------| 399 | PRACK (Answer) | 400 |------------------------>| 401 | | 402 | +----------------------+ 403 | |Bob: I know Alice can| 404 | |trickle and I know her| 405 | |dialog is in the early| 406 | |state. Send INFO! | 407 | +----------------------+ 408 | | 409 | INFO/OK (SRFLX Cand.) | 410 |<------------------------| 411 | | 413 Figure 4: A SIP Offerer in a 3PCC scenario can also freely start 414 trickling as soon as it receives an answer. 416 Agents that have sent an offer in a reliable provisional response or 417 in a 200 OK and that receive an answer in a PRACK or in an ACK are 418 also in a similar situation because, by the time the offer and the 419 answer are exchanged, support for trickle ICE will be confirmed and 420 the SIP dialog is guaranteed to be in a state that would allow in- 421 dialog INFO requests. 423 The situation is a bit more delicate for agents that have received an 424 offer in an INVITE request and have sent an answer in an unreliable 425 provisional response because, once the response has been sent, there 426 is no way for the answerer to know when or if it has been received 427 (Figure 5). 429 Alice Bob 430 | | 431 | INVITE (Offer) | 432 |------------------------>| 433 | 183 (Answer) | 434 |<------------------------| 435 | | 436 | +----------------------+ 437 | |Bob: I don't know if | 438 | |Alice got my 183 or if| 439 | |her dialog is already | 440 | |in the early state. | 441 | | Can I send INFO??? | 442 | +----------------------+ 443 | | 445 Figure 5: A SIP UA that has answer-ed in an unreliable provisional 446 response cannot know exactly when it is received and when the dialog 447 at the side of the receiver has entered the early state 449 In order to clear this ambiguity as soon as possible, trickle ICE SIP 450 UAs MUST send a trickle ICE INFO request as soon as they receive an 451 SDP Answer in an unreliable provisional response. This INFO message 452 can only contain the candidates that were already provided in the 453 offer (as would be the case when half trickle is performed or when no 454 new candidates have been learned since then) or they can also deliver 455 new information, such as new candidates (if available) or an end-of- 456 candidates indication in case candidate discovery has ended in the 457 mean time. 459 As soon as answerers have received such INFO requests, they would 460 have an indication that a dialog is well established at both ends and 461 they MAY begin trickling (Figure 6). 463 Alice Bob 464 | | 465 | INVITE (Offer) | 466 |------------------------>| 467 | 183 (Answer) | 468 |<------------------------| 469 | INFO/OK (SRFLX Cand.) | 470 |------------------------>| 471 | | 472 | +----------------------+ 473 | |Bob: Now I know Alice| 474 | | is ready. Send INFO! | 475 | +----------------------+ 476 | INFO/OK (SRFLX Cand.) | 477 |<------------------------| 478 | | 480 Figure 6: A SIP UA that has answer-ed in an unreliable provisional 481 response cannot know exactly when it is received and when the dialog 482 at the side of the receiver has entered the early state 484 Obviously, if PRACK [RFC3262] requests are supported and used, there 485 is no need for the above as the PRACKs themselves would provide 486 sufficient indication for the state of the dialog. 488 4.2. Delivering candidates in INFO messages 490 Whenever new ICE candidates become available for sending, agents 491 would encode them in "a=candidate" lines as described by 492 [I-D.ietf-mmusic-trickle-ice]. For example: 494 a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx 495 raddr 10.0.1.1 rport 8998 497 The use of SIP INFO requests happens within the context of an Info 498 Package specifically defined for the purpose (Section 6). 500 Such INFO requests MUST be sent within the existing SIP dialog. The 501 MIME type for their payload MUST be set to 'application/sdpfrag' as 502 defined in [I-D.ivov-dispatch-sdpfrag]. 504 Since neither the "a=candidate" nor the "a=end-of-candidates" lines 505 contain information that would allow correlating them to a specific 506 "m=" line, this is handled through the use of MID [RFC3388]. Agents 507 MUST include the corresponding "a=mid" line for every "m=" line whose 508 candidate list they intend to update. Such "a=mid" lines MUST 509 immediately precede the list of candidates for that specific "m=" 510 line. All "a=candidate" or "a=end-of-candidates" lines following an 511 "a=mid" line, up until (and excluding) the next occurrence of an 512 "a=mid" line, pertain the the "m=" line identified by that MID. 513 "a=end-of-candidates" lines preceding any "a=mid" lines indicate end 514 of all trickling from that agent (as opposed to end of trickling for 515 a specific "m=" line. 517 The use of "a=mid" lines allows for a structure similar to the one in 518 SDP offers and answers where one can distinguish separate media-level 519 and session-level sections. In the current case lines preceding any 520 "a=mid" lines are considered to be session-level. Lines appearing in 521 between or after "a=mid" lines will be interpreted as media-level. 523 All INFO requests MUST carry the "ice-pwd" and "ice-ufrag" attributes 524 that would allow mapping them to a specific ICE generation. INFO 525 requests containing ice-ufrag and ice-pwd values that do not match 526 those of the current ICE processing session MUST be discarded. The 527 "ice-pwd" and "ice-ufrag" attributes MUST appear at the same level as 528 the ones in the Offer/Answer exchange. In other words, if they were 529 present as sesssion-level attributes there, they will also appear at 530 the beginning of all INFO message payloads, preceding all "a=mid" 531 lines. If they were originally exchanged as media level attributes, 532 potentially overriding session-level values, then they will also be 533 included in INFO message payloads, following the corresponding 534 "a=mid' line. 536 In every INFO request agents MUST include all local candidates they 537 have previously signalled. This is necessary in order to more easily 538 avoid problems that would arise from misordering and unreliability. 540 When receiving INFO requests carrying any candidates, agents will 541 therefore first identify and discard the SDP lines containing 542 candidates they have already received in previous INFO requests or in 543 the Offer/Answer exchange preceding them. Two candidates are 544 considered to be equal if their IP address port, transport and 545 component ID are the same. After identifying and discarding known 546 candidates, agents will then process them remaining ones (the actual 547 new candidates) according to the rules described in 548 [I-D.ietf-mmusic-trickle-ice]. 550 The following example shows the content of one sample candidate 551 delivering INFO request: 553 INFO sip:alice@example.com SIP/2.0 554 ... 555 Info-Package: trickle-ice 556 Content-type: application/sdp 557 Content-Disposition: Info-Package 558 Content-length: ... 560 a=ice-pwd:asd88fgpdd777uzjYhagZg 561 a=ice-ufrag:8hhY 562 a=mid:1 563 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 564 a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx 565 raddr 10.0.1.1 rport 8998 566 a=mid:2 567 a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx 568 raddr 10.0.1.1 rport 9000 569 a=end-of-candidates 571 5. Initial discovery of trickle ICE support 573 SIP User Agents (UAs) that support and intend to use trickle ICE are 574 REQUIRED by [I-D.ietf-mmusic-trickle-ice] to indicate that in their 575 offers and answers using the following attribute: "a=ice- 576 options:trickle". This makes discovery fairly straightforward for 577 answerers or for cases where offers need to be generated within 578 existing dialogs (i.e., when sending re-INVITE requests). In both 579 scenarios prior SDP would have provided the necessary information. 581 Obviously, prior SDP is not available at the time a first offer is 582 being constructed and it is therefore impossible for ICE agents to 583 determine support for incremental provisioning that way. The 584 following options are suggested as ways of addressing this issue. 586 5.1. Provisioning support for trickle ICE 588 In certain situations it may be possible for integrators deploying 589 trickle ICE to know in advance that some or all endpoints reachable 590 from within the deployment will support trickle ICE. This is likely 591 to be the case, for example, for WebRTC clients that will always be 592 communicating with other WebRTC clients or known Session Border 593 Controllers (SBC) with support for this specification. 595 While the exact mechanism for allowing such provisioning is out of 596 scope here, this specification encourages trickle ICE implementations 597 to allow the option in the way they find most appropriate. 599 5.2. Trickle ICE discovery with GRUU 601 [RFC3840] provides a way for SIP user agents to query for support of 602 specific capabilities using, among others, OPTIONS requests. GRUU 603 support on the other hand allows SIP requests to be addressed to 604 specific UAs (as opposed to arbitrary instances of an address of 605 record). Combining the two and using the "trickle-ice" option tag 606 defined in Section 6.5 provides SIP UAs with a way of learning the 607 capabilities of specific US instances and then addressing them 608 directly with INVITE requests that require SIP support. 610 Such targeted trickling may happen in different ways. One option 611 would be for a SIP UA to learn the GRUU instance ID of a peer through 612 presence and to then query its capabilities direction with an OPTIONS 613 request. Alternately, it can also just send an OPTIONS request to 614 the AOR it intends to contact and then inspect the returned 615 response(s) for support of both GRUU and trickle ICE (Figure 7). 617 Alice Bob 618 | | 619 | OPTIONS sip:b1@example.com SIP/2.0 | 620 |-------------------------------------------------->| 621 | | 622 | 200 OK | 623 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 624 | ;audio;video|;trickle-ice;... | 625 |<--------------------------------------------------| 626 | | 627 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 628 |-------------------------------------------------->| 629 | | 630 | 183 (Answer) | 631 |<--------------------------------------------------| 632 | INFO/OK (Trickling) | 633 |<------------------------------------------------->| 634 | | 635 | ... | 636 | | 638 Figure 7: Trickle ICE support discovery with OPTIONS and GRUU 640 Confirming support for trickle ICE through [RFC3840] gives SIP UAs 641 the options to engage in full trickle negotiation (as opposed to the 642 more lengthy half-trickle) from the very first offer they send. 644 5.3. Trickle ICE discovery through other protocols 646 Protocols like XMPP [RFC6120] define advanced discovery mechanisms 647 that allow specific features to be queried priory to actually 648 attempting to use them. Solutions like [RFC7081] define ways of 649 using SIP and XMPP together which also provides a way for dual stack 650 SIP+XMPP endpoints to make use of such features and verify trickle 651 ICE support for a specific SIP endpoint through XMPP. [TODO expand 652 on a specific way to do this] 654 5.4. Fallback to half trickle 656 In cases where none of the other mechanisms in this section are 657 acceptable, SIP UAs should use the "half trickle" mode defined in 658 [I-D.ietf-mmusic-trickle-ice]. With half trickle, agents initiate 659 sessions the same way they would when using vanilla ICE [RFC5245]. 660 This means that, prior to actually sending an offer, agents would 661 first gather ICE candidates in a blocking way and then send them all 662 in that offer. The blocking nature of the process would likely imply 663 that some amount of latency will be accumulated and it is advised 664 that agents try to anticipate it where possible, like for example, 665 when user actions indicate a high likelyhood for an imminent call 666 (e.g., activity on a keypad or a phone going offhook). 668 Using half trickle would result in offers that are compatible with 669 both vanilla ICE and legacy [RFC3264] endpoints both. 671 A typical (half) trickle ICE exchange with SIP would look this way: 673 STUN/Turn STUN/TURN 674 Servers Alice Bob Servers 675 | | | | 676 |<--------------| | | 677 | | | | 678 | | | | 679 | Candidate | | | 680 | | | | 681 | | | | 682 | Discovery | | | 683 | | | | 684 | | | | 685 |-------------->| INVITE (Offer) | | 686 | |------------------------>| | 687 | | 183 (Answer) |-------------->| 688 | |<------------------------| | 689 | | | | 690 | | INFO (more candidates) | Candidate | 691 | |<------------------------| | 692 | | Connectivity Checks | | 693 | |<=======================>| Discovery | 694 | | INFO (more candidates) | | 695 | |<------------------------| | 696 | | Connectivity Checks |<--------------| 697 | |<=======================>| | 698 | | | | 699 | | 200 OK | | 700 | |<------------------------| | 701 | | | | 702 | | 5245 SIP re-INVITE | | 703 | |------------------------>| | 704 | | 200 OK | | 705 | |<------------------------| | 706 | | | | 707 | | | | 708 | |<===== MEDIA FLOWS =====>| | 709 | | | | 711 Figure 8: Example 713 It is worth reminding that once a single offer or answer had been 714 exchanged within a specific dialog, support for trickle ICE will have 715 been determined. No further use of half trickle will therefore be 716 necessary within that same dialog and all subsequent exchanges can 717 use the full trickle mode of operation. 719 6. Info Package 721 6.1. Overall Description 723 This specification defines an Info Package meant for use by SIP user 724 agents implementing Trickle ICE. Typically INFO requests would carry 725 ICE candidates discovered after the user agent has sent or received a 726 trickle-ice offer. 728 6.2. Applicability 730 The purpose of the ICE protocol is to establish a media path. The 731 candidates that this specification transports in INFO requests are 732 part of this establishment. There is hence no way for them to be 733 transported through the not yet existing media path. 735 Candidates sent by a trickle ICE agent after the offer, are meant to 736 follow the same signalling path and reach the same entity as the 737 offer itself. While it is true that GRUUs can be used to achieve 738 this, one of the goals of this specification is to allow operation of 739 trickle ICE in as many environments as possible including those with 740 no GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would 741 not satisfy this goal. 743 6.3. Info Package Name 745 This document defines a SIP Info Package as per [RFC6086]. The Info 746 Package token name for this package is "trickle-ice" 748 6.4. Info Package Parameters 750 This document does not define any Info package parameters. 752 6.5. SIP Option-Tags 754 [RFC6086] allows Info Package specifications to define SIP option- 755 tags. This document therefore stipulates that SIP entities that 756 support trickle ICE and this specification MUST place the 'trickle- 757 ice' option-tag in a SIP Supported header field. 759 When responding to, or generating a SIP OPTIONS request a SIP entity 760 MUST also include the 'trickle-ice' option-tag in a SIP Supported 761 header field. 763 6.6. Info Message Body Parts 765 Entities implementing this specification MUST include SDP encoded ICE 766 candidates in all SIP INFO requests. The MIME type for the payload 767 MUST be of type 'application/sdp' as defined in Section 4.2 and 768 [I-D.ietf-mmusic-trickle-ice]. 770 7. Security Considerations 772 [TODO] 774 8. Acknowledgements 776 The authors would like to thank Thomas Stach for suggesting the INFO 777 acknowledgements used in the specification as a way of avoiding 778 making PRACKs mandatory, Paul Kyzivat and Jonathan Lennox for making 779 various suggestions for improvements and optimisations. 781 9. References 783 9.1. Normative References 785 [I-D.ietf-mmusic-trickle-ice] 786 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 787 Incremental Provisioning of Candidates for the Interactive 788 Connectivity Establishment (ICE) Protocol", draft-ietf- 789 mmusic-trickle-ice-01 (work in progress), February 2014. 791 [I-D.ivov-dispatch-sdpfrag] 792 Ivov, E. and A. Roach, "Internet Media Type application/ 793 sdpfrag", draft-ivov-dispatch-sdpfrag-03 (work in 794 progress), October 2013. 796 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 797 Requirement Levels", BCP 14, RFC 2119, March 1997. 799 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 800 A., Peterson, J., Sparks, R., Handley, M., and E. 801 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 802 June 2002. 804 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 805 Provisional Responses in Session Initiation Protocol 806 (SIP)", RFC 3262, June 2002. 808 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 809 with Session Description Protocol (SDP)", RFC 3264, June 810 2002. 812 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 813 Description Protocol", RFC 4566, July 2006. 815 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 816 (ICE): A Protocol for Network Address Translator (NAT) 817 Traversal for Offer/Answer Protocols", RFC 5245, April 818 2010. 820 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 821 Initiation Protocol (SIP) INFO Method and Package 822 Framework", RFC 6086, January 2011. 824 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 825 Protocol (XMPP): Core", RFC 6120, March 2011. 827 9.2. Informative References 829 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 830 Schulzrinne, "Grouping of Media Lines in the Session 831 Description Protocol (SDP)", RFC 3388, December 2002. 833 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 834 "Indicating User Agent Capabilities in the Session 835 Initiation Protocol (SIP)", RFC 3840, August 2004. 837 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 838 Agent URIs (GRUUs) in the Session Initiation Protocol 839 (SIP)", RFC 5627, October 2009. 841 [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: 842 Combined Use of the Session Initiation Protocol (SIP) and 843 the Extensible Messaging and Presence Protocol (XMPP)", 844 RFC 7081, November 2013. 846 Authors' Addresses 848 Emil Ivov 849 Jitsi 850 Strasbourg 67000 851 France 853 Phone: +33 6 72 81 15 55 854 Email: emcho@jitsi.org 855 Enrico Marocco 856 Telecom Italia 857 Via G. Reiss Romoli, 274 858 Turin 10148 859 Italy 861 Email: enrico.marocco@telecomitalia.it 863 Christer Holmberg 864 Ericsson 865 Hirsalantie 11 866 Jorvas 02420 867 Finland 869 Email: christer.holmberg@ericsson.com