idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-10.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC6086]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2017) is 2385 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 1510, 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: 3 errors (**), 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: April 18, 2018 Unaffiliated 6 E. Marocco 7 Telecom Italia 8 C. Holmberg 9 Ericsson 10 October 15, 2017 12 A Session Initiation Protocol (SIP) usage for Trickle ICE 13 draft-ietf-mmusic-trickle-ice-sip-10 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 18, 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 . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . 25 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 this case, the Offerer obviously cannot know the RTCP transport 345 address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. 346 This avoids potential ICE mismatch (see 347 [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. 349 If the Offerer wants to use RTCP multiplexing [RFC5761] and/or 350 exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still 351 MUST include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in 352 the initial Offer. 354 In any case, the Offerer MUST include the attribute a=ice- 355 options:trickle in accordance to [I-D.ietf-ice-trickle]. 357 4.1.2. Receiving the initial Offer 359 If the initial Offer included candidates, the Answerer MUST treat 360 these candidates as specified in [I-D.ietf-mmusic-ice-sip-sdp]. 362 If the initial Offer included the attribute a=ice-options:trickle, 363 the Answerer MUST be prepared for receiving trickled candidates later 364 on. 366 In case of a "m=" lines with default values neither of the eventually 367 trickled candidates will match the default destination. This 368 situation MUST NOT cause an ICE mismatch (see 369 [I-D.ietf-mmusic-ice-sip-sdp]). 371 4.1.3. Sending the initial Answer 373 Section Section 4.1.1 applies to the Answerer with the roles of 374 Offerer and Answer being swapped. 376 4.1.4. Receiving the initial Answer 378 Section Section 4.1.2 applies to the Answerer with the roles of 379 Offerer and Answer being swapped. 381 4.2. Establishing the dialog 383 In order to be able to start trickling, the following two conditions 384 need to be satisfied at the SIP UAs: 386 o Trickle ICE support at the peer agent MUST be confirmed. 388 o The dialog at both peers MUST be in early or confirmed state. 390 Section 5 discusses in detail the various options for satisfying the 391 first of the above conditions. Regardless of those mechanisms, 392 however, agents are certain to have a clear understanding of whether 393 their peers support trickle ICE once an Offer and an Answer have been 394 exchanged, which also allows for ICE processing to commence (see 395 Figure 3). 397 4.2.1. Asserting dialog state through reliable Offer/Answer delivery 399 Alice Bob 400 | | 401 | INVITE (Offer) | 402 |------------------------>| 403 | 183 (Answer) | 404 |<------------------------| 405 | PRACK/OK | 406 |------------------------>| 407 | | 408 +----------------------------------------+ 409 |Alice and Bob know that both can trickle| 410 |and know that the dialog is in the early| 411 |state. Send INFO! | 412 +----------------------------------------+ 413 | | 414 | INFO/OK (+SRFLX Cand.) | 415 |------------------------>| 416 | INFO/OK (+SRFLX Cand.) | 417 |<------------------------| 418 | | 420 Figure 3: SIP Offerer can freely trickle as soon as it receives an 421 Answer. 423 As shown in Figure 3 satisfying both conditions is relatively trivial 424 for ICE Agents that have sent an Offer in an INVITE and that have 425 received an Answer in a reliable provisional response. It is 426 guaranteed to have confirmed support for Trickle ICE at the Answerer 427 (or lack thereof) and to have fully initialized the SIP dialog at 428 both ends. Offerers and Answerers (after receipt of the PRACK 429 request) in the above situation can therefore freely commence 430 trickling within the newly established dialog. 432 4.2.2. Asserting dialog state through unreliable Offer/Answer delivery 434 The situation is a bit more delicate for agents that have received an 435 Offer in an INVITE request and have sent an Answer in an unreliable 436 provisional response because, once the response has been sent, the 437 Answerer does not know when or if it has been received (Figure 4). 439 Alice Bob 440 | | 441 | INVITE (Offer) | 442 |------------------------>| 443 | 183 (Answer) | 444 |<------------------------| 445 | | 446 | +----------------------+ 447 | |Bob: I don't know if | 448 | |Alice got my 183 or if| 449 | |her dialog is already | 450 | |in the early state. | 451 | | Can I send INFO??? | 452 | +----------------------+ 453 | | 455 Figure 4: A SIP UA that sent an Answer in an unreliable provisional 456 response does not know if it was received and if the dialog at the 457 side of the Offerer has entered the early state 459 In order to clear this ambiguity as soon as possible, the Answerer 460 needs to retransmit the provisional response with the exponential 461 back-off timers described in [RFC3262]. These retransmissions MUST 462 cease on receipt of an INFO request or on transmission of the Answer 463 in a 2xx response. This is similar to the procedure described in 464 section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN 465 binding Request is replaced by the INFO request. 467 [RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for 468 version 14 of said I-D. Please cross-check since it could have have 469 changed in the meantime.] 471 The Offerer MUST send a Trickle ICE INFO request as soon as it 472 receives an SDP Answer in an unreliable provisional response. This 473 INFO request MUST repeat the candidates that were already provided in 474 the Offer (as would be the case when Half Trickle is performed or 475 when new candidates have not been learned since then) and/or they MAY 476 also deliver newly learned candidates (if available). The Offerer 477 MAY include an end-of-candidates attribute in case candidate 478 discovery has ended in the mean time. 480 As soon as an Answerer has received such an INFO request, the 481 Answerer has an indication that a dialog is established at both ends 482 and MAY begin trickling (Figure 5). 484 Note: The +SRFLX in Figure 5 indicates that additionally newly 485 learned server-reflexive candidates are included. 487 Alice Bob 488 | | 489 | INVITE (Offer) | 490 |------------------------>| 491 | 183 (Answer) | 492 |<------------------------| 493 | INFO/OK (+SRFLX Cand.) | 494 |------------------------>| 495 | | 496 | +----------------------+ 497 | |Bob: Now I know Alice| 498 | | is ready. Send INFO! | 499 | +----------------------+ 500 | INFO/OK (+SRFLX Cand.) | 501 |<------------------------| 502 | | 503 | 200/ACK (Answer) | 504 |<------------------------| 506 Figure 5: A SIP UA that received an INFO request after sending an 507 unreliable provisional response knows that the dialog at the side of 508 the receiver has entered the early state 510 When sending the Answer in the 200 OK response to the INVITE request, 511 the Answerer MUST repeat exactly the same Answer that was previously 512 sent in the unreliable provisional response in order to fulfill the 513 corresponding requirements in [RFC3264]. Thus, the Offerer needs to 514 be prepared for receiving a different number of candidates in that 515 repeated Answer than previously exchanged via trickling and MUST 516 ignore the candidate information in that 200 OK response. 518 4.2.3. Initiating Trickle ICE without an SDP Answer 520 The possibility to convey arbitrary candidates in INFO message bodies 521 allows ICE Agents to initiate trickling without actually sending an 522 Answer. Trickle ICE Agents MAY therefore respond to an INVITE 523 request with provisional responses without an SDP Answer. Such 524 provisional responses serve for establishing an early dialog. 526 Agents that choose to establish the dialog in this way, MUST 527 retransmit these responses with the exponential back-off timers 528 described in [RFC3262]. These retransmissions MUST cease on receipt 529 of an INFO request or on transmission of the Answer in a 2xx 530 response. This is again similar to the procedure described in 531 section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer 532 is not yet provided. 534 [RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for 535 version 14 of said I-D. Please cross-check since it could have have 536 changed in the meantime.] 538 Note: The +SRFLX in Figure 6 indicates that additionally newly 539 learned server-reflexive candidates are included. 541 Alice Bob 542 | | 543 | INVITE (Offer) | 544 |------------------------>| 545 | 183 (-) | 546 |<------------------------| 547 | INFO/OK (SRFLX Cand.) | 548 |------------------------>| 549 | | 550 | +----------------------+ 551 | |Bob: Now I know again| 552 | | that Alice is ready. | 553 | | Send INFO! | 554 | +----------------------+ 555 | INFO/OK (SRFLX Cand.) | 556 |<------------------------| 557 | 183 (Answer) opt. | 558 |<------------------------| 559 | INFO/OK (SRFLX Cand.) | 560 |<------------------------| 561 | 200/ACK (Answer) | 562 |<------------------------| 564 Figure 6: A SIP UA sends an unreliable provisional response without 565 an Answer for establishing an early dialog 567 When sending the Answer, the agent MUST repeat all currently known 568 and used candidates, if any, and MAY include all newly gathered 569 candidates since the last INFO request was sent. If that Answer was 570 sent in a unreliable provisional response, the Answerers MUST repeat 571 exactly the same Answer in the 200 OK response to the INVITE request 572 in order to fulfill the corresponding requirements in [RFC3264]. In 573 case that trickling continued, an Offerer needs to be prepared for 574 receiving fewer candidates in that repeated Answer than previously 575 exchanged via trickling and MUST ignore the candidate information in 576 that 200 OK response. 578 4.2.4. Considerations for 3PCC 580 Agents that have sent an Offer in a reliable provisional response and 581 that receive an Answer in a PRACK are also in a situation where 582 support for Trickle ICE is confirmed and the SIP dialog is guaranteed 583 to be in a state that would allow in-dialog INFO requests (see 584 Figure 7). 586 Alice Bob 587 | | 588 | INVITE | 589 |------------------------>| 590 | 183 (Offer) | 591 |<------------------------| 592 | PRACK (Answer) | 593 |------------------------>| 594 | | 595 | +----------------------+ 596 | |Bob: I know Alice can| 597 | |trickle and I know her| 598 | |dialog is in the early| 599 | |state. Send INFO! | 600 | +----------------------+ 601 | | 602 | INFO/OK (SRFLX Cand.) | 603 |<------------------------| 604 | | 605 | INFO/OK (SRFLX Cand.) | 606 |------------------------>| 607 | 200 OK/ACK | 608 |<------------------------| 610 Figure 7: A SIP Offerer in a 3PCC scenario can also freely start 611 trickling as soon as it receives an Answer. 613 Trickle Agents that send an Offer in a 200 OK and receive an Answer 614 in an ACK can still create a dialog and confirm support for Trickle 615 ICE by sending an unreliable provisional response similar to 616 Section 4.2.3. According to [RFC3261], this unreliable response MUST 617 NOT contain an Offer. 619 The Trickle Agent (at the UAS) retransmits the provisional response 620 with the exponential back-off timers described in [RFC3262]. 621 Retransmits MUST cease on receipt of an INFO request or on 622 transmission of the Answer in a 2xx response. The peer Trickle Agent 623 (at the UAC) MUST send a Trickle ICE INFO request as soon as they 624 receive an unreliable provisional response (see Figure 8). 626 Alice Bob 627 | | 628 | INVITE | 629 |------------------------>| 630 | 183 (-) | 631 |<------------------------| 632 | INFO/OK (SRFLX Cand.) | 633 |------------------------>| 634 | | 635 | +-----------------------+ 636 | |Bob: I know Alice can | 637 | |trickle and I know her | 638 | |dialog is in the early | 639 | |state. | 640 | |INFO can be sent. | 641 | +-----------------------+ 642 | | 643 | INFO/OK (SRFLX Cand.) | 644 |<------------------------| 645 | | 646 | 200 (Offer) | 647 |<------------------------| 648 | ACK (Answer) | 649 |------------------------>| 650 | | 652 Figure 8: A SIP UAC in a 3PCC scenario can also freely start 653 trickling as soon as it receives an unreliable provisional response. 655 4.3. Delivering candidates in INFO messages 657 Whenever new ICE candidates become available for sending, agents 658 would encode them in "a=candidate" lines as described by 659 [I-D.ietf-mmusic-ice-sip-sdp]. For example: 661 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx 662 raddr 2001:db8:a0b:12f0::1 rport 8998 664 The use of SIP INFO requests happens within the context of the Info 665 Package as defined Section 10. The Media Type [RFC6838] for their 666 payload MUST be set to 'application/trickle-ice-sdpfrag' as defined 667 in Section 9. 669 Since neither the "a=candidate" nor the "a=end-of-candidates" 670 attributes contain information that would allow correlating them to a 671 specific "m=" line, this is handled through the use of pseudo "m=" 672 lines and identification tags in "a=mid:" attributes as defined in 673 [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as 674 defined in [RFC4566], but provide no semantics other than indicating 675 to which "m=" line a candidate belongs. Consequently, the receiving 676 agent MUST ignore any remaining content of the pseudo "m=" line, 677 which is not defined in this document. This guarantees that the 678 'application/trickle-ice-sdpfrag' bodies do not interfere with the 679 Offer/Answer procedures as specified in [RFC3264]. 681 When sending the INFO request, the agent MAY, if already known to the 682 agent, include the same content into the pseudo "m=" line as for the 683 "m=" line in the corresponding Offer or Answer. However, since 684 Trickle-ICE might be decoupled from the Offer/Answer negotiation this 685 content might be unknown to the agent. In this case, the agent MUST 686 include the following default values. 688 o The media field is set to 'audio'. 690 o The port value is set to '9'. 692 o The proto value is set to 'RTP/AVP'. 694 o The fmt SHOULD appear only once and is set to '0' 696 Agents MUST include a pseudo "m=" line and an identification tag in a 697 "a=mid:" attribute for every "m=" line whose candidate list they 698 intend to update. Such "a=mid:" attributes MUST immediately precede 699 the list of candidates for that specific "m=" line. All 700 "a=candidate" or "a=end-of-candidates" attributes following an 701 "a=mid:" attribute, up until (and excluding) the next occurrence of a 702 pseudo "m=" line, pertain to the "m=" line identified by that 703 identification tag. An "a=end-of-candidates" attribute, preceding 704 any pseudo "m=" line, indicates the end of all trickling from that 705 agent, as opposed to end of trickling for a specific "m=" line, which 706 would be indicated by a media level "a=end-of-candidates" attribute. 708 Refer to Figure 9 for an example of the INFO request content. 710 The use of pseudo "m=" lines allows for a structure similar to the 711 one in SDP Offers and Answers where separate media-level and session- 712 level sections can be distinguished. In the current case, lines 713 preceding any pseudo "m=" line are considered to be session-level. 714 Lines appearing in between or after pseudo "m=" lines will be 715 interpreted as media-level. 717 Note that while this specification uses the "a=mid:" attribute 718 from [RFC5888], it does not define any grouping semantics. 720 Consequently, the "a=group:" attribute from that same 721 specification is neither needed nor used in Trickle ICE for SIP. 723 All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" 724 attributes that would allow mapping them to a specific ICE 725 generation. An agent MUST discard any received INFO requests 726 containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not 727 match those of the current ICE Negotiation Session. 729 The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the 730 same level as the ones in the Offer/Answer exchange. In other words, 731 if they were present as session-level attributes, they will also 732 appear at the beginning of all INFO request payloads, i.e. preceding 733 all pseudo "m=" lines. If they were originally exchanged as media 734 level attributes, potentially overriding session-level values, then 735 they will also be included in INFO request payloads following the 736 corresponding pseudo "m=" lines. 738 Note that [I-D.ietf-ice-trickle] requires that when candidates are 739 trickled, each candidate MUST be delivered to the receiving Trickle 740 ICE implementation not more than once and in the same order as it was 741 conveyed. If the signaling protocol provides any candidate 742 retransmissions, they need to be hidden from the ICE implementation. 743 This requirement is fulfilled as follows. 745 Since the agent is not fully aware of the state of the ICE 746 Negotiation Session at its peer it MUST include all currently known 747 and used local candidates in every INFO request. I.e. the agent MUST 748 repeat in the INFO request body all candidates that were previously 749 sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in 750 the same order as they were gathered. In other words, the sequence 751 of a previously sent list of candidates MUST NOT change in subsequent 752 INFO requests and newly gathered candidates MUST be added at the end 753 of that list. Although repeating all candidates creates some 754 overhead, it also allows easier handling of problems that could arise 755 from unreliable transports, like e.g. loss of messages and 756 reordering, which can be detected through the CSeq: header field in 757 the INFO request. 759 When receiving INFO requests carrying any candidates, agents will 760 therefore first identify and discard the attribute lines containing 761 candidates they have already received in previous INFO requests or in 762 the Offer/Answer exchange preceding them. Two candidates are 763 considered to be equal if their IP address port, transport and 764 component ID are the same. After identifying and discarding known 765 candidates, the agents MUST forward the actually new candidates to 766 the ICE Agents in the same order as they were received in the INFO 767 request body. The ICE Agents will then process the new candidates 768 according to the rules described in [I-D.ietf-ice-trickle]. 770 Receiving an "a=end-of-candidates" attribute in an INFO request body 771 - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the 772 current ICE generation - is an indication of the peer agent that it 773 will not send any further candidates. When included at session 774 level, i.e. before any pseudo "m=" line, this indication applies to 775 the whole session; when included at media level the indication 776 applies only to the corresponding "m=" line. Handling of such end- 777 of-candidate indications is defined in [I-D.ietf-ice-trickle]. 779 Note: At the time of writing this specification there were ongoing 780 discussions if a functionality for removing already exchanged 781 candidates would be useful. Such a functionality is out of the scope 782 of this specification and most likely needs to be signaled by means 783 of a yet to be defined ICE extension, although it could in principle 784 be achieved quite easily, e.g. without anticipating any solution by 785 simply omitting a previously sent candidate from a subsequent INFO 786 request. However, if an implementation according to this 787 specification receives such an INFO request with a missing candidate 788 it MAY treat that as an exceptional case. Implementing appropriate 789 recovery procedures at the receiving side is RECOMMENDED for this 790 situation. Ignoring that a candidate was missing might be a sensible 791 strategy. 793 The following example shows the content of one sample candidate 794 delivering INFO request: 796 INFO sip:alice@example.com SIP/2.0 797 ... 798 Info-Package: trickle-ice 799 Content-type: application/trickle-ice-sdpfrag 800 Content-Disposition: Info-Package 801 Content-length: ... 803 a=ice-pwd:asd88fgpdd777uzjYhagZg 804 a=ice-ufrag:8hhY 805 m=audio 9 RTP/AVP 0 806 a=mid:1 807 a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host 808 a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host 809 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx 810 raddr 2001:db8:a0b:12f0::1 rport 8998 811 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx 812 raddr 2001:db8:a0b:12f0::1 rport 8998 813 a=end-of-candidates 814 m=audio 9 RTP/AVP 0 815 a=mid:2 816 a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 6000 typ host 817 a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 6001 typ host 818 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 6000 typ srflx 819 raddr 2001:db8:a0b:12f0::1 rport 9998 820 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 6001 typ srflx 821 raddr 2001:db8:a0b:12f0::1 rport 9998 822 a=end-of-candidates 824 Figure 9: An Example for the Content of an INFO Request 826 5. Initial discovery of Trickle ICE support 828 SIP User Agents (UAs) that support and intend to use trickle ICE are 829 REQUIRED by [I-D.ietf-ice-trickle] to indicate that in their Offers 830 and Answers using the following attribute: "a=ice-options:trickle". 831 This makes discovery fairly straightforward for Answerers or for 832 cases where Offers need to be generated within existing dialogs 833 (i.e., when sending re-INVITE requests). In both scenarios prior SDP 834 would have provided the necessary information. 836 Obviously, prior SDP is not available at the time a first Offer is 837 being constructed and it is therefore impossible for ICE Agents to 838 determine support for incremental provisioning that way. The 839 following options are suggested as ways of addressing this issue. 841 5.1. Provisioning support for Trickle ICE 843 In certain situations it may be possible for integrators deploying 844 Trickle ICE to know in advance that some or all endpoints reachable 845 from within the deployment will support Trickle ICE. This is likely 846 to be the case, for example, for WebRTC clients that will always be 847 communicating with other WebRTC clients or known Session Border 848 Controllers (SBC) with support for this specification. 850 While the exact mechanism for allowing such provisioning is out of 851 scope here, this specification encourages trickle ICE implementations 852 to allow the option in the way they find most appropriate. 854 5.2. Trickle ICE discovery with GRUU 856 [RFC3840] provides a way for SIP User Agents to query for support of 857 specific capabilities using, among others, OPTIONS requests. GRUU 858 support on the other hand allows SIP requests to be addressed to 859 specific UAs (as opposed to arbitrary instances of an address of 860 record). Combining the two and using the "trickle-ice" option tag 861 defined in Section 10.6 provides SIP UAs with a way of learning the 862 capabilities of specific US instances and then addressing them 863 directly with INVITE requests that require SIP support. 865 Such targeted trickling may happen in different ways. One option 866 would be for a SIP UA to learn the GRUU instance ID of a peer through 867 presence and to then query its capabilities direction with an OPTIONS 868 request. Alternately, it can also just send an OPTIONS request to 869 the AOR it intends to contact and then inspect the returned 870 response(s) for support of both GRUU and Trickle ICE (Figure 10). 872 Alice Bob 873 | | 874 | OPTIONS sip:b1@example.com SIP/2.0 | 875 |-------------------------------------------------->| 876 | | 877 | 200 OK | 878 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 879 | ;audio;video|;trickle-ice;... | 880 |<--------------------------------------------------| 881 | | 882 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 883 |-------------------------------------------------->| 884 | | 885 | 183 (Answer) | 886 |<--------------------------------------------------| 887 | INFO/OK (Trickling) | 888 |<------------------------------------------------->| 889 | | 890 | ... | 891 | | 893 Figure 10: Trickle ICE support discovery with OPTIONS and GRUU 895 Confirming support for Trickle ICE through [RFC3840] gives SIP UAs 896 the options to engage in Full Trickle negotiation (as opposed to the 897 more lengthy Half Trickle) from the very first Offer they send. 899 5.3. Trickle ICE discovery through other protocols 901 Protocols like XMPP [RFC6120] define advanced discovery mechanisms 902 that allow specific features to be queried priory to actually 903 attempting to use them. Solutions like [RFC7081] define ways of 904 using SIP and XMPP together which also provides a way for dual stack 905 SIP+XMPP endpoints to make use of such features and verify Trickle 906 ICE support for a specific SIP endpoint through XMPP. However, such 907 discovery mechanisms are out of the scope of this document. 909 5.4. Fall-back to Half Trickle 911 In cases where none of the other mechanisms in this section are 912 acceptable, SIP UAs should use the Half Trickle mode defined in 913 [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions 914 the same way they would when using ICE for SIP 915 [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually 916 sending an Offer, agents would first gather ICE candidates in a 917 blocking way and then send them all in that Offer. The blocking 918 nature of the process would likely imply that some amount of latency 919 will be accumulated and it is advised that agents try to anticipate 920 it where possible, like for example, when user actions indicate a 921 high likelihood for an imminent call (e.g., activity on a keypad or a 922 phone going off-hook). 924 Using Half Trickle would result in Offers that are compatible with 925 both ICE SIP endpoints and legacy [RFC3264] endpoints. 927 STUN/Turn STUN/TURN 928 Servers Alice Bob Servers 929 | | | | 930 |<--------------| | | 931 | | | | 932 | | | | 933 | Candidate | | | 934 | | | | 935 | | | | 936 | Discovery | | | 937 | | | | 938 | | | | 939 |-------------->| INVITE (Offer) | | 940 | |---------------------------->| | 941 | | 183 (Answer) |-------------->| 942 | |<----------------------------| | 943 | | INFO (repeated candidates) | | 944 | |---------------------------->| | 945 | | | | 946 | | INFO (more candidates) | Candidate | 947 | |<----------------------------| | 948 | | Connectivity Checks | | 949 | |<===========================>| Discovery | 950 | | INFO (more candidates) | | 951 | |<----------------------------| | 952 | | Connectivity Checks |<--------------| 953 | |<===========================>| | 954 | | | | 955 | | 200 OK | | 956 | |<----------------------------| | 957 | | | | 958 | |<======= MEDIA FLOWS =======>| | 959 | | | | 961 Figure 11: Example - A typical (Half) Trickle ICE exchange with SIP 963 It is worth reminding that once a single Offer or Answer had been 964 exchanged within a specific dialog, support for Trickle ICE will have 965 been determined. No further use of Half Trickle will therefore be 966 necessary within that same dialog and all subsequent exchanges can 967 use the Full Trickle mode of operation. 969 6. Considerations for RTP and RTCP multiplexing 971 The following consideration describe options for Trickle-ICE in order 972 to give some guidance to implementors on how trickling can be 973 optimized with respect to providing RTCP candidates. 975 Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" 976 attribute for RTP/RTCP multiplexing [RFC5761] is already considered 977 in section 5.6.1. of [I-D.ietf-mmusic-rfc5245bis] and as well in 978 [RFC5761] itself. These considerations are still valid for Trickle 979 ICE, however, trickling provides more flexibility for the sequence of 980 candidate exchange in case of RTCP multiplexing. 982 [RFC EDITOR NOTE: The section 5.6.1 in above sentence is correct for 983 version 05 of said I-D. Please cross-check since it could have have 984 changed in the meantime.] 986 If the Offerer supports RTP/RTCP multiplexing exclusively as 987 specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that 988 document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" 989 and the "a=rtcp-mux" attributes. 991 While a Half Trickle Offerer would have to send an offer compliant to 992 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for 993 all components, this flexibility allows a Full Trickle Offerer to 994 send only RTP candidates (component 1) in the initial Offer if it 995 assumes that RTCP multiplexing is supported by the Answerer. A Full 996 Trickle Offerer would need to start gathering and trickling RTCP 997 candidates (component 2) only after having received an indication in 998 the Answer that the Answerer unexpectedly does not support RTCP 999 multiplexing. 1001 A Trickle Answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in 1002 the application/trickle-ice-sdpfrag body if it supports and uses RTP 1003 and RTCP multiplexing. The Trickle Answerer MUST follow the guidance 1004 on the usage of the "a=rtcp" attribute as given in 1005 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]. Receipt of this 1006 attribute at the Offerer in an INFO request prior to the Answer 1007 indicates that the Answerer supports and uses RTP and RTCP 1008 multiplexing. The Offerer can use this information e.g. for stopping 1009 gathering of RTCP candidates and/or for freeing corresponding 1010 resources. 1012 This behavior is illustrated by the following example offer that 1013 indicates support for RTP and RTCP multiplexing. 1015 v=0 1016 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1017 s= 1018 c=IN IP4 atlanta.example.com 1019 t=0 0 1020 a=ice-pwd:777uzjYhagZgasd88fgpdd 1021 a=ice-ufrag:Yhh8 1022 m=audio 10000 RTP/AVP 0 1023 a=mid:1 1024 a=rtcp-mux 1025 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host 1027 Once the dialog is established as described in section Section 4.2 1028 the Answerer sends the following INFO request. 1030 INFO sip:alice@example.com SIP/2.0 1031 ... 1032 Info-Package: trickle-ice 1033 Content-type: application/sdp 1034 Content-Disposition: Info-Package 1035 Content-length: ... 1037 a=ice-pwd:asd88fgpdd777uzjYhagZg 1038 a=ice-ufrag:8hhY 1039 m=audio 9 RTP/AVP 0 1040 a=mid:1 1041 a=rtcp-mux 1042 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host 1044 This INFO request indicates that the Answerer supports and uses RTP 1045 and RTCP multiplexing as well. It allows the Offerer to omit 1046 gathering of RTCP candidates or releasing already gathered RTCP 1047 candidates. If the INFO request did not contain the a=rtcp-mux 1048 attribute, the Offerer would have to gather RTCP candidates unless it 1049 wants to wait until receipt of an Answer that eventually confirms 1050 support or non-support for RTP and RTCP multiplexing. 1052 7. Considerations for Media Multiplexing 1054 The following considerations describe options for Trickle-ICE in 1055 order to give some guidance to implementors on how trickling can be 1056 optimized with respect to providing candidates in case of Media 1057 Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed 1058 that the reader is familiar with 1059 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 1061 ICE candidate exchange is already considered in section 11 of 1062 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are 1063 still valid for Trickle ICE, however, trickling provides more 1064 flexibility for the sequence of candidate exchange, especially in 1065 Full Trickle mode. 1067 Except for bundle-only "m=" lines, a Half Trickle Offerer would have 1068 to send an offer with candidates for all bundled "m=" lines. The 1069 additional flexibility, however, allows a Full Trickle Offerer to 1070 initially send only candidates for the "m=" line with the suggested 1071 Offerer BUNDLE address. 1073 Latest on receipt of the Answer, the Offerer will detect if BUNDLE is 1074 supported by the Answerer and if the suggested Offerer BUNDLE address 1075 was selected. In this case, the Offerer does not need to trickle 1076 further candidates for the remaining "m=" lines in a bundle. 1077 However, if BUNDLE is not supported, the Full Trickle Offerer needs 1078 to gather and trickle candidates for the remaining "m=" lines as 1079 necessary. If the Answerer selects an Offerer BUNDLE address 1080 different from the suggested Offerer BUNDLE address, the Full Trickle 1081 Offerer needs to gather and trickle candidates for the "m=" line that 1082 carries the selected Offerer BUNDLE address. 1084 A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute 1085 [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle- 1086 ice-sdpfrag body if it supports and uses bundling. When doing so, 1087 the Answerer MUST include all identification-tags in the same order 1088 that is used or will be used in the Answer. 1090 Receipt of this attribute at the Offerer in an INFO request prior to 1091 the Answer indicates that the Answerer supports and uses bundling. 1092 The Offerer can use this information e.g. for stopping the gathering 1093 of candidates for the remaining "m=" lines in a bundle and/or for 1094 freeing corresponding resources. 1096 This behaviour is illustrated by the following example offer that 1097 indicates support for Media Multiplexing. 1099 v=0 1100 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com 1101 s= 1102 c=IN IP6 atlanta.example.com 1103 t=0 0 1104 a=group:BUNDLE foo bar 1105 a=ice-pwd:777uzjYhagZgasd88fgpdd 1106 a=ice-ufrag:Yhh8 1107 m=audio 10000 RTP/AVP 0 1108 a=mid:foo 1109 a=rtpmap:0 PCMU/8000 1110 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1111 m=video 10002 RTP/AVP 31 1112 a=mid:bar 1113 a=rtpmap:31 H261/90000 1114 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1116 Once the dialog is established as described in section Section 4.2 1117 the Answerer sends the following INFO request. 1119 INFO sip:alice@example.com SIP/2.0 1120 ... 1121 Info-Package: trickle-ice 1122 Content-type: application/sdp 1123 Content-Disposition: Info-Package 1124 Content-length: ... 1126 a=group:BUNDLE foo bar 1127 a=ice-pwd:asd88fgpdd777uzjYhagZg 1128 a=ice-ufrag:8hhY 1129 m=audio 9 RTP/AVP 0 1130 a=mid:foo 1131 a=rtcp-mux 1132 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host 1133 m=audio 9 RTP/AVP 0 1134 a=mid:bar 1136 This INFO request indicates that the Answerer supports and uses Media 1137 Multiplexing as well. Note, that the second "m=" line shows the 1138 default values as specified in section Section 4.3, e.g. media set 1139 'audio' although 'video' was offered. The receiving ICE Agents MUST 1140 ignore these default values in the pseudo "m=" lines. 1142 The INFO request also indicates that the Answerer accepted the 1143 suggested Offerer Bundle Address. This allows the Offerer to omit 1144 gathering of RTP and RTCP candidates for the other "m=" lines or 1145 releasing already gathered candidates. If the INFO request did not 1146 contain the a=group:BUNDLE attribute, the Offerer would have to 1147 gather RTP and RTCP candidates for the other "m=" lines unless it 1148 wants to wait until receipt of an Answer that eventually confirms 1149 support or non-support for Media Multiplexing. 1151 Independent of using Full Trickle or Half Trickle mode, the rules 1152 from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and 1153 Answerer, when putting attributes as specified in Section 9.2 in the 1154 application/trickle-ice-sdpfrag body. 1156 8. SDP 'end-of-candidate' Attribute 1158 8.1. Defintion 1160 This section defines a new SDP media-level and session-level 1161 attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' is a 1162 property attribute [RFC4566], and hence has no value. By including 1163 this attribute in an Offer or Answer the sending agent indicates that 1164 it will not trickle further candidates. When included at session 1165 level this indication applies to the whole session, when included at 1166 media level the indication applies only to the corresponding media 1167 desciption. 1169 Name: end-of-candidate 1171 Value: N/A 1173 Usage Level: media and session-level 1175 Charset Dependent: no 1177 Mux Category: IDENTICAL 1179 Example: a=end-of-candidate 1181 8.2. Offer/Answer procedures 1183 The Offerer or Answerer MAY include an "a=end-of-candidates" 1184 attribute in case candidate discovery has ended and no further 1185 candidates are to be trickled. The Offerer or Answerer MUST provide 1186 the "a=end-of-candidates" attribute together with the "a=ice-ufrag" 1187 and "a=ice-pwd" attributes of the current ICE generation as required 1188 by [I-D.ietf-ice-trickle]. When included at session level this 1189 indication applies to the whole session; when included at media level 1190 the indication applies only to the corresponding media description. 1192 Receipt of an "a=end-of-candidates" attribute at an Offerer or 1193 Anwerer - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching 1194 the current ICE generation - indicates that gathering of candidates 1195 has ended at the peer, either for the session or only for the 1196 corresponding media description as specified above. The receiving 1197 agent forwards an end-of-candidates indication to the ICE Agent, 1198 which in turn acts as specified in [I-D.ietf-ice-trickle]. 1200 9. Content Type 'application/trickle-ice-sdpfrag' 1202 9.1. Overall Description 1204 A application/trickle-ice-sdpfrag body is used by the 'trickle-ice' 1205 Info Package. It uses a subset of the possible SDP lines as defined 1206 by the grammar defined in [RFC4566]. A valid body uses only pseudo 1207 "m=" lines and certain attributes that are needed and/or useful for 1208 trickling candidates. The content adheres to the following grammar. 1210 9.2. Grammar 1212 The grammar of an 'application/trickle-ice-sdpfrag' body is based on 1213 the following ABNF [RFC5234]. It specifies the subset of existing 1214 SDP attributes, that are needed or useful for trickling candidates. 1215 The grammar uses the indicator for case-sensitivity %s is defined in 1216 [RFC7405], but also imports grammars for other SDP attributes that 1217 precede the production of that RFC. A sender SHOULD stick to lower- 1218 case for such grammars, but a receiver SHOULD treat them case- 1219 insensitive. 1221 ; Syntax 1222 trickle-ice-sdpfrag = session-level-fields 1223 pseudo-media-descriptions 1224 session-level-fields = [bundle-group-attribute CRLF] 1225 [ice-lite-attribute CRLF] 1226 ice-pwd-attribute CRLF 1227 ice-ufrag-attribute CRLF 1228 [ice-options-attribute CRLF] 1229 [ice-pacing-attribute CRLF] 1230 [end-of-candidates-attribute CRLF] 1231 extension-attribute-fields 1232 ; for future extensions 1234 ice-lite-attribute = %s"a" "=" ice-lite 1235 ice-pwd-attribute = %s"a" "=" ice-pwd-att 1236 ice-ufrag-attribute = %s"a" "=" ice-ufrag-att 1237 ice-pacing-attribute = %s"a" "=" ice-pacing-att 1238 ice-options-attribute = %s"a" "=" ice-options 1239 bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics 1240 *(SP identification-tag) 1241 bundle-semantics = "BUNDLE" 1242 end-of-candidates-attribute = %s"a" "=" end-of-candidates 1243 end-of-candidates = %s"end-of-candidates" 1244 extension-attribute-fields = attribute-fields 1246 pseudo-media-descriptions = *( media-field 1247 trickle-ice-attribute-fields 1248 [extension-attribute-fields] ) 1249 ; for future extensions 1250 trickle-ice-attribute-fields = %s"a" "=" mid-attribute CRLF 1251 [%s"a" "=" %s"rtcp" CRLF] 1252 [%s"a" "=" %s"rtcp-mux" CRLF] 1253 [%s"a" "=" %s"rtcp-mux-only" CRLF] 1254 *(candidate-attributes CRLF) 1255 [ice-pwd-attribute CRLF] 1256 [ice-ufrag-attribute CRLF] 1257 [remote-candidate-attribute CRLF] 1258 [end-of-candidates-attribute CRLF] 1259 remote-candidate-attribute = %s"a" "=" remote-candidate-att 1260 candidate-attributes = %s"a" "=" candidate-attribute 1262 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- 1263 pacing-att, ice-options, candidate-attribute remote-candidate-att 1264 from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute 1265 ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The 1266 "a=rtcp" attribute is defined in [RFC3605], the "a=rtcp-mux" 1267 attribute in [RFC5761] and the "a=rtcp-mux-only" attribute in 1269 [I-D.ietf-mmusic-mux-exclusive]. The latter attributes lack a formal 1270 grammar in their corresponding RFC and are reproduced here. 1272 An Agent MUST ignore any received unknown extension-attribute-fields. 1274 10. Info Package 1276 10.1. Rationale - Why INFO? 1278 The decision to use SIP INFO requests as a candidate transport method 1279 is based primarily on their lightweight nature. Once a dialog has 1280 been established, INFO messages can be exchanged both ways with no 1281 restrictions on timing and frequency and no risk of collision. 1283 On the other hand, using Offer/Answer and UPDATE requests [RFC3311] 1284 introduces the following complications: 1286 Blocking of messages: [RFC3264] defines Offer/Answer as a strictly 1287 sequential mechanism. There can only be a maximum of one exchange 1288 at any point of time. Both sides cannot simultaneously send 1289 Offers nor can they generate multiple Offers prior to receiving an 1290 Answer. Using UPDATE requests for candidate transport would 1291 therefore imply the implementation of a candidate pool at every 1292 agent where candidates can be stored until it is once again that 1293 agent's "turn" to emit an Answer or a new Offer. Such an approach 1294 would introduce non-negligible complexity for no additional value. 1296 Elevated risk of glare: The sequential nature of Offer/Answer also 1297 makes it impossible for both sides to send Offers simultaneously. 1298 What's worse is that there are no mechanisms in SIP to actually 1299 prevent that. [RFC3261], where the situation of Offers crossing 1300 on the wire is described as "glare", only defines a procedure for 1301 addressing the issue after it has occurred. According to that 1302 procedure both Offers are invalidated and both sides need to retry 1303 the negotiation after a period between 0 and 4 seconds. The high 1304 likelihood for glare to occur and the average two second back-off 1305 intervals would imply Trickle ICE processing duration would not 1306 only fail to improve but actually exceed those of regular ICE. 1308 INFO messages decouple the exchange of candidates from the Offer/ 1309 Answer negotiation and are subject to none of the glare issues 1310 described above, which makes them a very convenient and lightweight 1311 mechanism for asynchronous delivery of candidates. 1313 Using in-dialog INFO messages also provides a way of guaranteeing 1314 that candidates are delivered end-to-end, between the same entities 1315 that are actually in the process of initiating a session. Out-of- 1316 dialog alternatives would have implied requiring support for Globally 1317 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 1318 adoption levels, would have constituted too strong of a constraint to 1319 the adoption of Trickle ICE. 1321 10.2. Overall Description 1323 This specification defines an Info Package for use by SIP User Agents 1324 implementing Trickle ICE. INFO requests carry ICE candidates 1325 discovered after the peer user agents have confirmed mutual support 1326 for Trickle ICE. 1328 10.3. Applicability 1330 The purpose of the ICE protocol is to establish a media path in the 1331 presence of NAT and firewalls. The candidates are transported in 1332 INFO requests and are part of this establishment. 1334 Candidates sent by a Trickle ICE Agent after the Offer, follow the 1335 same signaling path and reach the same entity as the Offer itself. 1336 While it is true that GRUUs can be used to achieve this, one of the 1337 goals of this specification is to allow operation of Trickle ICE in 1338 as many environments as possible including those without GRUU 1339 support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not 1340 satisfy this goal. 1342 10.4. Info Package Name 1344 This document defines a SIP Info Package as per [RFC6086]. The Info 1345 Package token name for this package is "trickle-ice" 1347 10.5. Info Package Parameters 1349 This document does not define any Info Package parameters. 1351 10.6. SIP Option Tags 1353 [RFC6086] allows Info Package specifications to define SIP option- 1354 tags. This specification extends the option-tag construct of the SIP 1355 grammar as follows: 1357 option-tag /= "trickle-ice" 1359 SIP entities that support this specification MUST place the 'trickle- 1360 ice' option-tag in a SIP Supported: header field within all SIP 1361 INVITE requests and responses. 1363 When responding to, or generating a SIP OPTIONS request a SIP entity 1364 MUST also include the 'trickle-ice' option-tag in a SIP Supported: 1365 header field. 1367 10.7. Info Message Body Parts 1369 Entities implementing this specification MUST include a payload of 1370 type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 all 1371 SIP INFO requests. The payload is used to convey SDP encoded ICE 1372 candidates. 1374 10.8. Info Package Usage Restrictions 1376 This document does not define any Info Package Usage Restrictions. 1378 10.9. Rate of INFO Requests 1380 A Trickle ICE Agent with many network interfaces might create a high 1381 rate of INFO requests if every newly detected candidate is trickled 1382 individually without aggregation. Implementors that are concerned 1383 about loss of packets in such a case might consider aggregating ICE 1384 candidates and sending INFOs only at some configurable intervals. 1386 10.10. Info Package Security Considerations 1388 See Section 12 1390 11. IANA Considerations 1392 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1393 document. ] 1395 11.1. SDP 'end-of-candidate' Attribute 1397 This section defines a new SDP media-level and session-level 1398 attribute [RFC4566] , 'end-of-candidate'. 'end-of-candidate' is a 1399 property attribute [RFC4566] , and hence has no value. 1401 Name: end-of-candidate 1403 Value: N/A 1405 Usage Level: media and session 1407 Charset Dependent: no 1409 Purpose: The sender indicates that it will not trickle 1410 further candidates. 1412 O/A Procedures: RFCXXX defines the detailed 1413 SDP Offer/Answer procedures for 1414 the 'end-of-candidate' attribute. 1416 Mux Category: IDENTICAL 1418 Reference: RFCXXXX 1420 Example: 1422 a=end-of-candidate 1424 11.2. application/trickle-ice-sdpfrag Media Type 1426 Type name: application 1428 Subtype name: trickle-ice-sdpfrag 1430 Required parameters: None. 1432 Optional parameters: None. 1434 Encoding considerations: 1436 SDP files are primarily UTF-8 format text. Although the 1437 initially defined content of a trickle-ice-sdpfrag body does 1438 only include ASCII characters, UTF-8 encoded content might be 1439 introduced via extension attributes. The "a=charset:" 1440 attribute may be used to signal the presence of other character 1441 sets in certain parts of a trickle-ice-sdpfrag body (see 1442 [RFC4566]). Arbitrary binary content cannot be directly 1443 represented in SDP or a trickle-ice-sdpfrag body. 1445 Security considerations: 1447 See [RFC4566]) and RFCXXXX 1449 Interoperability considerations: 1451 See RFCXXXX 1453 Published specification: 1455 See RFCXXXX 1457 Applications which use this Media Type: 1459 Voice over IP, video teleconferencing, streaming media, instant 1460 messaging, Trickle-ICE among others. 1462 Fragment identifier considerations: N/A 1464 Additional information: 1466 Magic number(s): N/A 1468 File extension(s): N/A 1470 Macintosh File Type Code(s): N/A 1472 Person and email address to contact for further information: 1474 IETF MMUSIC working group mmusic@ietf.org 1476 Intended usage: 1478 Trickle-ICE for SIP as specified in RFCXXXX. 1480 Restrictions on usage: N/A 1482 Author/Change controller: 1484 IETF MMUSIC working group mmusic@ietf.org 1486 Provisional registration? (standards tree only): N/A 1488 11.3. SIP Info Package 'trickle-ice' 1490 This document defines a new SIP Info Package named 'trickle-ice' and 1491 updates the Info Packages Registry with the following entry. 1493 +-------------+-----------+ 1494 | Name | Reference | 1495 +-------------+-----------+ 1496 | trickle-ice | [RFCXXXX] | 1497 | | | 1498 +-------------+-----------+ 1500 11.4. SIP Option Tag 'trickle-ice' 1502 This specification registers a new SIP option tag 'trickle-ice' as 1503 per the guidelines in Section 27.1 of [RFC3261] and updates the 1504 "Option Tags" section of the SIP Parameter Registry with the 1505 following entry: 1507 +-------------+-------------------------------------+-----------+ 1508 | Name | Description | Reference | 1509 +-------------+-------------------------------------+-----------+ 1510 | trickle-ice | This option tag is used to indicate | [RFCXXXX] | 1511 | | that a UA supports and understands | | 1512 | | Trickle-ICE. | | 1513 +-------------+-------------------------------------+-----------+ 1515 12. Security Considerations 1517 The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], 1518 [RFC6086] and [I-D.ietf-ice-trickle] apply. This document clarifies 1519 how the above specifications are used together for trickling 1520 candidates and does not create addtitional security risks. 1522 13. Acknowledgements 1524 The authors would like to thank Flemming Andreasen, Ayush Jain, Paul 1525 Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount and Martin 1526 Thomson for reviewing and/or making various suggestions for 1527 improvements and optimizations. 1529 14. Change Log 1531 [RFC EDITOR NOTE: Please remove this section when publishing]. 1533 Changes from draft-ietf-mmusic-trickle-ice-sip-01 1535 o Editorial Clean up 1537 o IANA Consideration added 1539 o Security Consideration added 1541 o RTCP and BUNDLE Consideration added with rules for including 1542 "a=rtcp-mux" and "a=group: BUNDLLE" attributes 1544 o 3PCC Consideration added 1546 o Clarified that 18x w/o answer is sufficient to create a dialog 1547 that allows for trickling to start 1549 o Added remaining Info Package definition sections as outlined in 1550 section 10 of [RFC6086] 1552 o Added definition of application/sdpfrag making draft-ivov-mmusic- 1553 sdpfrag obsolete 1555 o Added pseudo m-lines as additional separator in sdpfrag bodies for 1556 Trickle ICE 1558 o Added ABNF for sdp-frag bodies and Trickle-ICE package 1560 Changes from draft-ietf-mmusic-trickle-ice-sip-02 1562 o Removed definition of application/sdpfrag 1564 o Replaced with new type application/trickle-ice-sdpfrag 1566 o RTCP and BUNDLE Consideration enhanced with some examples 1568 o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to 1569 normative reference 1571 o Removed reference to 4566bis 1573 o Addressed review comment from Simon Perreault 1575 Changes from draft-ietf-mmusic-trickle-ice-sip-03 1576 o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis 1577 and draft-ietf-mmusic-ice-sip-sdp 1579 o Corrected Figure 10, credits to Ayush Jain for finding the bug 1581 o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- 1582 ice-sip-sdp 1584 o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- 1585 mux-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive 1587 o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for 1588 the application/trickle-ice-sdpfrag body 1590 Changes from draft-ietf-mmusic-trickle-ice-sip-04 1592 o considered comments from Christer Holmberg 1594 o corrected grammar for INFO package, such that ice-ufrag/pwd are 1595 also allowed on media-level as specified in 1596 [I-D.ietf-mmusic-ice-sip-sdp] 1598 o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] 1600 o Added formal definition for the end-of-candidates attribute 1602 Changes from draft-ietf-mmusic-trickle-ice-sip-05 1604 o considered further comments from Christer Holmberg 1606 o editorial comments on section 3 addressed 1608 o moved section 3.1 to section 10.1 and applied some edits 1610 o replaced the term "previously sent candidates" with "currently 1611 known and used candidates". 1613 Changes from draft-ietf-mmusic-trickle-ice-sip-06 1615 o editorial fixes 1617 o additional text on the content of the INFO messages. 1619 o recommendation on what to do if a previously sent candidate is 1620 unexpectedly missing in a subsequent INFO 1622 o terminology alignment with draft-ietf-ice-trickle-07 1623 Changes from draft-ietf-mmusic-trickle-ice-sip-07 1625 o editorial fixes 1627 o clarification on ordering of candidates for alignment with draft- 1628 ietf-ice-trickle-12 1630 o O/A procedures for end-of-candidates attribute described here 1631 after corresponding procedures have been removed from draft-ietf- 1632 ice-trickle-11 1634 o using IPv6 addresses in examples 1636 Changes from draft-ietf-mmusic-trickle-ice-sip-08 1638 o editorial fixes/clarification based on Flemmings review 1640 o Description of Trickle specifics in O/A procedures for initial O/A 1641 exchange and specification of ICE mismatch exception 1643 Changes from draft-ietf-mmusic-trickle-ice-sip-09 1645 o editorial fixes/correction of references 1647 o adding missing Ref to RFC3605 in section 6, 5th para 1649 o replaced remaining IPv4 adresses with IPv6 1651 o Added text for handling a=rtcp in case of default RTP address 1652 0.0.0.0:9 based on comment from Roman Shpount. 1654 15. References 1656 15.1. Normative References 1658 [I-D.ietf-ice-trickle] 1659 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 1660 "Trickle ICE: Incremental Provisioning of Candidates for 1661 the Interactive Connectivity Establishment (ICE) 1662 Protocol", draft-ietf-ice-trickle-14 (work in progress), 1663 September 2017. 1665 [I-D.ietf-mmusic-ice-sip-sdp] 1666 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 1667 "Session Description Protocol (SDP) Offer/Answer 1668 procedures for Interactive Connectivity Establishment 1669 (ICE)", draft-ietf-mmusic-ice-sip-sdp-14 (work in 1670 progress), October 2017. 1672 [I-D.ietf-mmusic-mux-exclusive] 1673 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 1674 Multiplexing using SDP", draft-ietf-mmusic-mux- 1675 exclusive-12 (work in progress), May 2017. 1677 [I-D.ietf-mmusic-rfc5245bis] 1678 Keranen, A. and J. Rosenberg, "Interactive Connectivity 1679 Establishment (ICE): A Protocol for Network Address 1680 Translator (NAT) Traversal", draft-ietf-mmusic- 1681 rfc5245bis-05 (work in progress), September 2015. 1683 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1684 Holmberg, C., Alvestrand, H., and C. Jennings, 1685 "Negotiating Media Multiplexing Using the Session 1686 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1687 negotiation-39 (work in progress), August 2017. 1689 [I-D.ietf-mmusic-sdp-mux-attributes] 1690 Nandakumar, S., "A Framework for SDP Attributes when 1691 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1692 (work in progress), December 2016. 1694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1695 Requirement Levels", BCP 14, RFC 2119, 1696 DOI 10.17487/RFC2119, March 1997, 1697 . 1699 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1700 A., Peterson, J., Sparks, R., Handley, M., and E. 1701 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1702 DOI 10.17487/RFC3261, June 2002, 1703 . 1705 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1706 Provisional Responses in Session Initiation Protocol 1707 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1708 . 1710 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1711 with Session Description Protocol (SDP)", RFC 3264, 1712 DOI 10.17487/RFC3264, June 2002, 1713 . 1715 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1716 in Session Description Protocol (SDP)", RFC 3605, 1717 DOI 10.17487/RFC3605, October 2003, 1718 . 1720 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1721 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1722 July 2006, . 1724 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1725 Specifications: ABNF", STD 68, RFC 5234, 1726 DOI 10.17487/RFC5234, January 2008, 1727 . 1729 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1730 Control Packets on a Single Port", RFC 5761, 1731 DOI 10.17487/RFC5761, April 2010, 1732 . 1734 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1735 Protocol (SDP) Grouping Framework", RFC 5888, 1736 DOI 10.17487/RFC5888, June 2010, 1737 . 1739 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1740 Initiation Protocol (SIP) INFO Method and Package 1741 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1742 . 1744 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1745 Specifications and Registration Procedures", BCP 13, 1746 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1747 . 1749 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1750 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1751 . 1753 15.2. Informative References 1755 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1756 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1757 2002, . 1759 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1760 "Indicating User Agent Capabilities in the Session 1761 Initiation Protocol (SIP)", RFC 3840, 1762 DOI 10.17487/RFC3840, August 2004, 1763 . 1765 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1766 Agent URIs (GRUUs) in the Session Initiation Protocol 1767 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 1768 . 1770 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1771 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1772 March 2011, . 1774 [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: 1775 Combined Use of the Session Initiation Protocol (SIP) and 1776 the Extensible Messaging and Presence Protocol (XMPP)", 1777 RFC 7081, DOI 10.17487/RFC7081, November 2013, 1778 . 1780 Authors' Addresses 1782 Emil Ivov 1783 Jitsi 1784 Strasbourg 67000 1785 France 1787 Phone: +33 6 72 81 15 55 1788 Email: emcho@jitsi.org 1790 Thomas Stach 1791 Unaffiliated 1792 Vienna 1130 1793 Austria 1795 Email: thomass.stach@gmail.com 1797 Enrico Marocco 1798 Telecom Italia 1799 Via G. Reiss Romoli, 274 1800 Turin 10148 1801 Italy 1803 Email: enrico.marocco@telecomitalia.it 1804 Christer Holmberg 1805 Ericsson 1806 Hirsalantie 11 1807 Jorvas 02420 1808 Finland 1810 Email: christer.holmberg@ericsson.com