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