idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-09.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 abstract seems to contain references ([RFC6086]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 10, 2017) is 2389 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1493, but not defined == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-14 == Outdated reference: A later version (-21) exists of draft-ietf-ice-trickle-14 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-39 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft Jitsi 4 Intended status: Standards Track T. Stach 5 Expires: April 13, 2018 Unaffiliated 6 E. Marocco 7 Telecom Italia 8 C. Holmberg 9 Ericsson 10 October 10, 2017 12 A Session Initiation Protocol (SIP) usage for Trickle ICE 13 draft-ietf-mmusic-trickle-ice-sip-09 15 Abstract 17 The Interactive Connectivity Establishment (ICE) protocol describes a 18 Network Address Translator (NAT) traversal mechanism for UDP-based 19 multimedia sessions established with the Offer/Answer model. The ICE 20 extension for Incremental Provisioning of Candidates (Trickle ICE) 21 defines a mechanism that allows ICE Agents to shorten session 22 establishment delays by making the candidate gathering and 23 connectivity checking phases of ICE non-blocking and by executing 24 them in parallel. 26 This document defines usage semantics for Trickle ICE with the 27 Session Initiation Protocol (SIP) and defines a new Info Package as 28 specified in [RFC6086]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 13, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Discovery issues . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Relationship with the Offer/Answer Model . . . . . . . . 6 69 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 7 70 4.1. Initial Offer/Answer exchange . . . . . . . . . . . . . . 8 71 4.1.1. Sending the initial Offer . . . . . . . . . . . . . . 8 72 4.1.2. Receiving the initial Offer . . . . . . . . . . . . . 9 73 4.1.3. Sending the initial Answer . . . . . . . . . . . . . 9 74 4.1.4. Receiving the initial Answer . . . . . . . . . . . . 9 75 4.2. Establishing the dialog . . . . . . . . . . . . . . . . . 9 76 4.2.1. Asserting dialog state through reliable Offer/Answer 77 delivery . . . . . . . . . . . . . . . . . . . . . . 9 78 4.2.2. Asserting dialog state through unreliable 79 Offer/Answer delivery . . . . . . . . . . . . . . . . 10 80 4.2.3. Initiating Trickle ICE without an SDP Answer . . . . 12 81 4.2.4. Considerations for 3PCC . . . . . . . . . . . . . . . 14 82 4.3. Delivering candidates in INFO messages . . . . . . . . . 15 83 5. Initial discovery of Trickle ICE support . . . . . . . . . . 19 84 5.1. Provisioning support for Trickle ICE . . . . . . . . . . 20 85 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 20 86 5.3. Trickle ICE discovery through other protocols . . . . . . 21 87 5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 21 88 6. Considerations for RTP and RTCP multiplexing . . . . . . . . 23 89 7. Considerations for Media Multiplexing . . . . . . . . . . . . 24 90 8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 27 91 8.1. Defintion . . . . . . . . . . . . . . . . . . . . . . . . 27 92 8.2. Offer/Answer procedures . . . . . . . . . . . . . . . . . 27 93 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 28 94 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 28 95 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 28 96 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 30 97 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 30 98 10.2. Overall Description . . . . . . . . . . . . . . . . . . 31 99 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 31 100 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 31 101 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 31 102 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 31 103 10.7. Info Message Body Parts . . . . . . . . . . . . . . . . 32 104 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 32 105 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 32 106 10.10. Info Package Security Considerations . . . . . . . . . . 32 107 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 108 11.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 32 109 11.2. application/trickle-ice-sdpfrag Media Type . . . . . . . 33 110 11.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 35 111 11.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 35 112 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 113 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 114 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 36 115 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 116 15.1. Normative References . . . . . . . . . . . . . . . . . . 38 117 15.2. Informative References . . . . . . . . . . . . . . . . . 40 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 120 1. Introduction 122 The Interactive Connectivity Establishment protocol 123 [I-D.ietf-mmusic-rfc5245bis] describes a mechanism for NAT traversal 124 that consists of three main phases: a phase where an agent gathers a 125 set of candidate transport addresses (source IP address, port and 126 transport protocol), a second phase where these candidates are sent 127 to a remote agent. There, this gathering procedure is repeated and, 128 finally, a third phase starts where connectivity between all 129 candidates in both sets is checked (connectivity checks). Once these 130 phases have been completed, and only then, both agents can begin 131 communication. According to [I-D.ietf-mmusic-rfc5245bis] the three 132 phases above happen consecutively, in a blocking way, which can 133 introduce undesirable latency during session establishment. 135 The Trickle ICE extension [I-D.ietf-ice-trickle] defines generic 136 semantics required for these ICE phases to happen simultaneously, in 137 a non-blocking way and hence speed up session establishment. 139 This specification defines a usage of Trickle ICE with the Session 140 Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates 141 are to be exchanged incrementally with SIP INFO requests [RFC6086] 142 and how the Half Trickle and Full Trickle modes defined in 144 [I-D.ietf-ice-trickle] are to be used by SIP User Agents (UAs) 145 depending on their expectations for support of Trickle ICE by a 146 remote agent. 148 This document defines a new Info Package as specified in [RFC6086] 149 for use with Trickle ICE. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 This specification makes use of all terminology defined by the 158 protocol for Interactive Connectivity Establishment in 159 [I-D.ietf-mmusic-rfc5245bis] and its Trickle ICE extension 160 [I-D.ietf-ice-trickle]. It is assumed that the reader will be 161 familiar with the terminology from both documents. 163 3. Protocol Overview 165 When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the 166 ICE candidates are exchanged solely via SDP Offer/Answer as per 167 [RFC3264]. This specification defines an additional mechanism where 168 candidates can be exchanged using SIP INFO messages and a newly 169 defined Info Package [RFC6086]. This allows ICE candidates also to 170 be sent in parallel to an ongoing Offer/Answer negotiation and/or 171 after the completion of the Offer/Answer negotiation. 173 Typically, in cases where Trickle ICE is fully supported, the Offerer 174 would send an INVITE request containing a subset of candidates. Once 175 an early dialog is established the Offerer can continue sending 176 candidates in INFO requests within that dialog. 178 Similarly, an Answerer can send ICE candidates using INFO requests 179 within the dialog established by its 18x provisional response. 180 Figure 1 shows such a sample exchange: 182 STUN/Turn STUN/TURN 183 Servers Alice Bob Servers 184 | | | | 185 | STUN Bi.Req. | INVITE (Offer) | | 186 |<--------------|------------------------>| | 187 | | 183 (Answer) | TURN Alloc Req | 188 | STUN Bi.Resp. |<------------------------|--------------->| 189 |-------------->| INFO/OK (SRFLX Cand.) | | 190 | |------------------------>| TURN Alloc Resp| 191 | | INFO/OK (Relay Cand.) |<---------------| 192 | |<------------------------| | 193 | | | | 194 | | More Cands & ConnChecks| | 195 | |<=======================>| | 196 | | | | 197 | | 200 OK | | 198 | |<------------------------| | 199 | | ACK | | 200 | |------------------------>| | 201 | | | | 202 | |<===== MEDIA FLOWS =====>| | 203 | | | | 205 Figure 1: Sample Trickle ICE scenario with SIP 207 3.1. Discovery issues 209 In order to benefit from Trickle ICE's full potential and reduce 210 session establishment latency to a minimum, Trickle ICE agents need 211 to generate SDP Offers and Answers that contain incomplete, 212 potentially empty sets of candidates. Such Offers and Answers can 213 only be handled meaningfully by agents that actually support 214 incremental candidate provisioning, which implies the need to confirm 215 such support before actually using it. 217 Contrary to other protocols, like XMPP [RFC6120], where "in advance" 218 capability discovery is widely implemented, the mechanisms that allow 219 this for SIP (i.e., a combination of UA Capabilities [RFC3840] and 220 GRUU [RFC5627]) have only seen low levels of adoption. This presents 221 an issue for Trickle ICE implementations as SIP UAs do not have an 222 obvious means of verifying that their peer will support incremental 223 candidate provisioning. 225 The Half Trickle mode of operation defined in the Trickle ICE 226 specification [I-D.ietf-ice-trickle] provides one way around this, by 227 requiring the first Offer to contain a complete set of local ICE 228 candidates and only using incremental provisioning of remote 229 candidates for the rest of the session. 231 While using Half Trickle does provide a working solution it also 232 comes at the price of increased latency. Section 5 therefore makes 233 several alternative suggestions that enable SIP UAs to engage in Full 234 Trickle right from their first Offer: Section 5.1 discusses the use 235 of on-line provisioning as a means of allowing use of Trickle ICE for 236 all endpoints in controlled environments. Section 5.2 describes 237 anticipatory discovery for implementations that actually do support 238 GRUU and UA Capabilities and Section 5.4 discusses the implementation 239 and use of Half Trickle by SIP UAs where none of the above are an 240 option. 242 3.2. Relationship with the Offer/Answer Model 244 From the perspective of all SIP middle boxes and proxies, and with 245 the exception of the actual INFO messages, signaling in general and 246 Offer/Answer exchanges in particular would look the same way for 247 Trickle ICE as they would for ICE for SIP 248 [I-D.ietf-mmusic-ice-sip-sdp]. 250 +-------------------------------+ +-------------------------------+ 251 | Alice +--------------+ | | +--------------+ Bob | 252 | | Offer/Answer | | | | Offer/Answer | | 253 | +-------+ | Module | | | | Module | +-------+ | 254 | | ICE | +--------------+ | | +--------------+ | ICE | | 255 | | Agent | | | | | | Agent | | 256 | +-------+ | | | | +-------+ | 257 +-------------------------------+ +-------------------------------+ 258 | | | | 259 | | INVITE (Offer) | | 260 | |--------------------->| | 261 | | 183 (Answer) | | 262 | |<---------------------| | 263 | | | | 264 | | 265 | SIP INFO (more candidates) | 266 |----------------------------------------------------->| 267 | SIP INFO (more candidates) | 268 |<-----------------------------------------------------| 269 | | 270 | STUN Binding Requests/Responses | 271 |----------------------------------------------------->| 272 | STUN Binding Requests/Responses | 273 |<-----------------------------------------------------| 274 | | 276 Figure 2: Distinguishing between Trickle ICE and traditional 277 signaling. 279 From an architectural viewpoint, as displayed in Figure 2, exchanging 280 candidates through SIP INFO requests could be represented as 281 signaling between ICE Agents and not between Offer/Answer modules of 282 SIP User Agents. Then, such INFO requests do not impact the state of 283 the Offer/Answer transaction other than providing additional 284 candidates. Consequently, INFO requests are not considered Offers or 285 Answers. Nevertheless, candidates that have been exchanged using 286 INFO SHALL be included in subsequent Offers or Answers. The version 287 number in the "o=" line of that subsequent offer would need to be 288 incremented by 1 per the rules in [RFC3264]. 290 4. Incremental Signaling of ICE candidates 292 Trickle ICE Agents will construct Offers and Answers with ICE 293 descriptions compliant to [I-D.ietf-ice-trickle] and the following 294 additional SIP-specific additions: 296 1. Trickle ICE Agents MUST indicate support for Trickle ICE by 297 including the SIP option-tag 'trickle-ice' in a SIP Supported: 298 header field within all SIP INVITE requests and responses. 300 2. Trickle ICE Agents MUST indicate support for Trickle ICE by 301 including the ice-option 'trickle' within all SDP Offers and 302 Answers in accordance to [I-D.ietf-ice-trickle]. 304 3. Trickle ICE Agents MAY include any number of ICE candidates, i.e. 305 from zero to the complete set of candidates, in their initial 306 Offer or Answer. If the complete candidate set is included 307 already in the initial Offer, this is called Half-Trickle. 309 4. Trickle ICE Agents MAY exchange additional ICE candidates using 310 INFO requests within an existing INVITE dialog usage (including 311 an early dialog) as specified in [RFC6086]. The INFO requests 312 carry an Info-Package: trickle-ice. Trickle ICE Agents MUST be 313 prepared to receive INFO requests within that same dialog usage, 314 containing additional candidates or an indication for the end of 315 such candidates. 317 5. Trickle ICE Agents MAY exchange additional ICE candidates before 318 the Answerer has sent the Answer provided that an invite dialog 319 usage is established at both Trickle ICE Agents. Note that in 320 case of forking multiple early dialogs will exist. 322 The following sections provide further details on how Trickle ICE 323 Agents perform the initial Offers/Answers exchange and establish the 324 INVITE dialog usage such that they can trickle candidates. 326 4.1. Initial Offer/Answer exchange 328 4.1.1. Sending the initial Offer 330 If the Offerer includes candidates in its initial Offer, it MUST 331 encode these candidates as specified in 332 [I-D.ietf-mmusic-ice-sip-sdp]. 334 If the Offerer wants to send its initial Offer before knowing any 335 candidate of one or more media descriptions, it MUST include the 336 following default values in the corresponding "m=" line. 338 o The media field is set to 'audio'. 340 o The port value is set to '9'. 342 o The proto value is set to 'RTP/AVP'. 344 In any case, the Offerer MUST include the attribute a=ice- 345 options:trickle in accordance to [I-D.ietf-ice-trickle]. 347 4.1.2. Receiving the initial Offer 349 If the initial Offer included candidates, the Answerer MUST treat 350 these candidates as specified in [I-D.ietf-mmusic-ice-sip-sdp]. 352 If the initial Offer included the attribute a=ice-options:trickle, 353 the Answerer MUST be prepared for receiving trickled candidates later 354 on. 356 In case of a "m=" lines with default values neither of the eventually 357 trickled candidates will match the default destination. This 358 situation MUST NOT cause an ICE mismatch (see 359 [I-D.ietf-mmusic-ice-sip-sdp]). 361 4.1.3. Sending the initial Answer 363 Section Section 4.1.1 applies to the Answerer with the roles of 364 Offerer and Answer being swapped. 366 4.1.4. Receiving the initial Answer 368 Section Section 4.1.2 applies to the Answerer with the roles of 369 Offerer and Answer being swapped. 371 4.2. Establishing the dialog 373 In order to be able to start trickling, the following two conditions 374 need to be satisfied at the SIP UAs: 376 o Trickle ICE support at the peer agent MUST be confirmed. 378 o The dialog at both peers MUST be in early or confirmed state. 380 Section 5 discusses in detail the various options for satisfying the 381 first of the above conditions. Regardless of those mechanisms, 382 however, agents are certain to have a clear understanding of whether 383 their peers support trickle ICE once an Offer and an Answer have been 384 exchanged, which also allows for ICE processing to commence (see 385 Figure 3). 387 4.2.1. Asserting dialog state through reliable Offer/Answer delivery 388 Alice Bob 389 | | 390 | INVITE (Offer) | 391 |------------------------>| 392 | 183 (Answer) | 393 |<------------------------| 394 | PRACK/OK | 395 |------------------------>| 396 | | 397 +----------------------------------------+ 398 |Alice and Bob know that both can trickle| 399 |and know that the dialog is in the early| 400 |state. Send INFO! | 401 +----------------------------------------+ 402 | | 403 | INFO/OK (+SRFLX Cand.) | 404 |------------------------>| 405 | INFO/OK (+SRFLX Cand.) | 406 |<------------------------| 407 | | 409 Figure 3: SIP Offerer can freely trickle as soon as it receives an 410 Answer. 412 As shown in Figure 3 satisfying both conditions is relatively trivial 413 for ICE Agents that have sent an Offer in an INVITE and that have 414 received an Answer in a reliable provisional response. It is 415 guaranteed to have confirmed support for Trickle ICE at the Answerer 416 (or lack thereof) and to have fully initialized the SIP dialog at 417 both ends. Offerers and Answerers (after receipt of the PRACK 418 request) in the above situation can therefore freely commence 419 trickling within the newly established dialog. 421 4.2.2. Asserting dialog state through unreliable Offer/Answer delivery 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, the 426 Answerer does not know when or if it has been received (Figure 4). 428 Alice Bob 429 | | 430 | INVITE (Offer) | 431 |------------------------>| 432 | 183 (Answer) | 433 |<------------------------| 434 | | 435 | +----------------------+ 436 | |Bob: I don't know if | 437 | |Alice got my 183 or if| 438 | |her dialog is already | 439 | |in the early state. | 440 | | Can I send INFO??? | 441 | +----------------------+ 442 | | 444 Figure 4: A SIP UA that sent an Answer in an unreliable provisional 445 response does not know if it was received and if the dialog at the 446 side of the Offerer has entered the early state 448 In order to clear this ambiguity as soon as possible, the Answerer 449 needs to retransmit the provisional response with the exponential 450 back-off timers described in [RFC3262]. These retransmissions MUST 451 cease on receipt of an INFO request or on transmission of the answer 452 in a 2xx response. This is similar to the procedure described in 453 section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN 454 binding Request is replaced by the INFO request. 456 [RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for 457 version 14 of said I-D. Please cross-check since it could have have 458 changed in the meantime.] 460 The Offerer MUST send a Trickle ICE INFO request as soon as it 461 receives an SDP Answer in an unreliable provisional response. This 462 INFO request MUST repeat the candidates that were already provided in 463 the Offer (as would be the case when Half Trickle is performed or 464 when new candidates have not been learned since then) and/or they MAY 465 also deliver newly learned candidates (if available). The Offerer 466 MAY include an end-of-candidates attribute in case candidate 467 discovery has ended in the mean time. 469 As soon as an Answerer has received such an INFO request, the 470 Answerer has an indication that a dialog is established at both ends 471 and MAY begin trickling (Figure 5). 473 Note: The +SRFLX in Figure 5 indicates that additionally newly 474 learned server-reflexive candidates are included. 476 Alice Bob 477 | | 478 | INVITE (Offer) | 479 |------------------------>| 480 | 183 (Answer) | 481 |<------------------------| 482 | INFO/OK (+SRFLX Cand.) | 483 |------------------------>| 484 | | 485 | +----------------------+ 486 | |Bob: Now I know Alice| 487 | | is ready. Send INFO! | 488 | +----------------------+ 489 | INFO/OK (+SRFLX Cand.) | 490 |<------------------------| 491 | | 492 | 200/ACK (Answer) | 493 |<------------------------| 495 Figure 5: A SIP UA that received an INFO request after sending an 496 unreliable provisional response knows that the dialog at the side of 497 the receiver has entered the early state 499 When sending the Answer in the 200 OK response to the INVITE request, 500 the Answerer MUST repeat exactly the same Answer that was previously 501 sent in the unreliable provisional response in order to fulfill the 502 corresponding requirements in [RFC3264]. Thus, the Offerer needs to 503 be prepared for receiving a different number of candidates in that 504 repeated Answer than previously exchanged via trickling and MUST 505 ignore the candidate information in that 200 OK response. 507 4.2.3. Initiating Trickle ICE without an SDP Answer 509 The possibility to convey arbitrary candidates in INFO message bodies 510 allows ICE Agents to initiate trickling without actually sending an 511 Answer. Trickle ICE Agents MAY therefore respond to an INVITE 512 request with provisional responses without an SDP Answer. Such 513 provisional responses serve for establishing an early dialog. 515 Agents that choose to establish the dialog in this way, MUST 516 retransmit these responses with the exponential back-off timers 517 described in [RFC3262]. These retransmissions MUST cease on receipt 518 of an INFO request or on transmission of the answer in a 2xx 519 response. This is again similar to the procedure described in 520 section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer 521 is not yet provided. 523 [RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for 524 version 14 of said I-D. Please cross-check since it could have have 525 changed in the meantime.] 527 Note: The +SRFLX in Figure 6 indicates that additionally newly 528 learned server-reflexive candidates are included. 530 Alice Bob 531 | | 532 | INVITE (Offer) | 533 |------------------------>| 534 | 183 (-) | 535 |<------------------------| 536 | INFO/OK (SRFLX Cand.) | 537 |------------------------>| 538 | | 539 | +----------------------+ 540 | |Bob: Now I know again| 541 | | that Alice is ready. | 542 | | Send INFO! | 543 | +----------------------+ 544 | INFO/OK (SRFLX Cand.) | 545 |<------------------------| 546 | 183 (Answer) opt. | 547 |<------------------------| 548 | INFO/OK (SRFLX Cand.) | 549 |<------------------------| 550 | 200/ACK (Answer) | 551 |<------------------------| 553 Figure 6: A SIP UA sends an unreliable provisional response without 554 an Answer for establishing an early dialog 556 When sending the Answer, the agent MUST repeat all currently known 557 and used candidates, if any, and MAY include all newly gathered 558 candidates since the last INFO request was sent. If that Answer was 559 sent in a unreliable provisional response, the Answerers MUST repeat 560 exactly the same Answer in the 200 OK response to the INVITE request 561 in order to fulfill the corresponding requirements in [RFC3264]. In 562 case that trickling continued, an Offerer needs to be prepared for 563 receiving fewer candidates in that repeated Answer than previously 564 exchanged via trickling and MUST ignore the candidate information in 565 that 200 OK response. 567 4.2.4. Considerations for 3PCC 569 Agents that have sent an Offer in a reliable provisional response and 570 that receive an Answer in a PRACK are also in a situation where 571 support for Trickle ICE is confirmed and the SIP dialog is guaranteed 572 to be in a state that would allow in-dialog INFO requests (see 573 Figure 7). 575 Alice Bob 576 | | 577 | INVITE | 578 |------------------------>| 579 | 183 (Offer) | 580 |<------------------------| 581 | PRACK (Answer) | 582 |------------------------>| 583 | | 584 | +----------------------+ 585 | |Bob: I know Alice can| 586 | |trickle and I know her| 587 | |dialog is in the early| 588 | |state. Send INFO! | 589 | +----------------------+ 590 | | 591 | INFO/OK (SRFLX Cand.) | 592 |<------------------------| 593 | | 594 | INFO/OK (SRFLX Cand.) | 595 |------------------------>| 596 | 200 OK/ACK | 597 |<------------------------| 599 Figure 7: A SIP Offerer in a 3PCC scenario can also freely start 600 trickling as soon as it receives an Answer. 602 Trickle Agents that send an Offer in a 200 OK and receive an Answer 603 in an ACK can still create a dialog and confirm support for Trickle 604 ICE by sending an unreliable provisional response similar to 605 Section 4.2.3. According to [RFC3261], this unreliable response MUST 606 NOT contain an Offer. 608 The Trickle Agent (at the UAS) retransmits the provisional response 609 with the exponential back-off timers described in [RFC3262]. 610 Retransmits MUST cease on receipt of an INFO request or on 611 transmission of the answer in a 2xx response. The peer Trickle Agent 612 (at the UAC) MUST send a Trickle ICE INFO request as soon as they 613 receive an unreliable provisional response (see Figure 8). 615 Alice Bob 616 | | 617 | INVITE | 618 |------------------------>| 619 | 183 (-) | 620 |<------------------------| 621 | INFO/OK (SRFLX Cand.) | 622 |------------------------>| 623 | | 624 | +-----------------------+ 625 | |Bob: I know Alice can | 626 | |trickle and I know her | 627 | |dialog is in the early | 628 | |state. | 629 | |INFO can be sent. | 630 | +-----------------------+ 631 | | 632 | INFO/OK (SRFLX Cand.) | 633 |<------------------------| 634 | | 635 | 200 (Offer) | 636 |<------------------------| 637 | ACK (Answer) | 638 |------------------------>| 639 | | 641 Figure 8: A SIP UAC in a 3PCC scenario can also freely start 642 trickling as soon as it receives an unreliable provisional response. 644 4.3. Delivering candidates in INFO messages 646 Whenever new ICE candidates become available for sending, agents 647 would encode them in "a=candidate" lines as described by 648 [I-D.ietf-mmusic-ice-sip-sdp]. For example: 650 a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx 651 raddr 10.0.1.1 rport 8998 653 The use of SIP INFO requests happens within the context of the Info 654 Package as defined Section 10. The Media Type [RFC6838] for their 655 payload MUST be set to 'application/trickle-ice-sdpfrag' as defined 656 in Section 9. 658 Since neither the "a=candidate" nor the "a=end-of-candidates" 659 attributes contain information that would allow correlating them to a 660 specific "m=" line, this is handled through the use of pseudo "m=" 661 lines and identification tags in "a=mid:" attributes as defined in 662 [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as 663 defined in [RFC4566], but provide no semantics other than indicating 664 to which "m=" line a candidate belongs. Consequently, the receiving 665 agent MUST ignore any remaining content of the pseudo "m=" line, 666 which is not defined in this document. This guarantees that the 667 'application/trickle-ice-sdpfrag' bodies do not interfere with the 668 Offer/Answer procedures as specified in [RFC3264]. 670 When sending the INFO request, the agent MAY, if already known to the 671 agent, include the same content into the pseudo "m=" line as for the 672 "m=" line in the corresponding Offer or Answer. However, since 673 Trickle-ICE might be decoupled from the Offer/Answer negotiation this 674 content might be unknown to the agent. In this case, the agent MUST 675 include the following default values. 677 o The media field is set to 'audio'. 679 o The port value is set to '9'. 681 o The proto value is set to 'RTP/AVP'. 683 o The fmt SHOULD appear only once and is set to '0' 685 Agents MUST include a pseudo "m=" line and an identification tag in a 686 "a=mid:" attribute for every "m=" line whose candidate list they 687 intend to update. Such "a=mid:" attributes MUST immediately precede 688 the list of candidates for that specific "m=" line. All 689 "a=candidate" or "a=end-of-candidates" attributes following an 690 "a=mid:" attribute, up until (and excluding) the next occurrence of a 691 pseudo "m=" line, pertain to the "m=" line identified by that 692 identification tag. An "a=end-of-candidates" attribute, preceding 693 any pseudo "m=" line, indicates the end of all trickling from that 694 agent, as opposed to end of trickling for a specific "m=" line, which 695 would be indicated by a media level "a=end-of-candidates" attribute. 697 Refer to Figure 9 for an example of the INFO request content. 699 The use of pseudo "m=" lines allows for a structure similar to the 700 one in SDP Offers and Answers where separate media-level and session- 701 level sections can be distinguished. In the current case, lines 702 preceding any pseudo "m=" line are considered to be session-level. 703 Lines appearing in between or after pseudo "m=" lines will be 704 interpreted as media-level. 706 Note that while this specification uses the "a=mid:" attribute 707 from [RFC5888], it does not define any grouping semantics. 709 Consequently, the "a=group:" attribute from that same 710 specification is neither needed nor used in Trickle ICE for SIP. 712 All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" 713 attributes that would allow mapping them to a specific ICE 714 generation. An agent MUST discard any received INFO requests 715 containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not 716 match those of the current ICE Negotiation Session. 718 The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the 719 same level as the ones in the Offer/Answer exchange. In other words, 720 if they were present as session-level attributes, they will also 721 appear at the beginning of all INFO request payloads, i.e. preceding 722 all pseudo "m=" lines. If they were originally exchanged as media 723 level attributes, potentially overriding session-level values, then 724 they will also be included in INFO request payloads following the 725 corresponding pseudo "m=" lines. 727 Note that [I-D.ietf-ice-trickle] requires that when candidates are 728 trickled, each candidate MUST be delivered to the receiving Trickle 729 ICE implementation not more than once and in the same order as it was 730 conveyed. If the signaling protocol provides any candidate 731 retransmissions, they need to be hidden from the ICE implementation. 732 This requirement is fulfilled as follows. 734 Since the agent is not fully aware of the state of the ICE 735 Negotiation Session at its peer it MUST include all currently known 736 and used local candidates in every INFO request. I.e. the agent MUST 737 repeat in the INFO request body all candidates that were previously 738 sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in 739 the same order as they were gathered. In other words, the sequence 740 of a previously sent list of candidates MUST NOT change in subsequent 741 INFO requests and newly gathered candidates MUST be added at the end 742 of that list. Although repeating all candidates creates some 743 overhead, it also allows easier handling of problems that could arise 744 from unreliable transports, like e.g. loss of messages and 745 reordering, which can be detected through the CSeq: header field in 746 the INFO request. 748 When receiving INFO requests carrying any candidates, agents will 749 therefore first identify and discard the attribute lines containing 750 candidates they have already received in previous INFO requests or in 751 the Offer/Answer exchange preceding them. Two candidates are 752 considered to be equal if their IP address port, transport and 753 component ID are the same. After identifying and discarding known 754 candidates, the agents MUST forward the actually new candidates to 755 the ICE Agents in the same order as they were received in the INFO 756 request body. The ICE Agents will then process the new candidates 757 according to the rules described in [I-D.ietf-ice-trickle]. 759 Receiving an "a=end-of-candidates" attribute in an INFO request body 760 - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the 761 current ICE generation - is an indication of the peer agent that it 762 will not send any further candidates. When included at session 763 level, i.e. before any pseudo "m=" line, this indication applies to 764 the whole session; when included at media level the indication 765 applies only to the corresponding "m=" line. Handling of such end- 766 of-candidate indications is defined in [I-D.ietf-ice-trickle]. 768 Note: At the time of writing this specification there were ongoing 769 discussions if a functionality for removing already exchanged 770 candidates would be useful. Such a functionality is out of the scope 771 of this specification and most likely needs to be signaled by means 772 of a yet to be defined ICE extension, although it could in principle 773 be achieved quite easily, e.g. without anticipating any solution by 774 simply omitting a previously sent candidate from a subsequent INFO 775 request. However, if an implementation according to this 776 specification receives such an INFO request with a missing candidate 777 it MAY treat that as an exceptional case. Implementing appropriate 778 recovery procedures at the receiving side is RECOMMENDED for this 779 situation. Ignoring that a candidate was missing might be a sensible 780 strategy. 782 The following example shows the content of one sample candidate 783 delivering INFO request: 785 INFO sip:alice@example.com SIP/2.0 786 ... 787 Info-Package: trickle-ice 788 Content-type: application/trickle-ice-sdpfrag 789 Content-Disposition: Info-Package 790 Content-length: ... 792 a=ice-pwd:asd88fgpdd777uzjYhagZg 793 a=ice-ufrag:8hhY 794 m=audio 9 RTP/AVP 0 795 a=mid:1 796 a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host 797 a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host 798 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx 799 raddr 2001:db8:a0b:12f0::1 rport 8998 800 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx 801 raddr 2001:db8:a0b:12f0::1 rport 8998 802 a=end-of-candidates 803 m=audio 9 RTP/AVP 0 804 a=mid:2 805 a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 6000 typ host 806 a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 6001 typ host 807 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 6000 typ srflx 808 raddr 2001:db8:a0b:12f0::1 rport 9998 809 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 6001 typ srflx 810 raddr 2001:db8:a0b:12f0::1 rport 9998 811 a=end-of-candidates 813 Figure 9: An Example for the Content of an INFO Request 815 5. Initial discovery of Trickle ICE support 817 SIP User Agents (UAs) that support and intend to use trickle ICE are 818 REQUIRED by [I-D.ietf-ice-trickle] to indicate that in their Offers 819 and Answers using the following attribute: "a=ice-options:trickle". 820 This makes discovery fairly straightforward for Answerers or for 821 cases where Offers need to be generated within existing dialogs 822 (i.e., when sending re-INVITE requests). In both scenarios prior SDP 823 would have provided the necessary information. 825 Obviously, prior SDP is not available at the time a first Offer is 826 being constructed and it is therefore impossible for ICE Agents to 827 determine support for incremental provisioning that way. The 828 following options are suggested as ways of addressing this issue. 830 5.1. Provisioning support for Trickle ICE 832 In certain situations it may be possible for integrators deploying 833 Trickle ICE to know in advance that some or all endpoints reachable 834 from within the deployment will support Trickle ICE. This is likely 835 to be the case, for example, for WebRTC clients that will always be 836 communicating with other WebRTC clients or known Session Border 837 Controllers (SBC) with support for this specification. 839 While the exact mechanism for allowing such provisioning is out of 840 scope here, this specification encourages trickle ICE implementations 841 to allow the option in the way they find most appropriate. 843 5.2. Trickle ICE discovery with GRUU 845 [RFC3840] provides a way for SIP User Agents to query for support of 846 specific capabilities using, among others, OPTIONS requests. GRUU 847 support on the other hand allows SIP requests to be addressed to 848 specific UAs (as opposed to arbitrary instances of an address of 849 record). Combining the two and using the "trickle-ice" option tag 850 defined in Section 10.6 provides SIP UAs with a way of learning the 851 capabilities of specific US instances and then addressing them 852 directly with INVITE requests that require SIP support. 854 Such targeted trickling may happen in different ways. One option 855 would be for a SIP UA to learn the GRUU instance ID of a peer through 856 presence and to then query its capabilities direction with an OPTIONS 857 request. Alternately, it can also just send an OPTIONS request to 858 the AOR it intends to contact and then inspect the returned 859 response(s) for support of both GRUU and Trickle ICE (Figure 10). 861 Alice Bob 862 | | 863 | OPTIONS sip:b1@example.com SIP/2.0 | 864 |-------------------------------------------------->| 865 | | 866 | 200 OK | 867 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 868 | ;audio;video|;trickle-ice;... | 869 |<--------------------------------------------------| 870 | | 871 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 872 |-------------------------------------------------->| 873 | | 874 | 183 (Answer) | 875 |<--------------------------------------------------| 876 | INFO/OK (Trickling) | 877 |<------------------------------------------------->| 878 | | 879 | ... | 880 | | 882 Figure 10: Trickle ICE support discovery with OPTIONS and GRUU 884 Confirming support for Trickle ICE through [RFC3840] gives SIP UAs 885 the options to engage in Full Trickle negotiation (as opposed to the 886 more lengthy Half Trickle) from the very first Offer they send. 888 5.3. Trickle ICE discovery through other protocols 890 Protocols like XMPP [RFC6120] define advanced discovery mechanisms 891 that allow specific features to be queried priory to actually 892 attempting to use them. Solutions like [RFC7081] define ways of 893 using SIP and XMPP together which also provides a way for dual stack 894 SIP+XMPP endpoints to make use of such features and verify Trickle 895 ICE support for a specific SIP endpoint through XMPP. However, such 896 discovery mechanisms are out of the scope of this document. 898 5.4. Fall-back to Half Trickle 900 In cases where none of the other mechanisms in this section are 901 acceptable, SIP UAs should use the Half Trickle mode defined in 902 [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions 903 the same way they would when using ICE for SIP 904 [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually 905 sending an Offer, agents would first gather ICE candidates in a 906 blocking way and then send them all in that Offer. The blocking 907 nature of the process would likely imply that some amount of latency 908 will be accumulated and it is advised that agents try to anticipate 909 it where possible, like for example, when user actions indicate a 910 high likelihood for an imminent call (e.g., activity on a keypad or a 911 phone going off-hook). 913 Using Half Trickle would result in Offers that are compatible with 914 both ICE SIP endpoints and legacy [RFC3264] endpoints. 916 STUN/Turn STUN/TURN 917 Servers Alice Bob Servers 918 | | | | 919 |<--------------| | | 920 | | | | 921 | | | | 922 | Candidate | | | 923 | | | | 924 | | | | 925 | Discovery | | | 926 | | | | 927 | | | | 928 |-------------->| INVITE (Offer) | | 929 | |---------------------------->| | 930 | | 183 (Answer) |-------------->| 931 | |<----------------------------| | 932 | | INFO (repeated candidates) | | 933 | |---------------------------->| | 934 | | | | 935 | | INFO (more candidates) | Candidate | 936 | |<----------------------------| | 937 | | Connectivity Checks | | 938 | |<===========================>| Discovery | 939 | | INFO (more candidates) | | 940 | |<----------------------------| | 941 | | Connectivity Checks |<--------------| 942 | |<===========================>| | 943 | | | | 944 | | 200 OK | | 945 | |<----------------------------| | 946 | | | | 947 | |<======= MEDIA FLOWS =======>| | 948 | | | | 950 Figure 11: Example - A typical (Half) Trickle ICE exchange with SIP 952 It is worth reminding that once a single Offer or Answer had been 953 exchanged within a specific dialog, support for Trickle ICE will have 954 been determined. No further use of Half Trickle will therefore be 955 necessary within that same dialog and all subsequent exchanges can 956 use the Full Trickle mode of operation. 958 6. Considerations for RTP and RTCP multiplexing 960 The following consideration describe options for Trickle-ICE in order 961 to give some guidance to implementors on how trickling can be 962 optimized with respect to providing RTCP candidates. 964 Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" 965 attribute for RTP/RTCP multiplexing [RFC5761] is already considered 966 in section 4.2. of [I-D.ietf-mmusic-ice-sip-sdp], respectively, as 967 well in [RFC5761] itself. These considerations are still valid for 968 Trickle ICE, however, trickling provides more flexibility for the 969 sequence of candidate exchange in case of RTCP multiplexing. 971 If the Offerer supports RTP/RTCP multiplexing exclusively as 972 specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that 973 document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" 974 and the "a=rtcp-mux" attributes. 976 While a Half Trickle Offerer would have to send an offer compliant to 977 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for 978 all components, this flexibility allows a Full Trickle Offerer to 979 initially send only RTP candidates (component 1) if it assumes that 980 RTCP multiplexing is supported by the Answerer. A Full Trickle 981 Offerer would need to start gathering and trickling RTCP candidates 982 (component 2) only after having received an indication in the answer 983 that the Answerer unexpectedly does not support RTCP multiplexing. 985 A Trickle Answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in 986 the application/trickle-ice-sdpfrag body if it supports and uses RTP 987 and RTCP multiplexing. The Trickle Answerer MUST follow the guidance 988 on the usage of the "a=rtcp" attribute as given in 989 [I-D.ietf-mmusic-ice-sip-sdp] and Receipt of this attribute at the 990 Offerer in an INFO request prior to the Answer indicates that the 991 Answerer supports and uses RTP and RTCP multiplexing. The Offerer 992 can use this information e.g. for stopping gathering of RTCP 993 candidates and/or for freeing corresponding resources. 995 This behavior is illustrated by the following example offer that 996 indicates support for RTP and RTCP multiplexing. 998 v=0 999 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1000 s= 1001 c=IN IP4 atlanta.example.com 1002 t=0 0 1003 a=ice-pwd:777uzjYhagZgasd88fgpdd 1004 a=ice-ufrag:Yhh8 1005 m=audio 10000 RTP/AVP 0 1006 a=mid:1 1007 a=rtcp-mux 1008 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 1010 Once the dialog is established as described in section Section 4.2 1011 the Answerer sends the following INFO request. 1013 INFO sip:alice@example.com SIP/2.0 1014 ... 1015 Info-Package: trickle-ice 1016 Content-type: application/sdp 1017 Content-Disposition: Info-Package 1018 Content-length: ... 1020 a=ice-pwd:asd88fgpdd777uzjYhagZg 1021 a=ice-ufrag:8hhY 1022 m=audio 9 RTP/AVP 0 1023 a=mid:1 1024 a=rtcp-mux 1025 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 1027 This INFO request indicates that the Answerer supports and uses RTP 1028 and RTCP multiplexing as well. It allows the Offerer to omit 1029 gathering of RTCP candidates or releasing already gathered RTCP 1030 candidates. If the INFO request did not contain the a=rtcp-mux 1031 attribute, the Offerer would have to gather RTCP candidates unless it 1032 wants to wait until receipt of an Answer that eventually confirms 1033 support or non-support for RTP and RTCP multiplexing. 1035 7. Considerations for Media Multiplexing 1037 The following considerations describe options for Trickle-ICE in 1038 order to give some guidance to implementors on how trickling can be 1039 optimized with respect to providing candidates in case of Media 1040 Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed 1041 that the reader is familiar with 1042 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 1044 ICE candidate exchange is already considered in section 11 of 1045 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are 1046 still valid for Trickle ICE, however, trickling provides more 1047 flexibility for the sequence of candidate exchange, especially in 1048 Full Trickle mode. 1050 Except for bundle-only "m=" lines, a Half Trickle Offerer would have 1051 to send an offer with candidates for all bundled "m=" lines. The 1052 additional flexibility, however, allows a Full Trickle Offerer to 1053 initially send only candidates for the "m=" line with the suggested 1054 Offerer BUNDLE address. 1056 Latest on receipt of the answer, the Offerer will detect if BUNDLE is 1057 supported by the Answerer and if the suggested Offerer BUNDLE address 1058 was selected. In this case, the Offerer does not need to trickle 1059 further candidates for the remaining "m=" lines in a bundle. 1060 However, if BUNDLE is not supported, the Full Trickle Offerer needs 1061 to gather and trickle candidates for the remaining "m=" lines as 1062 necessary. If the Answerer selects an Offerer BUNDLE address 1063 different from the suggested Offerer BUNDLE address, the Full Trickle 1064 Offerer needs to gather and trickle candidates for the "m=" line that 1065 carries the selected Offerer BUNDLE address. 1067 A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute 1068 [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle- 1069 ice-sdpfrag body if it supports and uses bundling. When doing so, 1070 the Answerer MUST include all identification-tags in the same order 1071 that is used or will be used in the Answer. 1073 Receipt of this attribute at the Offerer in an INFO request prior to 1074 the Answer indicates that the Answerer supports and uses bundling. 1075 The Offerer can use this information e.g. for stopping the gathering 1076 of candidates for the remaining "m=" lines in a bundle and/or for 1077 freeing corresponding resources. 1079 This behaviour is illustrated by the following example offer that 1080 indicates support for Media Multiplexing. 1082 v=0 1083 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1084 s= 1085 c=IN IP4 atlanta.example.com 1086 t=0 0 1087 a=group:BUNDLE foo bar 1088 a=ice-pwd:777uzjYhagZgasd88fgpdd 1089 a=ice-ufrag:Yhh8 1090 m=audio 10000 RTP/AVP 0 1091 a=mid:foo 1092 a=rtpmap:0 PCMU/8000 1093 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1094 m=video 10002 RTP/AVP 31 1095 a=mid:bar 1096 a=rtpmap:31 H261/90000 1097 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1099 Once the dialog is established as described in section Section 4.2 1100 the Answerer sends the following INFO request. 1102 INFO sip:alice@example.com SIP/2.0 1103 ... 1104 Info-Package: trickle-ice 1105 Content-type: application/sdp 1106 Content-Disposition: Info-Package 1107 Content-length: ... 1109 a=group:BUNDLE foo bar 1110 a=ice-pwd:asd88fgpdd777uzjYhagZg 1111 a=ice-ufrag:8hhY 1112 m=audio 9 RTP/AVP 0 1113 a=mid:foo 1114 a=rtcp-mux 1115 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 1116 m=audio 9 RTP/AVP 0 1117 a=mid:bar 1119 This INFO request indicates that the Answerer supports and uses Media 1120 Multiplexing as well. Note, that the second "m=" line shows the 1121 default values as specified in section Section 4.3, e.g. media set 1122 'audio' although 'video' was offered. The receiving ICE Agents MUST 1123 ignore these default values in the pseudo "m=" lines. 1125 The INFO request also indicates that the Answerer accepted the 1126 suggested Offerer Bundle Address. This allows the Offerer to omit 1127 gathering of RTP and RTCP candidates for the other "m=" lines or 1128 releasing already gathered candidates. If the INFO request did not 1129 contain the a=group:BUNDLE attribute, the Offerer would have to 1130 gather RTP and RTCP candidates for the other "m=" lines unless it 1131 wants to wait until receipt of an Answer that eventually confirms 1132 support or non-support for Media Multiplexing. 1134 Independent of using Full Trickle or Half Trickle mode, the rules 1135 from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and 1136 Answerer, when putting attributes as specified in Section 9.2 in the 1137 application/trickle-ice-sdpfrag body. 1139 8. SDP 'end-of-candidate' Attribute 1141 8.1. Defintion 1143 This section defines a new SDP media-level and session-level 1144 attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' is a 1145 property attribute [RFC4566], and hence has no value. By including 1146 this attribute in an Offer or Answer the sending agent indicates that 1147 it will not trickle further candidates. When included at session 1148 level this indication applies to the whole session, when included at 1149 media level the indication applies only to the corresponding media 1150 desciption. 1152 Name: end-of-candidate 1154 Value: N/A 1156 Usage Level: media and session-level 1158 Charset Dependent: no 1160 Mux Category: IDENTICAL 1162 Example: a=end-of-candidate 1164 8.2. Offer/Answer procedures 1166 The Offerer or Answerer MAY include an "a=end-of-candidates" 1167 attribute in case candidate discovery has ended and no further 1168 candidates are to be trickled. The Offerer or Answerer MUST provide 1169 the "a=end-of-candidates" attribute together with the "a=ice-ufrag" 1170 and "a=ice-pwd" attributes of the current ICE generation as required 1171 by [I-D.ietf-ice-trickle]. When included at session level this 1172 indication applies to the whole session; when included at media level 1173 the indication applies only to the corresponding media description. 1175 Receipt of an "a=end-of-candidates" attribute at an Offerer or 1176 Anwerer - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching 1177 the current ICE generation - indicates that gathering of candidates 1178 has ended at the peer, either for the session or only for the 1179 corresponding media description as specified above. The receiving 1180 agent forwards an end-of-candidates indication to the ICE Agent, 1181 which in turn acts as specified in [I-D.ietf-ice-trickle]. 1183 9. Content Type 'application/trickle-ice-sdpfrag' 1185 9.1. Overall Description 1187 A application/trickle-ice-sdpfrag body is used by the 'trickle-ice' 1188 Info Package. It uses a subset of the possible SDP lines as defined 1189 by the grammar defined in [RFC4566]. A valid body uses only pseudo 1190 "m=" lines and certain attributes that are needed and/or useful for 1191 trickling candidates. The content adheres to the following grammar. 1193 9.2. Grammar 1195 The grammar of an 'application/trickle-ice-sdpfrag' body is based on 1196 the following ABNF [RFC5234]. It specifies the subset of existing 1197 SDP attributes, that are needed or useful for trickling candidates. 1198 The grammar uses the indicator for case-sensitivity %s is defined in 1199 [RFC7405], but also imports grammars for other SDP attributes that 1200 precede the production of that RFC. A sender SHOULD stick to lower- 1201 case for such grammars, but a receiver SHOULD treat them case- 1202 insensitive. 1204 ; Syntax 1205 trickle-ice-sdpfrag = session-level-fields 1206 pseudo-media-descriptions 1207 session-level-fields = [bundle-group-attribute CRLF] 1208 [ice-lite-attribute CRLF] 1209 ice-pwd-attribute CRLF 1210 ice-ufrag-attribute CRLF 1211 [ice-options-attribute CRLF] 1212 [ice-pacing-attribute CRLF] 1213 [end-of-candidates-attribute CRLF] 1214 extension-attribute-fields 1215 ; for future extensions 1217 ice-lite-attribute = %s"a" "=" ice-lite 1218 ice-pwd-attribute = %s"a" "=" ice-pwd-att 1219 ice-ufrag-attribute = %s"a" "=" ice-ufrag-att 1220 ice-pacing-attribute = %s"a" "=" ice-pacing-att 1221 ice-options-attribute = %s"a" "=" ice-options 1222 bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics 1223 *(SP identification-tag) 1224 bundle-semantics = "BUNDLE" 1225 end-of-candidates-attribute = %s"a" "=" end-of-candidates 1226 end-of-candidates = %s"end-of-candidates" 1227 extension-attribute-fields = attribute-fields 1229 pseudo-media-descriptions = *( media-field 1230 trickle-ice-attribute-fields 1231 [extension-attribute-fields] ) 1232 ; for future extensions 1233 trickle-ice-attribute-fields = %s"a" "=" mid-attribute CRLF 1234 [%s"a" "=" %s"rtcp" CRLF] 1235 [%s"a" "=" %s"rtcp-mux" CRLF] 1236 [%s"a" "=" %s"rtcp-mux-only" CRLF] 1237 *(candidate-attributes CRLF) 1238 [ice-pwd-attribute CRLF] 1239 [ice-ufrag-attribute CRLF] 1240 [remote-candidate-attribute CRLF] 1241 [end-of-candidates-attribute CRLF] 1242 remote-candidate-attribute = %s"a" "=" remote-candidate-att 1243 candidate-attributes = %s"a" "=" candidate-attribute 1245 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- 1246 pacing-att, ice-options, candidate-attribute remote-candidate-att 1247 from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute 1248 ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The 1249 "a=rtcp" attribute is defined in [RFC3605], the "a=rtcp-mux" 1250 attribute in [RFC5761] and the "a=rtcp-mux-only" attribute in 1252 [I-D.ietf-mmusic-mux-exclusive]. The latter attributes lack a formal 1253 grammar in their corresponding RFC and are reproduced here. 1255 An Agent MUST ignore any received unknown extension-attribute-fields. 1257 10. Info Package 1259 10.1. Rationale - Why INFO? 1261 The decision to use SIP INFO requests as a candidate transport method 1262 is based primarily on their lightweight nature. Once a dialog has 1263 been established, INFO messages can be exchanged both ways with no 1264 restrictions on timing and frequency and no risk of collision. 1266 On the other hand, using Offer/Answer and UPDATE requests [RFC3311] 1267 introduces the following complications: 1269 Blocking of messages: [RFC3264] defines Offer/Answer as a strictly 1270 sequential mechanism. There can only be a maximum of one exchange 1271 at any point of time. Both sides cannot simultaneously send 1272 Offers nor can they generate multiple Offers prior to receiving an 1273 Answer. Using UPDATE requests for candidate transport would 1274 therefore imply the implementation of a candidate pool at every 1275 agent where candidates can be stored until it is once again that 1276 agent's "turn" to emit an Answer or a new Offer. Such an approach 1277 would introduce non-negligible complexity for no additional value. 1279 Elevated risk of glare: The sequential nature of Offer/Answer also 1280 makes it impossible for both sides to send Offers simultaneously. 1281 What's worse is that there are no mechanisms in SIP to actually 1282 prevent that. [RFC3261], where the situation of Offers crossing 1283 on the wire is described as "glare", only defines a procedure for 1284 addressing the issue after it has occurred. According to that 1285 procedure both Offers are invalidated and both sides need to retry 1286 the negotiation after a period between 0 and 4 seconds. The high 1287 likelihood for glare to occur and the average two second back-off 1288 intervals would imply Trickle ICE processing duration would not 1289 only fail to improve but actually exceed those of regular ICE. 1291 INFO messages decouple the exchange of candidates from the Offer/ 1292 Answer negotiation and are subject to none of the glare issues 1293 described above, which makes them a very convenient and lightweight 1294 mechanism for asynchronous delivery of candidates. 1296 Using in-dialog INFO messages also provides a way of guaranteeing 1297 that candidates are delivered end-to-end, between the same entities 1298 that are actually in the process of initiating a session. Out-of- 1299 dialog alternatives would have implied requiring support for Globally 1300 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 1301 adoption levels, would have constituted too strong of a constraint to 1302 the adoption of Trickle ICE. 1304 10.2. Overall Description 1306 This specification defines an Info Package for use by SIP User Agents 1307 implementing Trickle ICE. INFO requests carry ICE candidates 1308 discovered after the peer user agents have confirmed mutual support 1309 for Trickle ICE. 1311 10.3. Applicability 1313 The purpose of the ICE protocol is to establish a media path in the 1314 presence of NAT and firewalls. The candidates are transported in 1315 INFO requests and are part of this establishment. 1317 Candidates sent by a Trickle ICE Agent after the Offer, follow the 1318 same signaling path and reach the same entity as the Offer itself. 1319 While it is true that GRUUs can be used to achieve this, one of the 1320 goals of this specification is to allow operation of Trickle ICE in 1321 as many environments as possible including those without GRUU 1322 support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not 1323 satisfy this goal. 1325 10.4. Info Package Name 1327 This document defines a SIP Info Package as per [RFC6086]. The Info 1328 Package token name for this package is "trickle-ice" 1330 10.5. Info Package Parameters 1332 This document does not define any Info Package parameters. 1334 10.6. SIP Option Tags 1336 [RFC6086] allows Info Package specifications to define SIP option- 1337 tags. This specification extends the option-tag construct of the SIP 1338 grammar as follows: 1340 option-tag /= "trickle-ice" 1342 SIP entities that support this specification MUST place the 'trickle- 1343 ice' option-tag in a SIP Supported: header field within all SIP 1344 INVITE requests and responses. 1346 When responding to, or generating a SIP OPTIONS request a SIP entity 1347 MUST also include the 'trickle-ice' option-tag in a SIP Supported: 1348 header field. 1350 10.7. Info Message Body Parts 1352 Entities implementing this specification MUST include a payload of 1353 type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 all 1354 SIP INFO requests. The payload is used to convey SDP encoded ICE 1355 candidates. 1357 10.8. Info Package Usage Restrictions 1359 This document does not define any Info Package Usage Restrictions. 1361 10.9. Rate of INFO Requests 1363 A Trickle ICE Agent with many network interfaces might create a high 1364 rate of INFO requests if every newly detected candidate is trickled 1365 individually without aggregation. Implementors that are concerned 1366 about loss of packets in such a case might consider aggregating ICE 1367 candidates and sending INFOs only at some configurable intervals. 1369 10.10. Info Package Security Considerations 1371 See Section 12 1373 11. IANA Considerations 1375 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1376 document. ] 1378 11.1. SDP 'end-of-candidate' Attribute 1380 This section defines a new SDP media-level and session-level 1381 attribute [RFC4566] , 'end-of-candidate'. 'end-of-candidate' is a 1382 property attribute [RFC4566] , and hence has no value. 1384 Name: end-of-candidate 1386 Value: N/A 1388 Usage Level: media and session 1390 Charset Dependent: no 1392 Purpose: The sender indicates that it will not trickle 1393 further candidates. 1395 O/A Procedures: RFCXXX defines the detailed 1396 SDP Offer/Answer procedures for 1397 the 'end-of-candidate' attribute. 1399 Mux Category: IDENTICAL 1401 Reference: RFCXXXX 1403 Example: 1405 a=end-of-candidate 1407 11.2. application/trickle-ice-sdpfrag Media Type 1409 Type name: application 1411 Subtype name: trickle-ice-sdpfrag 1413 Required parameters: None. 1415 Optional parameters: None. 1417 Encoding considerations: 1419 SDP files are primarily UTF-8 format text. Although the 1420 initially defined content of a trickle-ice-sdpfrag body does 1421 only include ASCII characters, UTF-8 encoded content might be 1422 introduced via extension attributes. The "a=charset:" 1423 attribute may be used to signal the presence of other character 1424 sets in certain parts of a trickle-ice-sdpfrag body (see 1425 [RFC4566]). Arbitrary binary content cannot be directly 1426 represented in SDP or a trickle-ice-sdpfrag body. 1428 Security considerations: 1430 See [RFC4566]) and RFCXXXX 1432 Interoperability considerations: 1434 See RFCXXXX 1436 Published specification: 1438 See RFCXXXX 1440 Applications which use this Media Type: 1442 Voice over IP, video teleconferencing, streaming media, instant 1443 messaging, Trickle-ICE among others. 1445 Fragment identifier considerations: N/A 1447 Additional information: 1449 Magic number(s): N/A 1451 File extension(s): N/A 1453 Macintosh File Type Code(s): N/A 1455 Person and email address to contact for further information: 1457 IETF MMUSIC working group mmusic@ietf.org 1459 Intended usage: 1461 Trickle-ICE for SIP as specified in RFCXXXX. 1463 Restrictions on usage: N/A 1465 Author/Change controller: 1467 IETF MMUSIC working group mmusic@ietf.org 1469 Provisional registration? (standards tree only): N/A 1471 11.3. SIP Info Package 'trickle-ice' 1473 This document defines a new SIP Info Package named 'trickle-ice' and 1474 updates the Info Packages Registry with the following entry. 1476 +-------------+-----------+ 1477 | Name | Reference | 1478 +-------------+-----------+ 1479 | trickle-ice | [RFCXXXX] | 1480 | | | 1481 +-------------+-----------+ 1483 11.4. SIP Option Tag 'trickle-ice' 1485 This specification registers a new SIP option tag 'trickle-ice' as 1486 per the guidelines in Section 27.1 of [RFC3261] and updates the 1487 "Option Tags" section of the SIP Parameter Registry with the 1488 following entry: 1490 +-------------+-------------------------------------+-----------+ 1491 | Name | Description | Reference | 1492 +-------------+-------------------------------------+-----------+ 1493 | trickle-ice | This option tag is used to indicate | [RFCXXXX] | 1494 | | that a UA supports and understands | | 1495 | | Trickle-ICE. | | 1496 +-------------+-------------------------------------+-----------+ 1498 12. Security Considerations 1500 The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], 1501 [RFC6086] and [I-D.ietf-ice-trickle] apply. This document clarifies 1502 how the above specifications are used together for trickling 1503 candidates and does not create addtitional security risks. 1505 13. Acknowledgements 1507 The authors would like to thank Flemming Andreasen, Ayush Jain, Paul 1508 Kyzivat, Jonathan Lennox, Simon Perreault and Martin Thomson for 1509 reviewing and/or making various suggestions for improvements and 1510 optimizations. 1512 14. Change Log 1514 [RFC EDITOR NOTE: Please remove this section when publishing]. 1516 Changes from draft-ietf-mmusic-trickle-ice-sip-01 1518 o Editorial Clean up 1520 o IANA Consideration added 1522 o Security Consideration added 1524 o RTCP and BUNDLE Consideration added with rules for including 1525 "a=rtcp-mux" and "a=group: BUNDLLE" attributes 1527 o 3PCC Consideration added 1529 o Clarified that 18x w/o answer is sufficient to create a dialog 1530 that allows for trickling to start 1532 o Added remaining Info Package definition sections as outlined in 1533 section 10 of [RFC6086] 1535 o Added definition of application/sdpfrag making draft-ivov-mmusic- 1536 sdpfrag obsolete 1538 o Added pseudo m-lines as additional separator in sdpfrag bodies for 1539 Trickle ICE 1541 o Added ABNF for sdp-frag bodies and Trickle-ICE package 1543 Changes from draft-ietf-mmusic-trickle-ice-sip-02 1545 o Removed definition of application/sdpfrag 1547 o Replaced with new type application/trickle-ice-sdpfrag 1549 o RTCP and BUNDLE Consideration enhanced with some examples 1551 o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to 1552 normative reference 1554 o Removed reference to 4566bis 1556 o Addressed review comment from Simon Perreault 1558 Changes from draft-ietf-mmusic-trickle-ice-sip-03 1559 o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis 1560 and draft-ietf-mmusic-ice-sip-sdp 1562 o Corrected Figure 10, credits to Ayush Jain for finding the bug 1564 o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- 1565 ice-sip-sdp 1567 o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- 1568 mux-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive 1570 o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for 1571 the application/trickle-ice-sdpfrag body 1573 Changes from draft-ietf-mmusic-trickle-ice-sip-04 1575 o considered comments from Christer Holmberg 1577 o corrected grammar for INFO package, such that ice-ufrag/pwd are 1578 also allowed on media-level as specified in 1579 [I-D.ietf-mmusic-ice-sip-sdp] 1581 o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] 1583 o Added formal definition for the end-of-candidates attribute 1585 Changes from draft-ietf-mmusic-trickle-ice-sip-05 1587 o considered further comments from Christer Holmberg 1589 o editorial comments on section 3 addressed 1591 o moved section 3.1 to section 10.1 and applied some edits 1593 o replaced the term "previously sent candidates" with "currently 1594 known and used candidates". 1596 Changes from draft-ietf-mmusic-trickle-ice-sip-06 1598 o editorial fixes 1600 o additional text on the content of the INFO messages. 1602 o recommendation on what to do if a previously sent candidate is 1603 unexpectedly missing in a subsequent INFO 1605 o terminology alignment with draft-ietf-ice-trickle-07 1606 Changes from draft-ietf-mmusic-trickle-ice-sip-07 1608 o editorial fixes 1610 o clarification on ordering of candidates for alignment with draft- 1611 ietf-ice-trickle-12 1613 o O/A procedures for end-of-candidates attribute described here 1614 after corresponding procedures have been removed from draft-ietf- 1615 ice-trickle-11 1617 o using IPv6 addresses in examples 1619 Changes from draft-ietf-mmusic-trickle-ice-sip-08 1621 o editorial fixes/clarification based on Flemmings review 1623 o Description of Trickle specifics in O/A procedures for initial O/A 1624 exchange and specification of ICE mismatch exception 1626 15. References 1628 15.1. Normative References 1630 [I-D.ietf-ice-trickle] 1631 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 1632 "Trickle ICE: Incremental Provisioning of Candidates for 1633 the Interactive Connectivity Establishment (ICE) 1634 Protocol", draft-ietf-ice-trickle-14 (work in progress), 1635 September 2017. 1637 [I-D.ietf-mmusic-ice-sip-sdp] 1638 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 1639 "Session Description Protocol (SDP) Offer/Answer 1640 procedures for Interactive Connectivity Establishment 1641 (ICE)", draft-ietf-mmusic-ice-sip-sdp-14 (work in 1642 progress), October 2017. 1644 [I-D.ietf-mmusic-mux-exclusive] 1645 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 1646 Multiplexing using SDP", draft-ietf-mmusic-mux- 1647 exclusive-12 (work in progress), May 2017. 1649 [I-D.ietf-mmusic-rfc5245bis] 1650 Keranen, A. and J. Rosenberg, "Interactive Connectivity 1651 Establishment (ICE): A Protocol for Network Address 1652 Translator (NAT) Traversal", draft-ietf-mmusic- 1653 rfc5245bis-05 (work in progress), September 2015. 1655 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1656 Holmberg, C., Alvestrand, H., and C. Jennings, 1657 "Negotiating Media Multiplexing Using the Session 1658 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1659 negotiation-39 (work in progress), August 2017. 1661 [I-D.ietf-mmusic-sdp-mux-attributes] 1662 Nandakumar, S., "A Framework for SDP Attributes when 1663 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1664 (work in progress), December 2016. 1666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1667 Requirement Levels", BCP 14, RFC 2119, 1668 DOI 10.17487/RFC2119, March 1997, 1669 . 1671 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1672 A., Peterson, J., Sparks, R., Handley, M., and E. 1673 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1674 DOI 10.17487/RFC3261, June 2002, 1675 . 1677 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1678 Provisional Responses in Session Initiation Protocol 1679 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1680 . 1682 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1683 with Session Description Protocol (SDP)", RFC 3264, 1684 DOI 10.17487/RFC3264, June 2002, 1685 . 1687 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1688 in Session Description Protocol (SDP)", RFC 3605, 1689 DOI 10.17487/RFC3605, October 2003, 1690 . 1692 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1693 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1694 July 2006, . 1696 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1697 Specifications: ABNF", STD 68, RFC 5234, 1698 DOI 10.17487/RFC5234, January 2008, 1699 . 1701 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1702 Control Packets on a Single Port", RFC 5761, 1703 DOI 10.17487/RFC5761, April 2010, 1704 . 1706 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1707 Protocol (SDP) Grouping Framework", RFC 5888, 1708 DOI 10.17487/RFC5888, June 2010, 1709 . 1711 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1712 Initiation Protocol (SIP) INFO Method and Package 1713 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1714 . 1716 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1717 Specifications and Registration Procedures", BCP 13, 1718 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1719 . 1721 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1722 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1723 . 1725 15.2. Informative References 1727 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1728 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1729 2002, . 1731 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1732 "Indicating User Agent Capabilities in the Session 1733 Initiation Protocol (SIP)", RFC 3840, 1734 DOI 10.17487/RFC3840, August 2004, 1735 . 1737 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1738 Agent URIs (GRUUs) in the Session Initiation Protocol 1739 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 1740 . 1742 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1743 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1744 March 2011, . 1746 [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: 1747 Combined Use of the Session Initiation Protocol (SIP) and 1748 the Extensible Messaging and Presence Protocol (XMPP)", 1749 RFC 7081, DOI 10.17487/RFC7081, November 2013, 1750 . 1752 Authors' Addresses 1754 Emil Ivov 1755 Jitsi 1756 Strasbourg 67000 1757 France 1759 Phone: +33 6 72 81 15 55 1760 Email: emcho@jitsi.org 1762 Thomas Stach 1763 Unaffiliated 1764 Vienna 1130 1765 Austria 1767 Email: thomass.stach@gmail.com 1769 Enrico Marocco 1770 Telecom Italia 1771 Via G. Reiss Romoli, 274 1772 Turin 10148 1773 Italy 1775 Email: enrico.marocco@telecomitalia.it 1777 Christer Holmberg 1778 Ericsson 1779 Hirsalantie 11 1780 Jorvas 02420 1781 Finland 1783 Email: christer.holmberg@ericsson.com