idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-17.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 21, 2018) is 2135 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 1627, but not defined == Unused Reference: 'RFC8085' is defined on line 1960, but no explicit reference was found in the text == Unused Reference: 'RFC3725' is defined on line 1974, but no explicit reference was found in the text == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-20 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-52 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft Jitsi 4 Intended status: Standards Track T. Stach 5 Expires: December 23, 2018 Unaffiliated 6 E. Marocco 7 Telecom Italia 8 C. Holmberg 9 Ericsson 10 June 21, 2018 12 A Session Initiation Protocol (SIP) Usage for Incremental Provisioning 13 of Candidates for the Interactive Connectivity Establishment (Trickle 14 ICE) 15 draft-ietf-mmusic-trickle-ice-sip-17 17 Abstract 19 The Interactive Connectivity Establishment (ICE) protocol describes a 20 Network Address Translator (NAT) traversal mechanism for UDP-based 21 multimedia sessions established with the Offer/Answer model. The ICE 22 extension for Incremental Provisioning of Candidates (Trickle ICE) 23 defines a mechanism that allows ICE Agents to shorten session 24 establishment delays by making the candidate gathering and 25 connectivity checking phases of ICE non-blocking and by executing 26 them in parallel. 28 This document defines usage semantics for Trickle ICE with the 29 Session Initiation Protocol (SIP). The document also defines a new 30 SIP Info Package to support this usage together with the 31 corresponding media type. Additionally, a new SDP 'end-of- 32 candidates' attribute and a new SIP Option Tag 'trickle-ice' are 33 defined. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on December 23, 2018. 51 Copyright Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Discovery issues . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Relationship with the Offer/Answer Model . . . . . . . . 6 73 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 7 74 4.1. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8 75 4.1.1. Sending the Initial Offer . . . . . . . . . . . . . . 8 76 4.1.2. Receiving the Initial Offer . . . . . . . . . . . . . 9 77 4.1.3. Sending the Initial Answer . . . . . . . . . . . . . 9 78 4.1.4. Receiving the Initial Answer . . . . . . . . . . . . 10 79 4.2. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10 80 4.3. Establishing the Dialog . . . . . . . . . . . . . . . . . 10 81 4.3.1. Establishing Dialog State through Reliable 82 Offer/Answer Delivery . . . . . . . . . . . . . . . . 11 83 4.3.2. Establishing Dialog State through Unreliable 84 Offer/Answer Delivery . . . . . . . . . . . . . . . . 12 85 4.3.3. Initiating Trickle ICE without an SDP Answer . . . . 14 86 4.4. Delivering Candidates in INFO Requests . . . . . . . . . 16 87 5. Initial Discovery of Trickle ICE Support . . . . . . . . . . 20 88 5.1. Provisioning Support for Trickle ICE . . . . . . . . . . 20 89 5.2. Trickle ICE Discovery with Globally Routable User Agent 90 URIs (GRUU) . . . . . . . . . . . . . . . . . . . . . . . 20 91 5.3. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 21 92 6. Considerations for RTP and RTCP Multiplexing . . . . . . . . 23 93 7. Considerations for Media Multiplexing . . . . . . . . . . . . 26 94 8. SDP 'end-of-candidates' Attribute . . . . . . . . . . . . . . 28 95 8.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 28 96 8.2. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 29 98 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 29 99 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 29 100 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 29 101 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 32 102 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 32 103 10.2. Overall Description . . . . . . . . . . . . . . . . . . 33 104 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 33 105 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 34 106 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 34 107 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 34 108 10.7. Info Request Body Parts . . . . . . . . . . . . . . . . 34 109 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 34 110 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 34 111 10.10. Info Package Security Considerations . . . . . . . . . . 35 112 11. Deployment Considerations . . . . . . . . . . . . . . . . . . 35 113 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 114 12.1. SDP 'end-of-candidates' Attribute . . . . . . . . . . . 35 115 12.2. Media Type 'application/trickle-ice-sdpfrag' . . . . . . 36 116 12.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 38 117 12.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 38 118 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 119 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 120 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 121 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 122 16.1. Normative References . . . . . . . . . . . . . . . . . . 43 123 16.2. Informative References . . . . . . . . . . . . . . . . . 46 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 126 1. Introduction 128 The Interactive Connectivity Establishment (ICE) protocol 129 [I-D.ietf-ice-rfc5245bis] describes a mechanism for Network Address 130 Translator (NAT) traversal that consists of three main phases. 132 During the first phase an agent gathers a set of candidate transport 133 addresses (source IP address, port and transport protocol). This is 134 followed by a second phase where these candidates are sent to a 135 remote agent within the Session Description Protocol (SDP) body of a 136 SIP message. At the remote agent the gathering procedure is repeated 137 and candidates are sent to the first agent. Once the candidate 138 information is available, a third phase starts in parallel where 139 connectivity between all candidates in both sets is checked 140 (connectivity checks). Once these phases have been completed, and 141 only then, both agents can begin communication. 143 According to [I-D.ietf-ice-rfc5245bis] the three phases above happen 144 consecutively, in a blocking way, which can introduce undesirable 145 setup delay during session establishment. The Trickle ICE extension 147 [I-D.ietf-ice-trickle] defines generic semantics required for these 148 ICE phases to happen in a parallel, non-blocking way and hence speed 149 up session establishment. 151 This specification defines a usage of Trickle ICE with the Session 152 Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates 153 are to be exchanged incrementally using SIP INFO requests [RFC6086] 154 and how the Half Trickle and Full Trickle modes defined in 155 [I-D.ietf-ice-trickle] are to be used by SIP User Agents (UAs) 156 depending on their expectations for support of Trickle ICE by a 157 remote agent. 159 This document defines a new Info Package as specified in [RFC6086] 160 for use with Trickle ICE together with the corresponding media type, 161 SDP attribute and SIP option tag. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119], [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 This specification makes use of terminology defined by the protocol 172 for Interactive Connectivity Establishment in 173 [I-D.ietf-ice-rfc5245bis] and its Trickle ICE extension 174 [I-D.ietf-ice-trickle]. It is assumed that the reader is familiar 175 with the terminology from both documents. 177 [I-D.ietf-ice-rfc5245bis] also describes how ICE makes use of the 178 Session Traversal Utilities for NAT (STUN) protocol [RFC5389] and its 179 extension Traversal Using Relay NAT (TURN) [RFC5766]. 181 3. Protocol Overview 183 When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the 184 ICE candidates are exchanged solely via SDP Offer/Answer as per 185 [RFC3264]. This specification defines an additional mechanism where 186 candidates can be exchanged using SIP INFO messages and a newly 187 defined Info Package [RFC6086]. This allows ICE candidates also to 188 be sent in parallel to an ongoing Offer/Answer negotiation and/or 189 after the completion of the Offer/Answer negotiation. 191 Typically, in cases where Trickle ICE is fully supported, the Offerer 192 sends an INVITE request containing a subset of candidates. Once an 193 early dialog is established the Offerer can continue sending 194 candidates in INFO requests within that dialog. 196 Similarly, an Answerer can send ICE candidates using INFO requests 197 within the dialog established by its 18x provisional response. 198 Figure 1 shows such a sample exchange: 200 STUN/Turn STUN/TURN 201 Servers Alice Bob Servers 202 | | | | 203 | STUN Bi.Req. | INVITE (Offer) | | 204 |<--------------|------------------------>| | 205 | | 183 (Answer) | TURN Alloc Req | 206 | STUN Bi.Resp. |<------------------------|--------------->| 207 |-------------->| INFO/OK (SRFLX Cand.) | | 208 | |------------------------>| TURN Alloc Resp| 209 | | INFO/OK (Relay Cand.) |<---------------| 210 | |<------------------------| | 211 | | | | 212 | | More Cands & ConnChecks| | 213 | |<=======================>| | 214 | | | | 215 | | 200 OK | | 216 | |<------------------------| | 217 | | ACK | | 218 | |------------------------>| | 219 | | | | 220 | |<===== MEDIA FLOWS =====>| | 221 | | | | 223 Note: SRFLX denotes server-reflexive candidates 225 Figure 1: Sample Trickle ICE scenario with SIP 227 3.1. Discovery issues 229 In order to benefit from Trickle ICE's full potential and reduce 230 session establishment latency to a minimum, Trickle ICE agents need 231 to generate SDP Offers and Answers that contain incomplete, 232 potentially empty sets of candidates. Such Offers and Answers can 233 only be handled meaningfully by agents that actually support 234 incremental candidate provisioning, which implies the need to confirm 235 such support before using it. 237 Contrary to other protocols, where "in advance" capability discovery 238 is widely implemented, the mechanisms that allow this for SIP (i.e., 239 a combination of UA Capabilities [RFC3840] and Globally Routable User 240 Agent URIs (GRUU) [RFC5627]) have only seen low levels of adoption. 241 This presents an issue for Trickle ICE implementations as SIP UAs do 242 not have an obvious means of verifying that their peer will support 243 incremental candidate provisioning. 245 The Half Trickle mode of operation defined in the Trickle ICE 246 specification [I-D.ietf-ice-trickle] provides one way around this, by 247 requiring the first Offer to contain a complete set of local ICE 248 candidates and only using incremental provisioning of remote 249 candidates for the rest of the session. 251 While using Half Trickle does provide a working solution it also 252 comes at the price of increased latency. Section 5 therefore makes 253 several alternative suggestions that enable SIP UAs to engage in Full 254 Trickle right from their first Offer: Section 5.1 discusses the use 255 of on-line provisioning as a means of allowing use of Trickle ICE for 256 all endpoints in controlled environments. Section 5.2 describes 257 anticipatory discovery for implementations that actually do support 258 GRUU and UA Capabilities and Section 5.3 discusses the implementation 259 and use of Half Trickle by SIP UAs where none of the above are an 260 option. 262 3.2. Relationship with the Offer/Answer Model 264 From the perspective of SIP middle boxes and proxies the Offer/Answer 265 exchange for Trickle ICE looks partly similar to the Offer/Answer 266 exchange for regular ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. 267 However, in order to have the full picture of the candidate exchange, 268 the newly introduced INFO messages need to be considered as well. 270 +-------------------------------+ +-------------------------------+ 271 | Alice +--------------+ | | +--------------+ Bob | 272 | | Offer/Answer | | | | Offer/Answer | | 273 | +--------+ | Module | | | | Module | +--------+ | 274 | | ICE | +--------------+ | | +--------------+ | ICE | | 275 | | Module | | | | | | Module | | 276 | +--------+ | | | | +--------+ | 277 +-------------------------------+ +-------------------------------+ 278 | | | | 279 | | INVITE (Offer) | | 280 | |--------------------->| | 281 | | 183 (Answer) | | 282 | |<---------------------| | 283 | | | | 284 | | 285 | SIP INFO (more candidates) | 286 |----------------------------------------------------->| 287 | SIP INFO (more candidates) | 288 |<-----------------------------------------------------| 289 | | 290 | STUN Binding Requests/Responses | 291 |----------------------------------------------------->| 292 | STUN Binding Requests/Responses | 293 |<-----------------------------------------------------| 294 | | 296 Figure 2: Distinguishing between Trickle ICE and traditional 297 signaling. 299 From an architectural viewpoint, as displayed in Figure 2, exchanging 300 candidates through SIP INFO requests could be represented as 301 signaling between ICE modules and not between Offer/Answer modules of 302 SIP User Agents. Then, such INFO requests do not impact the state of 303 the Offer/Answer transaction other than providing additional 304 candidates. Consequently, INFO requests are not considered Offers or 305 Answers. Nevertheless, candidates that have been exchanged using 306 INFO requests SHALL be included in subsequent Offers or Answers. The 307 version number in the "o=" line of that subsequent Offer needs to be 308 incremented by 1 per the rules in [RFC3264]. 310 4. Incremental Signaling of ICE candidates 312 Trickle ICE Agents will exchange ICE descriptions compliant to 313 [I-D.ietf-ice-trickle] via Offer/Answer procedures and/or INFO 314 request bodies. This requires the following SIP-specific extensions: 316 1. Trickle ICE Agents MUST indicate support for Trickle ICE by 317 including the SIP option-tag 'trickle-ice' in a SIP Supported: 318 header field within all SIP INVITE requests and responses. 320 2. Trickle ICE Agents MUST indicate support for Trickle ICE by 321 including the ice-option 'trickle' within all SDP Offers and 322 Answers in accordance to [I-D.ietf-ice-trickle]. 324 3. Trickle ICE Agents MAY include any number of ICE candidates, i.e. 325 from zero to the complete set of candidates, in their initial 326 Offer or Answer. If the complete candidate set is included 327 already in the initial Offer, this is called Half-Trickle. 329 4. Trickle ICE Agents MAY exchange additional ICE candidates using 330 INFO requests within an existing INVITE dialog usage (including 331 an early dialog) as specified in [RFC6086]. The INFO requests 332 carry an Info-Package: trickle-ice. Trickle ICE Agents MUST be 333 prepared to receive INFO requests within that same dialog usage, 334 containing additional candidates and/or an indication that 335 trickling of such candidates has ended. 337 5. Trickle ICE Agents MAY exchange additional ICE candidates before 338 the Answerer has sent the Answer provided that an invite dialog 339 usage is established at both Trickle ICE Agents. Note that in 340 case of forking multiple early dialogs may exist. 342 The following sections provide further details on how Trickle ICE 343 Agents perform the initial Offer/Answer exchange (Section 4.1), 344 perform subsequent Offer/Answer exchanges (Section 4.2) and establish 345 the INVITE dialog usage (Section 4.3) such that they can 346 incrementally trickle candidates (Section 4.4). 348 4.1. Initial Offer/Answer Exchange 350 4.1.1. Sending the Initial Offer 352 If the Offerer includes candidates in its initial Offer, it MUST 353 encode these candidates as specified in 354 [I-D.ietf-mmusic-ice-sip-sdp]. 356 If the Offerer wants to send its initial Offer before knowing any 357 candidate for one or more media descriptions, it MUST set the port to 358 the default value '9' for these media descriptions. If the Offerer 359 does not want to include the host IP address in the corresponding 360 c-line, e.g. due to privacy reasons, it SHOULD include a default 361 address in the c-line, which is set to the IPv4 address 0.0.0.0 or to 362 the IPv6 equivalent ::. 364 In this case, the Offerer obviously cannot know the RTCP transport 365 address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. 366 This avoids potential ICE mismatch (see 367 [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. 369 If the Offerer wants to use RTCP multiplexing [RFC5761] and/or 370 exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still 371 will include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in 372 the initial Offer. 374 In any case, the Offerer MUST include the attribute "a=ice- 375 options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST 376 include in each "m="-line a "a=mid:" attribute in accordance to 377 [RFC5888]. The "a=mid:" attribute identifies the "m="-line to which 378 a candidate belongs and helps in case of multiple "m="-lines, when 379 candidates gathering could occur in a order different from the order 380 of the "m="-lines. 382 4.1.2. Receiving the Initial Offer 384 If the initial Offer included candidates, the Answerer uses these 385 candidates to start ICE processing as specified in 386 [I-D.ietf-ice-trickle]. 388 If the initial Offer included the attribute a=ice-options:trickle, 389 the Answerer MUST be prepared for receiving trickled candidates later 390 on. 392 In case of a "m/c=" line with default values none of the eventually 393 trickled candidates will match the default destination. This 394 situation MUST NOT cause an ICE mismatch (see 395 [I-D.ietf-mmusic-ice-sip-sdp]). 397 4.1.3. Sending the Initial Answer 399 If the Answerer includes candidates in its initial Answer, it MUST 400 encode these candidates as specified in 401 [I-D.ietf-mmusic-ice-sip-sdp]. 403 If the Answerer wants to send its initial Answer before knowing any 404 candidate for one or more media descriptions, it MUST set the port to 405 the default value '9' for these media descriptions. If the Answerer 406 does not want to include the host IP address in the corresponding 407 c-line, e.g. due to privacy reasons, it SHOULD include a default 408 address in the c-line, which is set to the IPv4 address 0.0.0.0 or to 409 the IPv6 equivalent ::. 411 In this case, the Answerer obviously cannot know the RTCP transport 412 address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. 413 This avoids potential ICE mismatch (see 414 [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. 416 If the Answerer accepts to use RTCP multiplexing [RFC5761] and/or 417 exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it will 418 include the "a=rtcp-mux" attribute in the initial Answer. 420 In any case, the Answerer MUST include the attribute "a=ice- 421 options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST 422 include in each "m="-line a "a=mid:" attribute in accordance to 423 [RFC5888]. 425 4.1.4. Receiving the Initial Answer 427 If the initial Answer included candidates, the Offerer uses these 428 candidates to start ICE processing as specified in 429 [I-D.ietf-ice-trickle]. 431 In case of a "m/c=" line with default values none of the eventually 432 trickled candidates will match the default destination. This 433 situation MUST NOT cause an ICE mismatch (see 434 [I-D.ietf-mmusic-ice-sip-sdp]). 436 4.2. Subsequent Offer/Answer Exchanges 438 Subsequent Offer/Answer exchanges are handled as for regular ICE (see 439 section 4.2 of [I-D.ietf-mmusic-ice-sip-sdp]). 441 If an Offer or Answer needs to be sent while the ICE agents are in 442 the middle of trickling section 3.2 of [I-D.ietf-mmusic-ice-sip-sdp]) 443 applies. This means that an ICE agent includes candidate attributes 444 for all local candidates it had trickled previously for a specific 445 media stream. 447 [RFC EDITOR NOTE: The section 3.2 in above sentence is correct for 448 version 20 of said I-D. Authors need to cross-check during Auth48 449 since it could have have changed in the meantime.] 451 4.3. Establishing the Dialog 453 In order to be able to start trickling, the following two conditions 454 need to be satisfied at the SIP UAs: 456 o Trickle ICE support at the peer agent MUST be confirmed. 458 o A dialog MUST have been created between the peers. 460 Section 5 discusses in detail the various options for satisfying the 461 first of the above conditions. Regardless of those mechanisms, 462 however, agents are certain to have a clear understanding of whether 463 their peers support trickle ICE once an Offer and an Answer have been 464 exchanged, which also allows for ICE processing to commence (see 465 Figure 3). 467 4.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery 469 Alice Bob 470 | | 471 | INVITE (Offer) | 472 |------------------------>| 473 | 183 (Answer) | 474 |<------------------------| 475 | PRACK/OK | 476 |------------------------>| 477 | | 478 +----------------------------------------+ 479 |Alice and Bob know that both can trickle| 480 |and know that the dialog is in the early| 481 |state. Send INFO! | 482 +----------------------------------------+ 483 | | 484 | INFO/OK (+SRFLX Cand.) | 485 |------------------------>| 486 | INFO/OK (+SRFLX Cand.) | 487 |<------------------------| 488 | | 490 Note: SRFLX denotes server-reflexive candidates 492 Figure 3: SIP Offerer can freely trickle as soon as it receives an 493 Answer. 495 As shown in Figure 3 satisfying both conditions is relatively trivial 496 for ICE Agents that have sent an Offer in an INVITE and that have 497 received an Answer in a reliable provisional response. It is 498 guaranteed to have confirmed support for Trickle ICE at the Answerer 499 (or lack thereof) and to have fully initialized the SIP dialog at 500 both ends. Offerers and Answerers (after receipt of the PRACK 501 request) in the above situation can therefore freely commence 502 trickling within the newly established dialog. 504 4.3.2. Establishing Dialog State through Unreliable Offer/Answer 505 Delivery 507 The situation is a bit more delicate for agents that have received an 508 Offer in an INVITE request and have sent an Answer in an unreliable 509 provisional response because, once the response has been sent, the 510 Answerer does not know when or if it has been received (Figure 4). 512 Alice Bob 513 | | 514 | INVITE (Offer) | 515 |------------------------>| 516 | 183 (Answer) | 517 |<------------------------| 518 | | 519 | +----------------------+ 520 | |Bob: I don't know if | 521 | |Alice got my 183 or if| 522 | |her dialog is already | 523 | |in the early state. | 524 | | Can I send INFO??? | 525 | +----------------------+ 526 | | 528 Figure 4: A SIP UA that sent an Answer in an unreliable provisional 529 response does not know if it was received and if the dialog at the 530 side of the Offerer has entered the early state 532 In order to clear this ambiguity as soon as possible, the Answerer 533 needs to retransmit the provisional response with the exponential 534 back-off timers described in [RFC3262]. These retransmissions MUST 535 cease on receipt of an INFO request carrying a 'trickle-ice' Info 536 Package body, on receipt of any other in-dialog request from the 537 offerer or on transmission of the Answer in a 2xx response. The 538 offerer cannot send in-dialog requests until it receives a response, 539 so the arrival of such a request proves that the response has 540 arrived. Using the INFO request for dialog confirmation is similar 541 to the procedure described in section 6.1.1 of 542 [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding Request is 543 replaced by the INFO request. 545 [RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for 546 version 20 of said I-D. Authors need to cross-check during Auth48 547 since it could have have changed in the meantime.] 549 The Offerer MUST send a Trickle ICE INFO request as soon as it 550 receives an SDP Answer in an unreliable provisional response. This 551 INFO request MUST repeat the candidates that were already provided in 552 the Offer (as would be the case when Half Trickle is performed or 553 when new candidates have not been learned since then). The first 554 case could happen when Half Trickle is used and all candidate are 555 already in the initial offer. The second case could happen when Full 556 Trickle is used and the offerer is currently gathering additional 557 candidates, but did not yet get them. Also, if the initial Offer did 558 not contain any candidates, depending on how the Offerer gathers its 559 candidates and how long it takes to do so, this INFO could still 560 contain no candidates. 562 When Full Trickle is used and if newly learned candidates are 563 available, the Offerer SHOULD also deliver these candidates in said 564 INFO request, unless it wants to hold back some candidates in 565 reserve, e.g. in case that these candidates are expensive to use and 566 would only be trickled if all other candidates failed. 568 The Offerer SHOULD include an end-of-candidates attribute in case 569 candidate discovery has ended in the mean time and no further 570 candidates are to be trickled. 572 As soon as an Answerer has received such an INFO request, the 573 Answerer has an indication that a dialog is established at both ends 574 and can begin trickling (Figure 5). 576 Note: The +SRFLX in Figure 5 indicates that additionally newly 577 learned server-reflexive candidates are included. 579 Alice Bob 580 | | 581 | INVITE (Offer) | 582 |------------------------>| 583 | 183 (Answer) | 584 |<------------------------| 585 | INFO/OK (+SRFLX Cand.) | 586 |------------------------>| 587 | | 588 | +----------------------+ 589 | |Bob: Now I know Alice| 590 | | is ready. Send INFO! | 591 | +----------------------+ 592 | INFO/OK (+SRFLX Cand.) | 593 |<------------------------| 594 | | 595 | 200/ACK (Answer) | 596 |<------------------------| 598 Note: SRFLX denotes server-reflexive candidates 600 Figure 5: A SIP UA that received an INFO request after sending an 601 unreliable provisional response knows that the dialog at the side of 602 the receiver has entered the early state 604 When sending the Answer in the 200 OK response to the INVITE request, 605 the Answerer needs to repeat exactly the same Answer that was 606 previously sent in the unreliable provisional response in order to 607 fulfill the corresponding requirements in [RFC3264]. Thus, the 608 Offerer needs to be prepared for receiving a different number of 609 candidates in that repeated Answer than previously exchanged via 610 trickling and MUST ignore the candidate information in that 200 OK 611 response. 613 4.3.3. Initiating Trickle ICE without an SDP Answer 615 The ability to convey arbitrary candidates in INFO message bodies 616 allows ICE Agents to initiate trickling without actually sending an 617 Answer. Trickle ICE Agents can therefore respond to an INVITE 618 request with provisional responses without an SDP Answer [RFC3261]. 619 Such provisional responses serve for establishing an early dialog. 621 Agents that choose to establish the dialog in this way, MUST 622 retransmit these responses with the exponential back-off timers 623 described in [RFC3262]. These retransmissions MUST cease on receipt 624 of an INFO request carrying a 'trickle-ice' Info Package body, on 625 receipt any in-dialog request from the offerer or on transmission of 626 the Answer in a 2xx response. The offerer cannot send in-dialog 627 requests until it receives a response, so the arrival of such a 628 request proves that the response has arrived. This is again similar 629 to the procedure described in section 6.1.1 of 630 [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is not yet 631 provided. 633 [RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for 634 version 20 of said I-D. Authors need to cross-check during Auth48 635 since it could have have changed in the meantime.] 637 Note: The +SRFLX in Figure 6 indicates that additionally newly 638 learned server-reflexive candidates are included. 640 Alice Bob 641 | | 642 | INVITE (Offer) | 643 |------------------------>| 644 | 183 (-) | 645 |<------------------------| 646 | INFO/OK (SRFLX Cand.) | 647 |------------------------>| 648 | | 649 | +----------------------+ 650 | |Bob: Now I know again| 651 | | that Alice is ready. | 652 | | Send INFO! | 653 | +----------------------+ 654 | INFO/OK (SRFLX Cand.) | 655 |<------------------------| 656 | 183 (Answer) opt. | 657 |<------------------------| 658 | INFO/OK (SRFLX Cand.) | 659 |<------------------------| 660 | 200/ACK (Answer) | 661 |<------------------------| 663 Note: SRFLX denotes server-reflexive candidates 665 Figure 6: A SIP UA sends an unreliable provisional response without 666 an Answer for establishing an early dialog 668 When sending the Answer, the agent MUST repeat all currently known 669 and used candidates, if any, and MAY include all newly gathered 670 candidates since the last INFO request was sent. However, if that 671 Answer was already sent in a unreliable provisional response, the 672 Answerers MUST repeat exactly the same Answer in the 200 OK response 673 to the INVITE request in order to fulfill the corresponding 674 requirements in [RFC3264]. In case that trickling continued, an 675 Offerer needs to be prepared for receiving fewer candidates in that 676 repeated Answer than previously exchanged via trickling and MUST 677 ignore the candidate information in that 200 OK response. 679 4.4. Delivering Candidates in INFO Requests 681 Whenever new ICE candidates become available for sending, agents 682 encode them in "a=candidate:" attributes as described by 683 [I-D.ietf-mmusic-ice-sip-sdp]. For example: 685 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx 686 raddr 2001:db8:a0b:12f0::1 rport 8998 688 The use of SIP INFO requests happens within the context of the Info 689 Package as defined Section 10. The Media Type [RFC6838] for their 690 payload MUST be set to 'application/trickle-ice-sdpfrag' as defined 691 in Section 9. The Info request body adheres to the grammar as 692 specified in Section 9.2. 694 Since neither the "a=candidate:" nor the "a=end-of-candidates" 695 attributes contain information that would allow correlating them to a 696 specific "m=" line, this is handled through the use of pseudo "m=" 697 lines. 699 Pseudo "m=" lines follow the SDP syntax for "m=" lines as defined in 700 [RFC4566] and are linked to the corresponding "m=" line in the SDP 701 Offer or Answer via the identification tag in a "a=mid:" attribute 702 [RFC5888]. A pseudo "m=" line does not provide semantics other than 703 indicating to which "m=" line a candidate belongs. Consequently, the 704 receiving agent MUST ignore any remaining content of the pseudo "m=" 705 line, which is not defined in this document. This guarantees that 706 the 'application/trickle-ice-sdpfrag' bodies do not interfere with 707 the Offer/Answer procedures as specified in [RFC3264]. 709 When sending the INFO request, the agent MAY, if already known to the 710 agent, include the same content into the pseudo "m=" line as for the 711 "m=" line in the corresponding Offer or Answer. However, since 712 Trickle-ICE might be decoupled from the Offer/Answer negotiation this 713 content might be unknown to the agent. In this case, the agent MUST 714 include the following default values. 716 o The media field is set to 'audio'. 718 o The port value is set to '9'. 720 o The proto value is set to 'RTP/AVP'. 722 o The fmt field MUST appear only once and is set to '0' 724 Agents MUST include a pseudo "m=" line and an identification tag in a 725 "a=mid:" attribute for every "m=" line whose candidate list they 726 intend to update. Such "a=mid:" attributes MUST immediately precede 727 the list of candidates for that specific "m=" line. 729 All "a=candidate:" or "a=end-of-candidates" attributes following an 730 "a=mid:" attribute, up until (and excluding) the next occurrence of a 731 pseudo "m=" line, pertain to the "m=" line identified by that 732 identification tag. 734 Note, that there is no requirement that the Info request body 735 contains as many pseudo m= lines as the Offer/Answer contains 736 m=lines, nor that the pseudo m= lines be in the same order as the 737 m=lines that they pertain to. The correspondence can be made via the 738 "a=mid:" attributes since candidates are grouped in sections headed 739 by "pseudo" m=lines. These sections contain "a=mid:" attribute 740 values which point back to the true m=line. 742 An "a=end-of-candidates" attribute, preceding the first pseudo "m=" 743 line, indicates the end of all trickling from that agent, as opposed 744 to end of trickling for a specific "m=" line, which would be 745 indicated by a media level "a=end-of-candidates" attribute. 747 Refer to Figure 7 for an example of the INFO request content. 749 The use of pseudo "m=" lines allows for a structure similar to the 750 one in SDP Offers and Answers where separate media-level and session- 751 level sections can be distinguished. In the current case, lines 752 preceding the first pseudo "m=" line are considered to be session- 753 level. Lines appearing in between or after pseudo "m=" lines will be 754 interpreted as media-level. 756 Note that while this specification uses the "a=mid:" attribute 757 from [RFC5888], it does not define any grouping semantics. 759 All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" 760 attributes that allow mapping them to a specific ICE generation. An 761 agent MUST discard any received INFO requests containing "a=ice-pwd:" 762 and "a=ice-ufrag:" attributes that do not match those of the current 763 ICE Negotiation Session. 765 The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the 766 same level as the ones in the Offer/Answer exchange. In other words, 767 if they were present as session-level attributes, they will also 768 appear at the beginning of all INFO request payloads, i.e. preceding 769 the first pseudo "m=" line. If they were originally exchanged as 770 media level attributes, potentially overriding session-level values, 771 then they will also be included in INFO request payloads following 772 the corresponding pseudo "m=" lines. 774 Note that [I-D.ietf-ice-trickle] requires that when candidates are 775 trickled, each candidate must be delivered to the receiving Trickle 776 ICE implementation not more than once and in the same order as it was 777 conveyed. If the signaling protocol provides any candidate 778 retransmissions, they need to be hidden from the ICE implementation. 779 This requirement is fulfilled as follows. 781 Since the agent is not fully aware of the state of the ICE 782 Negotiation Session at its peer it MUST include all currently known 783 and used local candidates in every INFO request. I.e. the agent MUST 784 repeat in the INFO request body all candidates that were previously 785 sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in 786 the same order as they were sent before. In other words, the 787 sequence of a previously sent list of candidates MUST NOT change in 788 subsequent INFO requests and newly gathered candidates MUST be added 789 at the end of that list. Although repeating all candidates creates 790 some overhead, it also allows easier handling of problems that could 791 arise from unreliable transports, like e.g. loss of messages and 792 reordering, which can be detected through the CSeq: header field in 793 the INFO request. 795 In addition, an ICE agent needs to adhere to section 17 of 796 [I-D.ietf-ice-trickle] on preserving candidate order while trickling. 798 When receiving INFO requests carrying any candidates, agents MUST 799 therefore first identify and discard the attribute lines containing 800 candidates they have already received in previous INFO requests or in 801 the Offer/Answer exchange preceding them. 803 Such candidates are considered to be equal if their IP address port, 804 transport and component ID are the same. After identifying and 805 discarding the known candidates, the agents MUST forward the actually 806 new candidates to the ICE Agents in the same order as they were 807 received in the INFO request body. The ICE Agents will then process 808 the new candidates according to the rules described in 809 [I-D.ietf-ice-trickle]. 811 Receiving an "a=end-of-candidates" attribute in an INFO request body 812 - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the 813 current ICE generation - is an indication from the peer agent that it 814 will not send any further candidates. When included at session 815 level, i.e. before any pseudo "m=" line, this indication applies to 816 the whole session; when included at media level the indication 817 applies only to the corresponding "m=" line. Handling of such end- 818 of-candidates indications is defined in [I-D.ietf-ice-trickle]. 820 The example in Figure 7 shows the content of a candidate delivering 821 INFO request. In the example the "a=end-of-candidates" attributes 822 indicate that the candidate gathering is finished and that no further 823 INFO requests follow. 825 INFO sip:alice@example.com SIP/2.0 826 ... 827 Info-Package: trickle-ice 828 Content-type: application/trickle-ice-sdpfrag 829 Content-Disposition: Info-Package 830 Content-length: 862 832 a=ice-pwd:asd88fgpdd777uzjYhagZg 833 a=ice-ufrag:8hhY 834 m=audio 9 RTP/AVP 0 835 a=mid:1 836 a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host 837 a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host 838 a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host 839 a=candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host 840 a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx 841 raddr 192.0.2.1 rport 8998 842 a=candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx 843 raddr 192.0.2.1 rport 8998 844 a=end-of-candidates 845 m=audio 9 RTP/AVP 0 846 a=mid:2 847 a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host 848 a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host 849 a=candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host 850 a=candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host 851 a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx 852 raddr 192.0.2.1 rport 9998 853 a=candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx 854 raddr 192.0.2.1 rport 9998 855 a=end-of-candidates 857 Note: In a real INFO request there will be no line breaks 858 in the a=candidate: attributes 860 Figure 7: An Example for the Content of an INFO Request 862 5. Initial Discovery of Trickle ICE Support 864 SIP User Agents (UAs) that support and intend to use trickle ICE are 865 required by [I-D.ietf-ice-trickle] to indicate that in their Offers 866 and Answers using the attribute "a=ice-options:trickle" and MUST 867 include the SIP option-tag "trickle-ice" in a SIP Supported: or 868 Require: header field. This makes discovery fairly straightforward 869 for Answerers or for cases where Offers need to be generated within 870 existing dialogs (i.e., when sending UPDATE or re-INVITE requests). 871 In both scenarios prior SDP bodies will have provided the necessary 872 information. 874 Obviously, such information is not available at the time a first 875 Offer is being constructed and it is therefore impossible for ICE 876 Agents to determine support for incremental provisioning that way. 877 The following options are suggested as ways of addressing this issue. 879 5.1. Provisioning Support for Trickle ICE 881 In certain situations it may be possible for integrators deploying 882 Trickle ICE to know in advance that some or all endpoints reachable 883 from within the deployment will support Trickle ICE. This is the 884 case, for example, if Session Border Controllers (SBC) with support 885 for this specification are used to connect to UAs that do not support 886 Trickle ICE. 888 While the exact mechanism for allowing such provisioning is out of 889 scope here, this specification encourages trickle ICE implementations 890 to allow the option in the way they find most appropriate. 892 However, an Offerer assuming Trickle ICE support MUST include a SIP 893 Require: trickle-ice header field. That way, if the provisioned 894 assumption of Trickle ICE support ends up being incorrect, the 895 failure is (a) operationally easy to track down, and (b) recoverable 896 by the client, i.e., they can re-send the request without the SIP 897 Require: header field and without the assumption of Trickle ICE 898 support. 900 5.2. Trickle ICE Discovery with Globally Routable User Agent URIs 901 (GRUU) 903 [RFC3840] provides a way for SIP User Agents to query for support of 904 specific capabilities using, among others, OPTIONS requests. Support 905 for GRUU according to [RFC5627] on the other hand allows SIP requests 906 to be addressed to specific UAs (as opposed to arbitrary instances of 907 an address of record). Combining the two and using the "trickle-ice" 908 option tag defined in Section 10.6 provides SIP UAs with a way of 909 learning the capabilities of specific SIP UA instances and then 910 addressing them directly with INVITE requests that require Trickle 911 ICE support. 913 Such learning of capabilities may happen in different ways. One 914 option for a SIP UA is to learn the GRUU instance ID of a peer 915 through presence and then to query its capabilities with an OPTIONS 916 request. Alternatively, it can also just send an OPTIONS request to 917 the Address of Record (AOR) it intends to contact and then inspect 918 the returned response(s) for support of both GRUU and Trickle ICE 919 (Figure 8). It is noted that using the GRUU means that the INVITE 920 request can go only to that particular device. This prevents the use 921 of forking for that request. 923 Alice Bob 924 | | 925 | OPTIONS sip:b1@example.com SIP/2.0 | 926 |-------------------------------------------------->| 927 | | 928 | 200 OK | 929 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 930 | ;audio;video|;trickle-ice;... | 931 |<--------------------------------------------------| 932 | | 933 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 934 | Supported: trickle-ice | 935 | (Offer) | 936 |-------------------------------------------------->| 937 | | 938 | 183 (Answer) | 939 |<--------------------------------------------------| 940 | INFO/OK (Trickling) | 941 |<------------------------------------------------->| 942 | | 943 | ... | 944 | | 946 Figure 8: Trickle ICE support discovery with OPTIONS and GRUU 948 Confirming support for Trickle ICE through [RFC3840] gives SIP UAs 949 the options to engage in Full Trickle negotiation (as opposed to the 950 more lengthy Half Trickle) from the very first Offer they send. 952 5.3. Fall-back to Half Trickle 954 In cases where none of the other mechanisms in this section are 955 acceptable, SIP UAs should use the Half Trickle mode defined in 956 [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions 957 the same way they would when using ICE for SIP 958 [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually 959 sending an Offer, agents first gather ICE candidates in a blocking 960 way and then send them all in that Offer. The blocking nature of the 961 process implies that some amount of latency will be accumulated and 962 it is advised that agents try to anticipate it where possible, for 963 example, when user actions indicate a high likelihood for an imminent 964 call (e.g., activity on a keypad or a phone going off-hook). 966 Using Half Trickle results in Offers that are compatible with both 967 ICE SIP endpoints and legacy [RFC3264] endpoints. 969 STUN/Turn STUN/TURN 970 Servers Alice Bob Servers 971 | | | | 972 |<--------------| | | 973 | | | | 974 | | | | 975 | Candidate | | | 976 | | | | 977 | | | | 978 | Discovery | | | 979 | | | | 980 | | | | 981 |-------------->| INVITE (Offer) | | 982 | |---------------------------->| | 983 | | 183 (Answer) |-------------->| 984 | |<----------------------------| | 985 | | INFO (repeated candidates) | | 986 | |---------------------------->| | 987 | | | | 988 | | INFO (more candidates) | Candidate | 989 | |<----------------------------| | 990 | | Connectivity Checks | | 991 | |<===========================>| Discovery | 992 | | INFO (more candidates) | | 993 | |<----------------------------| | 994 | | Connectivity Checks |<--------------| 995 | |<===========================>| | 996 | | | | 997 | | 200 OK | | 998 | |<----------------------------| | 999 | | | | 1000 | |<======= MEDIA FLOWS =======>| | 1001 | | | | 1003 Figure 9: Example - A typical (Half) Trickle ICE exchange with SIP 1005 It is worth reminding that once a single Offer or Answer had been 1006 exchanged within a specific dialog, support for Trickle ICE will have 1007 been determined. No further use of Half Trickle will therefore be 1008 necessary within that same dialog and all subsequent exchanges can 1009 use the Full Trickle mode of operation. 1011 6. Considerations for RTP and RTCP Multiplexing 1013 The following consideration describe options for Trickle-ICE in order 1014 to give some guidance to implementors on how trickling can be 1015 optimized with respect to providing RTCP candidates. 1017 Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" 1018 attribute for RTP/RTCP multiplexing [RFC5761] is already considered 1019 in section 5.1.1.1. of [I-D.ietf-ice-rfc5245bis] and as well in 1020 [RFC5761] itself. These considerations are still valid for Trickle 1021 ICE, however, trickling provides more flexibility for the sequence of 1022 candidate exchange in case of RTCP multiplexing. 1024 [RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct 1025 for version 17 of said I-D. Authors need to cross-check during 1026 Auth48 since it could have have changed in the meantime.] 1028 If the Offerer supports RTP/RTCP multiplexing exclusively as 1029 specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that 1030 document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" 1031 and the "a=rtcp-mux" attributes. 1033 While a Half Trickle Offerer has to send an Offer compliant to 1034 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for 1035 all components, the flexibility of a Full Trickle Offerer allows to 1036 send only RTP candidates (component 1) in the initial Offer assuming 1037 that RTCP multiplexing is supported by the Answerer. A Full Trickle 1038 Offerer would need to start gathering and trickling RTCP candidates 1039 (component 2) only after having received an indication in the Answer 1040 that the Answerer unexpectedly does not support RTCP multiplexing. 1042 A Trickle Answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in 1043 the application/trickle-ice-sdpfrag body if it supports and uses RTP 1044 and RTCP multiplexing. The Trickle Answerer needs to follow the 1045 guidance on the usage of the "a=rtcp" attribute as given in 1046 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]. Receipt of this 1047 attribute at the Offerer in an INFO request prior to the Answer 1048 indicates that the Answerer supports and uses RTP and RTCP 1049 multiplexing. The Offerer can use this information e.g. for stopping 1050 gathering of RTCP candidates and/or for freeing corresponding 1051 resources. 1053 This behavior is illustrated by the following example Offer that 1054 indicates support for RTP and RTCP multiplexing. 1056 v=0 1057 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com 1058 s= 1059 c=IN IP6 2001:db8:a0b:12f0::3 1060 t=0 0 1061 a=ice-pwd:777uzjYhagZgasd88fgpdd 1062 a=ice-ufrag:Yhh8 1063 m=audio 5000 RTP/AVP 0 1064 a=mid:1 1065 a=rtcp-mux 1066 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host 1068 Once the dialog is established as described in section Section 4.3 1069 the Answerer sends the following INFO request. 1071 INFO sip:alice@example.com SIP/2.0 1072 ... 1073 Info-Package: trickle-ice 1074 Content-type: application/trickle-ice-sdpfrag 1075 Content-Disposition: Info-Package 1076 Content-length: 161 1078 a=ice-pwd:asd88fgpdd777uzjYhagZg 1079 a=ice-ufrag:8hhY 1080 m=audio 9 RTP/AVP 0 1081 a=mid:1 1082 a=rtcp-mux 1083 a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host 1085 This INFO request indicates that the Answerer supports and uses RTP 1086 and RTCP multiplexing as well. It allows the Offerer to omit 1087 gathering of RTCP candidates or releasing already gathered RTCP 1088 candidates. If the INFO request did not contain the a=rtcp-mux 1089 attribute, the Offerer has to gather RTCP candidates unless it wants 1090 to wait until receipt of an Answer that eventually confirms support 1091 or non-support for RTP and RTCP multiplexing. In case the Offerer 1092 had sent RTCP candidates in a previous INFO request, it still needs 1093 to repeat them in subsequent INFO requests, even in case that support 1094 for RTCP multiplexing was confirmed by the Answerer and the Offerer 1095 has released its RTCP candidates. 1097 7. Considerations for Media Multiplexing 1099 The following considerations describe options for Trickle-ICE in 1100 order to give some guidance to implementors on how trickling can be 1101 optimized with respect to providing candidates in case of Media 1102 Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed 1103 that the reader is familiar with 1104 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 1106 ICE candidate exchange is already considered in section 11 of 1107 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are 1108 still valid for Trickle ICE, however, trickling provides more 1109 flexibility for the sequence of candidate exchange, especially in 1110 Full Trickle mode. 1112 Except for bundle-only "m=" lines, a Half Trickle Offerer has to send 1113 an Offer with candidates for all bundled "m=" lines. The additional 1114 flexibility, however, allows a Full Trickle Offerer to initially send 1115 only candidates for the "m=" line with the suggested Offerer BUNDLE 1116 address. 1118 On receipt of the Answer, the Offerer will detect if BUNDLE is 1119 supported by the Answerer and if the suggested Offerer BUNDLE address 1120 was selected. In this case, the Offerer does not need to trickle 1121 further candidates for the remaining "m=" lines in a bundle. 1122 However, if BUNDLE is not supported, the Full Trickle Offerer needs 1123 to gather and trickle candidates for the remaining "m=" lines as 1124 necessary. If the Answerer selects an Offerer BUNDLE address 1125 different from the suggested Offerer BUNDLE address, the Full Trickle 1126 Offerer needs to gather and trickle candidates for the "m=" line that 1127 carries the selected Offerer BUNDLE address. 1129 A Trickle Answerer SHOULD include an "a=group:BUNDLE" attribute 1130 [I-D.ietf-mmusic-sdp-bundle-negotiation] at session level in the 1131 application/trickle-ice-sdpfrag body if it supports and uses 1132 bundling. When doing so, the Answerer MUST include all 1133 identification-tags in the same order that is used or will be used in 1134 the Answer. 1136 Receipt of this attribute at the Offerer in an INFO request prior to 1137 the Answer indicates that the Answerer supports and uses bundling. 1138 The Offerer can use this information e.g. for stopping the gathering 1139 of candidates for the remaining "m=" lines in a bundle and/or for 1140 freeing corresponding resources. 1142 This behaviour is illustrated by the following example Offer that 1143 indicates support for Media Multiplexing. 1145 In case the Offerer had sent already candidates for "m="-lines in a 1146 bundle in a previous INFO request, it still needs to repeat them in 1147 subsequent INFO requests, even in case that support for bundling was 1148 confirmed by the Answerer and the Offerer has released no longer 1149 needed candidates. 1151 v=0 1152 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com 1153 s= 1154 c=IN IP6 2001:db8:a0b:12f0::3 1155 t=0 0 1156 a=group:BUNDLE foo bar 1157 a=ice-pwd:777uzjYhagZgasd88fgpdd 1158 a=ice-ufrag:Yhh8 1159 m=audio 10000 RTP/AVP 0 1160 a=mid:foo 1161 a=rtcp-mux 1162 a=rtpmap:0 PCMU/8000 1163 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1164 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host 1165 m=video 10002 RTP/AVP 31 1166 a=mid:bar 1167 a=rtcp-mux 1168 a=rtpmap:31 H261/90000 1169 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1171 The example Offer indicates support for RTP and RTCP multiplexing and 1172 contains a "a=candidate:" attribute only for the "m="-line with the 1173 suggested Offerer bundle address. Once the dialog is established as 1174 described in Section 4.3 the Answerer sends the following INFO 1175 request. 1177 INFO sip:alice@example.com SIP/2.0 1178 ... 1179 Info-Package: trickle-ice 1180 Content-type: application/trickle-ice-sdpfrag 1181 Content-Disposition: Info-Package 1182 Content-length: 219 1184 a=group:BUNDLE foo bar 1185 a=ice-pwd:asd88fgpdd777uzjYhagZg 1186 a=ice-ufrag:8hhY 1187 m=audio 9 RTP/AVP 0 1188 a=mid:foo 1189 a=rtcp-mux 1190 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host 1192 This INFO request indicates that the Answerer supports and uses Media 1193 Multiplexing as well. Note that the Answerer only includes a single 1194 pseudo "m="-line since candidates matching those from the second 1195 "m="-line in the offer are not needed from the Answerer. 1197 The INFO request also indicates that the Answerer accepted the 1198 suggested Offerer Bundle Address. This allows the Offerer to omit 1199 gathering of RTP and RTCP candidates for the other "m=" lines or 1200 releasing already gathered candidates. If the INFO request did not 1201 contain the a=group:BUNDLE attribute, the Offerer has to gather RTP 1202 and RTCP candidates for the other "m=" lines unless it wants to wait 1203 until receipt of an Answer that eventually confirms support or non- 1204 support for Media Multiplexing. 1206 Independent of using Full Trickle or Half Trickle mode, the rules 1207 from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and 1208 Answerer, when putting attributes as specified in Section 9.2 in the 1209 application/trickle-ice-sdpfrag body. 1211 8. SDP 'end-of-candidates' Attribute 1213 8.1. Definition 1215 This section defines a new SDP media-level and session-level 1216 attribute [RFC4566] 'end-of-candidates'. 'end-of-candidates' is a 1217 property attribute [RFC4566], and hence has no value. By including 1218 this attribute in an Offer or Answer the sending agent indicates that 1219 it will not trickle further candidates. When included at session 1220 level this indication applies to the whole session, when included at 1221 media level the indication applies only to the corresponding media 1222 description. 1224 Name: end-of-candidates 1226 Value: N/A 1228 Usage Level: media and session-level 1230 Charset Dependent: no 1232 Mux Category: IDENTICAL 1234 Example: a=end-of-candidates 1236 8.2. Offer/Answer Procedures 1238 The Offerer or Answerer MAY include an "a=end-of-candidates" 1239 attribute in case candidate discovery has ended and no further 1240 candidates are to be trickled. The Offerer or Answerer MUST provide 1241 the "a=end-of-candidates" attribute together with the "a=ice-ufrag" 1242 and "a=ice-pwd" attributes of the current ICE generation as required 1243 by [I-D.ietf-ice-trickle]. When included at session level this 1244 indication applies to the whole session; when included at media level 1245 the indication applies only to the corresponding media description. 1247 Receipt of an "a=end-of-candidates" attribute at an Offerer or 1248 Answerer - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching 1249 the current ICE generation - indicates that gathering of candidates 1250 has ended at the peer, either for the session or only for the 1251 corresponding media description as specified above. The receiving 1252 agent forwards an end-of-candidates indication to the ICE Agent, 1253 which in turn acts as specified in [I-D.ietf-ice-trickle]. 1255 9. Content Type 'application/trickle-ice-sdpfrag' 1257 9.1. Overall Description 1259 A application/trickle-ice-sdpfrag body is used exclusively by the 1260 'trickle-ice' Info Package. Other SDP related applications need to 1261 define their own media type. The INFO request body uses a subset of 1262 the possible SDP lines as defined by the grammar defined in 1263 [RFC4566]. A valid body uses only pseudo "m=" lines and certain 1264 attributes that are needed and/or useful for trickling candidates. 1265 The content adheres to the following grammar. 1267 9.2. Grammar 1269 The grammar of an 'application/trickle-ice-sdpfrag' body is based on 1270 the following ABNF [RFC5234]. It specifies the subset of existing 1271 SDP attributes, that is needed or useful for trickling candidates. 1273 The grammar uses the indicator for case-sensitivity %s as defined in 1274 [RFC7405], but also imports grammars for other SDP attributes that 1275 precede the production of [RFC7405]. A sender SHOULD use lower-case 1276 for attributes from such earlier grammars, but a receiver MUST treat 1277 them case-insensitively. 1279 ; Syntax 1280 trickle-ice-sdpfrag = session-level-fields 1281 pseudo-media-descriptions 1282 session-level-fields = *(session-level-field CRLF) 1284 session-level-field = ice-lite-attribute / 1285 ice-pwd-attribute / 1286 ice-ufrag-attribute / 1287 ice-options-attribute / 1288 ice-pacing-attribute / 1289 end-of-candidates-attribute / 1290 bundle-group-attribute / 1291 extension-attribute-fields 1292 ; for future extensions 1294 ice-lite-attribute = %s"a" "=" ice-lite 1295 ice-pwd-attribute = %s"a" "=" ice-pwd-att 1296 ice-ufrag-attribute = %s"a" "=" ice-ufrag-att 1297 ice-pacing-attribute = %s"a" "=" ice-pacing-att 1298 ice-options-attribute = %s"a" "=" ice-options 1299 end-of-candidates-attribute = %s"a" "=" end-of-candidates 1300 end-of-candidates = %s"end-of-candidates" 1301 bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics 1302 *(SP identification-tag) 1303 bundle-semantics = "BUNDLE" 1304 extension-attribute-fields = attribute-fields 1306 pseudo-media-descriptions = *( media-field 1307 trickle-ice-attribute-fields ) 1308 trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF) 1309 trickle-ice-attribute-field = mid-attribute / 1310 candidate-attributes / 1311 ice-pwd-attribute / 1312 ice-ufrag-attribute / 1313 remote-candidate-attribute / 1314 end-of-candidates-attribute / 1315 rtcp-attribute / 1316 rtcp-mux-attribute / 1317 rtcp-mux-only-attribute / 1318 extension-attribute-fields 1319 ; for future extensions 1321 rtcp-attribute = %s"a" "=" %s"rtcp" 1322 rtcp-mux-attribute = %s"a" "=" %s"rtcp-mux" 1323 rtcp-mux-only-attribute = %s"a" "=" %s"rtcp-mux-only" 1324 candidate-attributes = %s"a" "=" candidate-attribute 1325 remote-candidate-attribute = %s"a" "=" remote-candidate-att 1327 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- 1328 pacing-att, ice-options, candidate-attribute remote-candidate-att 1329 from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute 1330 ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The 1331 "a=rtcp" attribute is defined in [RFC3605], the "a=rtcp-mux" 1332 attribute in [RFC5761] and the "a=rtcp-mux-only" attribute in 1333 [I-D.ietf-mmusic-mux-exclusive]. The latter attributes lack a formal 1334 grammar in their corresponding RFC and are reproduced here. 1336 The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the 1337 same level as the ones in the Offer/Answer exchange. In other words, 1338 if they were present as session-level attributes, they will also 1339 appear at the beginning of all INFO request payloads, i.e. preceding 1340 all pseudo "m=" lines. If they were originally exchanged as media 1341 level attributes, potentially overriding session-level values, then 1342 they will also be included in INFO request payloads following the 1343 corresponding pseudo "m=" lines. 1345 An Agent MUST ignore any received unknown extension-attribute-fields. 1347 10. Info Package 1349 10.1. Rationale - Why INFO? 1351 The decision to use SIP INFO requests as a candidate transport method 1352 is based primarily on their lightweight nature. Once a dialog has 1353 been established, INFO requests can be exchanged both ways with no 1354 restrictions on timing and frequency and no risk of collision. 1356 A critical fact is that the sending of Trickle ICE candidates in one 1357 direction is entirely uncoupled from sending candidates in the other 1358 direction. Thus, the sending of candidates in each direction can be 1359 done by a stream of INFO requests that is not correlated with the 1360 stream of INFO requests in the other direction. And since each INFO 1361 request cumulatively includes the contents of all previous INFO 1362 requests in that direction, ordering between INFO requests need not 1363 be preserved. All of this permits using largely-independent INFO 1364 requests. 1366 Contrarily, UPDATE or other offer/answer mechanisms assume that the 1367 messages in each direction are tightly coupled with messages in the 1368 other direction. Using Offer/Answer and UPDATE requests [RFC3311] 1369 would introduce the following complications: 1371 Blocking of messages: [RFC3264] defines Offer/Answer as a strictly 1372 sequential mechanism. There can only be a maximum of one active 1373 exchange at any point of time. Both sides cannot simultaneously 1374 send Offers nor can they generate multiple Offers prior to 1375 receiving an Answer. Using UPDATE requests for candidate 1376 transport would therefore imply the implementation of a candidate 1377 pool at every agent where candidates can be stored until it is 1378 once again that agent's "turn" to emit an Answer or a new Offer. 1379 Such an approach would introduce non-negligible complexity for no 1380 additional value. 1382 Elevated risk of glare: The sequential nature of Offer/Answer also 1383 makes it impossible for both sides to send Offers simultaneously. 1384 What's worse is that there are no mechanisms in SIP to actually 1385 prevent that. [RFC3261], where the situation of Offers crossing 1386 on the wire is described as "glare", only defines a procedure for 1387 addressing the issue after it has occurred. According to that 1388 procedure both Offers are invalidated and both sides need to retry 1389 the negotiation after a period between 0 and 4 seconds. The high 1390 likelihood for glare to occur and the average two second back-off 1391 intervals implies that the duration of Trickle ICE processing 1392 would not only fail to improve but actually exceed those of 1393 regular ICE. 1395 INFO messages decouple the exchange of candidates from the Offer/ 1396 Answer negotiation and are subject to none of the glare issues 1397 described above, which makes them a very convenient and lightweight 1398 mechanism for asynchronous delivery of candidates. 1400 Using in-dialog INFO messages also provides a way of guaranteeing 1401 that candidates are delivered end-to-end, between the same entities 1402 that are actually in the process of initiating a session. Out-of- 1403 dialog alternatives would have implied requiring support for Globally 1404 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 1405 adoption levels, would have constituted too strong of a constraint to 1406 the adoption of Trickle ICE. 1408 10.2. Overall Description 1410 This specification defines an Info Package for use by SIP User Agents 1411 implementing Trickle ICE. INFO requests carry ICE candidates 1412 discovered after the peer user agents have confirmed mutual support 1413 for Trickle ICE. 1415 10.3. Applicability 1417 The purpose of the ICE protocol is to establish a media path in the 1418 presence of NAT and firewalls. The candidates are transported in 1419 INFO requests and are part of this establishment. 1421 Candidates sent by a Trickle ICE Agent after the Offer, follow the 1422 same signaling path and reach the same entity as the Offer itself. 1424 While it is true that GRUUs can be used to achieve this, one of the 1425 goals of this specification is to allow operation of Trickle ICE in 1426 as many environments as possible including those without GRUU 1427 support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not 1428 satisfy this goal. 1430 10.4. Info Package Name 1432 This document defines a SIP Info Package as per [RFC6086]. The Info 1433 Package token name for this package is "trickle-ice" 1435 10.5. Info Package Parameters 1437 This document does not define any Info Package parameters. 1439 10.6. SIP Option Tags 1441 [RFC6086] allows Info Package specifications to define SIP option- 1442 tags. This specification extends the option-tag construct of the SIP 1443 grammar as follows: 1445 option-tag /= "trickle-ice" 1447 SIP entities that support this specification MUST place the 'trickle- 1448 ice' option-tag in a SIP Supported: or Require: header field within 1449 all SIP INVITE requests and responses. 1451 When responding to, or generating a SIP OPTIONS request a SIP entity 1452 MUST also include the 'trickle-ice' option-tag in a SIP Supported: or 1453 Require: header field. 1455 10.7. Info Request Body Parts 1457 Entities implementing this specification MUST include a payload of 1458 type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 in 1459 SIP INFO requests. The payload is used to convey SDP-encoded ICE 1460 candidates. 1462 10.8. Info Package Usage Restrictions 1464 This document does not define any Info Package Usage Restrictions. 1466 10.9. Rate of INFO Requests 1468 Given that IP addresses may be gathered rapidly a Trickle ICE Agent 1469 with many network interfaces might create a high rate of INFO 1470 requests if every newly detected candidate is trickled individually 1471 without aggregation. An implementation MUST aggregate ICE candidates 1472 in case that an unreliable transport protocol such as UDP is used. A 1473 Trickle ICE agent MUST NOT have more than one INFO request pending at 1474 any one time. When INFO messages are sent over an unreliable 1475 transport, they are retransmitted according to the rules specified in 1476 [RFC3261] section 17.1.2.1." 1478 If the INFO requests are sent on top of TCP, which is probably the 1479 standard way, this is not an issue for the network anymore, but it 1480 can remain one for SIP proxies and other intermediaries forwarding 1481 the SIP INFO messages. Also, an endpoint may not be able to tell 1482 that it has congestion controlled transport all the way. 1484 10.10. Info Package Security Considerations 1486 See Section 13 1488 11. Deployment Considerations 1490 Trickle ICE uses two mechanisms for exchange of candidate 1491 information. This imposes new requirements to certain middleboxes 1492 that are used in some networks, e.g. for monitoring purposes. While 1493 the first mechanism, SDP Offers and Answers, is already used by 1494 regular ICE and is assumed to be supported, the second mechanism, 1495 INFO request bodies, needs to be considered by such middleboxes as 1496 well when trickle ICE is used. Such middleboxes need to make sure 1497 that they remain in the signaling path of the INFO requests and need 1498 to understand the INFO request body. 1500 12. IANA Considerations 1502 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1503 document. ] 1505 12.1. SDP 'end-of-candidates' Attribute 1507 This section defines a new SDP media-level and session-level 1508 attribute [RFC4566] , 'end-of-candidates'. 'end-of-candidates' is a 1509 property attribute [RFC4566] , and hence has no value. 1511 Name: end-of-candidates 1513 Value: N/A 1515 Usage Level: media and session 1517 Charset Dependent: no 1519 Purpose: The sender indicates that it will not trickle 1520 further ICE candidates. 1522 O/A Procedures: RFCXXX defines the detailed 1523 SDP Offer/Answer procedures for 1524 the 'end-of-candidates' attribute. 1526 Mux Category: IDENTICAL 1528 Reference: RFCXXXX 1530 Example: 1532 a=end-of-candidates 1534 12.2. Media Type 'application/trickle-ice-sdpfrag' 1536 This document defines a new Media Type 'application/trickle-ice- 1537 sdpfrag' in accordance with [RFC6838]. 1539 Type name: application 1541 Subtype name: trickle-ice-sdpfrag 1543 Required parameters: None. 1545 Optional parameters: None. 1547 Encoding considerations: 1549 The media contents follow the same rules as SDP, except as 1550 noted in this document. The media contents are text, with the 1551 grammar specified in Section 9.2. 1553 Although the initially defined content of a trickle-ice-sdpfrag 1554 body does only include ASCII characters, UTF-8 encoded content 1555 might be introduced via extension attributes. The "a=charset:" 1556 attribute may be used to signal the presence of other character 1557 sets in certain parts of a trickle-ice-sdpfrag body (see 1558 [RFC4566]). Arbitrary binary content cannot be directly 1559 represented in SDP or a trickle-ice-sdpfrag body. 1561 Security considerations: 1563 See [RFC4566] and RFCXXXX 1565 Interoperability considerations: 1567 See RFCXXXX 1569 Published specification: 1571 See RFCXXXX 1573 Applications which use this Media Type: 1575 Trickle-ICE 1577 Fragment identifier considerations: N/A 1579 Additional information: 1581 Deprecated alias names for this type: N/A 1583 Magic number(s): N/A 1585 File extension(s): N/A 1587 Macintosh File Type Code(s): N/A 1589 Person and email address to contact for further information: 1591 The IESG (iesg@ietf.org) 1593 Intended usage: 1595 Trickle-ICE for SIP as specified in RFCXXXX. 1597 Restrictions on usage: N/A 1599 Author/Change controller: 1601 The IESG (iesg@ietf.org) 1603 Provisional registration? (standards tree only): N/A 1605 12.3. SIP Info Package 'trickle-ice' 1607 This document defines a new SIP Info Package named 'trickle-ice' and 1608 updates the Info Packages Registry with the following entry. 1610 +-------------+-----------+ 1611 | Name | Reference | 1612 +-------------+-----------+ 1613 | trickle-ice | [RFCXXXX] | 1614 | | | 1615 +-------------+-----------+ 1617 12.4. SIP Option Tag 'trickle-ice' 1619 This specification registers a new SIP option tag 'trickle-ice' as 1620 per the guidelines in Section 27.1 of [RFC3261] and updates the 1621 "Option Tags" section of the SIP Parameter Registry with the 1622 following entry: 1624 +-------------+-------------------------------------+-----------+ 1625 | Name | Description | Reference | 1626 +-------------+-------------------------------------+-----------+ 1627 | trickle-ice | This option tag is used to indicate | [RFCXXXX] | 1628 | | that a UA supports and understands | | 1629 | | Trickle-ICE. | | 1630 +-------------+-------------------------------------+-----------+ 1632 13. Security Considerations 1634 The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], 1635 [RFC6086] and [I-D.ietf-ice-trickle] apply. This document clarifies 1636 how the above specifications are used together for trickling 1637 candidates and does not create additional security risks. 1639 The new Info Package 'trickle-ice' and the new Media Type 1640 'application/trickle-ice-sdpfrag' do not introduce additional 1641 security considerations when used in the context of Trickle ICE. 1642 Both are not intended to be used for other applications, so any 1643 security considerations for its use in other contexts is out of the 1644 scope of this document 1646 14. Acknowledgements 1648 The authors like to thank Flemming Andreasen, Ayush Jain, Paul 1649 Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount and Martin 1650 Thomson for reviewing and/or making various suggestions for 1651 improvements and optimizations. 1653 The authors also like to thank Flemming Andreasen for shepherding 1654 this document and Ben Campbell for his AD review and suggestions. In 1655 addition, the author like to thank Benjamin Kaduk, Adam Roach, Mirja 1656 Kuehlewind and Eric Rescorla for their comments and/or text proposals 1657 for improving the document during IESG review. 1659 Many thanks to Dale Worley for Gen-Art review and proposed 1660 enhancements for several sections. 1662 Many thanks to Joerg Ott for TSV-Art review and suggested 1663 improvements. 1665 The authors thank Shawn Emery for Security Directorate review. 1667 15. Change Log 1669 [RFC EDITOR NOTE: Please remove this section when publishing]. 1671 Changes from draft-ietf-mmusic-trickle-ice-sip-01 1673 o Editorial Clean up 1675 o IANA Consideration added 1677 o Security Consideration added 1679 o RTCP and BUNDLE Consideration added with rules for including 1680 "a=rtcp-mux" and "a=group: BUNDLLE" attributes 1682 o 3PCC Consideration added 1683 o Clarified that 18x w/o answer is sufficient to create a dialog 1684 that allows for trickling to start 1686 o Added remaining Info Package definition sections as outlined in 1687 section 10 of [RFC6086] 1689 o Added definition of application/sdpfrag making draft-ivov-mmusic- 1690 sdpfrag obsolete 1692 o Added pseudo m-lines as additional separator in sdpfrag bodies for 1693 Trickle ICE 1695 o Added ABNF for sdp-frag bodies and Trickle-ICE package 1697 Changes from draft-ietf-mmusic-trickle-ice-sip-02 1699 o Removed definition of application/sdpfrag 1701 o Replaced with new type application/trickle-ice-sdpfrag 1703 o RTCP and BUNDLE Consideration enhanced with some examples 1705 o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to 1706 normative reference 1708 o Removed reference to 4566bis 1710 o Addressed review comment from Simon Perreault 1712 Changes from draft-ietf-mmusic-trickle-ice-sip-03 1714 o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis 1715 and draft-ietf-mmusic-ice-sip-sdp 1717 o Corrected Figure 10, credits to Ayush Jain for finding the bug 1719 o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- 1720 ice-sip-sdp 1722 o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- 1723 mux-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive 1725 o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for 1726 the application/trickle-ice-sdpfrag body 1728 Changes from draft-ietf-mmusic-trickle-ice-sip-04 1730 o considered comments from Christer Holmberg 1731 o corrected grammar for INFO package, such that ice-ufrag/pwd are 1732 also allowed on media-level as specified in 1733 [I-D.ietf-mmusic-ice-sip-sdp] 1735 o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] 1737 o Added formal definition for the end-of-candidates attribute 1739 Changes from draft-ietf-mmusic-trickle-ice-sip-05 1741 o considered further comments from Christer Holmberg 1743 o editorial comments on section 3 addressed 1745 o moved section 3.1 to section 10.1 and applied some edits 1747 o replaced the term "previously sent candidates" with "currently 1748 known and used candidates". 1750 Changes from draft-ietf-mmusic-trickle-ice-sip-06 1752 o editorial fixes 1754 o additional text on the content of the INFO messages. 1756 o recommendation on what to do if a previously sent candidate is 1757 unexpectedly missing in a subsequent INFO 1759 o terminology alignment with draft-ietf-ice-trickle-07 1761 Changes from draft-ietf-mmusic-trickle-ice-sip-07 1763 o editorial fixes 1765 o clarification on ordering of candidates for alignment with draft- 1766 ietf-ice-trickle-12 1768 o O/A procedures for end-of-candidates attribute described here 1769 after corresponding procedures have been removed from draft-ietf- 1770 ice-trickle-11 1772 o using IPv6 addresses in examples 1774 Changes from draft-ietf-mmusic-trickle-ice-sip-08 1776 o editorial fixes/clarification based on Flemmings review 1777 o Description of Trickle specifics in O/A procedures for initial O/A 1778 exchange and specification of ICE mismatch exception 1780 Changes from draft-ietf-mmusic-trickle-ice-sip-09 1782 o editorial fixes/correction of references 1784 o adding missing Ref to RFC3605 in section 6, 5th para 1786 o replaced remaining IPv4 adresses with IPv6 1788 o Added text for handling a=rtcp in case of default RTP address 1789 0.0.0.0:9 based on comment from Roman Shpount. 1791 Changes from draft-ietf-mmusic-trickle-ice-sip-10 1793 o editorial fixes due to idnits output 1795 Changes from draft-ietf-mmusic-trickle-ice-sip-11 1797 o addressing comments from Ben Campell's AD review and Christer's 1798 review 1800 o Numerous editorial improvements/corrections 1802 o Added [RFC8174] boiler plate and adapted usage of normative 1803 language 1805 o Clarified terminology ICE modules .vs. ICE agent 1807 o Added more detailed OA procedures 1809 o Corrected default values in m-line and usage of "a=mid:" attribute 1810 explicitly mentioned for offer/answer 1812 o Removed explicit mentioning of XMPP 1814 o Added Deployment Considerations section 1816 o Fixed ref for rfc5245bis 1818 Changes from draft-ietf-mmusic-trickle-ice-sip-12 1820 o addressing comments from Gen-Art review, TSV-Art review and 1821 Security Directorate review 1823 o Numerous editorial improvements/corrections/clarifications 1824 Changes from draft-ietf-mmusic-trickle-ice-sip-13 1826 o added expansions for SDP,GRUU, AOR, STUN, TURN 1828 o some editorial corrections 1830 Changes from draft-ietf-mmusic-trickle-ice-sip-14 1832 Addressing comments from IESG review 1834 o Clarification/enhancement in section 5 and Fig. 10 based on 1835 comments from Benjamin Kaduk 1837 o Clarification on sequence for sending candidates, definition of 1838 pseudo m-lines, usage of a=mid attribute, usage of INFO as ACK for 1839 receipt of 18x based on comments from Eric Rescorla 1841 o Removal of 3PCC Section 3.4, removal of NATted IPv6 addresses, 1842 adding more flexibility to in the grammar, explicit mentioning of 1843 Require: header field, usage of Require: header field in case of 1844 provisioning, text on repetition of candidates in case of RTCP mux 1845 and Bundle, various other editorial improvements/corrections based 1846 on comments from Adam Roach 1848 o Modified text on rate limitation of INFO requests based on 1849 comments of Mirja Kuehlewind, Adam Roach and Roman Shpount 1851 o some editorial corrections 1853 Changes from draft-ietf-mmusic-trickle-ice-sip-15 1855 o Corrections in section 7 on Media Multiplexing 1857 Changes from draft-ietf-mmusic-trickle-ice-sip-16 1859 o some editorial corrections 1861 16. References 1863 16.1. Normative References 1865 [I-D.ietf-ice-rfc5245bis] 1866 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1867 Connectivity Establishment (ICE): A Protocol for Network 1868 Address Translator (NAT) Traversal", draft-ietf-ice- 1869 rfc5245bis-20 (work in progress), March 2018. 1871 [I-D.ietf-ice-trickle] 1872 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 1873 "Trickle ICE: Incremental Provisioning of Candidates for 1874 the Interactive Connectivity Establishment (ICE) 1875 Protocol", draft-ietf-ice-trickle-21 (work in progress), 1876 April 2018. 1878 [I-D.ietf-mmusic-ice-sip-sdp] 1879 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 1880 "Session Description Protocol (SDP) Offer/Answer 1881 procedures for Interactive Connectivity Establishment 1882 (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in 1883 progress), April 2018. 1885 [I-D.ietf-mmusic-mux-exclusive] 1886 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 1887 Multiplexing using SDP", draft-ietf-mmusic-mux- 1888 exclusive-12 (work in progress), May 2017. 1890 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1891 Holmberg, C., Alvestrand, H., and C. Jennings, 1892 "Negotiating Media Multiplexing Using the Session 1893 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1894 negotiation-52 (work in progress), May 2018. 1896 [I-D.ietf-mmusic-sdp-mux-attributes] 1897 Nandakumar, S., "A Framework for SDP Attributes when 1898 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 1899 (work in progress), February 2018. 1901 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1902 Requirement Levels", BCP 14, RFC 2119, 1903 DOI 10.17487/RFC2119, March 1997, 1904 . 1906 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1907 A., Peterson, J., Sparks, R., Handley, M., and E. 1908 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1909 DOI 10.17487/RFC3261, June 2002, 1910 . 1912 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1913 Provisional Responses in Session Initiation Protocol 1914 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1915 . 1917 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1918 with Session Description Protocol (SDP)", RFC 3264, 1919 DOI 10.17487/RFC3264, June 2002, 1920 . 1922 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1923 in Session Description Protocol (SDP)", RFC 3605, 1924 DOI 10.17487/RFC3605, October 2003, 1925 . 1927 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1928 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1929 July 2006, . 1931 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1932 Specifications: ABNF", STD 68, RFC 5234, 1933 DOI 10.17487/RFC5234, January 2008, 1934 . 1936 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1937 Control Packets on a Single Port", RFC 5761, 1938 DOI 10.17487/RFC5761, April 2010, 1939 . 1941 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1942 Protocol (SDP) Grouping Framework", RFC 5888, 1943 DOI 10.17487/RFC5888, June 2010, 1944 . 1946 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1947 Initiation Protocol (SIP) INFO Method and Package 1948 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1949 . 1951 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1952 Specifications and Registration Procedures", BCP 13, 1953 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1954 . 1956 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1957 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1958 . 1960 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1961 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1962 March 2017, . 1964 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1965 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1966 May 2017, . 1968 16.2. Informative References 1970 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1971 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1972 2002, . 1974 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1975 Camarillo, "Best Current Practices for Third Party Call 1976 Control (3pcc) in the Session Initiation Protocol (SIP)", 1977 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 1978 . 1980 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1981 "Indicating User Agent Capabilities in the Session 1982 Initiation Protocol (SIP)", RFC 3840, 1983 DOI 10.17487/RFC3840, August 2004, 1984 . 1986 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1987 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1988 DOI 10.17487/RFC5389, October 2008, 1989 . 1991 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1992 Agent URIs (GRUUs) in the Session Initiation Protocol 1993 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 1994 . 1996 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1997 Relays around NAT (TURN): Relay Extensions to Session 1998 Traversal Utilities for NAT (STUN)", RFC 5766, 1999 DOI 10.17487/RFC5766, April 2010, 2000 . 2002 Authors' Addresses 2004 Emil Ivov 2005 Jitsi 2006 Strasbourg 67000 2007 France 2009 Phone: +33 6 72 81 15 55 2010 Email: emcho@jitsi.org 2011 Thomas Stach 2012 Unaffiliated 2013 Vienna 1130 2014 Austria 2016 Email: thomass.stach@gmail.com 2018 Enrico Marocco 2019 Telecom Italia 2020 Via G. Reiss Romoli, 274 2021 Turin 10148 2022 Italy 2024 Email: enrico.marocco@telecomitalia.it 2026 Christer Holmberg 2027 Ericsson 2028 Hirsalantie 11 2029 Jorvas 02420 2030 Finland 2032 Email: christer.holmberg@ericsson.com