idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-01.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 (January 15, 2015) is 3389 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 797, 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) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft Jitsi 4 Intended status: Standards Track E. Marocco 5 Expires: July 19, 2015 Telecom Italia 6 C. Holmberg 7 Ericsson 8 January 15, 2015 10 A Session Initiation Protocol (SIP) usage for Trickle ICE 11 draft-ietf-mmusic-trickle-ice-sip-01 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 July 19, 2015. 44 Copyright Notice 46 Copyright (c) 2015 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 4.3. Initiating trickle ICE without an SDP Answer . . . . . . 14 71 5. Initial discovery of trickle ICE support . . . . . . . . . . 14 72 5.1. Provisioning support for trickle ICE . . . . . . . . . . 15 73 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 15 74 5.3. Trickle ICE discovery through other protocols . . . . . . 16 75 5.4. Fallback to half trickle . . . . . . . . . . . . . . . . 16 76 6. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 19 77 6.1. Overall Description . . . . . . . . . . . . . . . . . . . 19 78 6.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 19 79 6.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 19 80 6.4. Info Package Parameters . . . . . . . . . . . . . . . . . 19 81 6.5. SIP Option-Tags . . . . . . . . . . . . . . . . . . . . . 19 82 6.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 20 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 87 9.2. Informative References . . . . . . . . . . . . . . . . . 21 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 Trickle 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 [RFC5588]. 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, which would be indicated by a media level 517 "a=end-of-candidates" line). 519 The use of "a=mid" lines allows for a structure similar to the one in 520 SDP offers and answers where one can distinguish separate media-level 521 and session-level sections. In the current case lines preceding any 522 "a=mid" lines are considered to be session-level. Lines appearing in 523 between or after "a=mid" lines will be interpreted as media-level. 525 Note that while this specification uses the a=mid: attribute from 526 [RFC5588], it does not define any grouping semantics. 527 Consequently, using the a=group: attribute from that same 528 specification is neither needed nor used in trickle ICE for SIP. 530 All INFO requests MUST carry the "ice-pwd" and "ice-ufrag" attributes 531 that would allow mapping them to a specific ICE generation. INFO 532 requests containing ice-ufrag and ice-pwd values that do not match 533 those of the current ICE processing session MUST be discarded. The 534 "ice-pwd" and "ice-ufrag" attributes MUST appear at the same level as 535 the ones in the Offer/Answer exchange. In other words, if they were 536 present as sesssion-level attributes there, they will also appear at 537 the beginning of all INFO message payloads, preceding all "a=mid" 538 lines. If they were originally exchanged as media level attributes, 539 potentially overriding session-level values, then they will also be 540 included in INFO message payloads, following the corresponding 541 "a=mid' line. 543 In every INFO request agents MUST include all local candidates they 544 have previously signalled. This is necessary in order to more easily 545 avoid problems that would arise from misordering and unreliability. 547 When receiving INFO requests carrying any candidates, agents will 548 therefore first identify and discard the SDP lines containing 549 candidates they have already received in previous INFO requests or in 550 the Offer/Answer exchange preceding them. Two candidates are 551 considered to be equal if their IP address port, transport and 552 component ID are the same. After identifying and discarding known 553 candidates, agents will then process them remaining ones (the actual 554 new candidates) according to the rules described in 555 [I-D.ietf-mmusic-trickle-ice]. 557 The following example shows the content of one sample candidate 558 delivering INFO request: 560 INFO sip:alice@example.com SIP/2.0 561 ... 562 Info-Package: trickle-ice 563 Content-type: application/sdp 564 Content-Disposition: Info-Package 565 Content-length: ... 567 a=ice-pwd:asd88fgpdd777uzjYhagZg 568 a=ice-ufrag:8hhY 569 a=mid:1 570 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 571 a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx 572 raddr 10.0.1.1 rport 8998 573 a=mid:2 574 a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx 575 raddr 10.0.1.1 rport 9000 576 a=end-of-candidates 578 4.3. Initiating trickle ICE without an SDP Answer 580 The possibility to convey arbitrary SDP fragments in SIP message 581 bodies [I-D.ivov-dispatch-sdpfrag] allows ICE agents to initiate 582 trickling without actually sending an answer. Trickle ICE answerers 583 MAY therefore respond to INVITEs with provisional responses that only 584 contain the information necessary for ICE processing to begin. 586 Agents that choose to do so, need to send in these responses all ICE- 587 related session level information that would have otherwise been 588 present in an SDP answer. At the very least these responses MUST 589 include the "ice-options" attribute for "trickle" and all other ICE 590 options they support. 592 The "ice-ufrag" and "ice-pwd" options MUST also be present in all 183 593 responses and they MAY appear as either session or media level 594 attributes. 596 5. Initial discovery of trickle ICE support 598 SIP User Agents (UAs) that support and intend to use trickle ICE are 599 REQUIRED by [I-D.ietf-mmusic-trickle-ice] to indicate that in their 600 offers and answers using the following attribute: "a=ice- 601 options:trickle". This makes discovery fairly straightforward for 602 answerers or for cases where offers need to be generated within 603 existing dialogs (i.e., when sending re-INVITE requests). In both 604 scenarios prior SDP would have provided the necessary information. 606 Obviously, prior SDP is not available at the time a first offer is 607 being constructed and it is therefore impossible for ICE agents to 608 determine support for incremental provisioning that way. The 609 following options are suggested as ways of addressing this issue. 611 5.1. Provisioning support for trickle ICE 613 In certain situations it may be possible for integrators deploying 614 trickle ICE to know in advance that some or all endpoints reachable 615 from within the deployment will support trickle ICE. This is likely 616 to be the case, for example, for WebRTC clients that will always be 617 communicating with other WebRTC clients or known Session Border 618 Controllers (SBC) with support for this specification. 620 While the exact mechanism for allowing such provisioning is out of 621 scope here, this specification encourages trickle ICE implementations 622 to allow the option in the way they find most appropriate. 624 5.2. Trickle ICE discovery with GRUU 626 [RFC3840] provides a way for SIP user agents to query for support of 627 specific capabilities using, among others, OPTIONS requests. GRUU 628 support on the other hand allows SIP requests to be addressed to 629 specific UAs (as opposed to arbitrary instances of an address of 630 record). Combining the two and using the "trickle-ice" option tag 631 defined in Section 6.5 provides SIP UAs with a way of learning the 632 capabilities of specific US instances and then addressing them 633 directly with INVITE requests that require SIP support. 635 Such targeted trickling may happen in different ways. One option 636 would be for a SIP UA to learn the GRUU instance ID of a peer through 637 presence and to then query its capabilities direction with an OPTIONS 638 request. Alternately, it can also just send an OPTIONS request to 639 the AOR it intends to contact and then inspect the returned 640 response(s) for support of both GRUU and trickle ICE (Figure 7). 642 Alice Bob 643 | | 644 | OPTIONS sip:b1@example.com SIP/2.0 | 645 |-------------------------------------------------->| 646 | | 647 | 200 OK | 648 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 649 | ;audio;video|;trickle-ice;... | 650 |<--------------------------------------------------| 651 | | 652 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 653 |-------------------------------------------------->| 654 | | 655 | 183 (Answer) | 656 |<--------------------------------------------------| 657 | INFO/OK (Trickling) | 658 |<------------------------------------------------->| 659 | | 660 | ... | 661 | | 663 Figure 7: Trickle ICE support discovery with OPTIONS and GRUU 665 Confirming support for trickle ICE through [RFC3840] gives SIP UAs 666 the options to engage in full trickle negotiation (as opposed to the 667 more lengthy half-trickle) from the very first offer they send. 669 5.3. Trickle ICE discovery through other protocols 671 Protocols like XMPP [RFC6120] define advanced discovery mechanisms 672 that allow specific features to be queried priory to actually 673 attempting to use them. Solutions like [RFC7081] define ways of 674 using SIP and XMPP together which also provides a way for dual stack 675 SIP+XMPP endpoints to make use of such features and verify trickle 676 ICE support for a specific SIP endpoint through XMPP. [TODO expand 677 on a specific way to do this] 679 5.4. Fallback to half trickle 681 In cases where none of the other mechanisms in this section are 682 acceptable, SIP UAs should use the "half trickle" mode defined in 683 [I-D.ietf-mmusic-trickle-ice]. With half trickle, agents initiate 684 sessions the same way they would when using vanilla ICE [RFC5245]. 685 This means that, prior to actually sending an offer, agents would 686 first gather ICE candidates in a blocking way and then send them all 687 in that offer. The blocking nature of the process would likely imply 688 that some amount of latency will be accumulated and it is advised 689 that agents try to anticipate it where possible, like for example, 690 when user actions indicate a high likelyhood for an imminent call 691 (e.g., activity on a keypad or a phone going offhook). 693 Using half trickle would result in offers that are compatible with 694 both vanilla ICE and legacy [RFC3264] endpoints both. 696 A typical (half) trickle ICE exchange with SIP would look this way: 698 STUN/Turn STUN/TURN 699 Servers Alice Bob Servers 700 | | | | 701 |<--------------| | | 702 | | | | 703 | | | | 704 | Candidate | | | 705 | | | | 706 | | | | 707 | Discovery | | | 708 | | | | 709 | | | | 710 |-------------->| INVITE (Offer) | | 711 | |------------------------>| | 712 | | 183 (Answer) |-------------->| 713 | |<------------------------| | 714 | | | | 715 | | INFO (more candidates) | Candidate | 716 | |<------------------------| | 717 | | Connectivity Checks | | 718 | |<=======================>| Discovery | 719 | | INFO (more candidates) | | 720 | |<------------------------| | 721 | | Connectivity Checks |<--------------| 722 | |<=======================>| | 723 | | | | 724 | | 200 OK | | 725 | |<------------------------| | 726 | | | | 727 | | 5245 SIP re-INVITE | | 728 | |------------------------>| | 729 | | 200 OK | | 730 | |<------------------------| | 731 | | | | 732 | | | | 733 | |<===== MEDIA FLOWS =====>| | 734 | | | | 736 Figure 8: Example 738 It is worth reminding that once a single offer or answer had been 739 exchanged within a specific dialog, support for trickle ICE will have 740 been determined. No further use of half trickle will therefore be 741 necessary within that same dialog and all subsequent exchanges can 742 use the full trickle mode of operation. 744 6. Info Package 746 6.1. Overall Description 748 This specification defines an Info Package meant for use by SIP user 749 agents implementing Trickle ICE. Typically INFO requests would carry 750 ICE candidates discovered after the user agent has sent or received a 751 trickle-ice offer. 753 6.2. Applicability 755 The purpose of the ICE protocol is to establish a media path. The 756 candidates that this specification transports in INFO requests are 757 part of this establishment. There is hence no way for them to be 758 transported through the not yet existing media path. 760 Candidates sent by a trickle ICE agent after the offer, are meant to 761 follow the same signalling path and reach the same entity as the 762 offer itself. While it is true that GRUUs can be used to achieve 763 this, one of the goals of this specification is to allow operation of 764 trickle ICE in as many environments as possible including those with 765 no GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would 766 not satisfy this goal. 768 6.3. Info Package Name 770 This document defines a SIP Info Package as per [RFC6086]. The Info 771 Package token name for this package is "trickle-ice" 773 6.4. Info Package Parameters 775 This document does not define any Info package parameters. 777 6.5. SIP Option-Tags 779 [RFC6086] allows Info Package specifications to define SIP option- 780 tags. This document therefore stipulates that SIP entities that 781 support trickle ICE and this specification MUST place the 'trickle- 782 ice' option-tag in a SIP Supported header field. 784 When responding to, or generating a SIP OPTIONS request a SIP entity 785 MUST also include the 'trickle-ice' option-tag in a SIP Supported 786 header field. 788 6.6. Info Message Body Parts 790 Entities implementing this specification MUST include SDP encoded ICE 791 candidates in all SIP INFO requests. The MIME type for the payload 792 MUST be of type 'application/sdp' as defined in Section 4.2 and 793 [I-D.ietf-mmusic-trickle-ice]. 795 7. Security Considerations 797 [TODO] 799 8. Acknowledgements 801 The authors would like to thank Thomas Stach for suggesting the INFO 802 acknowledgements used in the specification as a way of avoiding 803 making PRACKs mandatory, Paul Kyzivat and Jonathan Lennox and Thomas 804 Stach for making various other suggestions for improvements and 805 optimisations. 807 9. References 809 9.1. Normative References 811 [I-D.ietf-mmusic-trickle-ice] 812 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 813 Incremental Provisioning of Candidates for the Interactive 814 Connectivity Establishment (ICE) Protocol", draft-ietf- 815 mmusic-trickle-ice-01 (work in progress), February 2014. 817 [I-D.ivov-dispatch-sdpfrag] 818 Ivov, E. and A. Roach, "Internet Media Type application/ 819 sdpfrag", draft-ivov-dispatch-sdpfrag-03 (work in 820 progress), October 2013. 822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 823 Requirement Levels", BCP 14, RFC 2119, March 1997. 825 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 826 A., Peterson, J., Sparks, R., Handley, M., and E. 827 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 828 June 2002. 830 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 831 Provisional Responses in Session Initiation Protocol 832 (SIP)", RFC 3262, June 2002. 834 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 835 with Session Description Protocol (SDP)", RFC 3264, June 836 2002. 838 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 839 Description Protocol", RFC 4566, July 2006. 841 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 842 (ICE): A Protocol for Network Address Translator (NAT) 843 Traversal for Offer/Answer Protocols", RFC 5245, April 844 2010. 846 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 847 Initiation Protocol (SIP) INFO Method and Package 848 Framework", RFC 6086, January 2011. 850 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 851 Protocol (XMPP): Core", RFC 6120, March 2011. 853 9.2. Informative References 855 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 856 "Indicating User Agent Capabilities in the Session 857 Initiation Protocol (SIP)", RFC 3840, August 2004. 859 [RFC5588] Williams, N., "Generic Security Service Application 860 Program Interface (GSS-API) Extension for Storing 861 Delegated Credentials", RFC 5588, July 2009. 863 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 864 Agent URIs (GRUUs) in the Session Initiation Protocol 865 (SIP)", RFC 5627, October 2009. 867 [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: 868 Combined Use of the Session Initiation Protocol (SIP) and 869 the Extensible Messaging and Presence Protocol (XMPP)", 870 RFC 7081, November 2013. 872 Authors' Addresses 874 Emil Ivov 875 Jitsi 876 Strasbourg 67000 877 France 879 Phone: +33 6 72 81 15 55 880 Email: emcho@jitsi.org 881 Enrico Marocco 882 Telecom Italia 883 Via G. Reiss Romoli, 274 884 Turin 10148 885 Italy 887 Email: enrico.marocco@telecomitalia.it 889 Christer Holmberg 890 Ericsson 891 Hirsalantie 11 892 Jorvas 02420 893 Finland 895 Email: christer.holmberg@ericsson.com