idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-13.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 (February 21, 2018) is 2255 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 1660, but not defined == Outdated reference: A later version (-39) exists of draft-ietf-mmusic-ice-sip-sdp-16 == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-17 == Outdated reference: A later version (-21) exists of draft-ietf-ice-trickle-16 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-48 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 8 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: August 25, 2018 Unaffiliated 6 E. Marocco 7 Telecom Italia 8 C. Holmberg 9 Ericsson 10 February 21, 2018 12 A Session Initiation Protocol (SIP) Usage for Trickle ICE 13 draft-ietf-mmusic-trickle-ice-sip-13 15 Abstract 17 The Interactive Connectivity Establishment (ICE) protocol describes a 18 Network Address Translator (NAT) traversal mechanism for UDP-based 19 multimedia sessions established with the Offer/Answer model. The ICE 20 extension for Incremental Provisioning of Candidates (Trickle ICE) 21 defines a mechanism that allows ICE Agents to shorten session 22 establishment delays by making the candidate gathering and 23 connectivity checking phases of ICE non-blocking and by executing 24 them in parallel. 26 This document defines usage semantics for Trickle ICE with the 27 Session Initiation Protocol (SIP) and defines a new SIP Info Package 28 to support this usage. 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 August 25, 2018. 47 Copyright Notice 49 Copyright (c) 2018 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 . . . . . . . . . . . . 10 75 4.2. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10 76 4.3. Establishing the Dialog . . . . . . . . . . . . . . . . . 10 77 4.3.1. Establishing Dialog State through Reliable 78 Offer/Answer delivery . . . . . . . . . . . . . . . . 11 79 4.3.2. Establishing Dialog State through Unreliable 80 Offer/Answer Delivery . . . . . . . . . . . . . . . . 12 81 4.3.3. Initiating Trickle ICE without an SDP Answer . . . . 14 82 4.3.4. Considerations for Third Party Call Control . . . . . 15 83 4.4. Delivering Candidates in INFO Requests . . . . . . . . . 17 84 5. Initial Discovery of Trickle ICE Support . . . . . . . . . . 22 85 5.1. Provisioning Support for Trickle ICE . . . . . . . . . . 22 86 5.2. Trickle ICE Discovery with Globally Routable User Agent 87 URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 5.3. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 23 89 6. Considerations for RTP and RTCP Multiplexing . . . . . . . . 24 90 7. Considerations for Media Multiplexing . . . . . . . . . . . . 26 91 8. SDP 'end-of-candidates' Attribute . . . . . . . . . . . . . . 29 92 8.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 29 93 8.2. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 30 94 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 30 95 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 30 96 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 32 98 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 32 99 10.2. Overall Description . . . . . . . . . . . . . . . . . . 33 100 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 33 101 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 33 102 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 34 103 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 34 104 10.7. Info Request Body Parts . . . . . . . . . . . . . . . . 34 105 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 34 106 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 34 107 10.10. Info Package Security Considerations . . . . . . . . . . 35 108 11. Deployment Considerations . . . . . . . . . . . . . . . . . . 35 109 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 110 12.1. SDP 'end-of-candidates' Attribute . . . . . . . . . . . 35 111 12.2. Media Type 'application/trickle-ice-sdpfrag' . . . . . . 36 112 12.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 38 113 12.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 38 114 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 115 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 116 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 117 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 118 16.1. Normative References . . . . . . . . . . . . . . . . . . 43 119 16.2. Informative References . . . . . . . . . . . . . . . . . 45 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 122 1. Introduction 124 The Interactive Connectivity Establishment (ICE) protocol 125 [I-D.ietf-ice-rfc5245bis] describes a mechanism for Network Address 126 Translator (NAT) traversal that consists of three main phases. 128 During the first phase an agent gathers a set of candidate transport 129 addresses (source IP address, port and transport protocol). This is 130 followed by a second phase where these candidates are sent to a 131 remote agent. There, the gathering procedure is repeated and 132 candidates are sent to the first agent. Finally, a third phase 133 starts where connectivity between all candidates in both sets is 134 checked (connectivity checks). Once these phases have been 135 completed, and only then, both agents can begin communication. 137 According to [I-D.ietf-ice-rfc5245bis] the three phases above happen 138 consecutively, in a blocking way, which can introduce undesirable 139 setup delay during session establishment. The Trickle ICE extension 140 [I-D.ietf-ice-trickle] defines generic semantics required for these 141 ICE phases to happen in a parallel, non-blocking way and hence speed 142 up session establishment. 144 This specification defines a usage of Trickle ICE with the Session 145 Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates 146 are to be exchanged incrementally using SIP INFO requests [RFC6086] 147 and how the Half Trickle and Full Trickle modes defined in 148 [I-D.ietf-ice-trickle] are to be used by SIP User Agents (UAs) 149 depending on their expectations for support of Trickle ICE by a 150 remote agent. 152 This document defines a new Info Package as specified in [RFC6086] 153 for use with Trickle ICE. 155 2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 [RFC2119], [RFC8174] when, and only when, they appear in all 161 capitals, as shown here. 163 This specification makes use of terminology defined by the protocol 164 for Interactive Connectivity Establishment in 165 [I-D.ietf-ice-rfc5245bis] and its Trickle ICE extension 166 [I-D.ietf-ice-trickle]. It is assumed that the reader is familiar 167 with the terminology from both documents. 169 3. Protocol Overview 171 When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] 172 the ICE candidates are exchanged solely via SDP Offer/Answer as per 173 [RFC3264]. This specification defines an additional mechanism where 174 candidates can be exchanged using SIP INFO messages and a newly 175 defined Info Package [RFC6086]. This allows ICE candidates also to 176 be sent in parallel to an ongoing Offer/Answer negotiation and/or 177 after the completion of the Offer/Answer negotiation. 179 Typically, in cases where Trickle ICE is fully supported, the Offerer 180 sends an INVITE request containing a subset of candidates. Once an 181 early dialog is established the Offerer can continue sending 182 candidates in INFO requests within that dialog. 184 Similarly, an Answerer can send ICE candidates using INFO requests 185 within the dialog established by its 18x provisional response. 186 Figure 1 shows such a sample exchange: 188 STUN/Turn STUN/TURN 189 Servers Alice Bob Servers 190 | | | | 191 | STUN Bi.Req. | INVITE (Offer) | | 192 |<--------------|------------------------>| | 193 | | 183 (Answer) | TURN Alloc Req | 194 | STUN Bi.Resp. |<------------------------|--------------->| 195 |-------------->| INFO/OK (SRFLX Cand.) | | 196 | |------------------------>| TURN Alloc Resp| 197 | | INFO/OK (Relay Cand.) |<---------------| 198 | |<------------------------| | 199 | | | | 200 | | More Cands & ConnChecks| | 201 | |<=======================>| | 202 | | | | 203 | | 200 OK | | 204 | |<------------------------| | 205 | | ACK | | 206 | |------------------------>| | 207 | | | | 208 | |<===== MEDIA FLOWS =====>| | 209 | | | | 211 Note: SRFLX denotes server-reflexive candidates 213 Figure 1: Sample Trickle ICE scenario with SIP 215 3.1. Discovery issues 217 In order to benefit from Trickle ICE's full potential and reduce 218 session establishment latency to a minimum, Trickle ICE agents need 219 to generate SDP Offers and Answers that contain incomplete, 220 potentially empty sets of candidates. Such Offers and Answers can 221 only be handled meaningfully by agents that actually support 222 incremental candidate provisioning, which implies the need to confirm 223 such support before using it. 225 Contrary to other protocols, where "in advance" capability discovery 226 is widely implemented, the mechanisms that allow this for SIP (i.e., 227 a combination of UA Capabilities [RFC3840] and GRUU [RFC5627]) have 228 only seen low levels of adoption. This presents an issue for Trickle 229 ICE implementations as SIP UAs do not have an obvious means of 230 verifying that their peer will support incremental candidate 231 provisioning. 233 The Half Trickle mode of operation defined in the Trickle ICE 234 specification [I-D.ietf-ice-trickle] provides one way around this, 235 by requiring the first Offer to contain a complete set of local ICE 236 candidates and only using incremental provisioning of remote 237 candidates for the rest of the session. 239 While using Half Trickle does provide a working solution it also 240 comes at the price of increased latency. Section 5 therefore makes 241 several alternative suggestions that enable SIP UAs to engage in Full 242 Trickle right from their first Offer: Section 5.1 discusses the use 243 of on-line provisioning as a means of allowing use of Trickle ICE for 244 all endpoints in controlled environments. Section 5.2 describes 245 anticipatory discovery for implementations that actually do support 246 GRUU and UA Capabilities and Section 5.3 discusses the implementation 247 and use of Half Trickle by SIP UAs where none of the above are an 248 option. 250 3.2. Relationship with the Offer/Answer Model 252 From the perspective of SIP middle boxes and proxies the Offer/Answer 253 exchange for Trickle ICE looks partly similar to the Offer/Answer 254 exchange for regular ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. 255 However, in order to have the full picture of the candidate exchange, 256 the newly introduced INFO messages need to be considered as well. 258 +-------------------------------+ +-------------------------------+ 259 | Alice +--------------+ | | +--------------+ Bob | 260 | | Offer/Answer | | | | Offer/Answer | | 261 | +--------+ | Module | | | | Module | +--------+ | 262 | | ICE | +--------------+ | | +--------------+ | ICE | | 263 | | Module | | | | | | Module | | 264 | +--------+ | | | | +--------+ | 265 +-------------------------------+ +-------------------------------+ 266 | | | | 267 | | INVITE (Offer) | | 268 | |--------------------->| | 269 | | 183 (Answer) | | 270 | |<---------------------| | 271 | | | | 272 | | 273 | SIP INFO (more candidates) | 274 |----------------------------------------------------->| 275 | SIP INFO (more candidates) | 276 |<-----------------------------------------------------| 277 | | 278 | STUN Binding Requests/Responses | 279 |----------------------------------------------------->| 280 | STUN Binding Requests/Responses | 281 |<-----------------------------------------------------| 282 | | 284 Figure 2: Distinguishing between Trickle ICE and traditional 285 signaling. 287 From an architectural viewpoint, as displayed in Figure 2, exchanging 288 candidates through SIP INFO requests could be represented as 289 signaling between ICE modules and not between Offer/Answer modules of 290 SIP User Agents. Then, such INFO requests do not impact the state of 291 the Offer/Answer transaction other than providing additional 292 candidates. Consequently, INFO requests are not considered Offers or 293 Answers. Nevertheless, candidates that have been exchanged using 294 INFO requests SHALL be included in subsequent Offers or Answers. The 295 version number in the "o=" line of that subsequent Offer needs to be 296 incremented by 1 per the rules in [RFC3264]. 298 4. Incremental Signaling of ICE candidates 300 Trickle ICE Agents will exchange ICE descriptions compliant to 301 [I-D.ietf-ice-trickle] via Offer/Answer procedures and/or INFO 302 request bodies. This requires the following SIP-specific extensions: 304 1. Trickle ICE Agents MUST indicate support for Trickle ICE by 305 including the SIP option-tag 'trickle-ice' in a SIP Supported: 306 header field within all SIP INVITE requests and responses. 308 2. Trickle ICE Agents MUST indicate support for Trickle ICE by 309 including the ice-option 'trickle' within all SDP Offers and 310 Answers in accordance to [I-D.ietf-ice-trickle]. 312 3. Trickle ICE Agents MAY include any number of ICE candidates, i.e. 313 from zero to the complete set of candidates, in their initial 314 Offer or Answer. If the complete candidate set is included 315 already in the initial Offer, this is called Half-Trickle. 317 4. Trickle ICE Agents MAY exchange additional ICE candidates using 318 INFO requests within an existing INVITE dialog usage (including 319 an early dialog) as specified in [RFC6086]. The INFO requests 320 carry an Info-Package: trickle-ice. Trickle ICE Agents MUST be 321 prepared to receive INFO requests within that same dialog usage, 322 containing additional candidates and/or an indication that 323 trickling of such candidates has ended. 325 5. Trickle ICE Agents MAY exchange additional ICE candidates before 326 the Answerer has sent the Answer provided that an invite dialog 327 usage is established at both Trickle ICE Agents. Note that in 328 case of forking multiple early dialogs may exist. 330 The following sections provide further details on how Trickle ICE 331 Agents perform the initial Offer/Answer exchange (Section 4.1), 332 perform subsequent Offer/Answer exchanges (Section 4.2) and establish 333 the INVITE dialog usage (Section 4.3) such that they can 334 incrementally trickle candidates (Section 4.4). 336 4.1. Initial Offer/Answer Exchange 338 4.1.1. Sending the Initial Offer 340 If the Offerer includes candidates in its initial Offer, it MUST 341 encode these candidates as specified in 342 [I-D.ietf-mmusic-ice-sip-sdp]. 344 If the Offerer wants to send its initial Offer before knowing any 345 candidate for one or more media descriptions, it MUST set the port to 346 the default value '9' for these media descriptions. If the Offerer 347 does not want to include the host IP address in the corresponding 348 c-line, e.g. due to privacy reasons, it SHOULD include a default 349 address in the c-line, which is set to the IPv4 address 0.0.0.0 or to 350 the IPv6 equivalent ::. 352 In this case, the Offerer obviously cannot know the RTCP transport 353 address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. 354 This avoids potential ICE mismatch (see 355 [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. 357 If the Offerer wants to use RTCP multiplexing [RFC5761] and/or 358 exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still 359 will include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in 360 the initial Offer. 362 In any case, the Offerer MUST include the attribute "a=ice- 363 options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST 364 include in each "m="-line a "a=mid:" attribute in accordance to 365 [RFC5888]. 367 4.1.2. Receiving the Initial Offer 369 If the initial Offer included candidates, the Answerer uses these 370 candidates to start ICE processing as specified in 371 [I-D.ietf-ice-trickle]. 373 If the initial Offer included the attribute a=ice-options:trickle, 374 the Answerer MUST be prepared for receiving trickled candidates later 375 on. 377 In case of a "m/c=" line with default values none of the eventually 378 trickled candidates will match the default destination. This 379 situation MUST NOT cause an ICE mismatch (see 380 [I-D.ietf-mmusic-ice-sip-sdp]). 382 4.1.3. Sending the Initial Answer 384 If the Answerer includes candidates in its initial Answerer, it MUST 385 encode these candidates as specified in 386 [I-D.ietf-mmusic-ice-sip-sdp]. 388 If the Answerer wants to send its initial Answer before knowing any 389 candidate for one or more media descriptions, it MUST set the port to 390 the default value '9' for these media descriptions. If the Answerer 391 does not want to include the host IP address in the corresponding 392 c-line, e.g. due to privacy reasons, it SHOULD include a default 393 address in the c-line, which is set to the IPv4 address 0.0.0.0 or to 394 the IPv6 equivalent ::. 396 In this case, the Answerer obviously cannot know the RTCP transport 397 address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. 398 This avoids potential ICE mismatch (see 399 [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. 401 If the Answerer accepts to use RTCP multiplexing [RFC5761] and/or 402 exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it will 403 include the "a=rtcp-mux" attribute in the initial Answer. 405 In any case, the Answerer MUST include the attribute "a=ice- 406 options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST 407 include in each "m="-line a "a=mid:" attribute in accordance to 408 [RFC5888]. 410 4.1.4. Receiving the Initial Answer 412 If the initial Answer included candidates, the Offerer uses these 413 candidates to start ICE processing as specified in 414 [I-D.ietf-ice-trickle]. 416 If the initial Answer included the attribute a=ice-options:trickle, 417 the Offerer MUST be prepared for receiving trickled candidates later 418 on. 420 In case of a "m/c=" line with default values none of the eventually 421 trickled candidates will match the default destination. This 422 situation MUST NOT cause an ICE mismatch (see 423 [I-D.ietf-mmusic-ice-sip-sdp]). 425 4.2. Subsequent Offer/Answer Exchanges 427 Subsequent Offer/Answer exchanges are handled as for regular ICE (see 428 section 4.2 of [I-D.ietf-mmusic-ice-sip-sdp]). 430 If an Offer or Answer needs to be sent while the ICE agents are in 431 the middle of trickling section 4.2.1.2.1 of 432 [I-D.ietf-mmusic-ice-sip-sdp]) applies. This means that an ICE agent 433 includes candidate attributes for all local candidates it had 434 trickled previously for a specific media stream. 436 [RFC EDITOR NOTE: The section 4.2.1.2.1 in above sentence is correct 437 for version 16 of said I-D. Authors need to cross-check during 438 Auth48 since it could have have changed in the meantime.] 440 4.3. Establishing the Dialog 442 In order to be able to start trickling, the following two conditions 443 need to be satisfied at the SIP UAs: 445 o Trickle ICE support at the peer agent MUST be confirmed. 447 o The dialog at both peers MUST be in early or confirmed state. 449 Section 5 discusses in detail the various options for satisfying the 450 first of the above conditions. Regardless of those mechanisms, 451 however, agents are certain to have a clear understanding of whether 452 their peers support trickle ICE once an Offer and an Answer have been 453 exchanged, which also allows for ICE processing to commence (see 454 Figure 3). 456 4.3.1. Establishing Dialog State through Reliable Offer/Answer delivery 458 Alice Bob 459 | | 460 | INVITE (Offer) | 461 |------------------------>| 462 | 183 (Answer) | 463 |<------------------------| 464 | PRACK/OK | 465 |------------------------>| 466 | | 467 +----------------------------------------+ 468 |Alice and Bob know that both can trickle| 469 |and know that the dialog is in the early| 470 |state. Send INFO! | 471 +----------------------------------------+ 472 | | 473 | INFO/OK (+SRFLX Cand.) | 474 |------------------------>| 475 | INFO/OK (+SRFLX Cand.) | 476 |<------------------------| 477 | | 479 Note: SRFLX denotes server-reflexive candidates 481 Figure 3: SIP Offerer can freely trickle as soon as it receives an 482 Answer. 484 As shown in Figure 3 satisfying both conditions is relatively trivial 485 for ICE Agents that have sent an Offer in an INVITE and that have 486 received an Answer in a reliable provisional response. It is 487 guaranteed to have confirmed support for Trickle ICE at the Answerer 488 (or lack thereof) and to have fully initialized the SIP dialog at 489 both ends. Offerers and Answerers (after receipt of the PRACK 490 request) in the above situation can therefore freely commence 491 trickling within the newly established dialog. 493 4.3.2. Establishing Dialog State through Unreliable Offer/Answer 494 Delivery 496 The situation is a bit more delicate for agents that have received an 497 Offer in an INVITE request and have sent an Answer in an unreliable 498 provisional response because, once the response has been sent, the 499 Answerer does not know when or if it has been received (Figure 4). 501 Alice Bob 502 | | 503 | INVITE (Offer) | 504 |------------------------>| 505 | 183 (Answer) | 506 |<------------------------| 507 | | 508 | +----------------------+ 509 | |Bob: I don't know if | 510 | |Alice got my 183 or if| 511 | |her dialog is already | 512 | |in the early state. | 513 | | Can I send INFO??? | 514 | +----------------------+ 515 | | 517 Figure 4: A SIP UA that sent an Answer in an unreliable provisional 518 response does not know if it was received and if the dialog at the 519 side of the Offerer has entered the early state 521 In order to clear this ambiguity as soon as possible, the Answerer 522 needs to retransmit the provisional response with the exponential 523 back-off timers described in [RFC3262]. These retransmissions MUST 524 cease on receipt of an INFO request carrying a 'trickle-ice' Info 525 Package body or on transmission of the Answer in a 2xx response. 526 This is similar to the procedure described in section 8.1.1 of 527 [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding Request is 528 replaced by the INFO request. 530 [RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for 531 version 16 of said I-D. Authors need to cross-check during Auth48 532 since it could have have changed in the meantime.] 534 The Offerer MUST send a Trickle ICE INFO request as soon as it 535 receives an SDP Answer in an unreliable provisional response. This 536 INFO request MUST repeat the candidates that were already provided in 537 the Offer (as would be the case when Half Trickle is performed or 538 when new candidates have not been learned since then). 540 If available, the Offerer SHOULD also deliver newly learned 541 candidates in this INFO request, unless it wants to hold back some 542 candidates in reserve, e.g. in case that these candidates are 543 expensive to use and would only be trickled if all other candidates 544 failed. 546 The Offerer SHOULD include an end-of-candidates attribute in case 547 candidate discovery has ended in the mean time and no further 548 candidates are to be trickled. 550 As soon as an Answerer has received such an INFO request, the 551 Answerer has an indication that a dialog is established at both ends 552 and can begin trickling (Figure 5). 554 Note: The +SRFLX in Figure 5 indicates that additionally newly 555 learned server-reflexive candidates are included. 557 Alice Bob 558 | | 559 | INVITE (Offer) | 560 |------------------------>| 561 | 183 (Answer) | 562 |<------------------------| 563 | INFO/OK (+SRFLX Cand.) | 564 |------------------------>| 565 | | 566 | +----------------------+ 567 | |Bob: Now I know Alice| 568 | | is ready. Send INFO! | 569 | +----------------------+ 570 | INFO/OK (+SRFLX Cand.) | 571 |<------------------------| 572 | | 573 | 200/ACK (Answer) | 574 |<------------------------| 576 Note: SRFLX denotes server-reflexive candidates 578 Figure 5: A SIP UA that received an INFO request after sending an 579 unreliable provisional response knows that the dialog at the side of 580 the receiver has entered the early state 582 When sending the Answer in the 200 OK response to the INVITE request, 583 the Answerer needs to repeat exactly the same Answer that was 584 previously sent in the unreliable provisional response in order to 585 fulfill the corresponding requirements in [RFC3264]. Thus, the 586 Offerer needs to be prepared for receiving a different number of 587 candidates in that repeated Answer than previously exchanged via 588 trickling and MUST ignore the candidate information in that 200 OK 589 response. 591 4.3.3. Initiating Trickle ICE without an SDP Answer 593 The ability to convey arbitrary candidates in INFO message bodies 594 allows ICE Agents to initiate trickling without actually sending an 595 Answer. Trickle ICE Agents can therefore respond to an INVITE 596 request with provisional responses without an SDP Answer [RFC3261]. 597 Such provisional responses serve for establishing an early dialog. 599 Agents that choose to establish the dialog in this way, MUST 600 retransmit these responses with the exponential back-off timers 601 described in [RFC3262]. These retransmissions MUST cease on receipt 602 of an INFO request or on transmission of the Answer in a 2xx 603 response. This is again similar to the procedure described in 604 section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer 605 is not yet provided. 607 [RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for 608 version 16 of said I-D. Authors need to cross-check during Auth48 609 since it could have have changed in the meantime.] 611 Note: The +SRFLX in Figure 6 indicates that additionally newly 612 learned server-reflexive candidates are included. 614 Alice Bob 615 | | 616 | INVITE (Offer) | 617 |------------------------>| 618 | 183 (-) | 619 |<------------------------| 620 | INFO/OK (SRFLX Cand.) | 621 |------------------------>| 622 | | 623 | +----------------------+ 624 | |Bob: Now I know again| 625 | | that Alice is ready. | 626 | | Send INFO! | 627 | +----------------------+ 628 | INFO/OK (SRFLX Cand.) | 629 |<------------------------| 630 | 183 (Answer) opt. | 631 |<------------------------| 632 | INFO/OK (SRFLX Cand.) | 633 |<------------------------| 634 | 200/ACK (Answer) | 635 |<------------------------| 637 Note: SRFLX denotes server-reflexive candidates 639 Figure 6: A SIP UA sends an unreliable provisional response without 640 an Answer for establishing an early dialog 642 When sending the Answer, the agent MUST repeat all currently known 643 and used candidates, if any, and MAY include all newly gathered 644 candidates since the last INFO request was sent. However, if that 645 Answer was already sent in a unreliable provisional response, the 646 Answerers MUST repeat exactly the same Answer in the 200 OK response 647 to the INVITE request in order to fulfill the corresponding 648 requirements in [RFC3264]. In case that trickling continued, an 649 Offerer needs to be prepared for receiving fewer candidates in that 650 repeated Answer than previously exchanged via trickling and MUST 651 ignore the candidate information in that 200 OK response. 653 4.3.4. Considerations for Third Party Call Control 655 Third Party Call Control (3PCC) for SIP can be performed using 656 several signaling variants as described in [RFC3725]. We give 657 specific consideration for 3PCC that starts with an offerless INVITE 658 request [RFC3261]. As specified in Section 4 this offerless INVITE 659 MUST include the SIP option-tag 'trickle-ice' in a SIP Supported: 660 header field in order to indicate support for Trickle-ICE to the 661 Offerer (at the User Agent Server (UAS)). Then, a UAS has the option 662 to send its Offer in a reliable provisional response [RFC3262] or in 663 the 200 OK response to the INVITE request. 665 Agents that had sent an Offer in a reliable provisional response and 666 that received an Answer in a PRACK request [RFC3262] are also in a 667 situation where support for Trickle ICE is confirmed and the SIP 668 dialog is guaranteed to be in a state that allows in-dialog INFO 669 requests (see Figure 7). 671 Alice Bob 672 | | 673 | INVITE | 674 |------------------------>| 675 | 183 (Offer) | 676 |<------------------------| 677 | PRACK (Answer) | 678 |------------------------>| 679 | | 680 | +----------------------+ 681 | |Bob: I know Alice can| 682 | |trickle and I know her| 683 | |dialog is in the early| 684 | |state. Send INFO! | 685 | +----------------------+ 686 | | 687 | INFO/OK (SRFLX Cand.) | 688 |<------------------------| 689 | | 690 | INFO/OK (SRFLX Cand.) | 691 |------------------------>| 692 | 200 OK/ACK | 693 |<------------------------| 695 Note: SRFLX denotes server-reflexive candidates 697 Figure 7: A SIP Offerer in a 3PCC scenario can also freely start 698 trickling as soon as it receives an Answer. 700 Trickle ICE Agents that send an Offer in a 200 OK response and 701 receive an Answer in an ACK message can still create a dialog and 702 confirm support for Trickle ICE by sending an unreliable provisional 703 response similar to Section 4.3.3. As specified in Section 4 this 704 unreliable provisional response MUST include the SIP option-tag 705 'trickle-ice' in a SIP Supported: header field in order to indicate 706 support for Trickle-ICE to the UAC. According to [RFC3261], this 707 unreliable response cannot contain an Offer. 709 The Trickle ICE Agent, i.e. the user Agent server (UAS), retransmits 710 the provisional response with the exponential back-off timers 711 described in [RFC3262]. Retransmits MUST cease on receipt of an INFO 712 request or on transmission of the Answer in a 2xx response. The peer 713 Trickle ICE Agent (the UAC) MUST send a Trickle ICE INFO request as 714 soon as it receives an unreliable provisional response (see 715 Figure 8). 717 Alice Bob 718 | | 719 | INVITE | 720 |------------------------>| 721 | 183 (-) | 722 |<------------------------| 723 | INFO/OK (SRFLX Cand.) | 724 |------------------------>| 725 | | 726 | +-----------------------+ 727 | |Bob: I know Alice can | 728 | |trickle and I know her | 729 | |dialog is in the early | 730 | |state. | 731 | |INFO can be sent. | 732 | +-----------------------+ 733 | | 734 | INFO/OK (SRFLX Cand.) | 735 |<------------------------| 736 | | 737 | 200 (Offer) | 738 |<------------------------| 739 | ACK (Answer) | 740 |------------------------>| 741 | | 743 Note: SRFLX denotes server-reflexive candidates 745 Figure 8: A SIP UAC in a 3PCC scenario can also freely start 746 trickling as soon as it receives an unreliable provisional response. 748 4.4. Delivering Candidates in INFO Requests 750 Whenever new ICE candidates become available for sending, agents 751 encode them in "a=candidate:" attributes as described by 752 [I-D.ietf-mmusic-ice-sip-sdp]. For example: 754 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx 755 raddr 2001:db8:a0b:12f0::1 rport 8998 757 The use of SIP INFO requests happens within the context of the Info 758 Package as defined Section 10. The Media Type [RFC6838] for their 759 payload MUST be set to 'application/trickle-ice-sdpfrag' as defined 760 in Section 9. The Info request body adheres to the grammar as 761 specified in Section 9.2. 763 Since neither the "a=candidate:" nor the "a=end-of-candidates" 764 attributes contain information that would allow correlating them to a 765 specific "m=" line, this is handled through the use of pseudo "m=" 766 lines and identification tags in "a=mid:" attributes as defined in 767 [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as 768 defined in [RFC4566], but provide no semantics other than indicating 769 to which "m=" line a candidate belongs. Consequently, the receiving 770 agent MUST ignore any remaining content of the pseudo "m=" line, 771 which is not defined in this document. This guarantees that the 772 'application/trickle-ice-sdpfrag' bodies do not interfere with the 773 Offer/Answer procedures as specified in [RFC3264]. 775 When sending the INFO request, the agent MAY, if already known to the 776 agent, include the same content into the pseudo "m=" line as for the 777 "m=" line in the corresponding Offer or Answer. However, since 778 Trickle-ICE might be decoupled from the Offer/Answer negotiation this 779 content might be unknown to the agent. In this case, the agent MUST 780 include the following default values. 782 o The media field is set to 'audio'. 784 o The port value is set to '9'. 786 o The proto value is set to 'RTP/AVP'. 788 o The fmt field MUST appear only once and is set to '0' 790 Agents MUST include a pseudo "m=" line and an identification tag in a 791 "a=mid:" attribute for every "m=" line whose candidate list they 792 intend to update. Such "a=mid:" attributes MUST immediately precede 793 the list of candidates for that specific "m=" line. 795 All "a=candidate:" or "a=end-of-candidates" attributes following an 796 "a=mid:" attribute, up until (and excluding) the next occurrence of a 797 pseudo "m=" line, pertain to the "m=" line identified by that 798 identification tag. 800 Note, that there is no requirement that the Info request body 801 contains as many pseudo m= lines as the Offer/Answer contains m= 802 lines, nor that the pseudo m= lines be in the same order as the 803 m=lines that they pertain to. The correspondence can be made via the 804 "a=mid:" attributes. 806 An "a=end-of-candidates" attribute, preceding any pseudo "m=" line, 807 indicates the end of all trickling from that agent, as opposed to end 808 of trickling for a specific "m=" line, which would be indicated by a 809 media level "a=end-of-candidates" attribute. 811 Refer to Figure 9 for an example of the INFO request content. 813 The use of pseudo "m=" lines allows for a structure similar to the 814 one in SDP Offers and Answers where separate media-level and session- 815 level sections can be distinguished. In the current case, lines 816 preceding any pseudo "m=" line are considered to be session-level. 817 Lines appearing in between or after pseudo "m=" lines will be 818 interpreted as media-level. 820 Note that while this specification uses the "a=mid:" attribute 821 from [RFC5888], it does not define any grouping semantics. 822 Consequently, the "a=group:" attribute from that same 823 specification is neither needed nor used in Trickle ICE for SIP. 825 All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" 826 attributes that allows mapping them to a specific ICE generation. An 827 agent MUST discard any received INFO requests containing "a=ice-pwd:" 828 and "a=ice-ufrag:" attributes that do not match those of the current 829 ICE Negotiation Session. 831 The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the 832 same level as the ones in the Offer/Answer exchange. In other words, 833 if they were present as session-level attributes, they will also 834 appear at the beginning of all INFO request payloads, i.e. preceding 835 all pseudo "m=" lines. If they were originally exchanged as media 836 level attributes, potentially overriding session-level values, then 837 they will also be included in INFO request payloads following the 838 corresponding pseudo "m=" lines. 840 Note that [I-D.ietf-ice-trickle] requires that when candidates are 841 trickled, each candidate must be delivered to the receiving Trickle 842 ICE implementation not more than once and in the same order as it was 843 conveyed. If the signaling protocol provides any candidate 844 retransmissions, they need to be hidden from the ICE implementation. 845 This requirement is fulfilled as follows. 847 Since the agent is not fully aware of the state of the ICE 848 Negotiation Session at its peer it MUST include all currently known 849 and used local candidates in every INFO request. I.e. the agent MUST 850 repeat in the INFO request body all candidates that were previously 851 sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in 852 the same order as they were gathered. In other words, the sequence 853 of a previously sent list of candidates MUST NOT change in subsequent 854 INFO requests and newly gathered candidates MUST be added at the end 855 of that list. Although repeating all candidates creates some 856 overhead, it also allows easier handling of problems that could arise 857 from unreliable transports, like e.g. loss of messages and 858 reordering, which can be detected through the CSeq: header field in 859 the INFO request. 861 When receiving INFO requests carrying any candidates, agents MUST 862 therefore first identify and discard the attribute lines containing 863 candidates they have already received in previous INFO requests or in 864 the Offer/Answer exchange preceding them. 866 Such candidates are considered to be equal if their IP address port, 867 transport and component ID are the same. After identifying and 868 discarding the known candidates, the agents MUST forward the actually 869 new candidates to the ICE Agents in the same order as they were 870 received in the INFO request body. The ICE Agents will then process 871 the new candidates according to the rules described in 872 [I-D.ietf-ice-trickle]. 874 Receiving an "a=end-of-candidates" attribute in an INFO request body 875 - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the 876 current ICE generation - is an indication from the peer agent that it 877 will not send any further candidates. When included at session 878 level, i.e. before any pseudo "m=" line, this indication applies to 879 the whole session; when included at media level the indication 880 applies only to the corresponding "m=" line. Handling of such end- 881 of-candidates indications is defined in [I-D.ietf-ice-trickle]. 883 Note: At the time of writing this specification there were ongoing 884 discussions if a functionality for removing already exchanged 885 candidates would be useful. Such a functionality is out of the scope 886 of this specification and most likely needs to be signaled by means 887 of a yet to be defined ICE extension, although it could in principle 888 be achieved quite easily, e.g. without anticipating any solution by 889 simply omitting a previously sent candidate from a subsequent INFO 890 request. However, if an implementation according to this 891 specification receives such an INFO request with a missing candidate 892 it would have to treat that as an exceptional case. Implementing 893 appropriate recovery procedures at the receiving side is advisable 894 for this situation. Ignoring that a candidate was missing might be a 895 sensible strategy. 897 The example in Figure 9 shows the content of a candidate delivering 898 INFO request. In the example the "a=end-of-candidates" attributes 899 indicate that the candidate gathering is finished and that no further 900 INFO requests follow. 902 INFO sip:alice@example.com SIP/2.0 903 ... 904 Info-Package: trickle-ice 905 Content-type: application/trickle-ice-sdpfrag 906 Content-Disposition: Info-Package 907 Content-length: 862 909 a=ice-pwd:asd88fgpdd777uzjYhagZg 910 a=ice-ufrag:8hhY 911 m=audio 9 RTP/AVP 0 912 a=mid:1 913 a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host 914 a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host 915 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx 916 raddr 2001:db8:a0b:12f0::1 rport 8998 917 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx 918 raddr 2001:db8:a0b:12f0::1 rport 8998 919 a=end-of-candidates 920 m=audio 9 RTP/AVP 0 921 a=mid:2 922 a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 6000 typ host 923 a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 6001 typ host 924 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 6000 typ srflx 925 raddr 2001:db8:a0b:12f0::1 rport 9998 926 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 6001 typ srflx 927 raddr 2001:db8:a0b:12f0::1 rport 9998 928 a=end-of-candidates 930 Note: In a real INFO request there will be no line breaks 931 in the a=candidate: attributes 933 Figure 9: An Example for the Content of an INFO Request 935 5. Initial Discovery of Trickle ICE Support 937 SIP User Agents (UAs) that support and intend to use trickle ICE are 938 required by [I-D.ietf-ice-trickle] to indicate that in their Offers 939 and Answers using the attribute "a=ice-options:trickle" and MUST 940 include the SIP option-tag "trickle-ice" in a SIP Supported: header 941 field. This makes discovery fairly straightforward for Answerers or 942 for cases where Offers need to be generated within existing dialogs 943 (i.e., when sending UPDATE or re-INVITE requests). In both scenarios 944 prior SDP bodies will have provided the necessary information. 946 Obviously, such information is not available at the time a first 947 Offer is being constructed and it is therefore impossible for ICE 948 Agents to determine support for incremental provisioning that way. 949 The following options are suggested as ways of addressing this issue. 951 5.1. Provisioning Support for Trickle ICE 953 In certain situations it may be possible for integrators deploying 954 Trickle ICE to know in advance that some or all endpoints reachable 955 from within the deployment will support Trickle ICE. This is the 956 case, for example, if Session Border Controllers (SBC) with support 957 for this specification are used to connect to UAs that do not support 958 Trickle ICE. 960 While the exact mechanism for allowing such provisioning is out of 961 scope here, this specification encourages trickle ICE implementations 962 to allow the option in the way they find most appropriate. 964 5.2. Trickle ICE Discovery with Globally Routable User Agent URIs 966 [RFC3840] provides a way for SIP User Agents to query for support of 967 specific capabilities using, among others, OPTIONS requests. Support 968 for Globally Routable User Agent URIs (GRUU) according to [RFC5627] 969 on the other hand allows SIP requests to be addressed to specific UAs 970 (as opposed to arbitrary instances of an address of record). 971 Combining the two and using the "trickle-ice" option tag defined in 972 Section 10.6 provides SIP UAs with a way of learning the capabilities 973 of specific SIP UA instances and then addressing them directly with 974 INVITE requests that require Trickle ICE support. 976 Such learning of capabilities may happen in different ways. One 977 option for a SIP UA is to learn the GRUU instance ID of a peer 978 through presence and then to query its capabilities with an OPTIONS 979 request. Alternatively, it can also just send an OPTIONS request to 980 the AOR it intends to contact and then inspect the returned 981 response(s) for support of both GRUU and Trickle ICE (Figure 10). It 982 is noted that using the GRUU means that the INVITE request can go 983 only to that particular device. This prevents the use of forking for 984 that request. 986 Alice Bob 987 | | 988 | OPTIONS sip:b1@example.com SIP/2.0 | 989 |-------------------------------------------------->| 990 | | 991 | 200 OK | 992 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 993 | ;audio;video|;trickle-ice;... | 994 |<--------------------------------------------------| 995 | | 996 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 997 |-------------------------------------------------->| 998 | | 999 | 183 (Answer) | 1000 |<--------------------------------------------------| 1001 | INFO/OK (Trickling) | 1002 |<------------------------------------------------->| 1003 | | 1004 | ... | 1005 | | 1007 Figure 10: Trickle ICE support discovery with OPTIONS and GRUU 1009 Confirming support for Trickle ICE through [RFC3840] gives SIP UAs 1010 the options to engage in Full Trickle negotiation (as opposed to the 1011 more lengthy Half Trickle) from the very first Offer they send. 1013 5.3. Fall-back to Half Trickle 1015 In cases where none of the other mechanisms in this section are 1016 acceptable, SIP UAs should use the Half Trickle mode defined in 1017 [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions 1018 the same way they would when using ICE for SIP 1019 [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually 1020 sending an Offer, agents first gather ICE candidates in a blocking 1021 way and then send them all in that Offer. The blocking nature of the 1022 process implies that some amount of latency will be accumulated and 1023 it is advised that agents try to anticipate it where possible, for 1024 example, when user actions indicate a high likelihood for an imminent 1025 call (e.g., activity on a keypad or a phone going off-hook). 1027 Using Half Trickle results in Offers that are compatible with both 1028 ICE SIP endpoints and legacy [RFC3264] endpoints. 1030 STUN/Turn STUN/TURN 1031 Servers Alice Bob Servers 1032 | | | | 1033 |<--------------| | | 1034 | | | | 1035 | | | | 1036 | Candidate | | | 1037 | | | | 1038 | | | | 1039 | Discovery | | | 1040 | | | | 1041 | | | | 1042 |-------------->| INVITE (Offer) | | 1043 | |---------------------------->| | 1044 | | 183 (Answer) |-------------->| 1045 | |<----------------------------| | 1046 | | INFO (repeated candidates) | | 1047 | |---------------------------->| | 1048 | | | | 1049 | | INFO (more candidates) | Candidate | 1050 | |<----------------------------| | 1051 | | Connectivity Checks | | 1052 | |<===========================>| Discovery | 1053 | | INFO (more candidates) | | 1054 | |<----------------------------| | 1055 | | Connectivity Checks |<--------------| 1056 | |<===========================>| | 1057 | | | | 1058 | | 200 OK | | 1059 | |<----------------------------| | 1060 | | | | 1061 | |<======= MEDIA FLOWS =======>| | 1062 | | | | 1064 Figure 11: Example - A typical (Half) Trickle ICE exchange with SIP 1066 It is worth reminding that once a single Offer or Answer had been 1067 exchanged within a specific dialog, support for Trickle ICE will have 1068 been determined. No further use of Half Trickle will therefore be 1069 necessary within that same dialog and all subsequent exchanges can 1070 use the Full Trickle mode of operation. 1072 6. Considerations for RTP and RTCP Multiplexing 1074 The following consideration describe options for Trickle-ICE in order 1075 to give some guidance to implementors on how trickling can be 1076 optimized with respect to providing RTCP candidates. 1078 Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" 1079 attribute for RTP/RTCP multiplexing [RFC5761] is already considered 1080 in section 5.1.1.1. of [I-D.ietf-ice-rfc5245bis] and as well in 1081 [RFC5761] itself. These considerations are still valid for Trickle 1082 ICE, however, trickling provides more flexibility for the sequence of 1083 candidate exchange in case of RTCP multiplexing. 1085 [RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct 1086 for version 15 of said I-D. Authors need to cross-check during 1087 Auth48 since it could have have changed in the meantime.] 1089 If the Offerer supports RTP/RTCP multiplexing exclusively as 1090 specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that 1091 document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" 1092 and the "a=rtcp-mux" attributes. 1094 While a Half Trickle Offerer has to send an Offer compliant to 1095 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for 1096 all components, the flexibility of a Full Trickle Offerer allows to 1097 send only RTP candidates (component 1) in the initial Offer assuming 1098 that RTCP multiplexing is supported by the Answerer. A Full Trickle 1099 Offerer would need to start gathering and trickling RTCP candidates 1100 (component 2) only after having received an indication in the Answer 1101 that the Answerer unexpectedly does not support RTCP multiplexing. 1103 A Trickle Answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in 1104 the application/trickle-ice-sdpfrag body if it supports and uses RTP 1105 and RTCP multiplexing. The Trickle Answerer needs to follow the 1106 guidance on the usage of the "a=rtcp" attribute as given in 1107 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]. Receipt of this 1108 attribute at the Offerer in an INFO request prior to the Answer 1109 indicates that the Answerer supports and uses RTP and RTCP 1110 multiplexing. The Offerer can use this information e.g. for stopping 1111 gathering of RTCP candidates and/or for freeing corresponding 1112 resources. 1114 This behavior is illustrated by the following example Offer that 1115 indicates support for RTP and RTCP multiplexing. 1117 v=0 1118 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com 1119 s= 1120 c=IN IP6 2001:db8:a0b:12f0::3 1121 t=0 0 1122 a=ice-pwd:777uzjYhagZgasd88fgpdd 1123 a=ice-ufrag:Yhh8 1124 m=audio 5000 RTP/AVP 0 1125 a=mid:1 1126 a=rtcp-mux 1127 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host 1129 Once the dialog is established as described in section Section 4.3 1130 the Answerer sends the following INFO request. 1132 INFO sip:alice@example.com SIP/2.0 1133 ... 1134 Info-Package: trickle-ice 1135 Content-type: application/trickle-ice-sdpfrag 1136 Content-Disposition: Info-Package 1137 Content-length: 161 1139 a=ice-pwd:asd88fgpdd777uzjYhagZg 1140 a=ice-ufrag:8hhY 1141 m=audio 9 RTP/AVP 0 1142 a=mid:1 1143 a=rtcp-mux 1144 a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host 1146 This INFO request indicates that the Answerer supports and uses RTP 1147 and RTCP multiplexing as well. It allows the Offerer to omit 1148 gathering of RTCP candidates or releasing already gathered RTCP 1149 candidates. If the INFO request did not contain the a=rtcp-mux 1150 attribute, the Offerer has to gather RTCP candidates unless it wants 1151 to wait until receipt of an Answer that eventually confirms support 1152 or non-support for RTP and RTCP multiplexing. 1154 7. Considerations for Media Multiplexing 1156 The following considerations describe options for Trickle-ICE in 1157 order to give some guidance to implementors on how trickling can be 1158 optimized with respect to providing candidates in case of Media 1159 Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed 1160 that the reader is familiar with 1161 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 1163 ICE candidate exchange is already considered in section 11 of 1164 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are 1165 still valid for Trickle ICE, however, trickling provides more 1166 flexibility for the sequence of candidate exchange, especially in 1167 Full Trickle mode. 1169 Except for bundle-only "m=" lines, a Half Trickle Offerer has to send 1170 an Offer with candidates for all bundled "m=" lines. The additional 1171 flexibility, however, allows a Full Trickle Offerer to initially send 1172 only candidates for the "m=" line with the suggested Offerer BUNDLE 1173 address. 1175 On receipt of the Answer, the Offerer will detect if BUNDLE is 1176 supported by the Answerer and if the suggested Offerer BUNDLE address 1177 was selected. In this case, the Offerer does not need to trickle 1178 further candidates for the remaining "m=" lines in a bundle. 1179 However, if BUNDLE is not supported, the Full Trickle Offerer needs 1180 to gather and trickle candidates for the remaining "m=" lines as 1181 necessary. If the Answerer selects an Offerer BUNDLE address 1182 different from the suggested Offerer BUNDLE address, the Full Trickle 1183 Offerer needs to gather and trickle candidates for the "m=" line that 1184 carries the selected Offerer BUNDLE address. 1186 A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute 1187 [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle- 1188 ice-sdpfrag body if it supports and uses bundling. When doing so, 1189 the Answerer MUST include all identification-tags in the same order 1190 that is used or will be used in the Answer. 1192 Receipt of this attribute at the Offerer in an INFO request prior to 1193 the Answer indicates that the Answerer supports and uses bundling. 1194 The Offerer can use this information e.g. for stopping the gathering 1195 of candidates for the remaining "m=" lines in a bundle and/or for 1196 freeing corresponding resources. 1198 This behaviour is illustrated by the following example Offer that 1199 indicates support for Media Multiplexing. 1201 v=0 1202 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com 1203 s= 1204 c=IN IP6 2001:db8:a0b:12f0::3 1205 t=0 0 1206 a=group:BUNDLE foo bar 1207 a=ice-pwd:777uzjYhagZgasd88fgpdd 1208 a=ice-ufrag:Yhh8 1209 m=audio 10000 RTP/AVP 0 1210 a=mid:foo 1211 a=rtcp-mux 1212 a=rtpmap:0 PCMU/8000 1213 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1214 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host 1215 m=video 10002 RTP/AVP 31 1216 a=mid:bar 1217 a=rtcp-mux 1218 a=rtpmap:31 H261/90000 1219 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1221 The example Offer indicates support for RTP and RTCP multiplexing and 1222 contains a "a=candidate:" attribute only for the m-line with the 1223 suggested Offerer bundle address. Once the dialog is established as 1224 described in Section 4.3 the Answerer sends the following INFO 1225 request. 1227 INFO sip:alice@example.com SIP/2.0 1228 ... 1229 Info-Package: trickle-ice 1230 Content-type: application/trickle-ice-sdpfrag 1231 Content-Disposition: Info-Package 1232 Content-length: 219 1234 a=group:BUNDLE foo bar 1235 a=ice-pwd:asd88fgpdd777uzjYhagZg 1236 a=ice-ufrag:8hhY 1237 m=audio 9 RTP/AVP 0 1238 a=mid:foo 1239 a=rtcp-mux 1240 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host 1241 m=audio 9 RTP/AVP 0 1242 a=mid:bar 1244 This INFO request indicates that the Answerer supports and uses Media 1245 Multiplexing as well. Note, that the second "m=" line shows the 1246 default values as specified in section Section 4.4, e.g. media set 1247 'audio' although 'video' was offered. The receiving ICE Agents MUST 1248 ignore these default values in the pseudo "m=" lines. 1250 The INFO request also indicates that the Answerer accepted the 1251 suggested Offerer Bundle Address. This allows the Offerer to omit 1252 gathering of RTP and RTCP candidates for the other "m=" lines or 1253 releasing already gathered candidates. If the INFO request did not 1254 contain the a=group:BUNDLE attribute, the Offerer has to gather RTP 1255 and RTCP candidates for the other "m=" lines unless it wants to wait 1256 until receipt of an Answer that eventually confirms support or non- 1257 support for Media Multiplexing. 1259 Independent of using Full Trickle or Half Trickle mode, the rules 1260 from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and 1261 Answerer, when putting attributes as specified in Section 9.2 in the 1262 application/trickle-ice-sdpfrag body. 1264 8. SDP 'end-of-candidates' Attribute 1266 8.1. Definition 1268 This section defines a new SDP media-level and session-level 1269 attribute [RFC4566] 'end-of-candidates'. 'end-of-candidates' is a 1270 property attribute [RFC4566], and hence has no value. By including 1271 this attribute in an Offer or Answer the sending agent indicates that 1272 it will not trickle further candidates. When included at session 1273 level this indication applies to the whole session, when included at 1274 media level the indication applies only to the corresponding media 1275 description. 1277 Name: end-of-candidates 1279 Value: N/A 1281 Usage Level: media and session-level 1283 Charset Dependent: no 1285 Mux Category: IDENTICAL 1287 Example: a=end-of-candidates 1289 8.2. Offer/Answer Procedures 1291 The Offerer or Answerer MAY include an "a=end-of-candidates" 1292 attribute in case candidate discovery has ended and no further 1293 candidates are to be trickled. The Offerer or Answerer MUST provide 1294 the "a=end-of-candidates" attribute together with the "a=ice-ufrag" 1295 and "a=ice-pwd" attributes of the current ICE generation as required 1296 by [I-D.ietf-ice-trickle]. When included at session level this 1297 indication applies to the whole session; when included at media level 1298 the indication applies only to the corresponding media description. 1300 Receipt of an "a=end-of-candidates" attribute at an Offerer or 1301 Answerer - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching 1302 the current ICE generation - indicates that gathering of candidates 1303 has ended at the peer, either for the session or only for the 1304 corresponding media description as specified above. The receiving 1305 agent forwards an end-of-candidates indication to the ICE Agent, 1306 which in turn acts as specified in [I-D.ietf-ice-trickle]. 1308 9. Content Type 'application/trickle-ice-sdpfrag' 1310 9.1. Overall Description 1312 A application/trickle-ice-sdpfrag body is used exclusively by the 1313 'trickle-ice' Info Package. Other SDP related applications need to 1314 define their own media type. The INFO request body uses a subset of 1315 the possible SDP lines as defined by the grammar defined in 1316 [RFC4566]. A valid body uses only pseudo "m=" lines and certain 1317 attributes that are needed and/or useful for trickling candidates. 1318 The content adheres to the following grammar. 1320 9.2. Grammar 1322 The grammar of an 'application/trickle-ice-sdpfrag' body is based on 1323 the following ABNF [RFC5234]. It specifies the subset of existing 1324 SDP attributes, that is needed or useful for trickling candidates. 1325 The grammar uses the indicator for case-sensitivity %s as defined in 1326 [RFC7405], but also imports grammars for other SDP attributes that 1327 precede the production of [RFC7405]. A sender SHOULD use lower-case 1328 for attributes from such earlier grammars, but a receiver MUST treat 1329 them case-insensitively. 1331 ; Syntax 1332 trickle-ice-sdpfrag = session-level-fields 1333 pseudo-media-descriptions 1334 session-level-fields = [bundle-group-attribute CRLF] 1335 [ice-lite-attribute CRLF] 1336 ice-pwd-attribute CRLF 1337 ice-ufrag-attribute CRLF 1338 [ice-options-attribute CRLF] 1339 [ice-pacing-attribute CRLF] 1340 [end-of-candidates-attribute CRLF] 1341 extension-attribute-fields 1342 ; for future extensions 1344 ice-lite-attribute = %s"a" "=" ice-lite 1345 ice-pwd-attribute = %s"a" "=" ice-pwd-att 1346 ice-ufrag-attribute = %s"a" "=" ice-ufrag-att 1347 ice-pacing-attribute = %s"a" "=" ice-pacing-att 1348 ice-options-attribute = %s"a" "=" ice-options 1349 bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics 1350 *(SP identification-tag) 1351 bundle-semantics = "BUNDLE" 1352 end-of-candidates-attribute = %s"a" "=" end-of-candidates 1353 end-of-candidates = %s"end-of-candidates" 1354 extension-attribute-fields = attribute-fields 1356 pseudo-media-descriptions = *( media-field 1357 trickle-ice-attribute-fields 1358 [extension-attribute-fields] ) 1359 ; for future extensions 1360 trickle-ice-attribute-fields = %s"a" "=" mid-attribute CRLF 1361 [%s"a" "=" %s"rtcp" CRLF] 1362 [%s"a" "=" %s"rtcp-mux" CRLF] 1363 [%s"a" "=" %s"rtcp-mux-only" CRLF] 1364 *(candidate-attributes CRLF) 1365 [ice-pwd-attribute CRLF] 1366 [ice-ufrag-attribute CRLF] 1367 [remote-candidate-attribute CRLF] 1368 [end-of-candidates-attribute CRLF] 1369 remote-candidate-attribute = %s"a" "=" remote-candidate-att 1370 candidate-attributes = %s"a" "=" candidate-attribute 1372 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- 1373 pacing-att, ice-options, candidate-attribute remote-candidate-att 1374 from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute 1375 ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The 1376 "a=rtcp" attribute is defined in [RFC3605], the "a=rtcp-mux" 1377 attribute in [RFC5761] and the "a=rtcp-mux-only" attribute in 1379 [I-D.ietf-mmusic-mux-exclusive]. The latter attributes lack a formal 1380 grammar in their corresponding RFC and are reproduced here. 1382 An Agent MUST ignore any received unknown extension-attribute-fields. 1384 10. Info Package 1386 10.1. Rationale - Why INFO? 1388 The decision to use SIP INFO requests as a candidate transport method 1389 is based primarily on their lightweight nature. Once a dialog has 1390 been established, INFO requests can be exchanged both ways with no 1391 restrictions on timing and frequency and no risk of collision. 1393 A critical fact is that the sending of Trickle ICE candidates in one 1394 direction is entirely uncoupled from sending candidates in the other 1395 direction. Thus, the sending of candidates in each direction can be 1396 done by a stream of INFO requests that is not correlated with the 1397 stream of INFO requests in the other direction. And since each INFO 1398 request cumulatively includes the contents of all previous INFO 1399 requests in that direction, ordering between INFO requests need not 1400 be preserved. All of this permits using largely-independent INFO 1401 requests. 1403 Contrarily, UPDATE or other offer/answer mechanisms assume that the 1404 messages in each direction are tightly coupled with messages in the 1405 other direction. Using Offer/Answer and UPDATE requests [RFC3311] 1406 would introduce the following complications: 1408 Blocking of messages: [RFC3264] defines Offer/Answer as a strictly 1409 sequential mechanism. There can only be a maximum of one active 1410 exchange at any point of time. Both sides cannot simultaneously 1411 send Offers nor can they generate multiple Offers prior to 1412 receiving an Answer. Using UPDATE requests for candidate 1413 transport would therefore imply the implementation of a candidate 1414 pool at every agent where candidates can be stored until it is 1415 once again that agent's "turn" to emit an Answer or a new Offer. 1416 Such an approach would introduce non-negligible complexity for no 1417 additional value. 1419 Elevated risk of glare: The sequential nature of Offer/Answer also 1420 makes it impossible for both sides to send Offers simultaneously. 1421 What's worse is that there are no mechanisms in SIP to actually 1422 prevent that. [RFC3261], where the situation of Offers crossing 1423 on the wire is described as "glare", only defines a procedure for 1424 addressing the issue after it has occurred. According to that 1425 procedure both Offers are invalidated and both sides need to retry 1426 the negotiation after a period between 0 and 4 seconds. The high 1427 likelihood for glare to occur and the average two second back-off 1428 intervals implies that the duration of Trickle ICE processing 1429 would not only fail to improve but actually exceed those of 1430 regular ICE. 1432 INFO messages decouple the exchange of candidates from the Offer/ 1433 Answer negotiation and are subject to none of the glare issues 1434 described above, which makes them a very convenient and lightweight 1435 mechanism for asynchronous delivery of candidates. 1437 Using in-dialog INFO messages also provides a way of guaranteeing 1438 that candidates are delivered end-to-end, between the same entities 1439 that are actually in the process of initiating a session. Out-of- 1440 dialog alternatives would have implied requiring support for Globally 1441 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 1442 adoption levels, would have constituted too strong of a constraint to 1443 the adoption of Trickle ICE. 1445 10.2. Overall Description 1447 This specification defines an Info Package for use by SIP User Agents 1448 implementing Trickle ICE. INFO requests carry ICE candidates 1449 discovered after the peer user agents have confirmed mutual support 1450 for Trickle ICE. 1452 10.3. Applicability 1454 The purpose of the ICE protocol is to establish a media path in the 1455 presence of NAT and firewalls. The candidates are transported in 1456 INFO requests and are part of this establishment. 1458 Candidates sent by a Trickle ICE Agent after the Offer, follow the 1459 same signaling path and reach the same entity as the Offer itself. 1460 While it is true that GRUUs can be used to achieve this, one of the 1461 goals of this specification is to allow operation of Trickle ICE in 1462 as many environments as possible including those without GRUU 1463 support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not 1464 satisfy this goal. 1466 10.4. Info Package Name 1468 This document defines a SIP Info Package as per [RFC6086]. The Info 1469 Package token name for this package is "trickle-ice" 1471 10.5. Info Package Parameters 1473 This document does not define any Info Package parameters. 1475 10.6. SIP Option Tags 1477 [RFC6086] allows Info Package specifications to define SIP option- 1478 tags. This specification extends the option-tag construct of the SIP 1479 grammar as follows: 1481 option-tag /= "trickle-ice" 1483 SIP entities that support this specification MUST place the 'trickle- 1484 ice' option-tag in a SIP Supported: header field within all SIP 1485 INVITE requests and responses. 1487 When responding to, or generating a SIP OPTIONS request a SIP entity 1488 MUST also include the 'trickle-ice' option-tag in a SIP Supported: 1489 header field. 1491 10.7. Info Request Body Parts 1493 Entities implementing this specification MUST include a payload of 1494 type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 in 1495 SIP INFO requests. The payload is used to convey SDP-encoded ICE 1496 candidates. 1498 10.8. Info Package Usage Restrictions 1500 This document does not define any Info Package Usage Restrictions. 1502 10.9. Rate of INFO Requests 1504 Given that IP addresses may be gathered rapidly a Trickle ICE Agent 1505 with many network interfaces might create a high rate of INFO 1506 requests if every newly detected candidate is trickled individually 1507 without aggregation. Implementors MUST consider aggregating ICE 1508 candidates in case that UDP is used as transport protocol and send 1509 INFOs only at some configurable intervals. 1511 If the INFO requests are sent on top of TCP, which is probably the 1512 standard way, this is not an issue for the network anymore, but it 1513 can remain one for SIP proxies and other intermediaries forwarding 1514 the SIP INFO messages. Also, an endpoint may not be able to tell 1515 that it has congestion controlled transport all the way. 1517 10.10. Info Package Security Considerations 1519 See Section 13 1521 11. Deployment Considerations 1523 Trickle ICE uses two mechanism for exchange of candidate information. 1524 This imposes new requirements to certain middleboxes that are used in 1525 some networks, e.g. for monitoring purposes. While the first 1526 mechanism, SDP Offers and Answers, is already used by regular ICE and 1527 is assumed to be supported, the second mechanism, INFO request 1528 bodies, needs to be considered by such middleboxes as well when 1529 trickle ICE is used. Such middleboxes need to make sure that they 1530 remain in the signaling path of the INFO requests and need to 1531 understand the INFO request body. 1533 12. IANA Considerations 1535 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1536 document. ] 1538 12.1. SDP 'end-of-candidates' Attribute 1540 This section defines a new SDP media-level and session-level 1541 attribute [RFC4566] , 'end-of-candidates'. 'end-of-candidates' is a 1542 property attribute [RFC4566] , and hence has no value. 1544 Name: end-of-candidates 1546 Value: N/A 1548 Usage Level: media and session 1550 Charset Dependent: no 1552 Purpose: The sender indicates that it will not trickle 1553 further ICE candidates. 1555 O/A Procedures: RFCXXX defines the detailed 1556 SDP Offer/Answer procedures for 1557 the 'end-of-candidates' attribute. 1559 Mux Category: IDENTICAL 1561 Reference: RFCXXXX 1563 Example: 1565 a=end-of-candidates 1567 12.2. Media Type 'application/trickle-ice-sdpfrag' 1569 This document defines a new Media Type 'application/trickle-ice- 1570 sdpfrag' in accordance with [RFC6838]. 1572 Type name: application 1574 Subtype name: trickle-ice-sdpfrag 1576 Required parameters: None. 1578 Optional parameters: None. 1580 Encoding considerations: 1582 The media contents follow the same rules as SDP, except as 1583 noted in this document. The media contents are text, with the 1584 grammar specified in Section 9.2. 1586 Although the initially defined content of a trickle-ice-sdpfrag 1587 body does only include ASCII characters, UTF-8 encoded content 1588 might be introduced via extension attributes. The "a=charset:" 1589 attribute may be used to signal the presence of other character 1590 sets in certain parts of a trickle-ice-sdpfrag body (see 1591 [RFC4566]). Arbitrary binary content cannot be directly 1592 represented in SDP or a trickle-ice-sdpfrag body. 1594 Security considerations: 1596 See [RFC4566] and RFCXXXX 1598 Interoperability considerations: 1600 See RFCXXXX 1602 Published specification: 1604 See RFCXXXX 1606 Applications which use this Media Type: 1608 Trickle-ICE 1610 Fragment identifier considerations: N/A 1612 Additional information: 1614 Deprecated alias names for this type: N/A 1616 Magic number(s): N/A 1618 File extension(s): N/A 1620 Macintosh File Type Code(s): N/A 1622 Person and email address to contact for further information: 1624 The IESG (iesg@ietf.org) 1626 Intended usage: 1628 Trickle-ICE for SIP as specified in RFCXXXX. 1630 Restrictions on usage: N/A 1632 Author/Change controller: 1634 The IESG (iesg@ietf.org) 1636 Provisional registration? (standards tree only): N/A 1638 12.3. SIP Info Package 'trickle-ice' 1640 This document defines a new SIP Info Package named 'trickle-ice' and 1641 updates the Info Packages Registry with the following entry. 1643 +-------------+-----------+ 1644 | Name | Reference | 1645 +-------------+-----------+ 1646 | trickle-ice | [RFCXXXX] | 1647 | | | 1648 +-------------+-----------+ 1650 12.4. SIP Option Tag 'trickle-ice' 1652 This specification registers a new SIP option tag 'trickle-ice' as 1653 per the guidelines in Section 27.1 of [RFC3261] and updates the 1654 "Option Tags" section of the SIP Parameter Registry with the 1655 following entry: 1657 +-------------+-------------------------------------+-----------+ 1658 | Name | Description | Reference | 1659 +-------------+-------------------------------------+-----------+ 1660 | trickle-ice | This option tag is used to indicate | [RFCXXXX] | 1661 | | that a UA supports and understands | | 1662 | | Trickle-ICE. | | 1663 +-------------+-------------------------------------+-----------+ 1665 13. Security Considerations 1667 The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], 1668 [RFC6086] and [I-D.ietf-ice-trickle] apply. This document clarifies 1669 how the above specifications are used together for trickling 1670 candidates and does not create additional security risks. 1672 The new Info Package 'trickle-ice' and the new Media Type 1673 'application/trickle-ice-sdpfrag' do not introduce additional 1674 security considerations when used in the context of Trickle ICE. 1675 Both are not intended to be used for other applications, so any 1676 security considerations for its use in other contexts is out of the 1677 scope of this document 1679 14. Acknowledgements 1681 The authors like to thank Flemming Andreasen, Ayush Jain, Paul 1682 Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount and Martin 1683 Thomson for reviewing and/or making various suggestions for 1684 improvements and optimizations. 1686 The authors also like to thank Flemming Andreasen for shepherding 1687 this document and Ben Campbell for his AD review and suggestions. 1689 Many thanks to Dale Worley for Gen-Art review and proposed 1690 enhancements for several sections. 1692 Many thanks to Joerg Ott for TSV-Art review and suggested 1693 improvements. 1695 The authors thank Shawn Emery for Security Directorate review. 1697 15. Change Log 1699 [RFC EDITOR NOTE: Please remove this section when publishing]. 1701 Changes from draft-ietf-mmusic-trickle-ice-sip-01 1703 o Editorial Clean up 1705 o IANA Consideration added 1707 o Security Consideration added 1709 o RTCP and BUNDLE Consideration added with rules for including 1710 "a=rtcp-mux" and "a=group: BUNDLLE" attributes 1712 o 3PCC Consideration added 1714 o Clarified that 18x w/o answer is sufficient to create a dialog 1715 that allows for trickling to start 1717 o Added remaining Info Package definition sections as outlined in 1718 section 10 of [RFC6086] 1720 o Added definition of application/sdpfrag making draft-ivov-mmusic- 1721 sdpfrag obsolete 1723 o Added pseudo m-lines as additional separator in sdpfrag bodies for 1724 Trickle ICE 1726 o Added ABNF for sdp-frag bodies and Trickle-ICE package 1728 Changes from draft-ietf-mmusic-trickle-ice-sip-02 1730 o Removed definition of application/sdpfrag 1732 o Replaced with new type application/trickle-ice-sdpfrag 1734 o RTCP and BUNDLE Consideration enhanced with some examples 1736 o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to 1737 normative reference 1739 o Removed reference to 4566bis 1741 o Addressed review comment from Simon Perreault 1743 Changes from draft-ietf-mmusic-trickle-ice-sip-03 1745 o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis 1746 and draft-ietf-mmusic-ice-sip-sdp 1748 o Corrected Figure 10, credits to Ayush Jain for finding the bug 1750 o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- 1751 ice-sip-sdp 1753 o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- 1754 mux-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive 1756 o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for 1757 the application/trickle-ice-sdpfrag body 1759 Changes from draft-ietf-mmusic-trickle-ice-sip-04 1761 o considered comments from Christer Holmberg 1762 o corrected grammar for INFO package, such that ice-ufrag/pwd are 1763 also allowed on media-level as specified in 1764 [I-D.ietf-mmusic-ice-sip-sdp] 1766 o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] 1768 o Added formal definition for the end-of-candidates attribute 1770 Changes from draft-ietf-mmusic-trickle-ice-sip-05 1772 o considered further comments from Christer Holmberg 1774 o editorial comments on section 3 addressed 1776 o moved section 3.1 to section 10.1 and applied some edits 1778 o replaced the term "previously sent candidates" with "currently 1779 known and used candidates". 1781 Changes from draft-ietf-mmusic-trickle-ice-sip-06 1783 o editorial fixes 1785 o additional text on the content of the INFO messages. 1787 o recommendation on what to do if a previously sent candidate is 1788 unexpectedly missing in a subsequent INFO 1790 o terminology alignment with draft-ietf-ice-trickle-07 1792 Changes from draft-ietf-mmusic-trickle-ice-sip-07 1794 o editorial fixes 1796 o clarification on ordering of candidates for alignment with draft- 1797 ietf-ice-trickle-12 1799 o O/A procedures for end-of-candidates attribute described here 1800 after corresponding procedures have been removed from draft-ietf- 1801 ice-trickle-11 1803 o using IPv6 addresses in examples 1805 Changes from draft-ietf-mmusic-trickle-ice-sip-08 1807 o editorial fixes/clarification based on Flemmings review 1808 o Description of Trickle specifics in O/A procedures for initial O/A 1809 exchange and specification of ICE mismatch exception 1811 Changes from draft-ietf-mmusic-trickle-ice-sip-09 1813 o editorial fixes/correction of references 1815 o adding missing Ref to RFC3605 in section 6, 5th para 1817 o replaced remaining IPv4 adresses with IPv6 1819 o Added text for handling a=rtcp in case of default RTP address 1820 0.0.0.0:9 based on comment from Roman Shpount. 1822 Changes from draft-ietf-mmusic-trickle-ice-sip-10 1824 o editorial fixes due to idnits output 1826 Changes from draft-ietf-mmusic-trickle-ice-sip-11 1828 o addressing comments from Ben Campell's AD review and Christer's 1829 review 1831 o Numerous editorial improvements/corrections 1833 o Added [RFC8174] boiler plate and adapted usage of normative 1834 language 1836 o Clarified terminology ICE modules .vs. ICE agent 1838 o Added more detailed OA procedures 1840 o Corrected default values in m-line and usage of "a=mid:" attribute 1841 explicitly mentioned for offer/answer 1843 o Removed explicit mentioning of XMPP 1845 o Added Deployment Considerations section 1847 o Fixed ref for rfc5245bis 1849 Changes from draft-ietf-mmusic-trickle-ice-sip-12 1851 o addressing comments from Gen-Art review, TSV-Art review and 1852 Security Directorate review 1854 o Numerous editorial improvements/corrections/clarifications 1856 16. References 1858 16.1. Normative References 1860 [I-D.ietf-ice-rfc5245bis] 1861 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1862 Connectivity Establishment (ICE): A Protocol for Network 1863 Address Translator (NAT) Traversal", draft-ietf-ice- 1864 rfc5245bis-17 (work in progress), February 2018. 1866 [I-D.ietf-ice-trickle] 1867 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 1868 "Trickle ICE: Incremental Provisioning of Candidates for 1869 the Interactive Connectivity Establishment (ICE) 1870 Protocol", draft-ietf-ice-trickle-16 (work in progress), 1871 February 2018. 1873 [I-D.ietf-mmusic-ice-sip-sdp] 1874 Petit-Huguenin, M., Keranen, A., and S. Nandakumar, 1875 "Session Description Protocol (SDP) Offer/Answer 1876 procedures for Interactive Connectivity Establishment 1877 (ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in 1878 progress), November 2017. 1880 [I-D.ietf-mmusic-mux-exclusive] 1881 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 1882 Multiplexing using SDP", draft-ietf-mmusic-mux- 1883 exclusive-12 (work in progress), May 2017. 1885 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1886 Holmberg, C., Alvestrand, H., and C. Jennings, 1887 "Negotiating Media Multiplexing Using the Session 1888 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1889 negotiation-48 (work in progress), January 2018. 1891 [I-D.ietf-mmusic-sdp-mux-attributes] 1892 Nandakumar, S., "A Framework for SDP Attributes when 1893 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1894 (work in progress), December 2016. 1896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1897 Requirement Levels", BCP 14, RFC 2119, 1898 DOI 10.17487/RFC2119, March 1997, 1899 . 1901 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1902 A., Peterson, J., Sparks, R., Handley, M., and E. 1903 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1904 DOI 10.17487/RFC3261, June 2002, 1905 . 1907 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1908 Provisional Responses in Session Initiation Protocol 1909 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1910 . 1912 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1913 with Session Description Protocol (SDP)", RFC 3264, 1914 DOI 10.17487/RFC3264, June 2002, 1915 . 1917 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1918 in Session Description Protocol (SDP)", RFC 3605, 1919 DOI 10.17487/RFC3605, October 2003, 1920 . 1922 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1923 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1924 July 2006, . 1926 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1927 Specifications: ABNF", STD 68, RFC 5234, 1928 DOI 10.17487/RFC5234, January 2008, 1929 . 1931 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1932 Control Packets on a Single Port", RFC 5761, 1933 DOI 10.17487/RFC5761, April 2010, 1934 . 1936 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1937 Protocol (SDP) Grouping Framework", RFC 5888, 1938 DOI 10.17487/RFC5888, June 2010, 1939 . 1941 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1942 Initiation Protocol (SIP) INFO Method and Package 1943 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1944 . 1946 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1947 Specifications and Registration Procedures", BCP 13, 1948 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1949 . 1951 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1952 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1953 . 1955 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1956 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1957 May 2017, . 1959 16.2. Informative References 1961 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1962 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1963 2002, . 1965 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1966 Camarillo, "Best Current Practices for Third Party Call 1967 Control (3pcc) in the Session Initiation Protocol (SIP)", 1968 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 1969 . 1971 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1972 "Indicating User Agent Capabilities in the Session 1973 Initiation Protocol (SIP)", RFC 3840, 1974 DOI 10.17487/RFC3840, August 2004, 1975 . 1977 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1978 Agent URIs (GRUUs) in the Session Initiation Protocol 1979 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 1980 . 1982 Authors' Addresses 1984 Emil Ivov 1985 Jitsi 1986 Strasbourg 67000 1987 France 1989 Phone: +33 6 72 81 15 55 1990 Email: emcho@jitsi.org 1991 Thomas Stach 1992 Unaffiliated 1993 Vienna 1130 1994 Austria 1996 Email: thomass.stach@gmail.com 1998 Enrico Marocco 1999 Telecom Italia 2000 Via G. Reiss Romoli, 274 2001 Turin 10148 2002 Italy 2004 Email: enrico.marocco@telecomitalia.it 2006 Christer Holmberg 2007 Ericsson 2008 Hirsalantie 11 2009 Jorvas 02420 2010 Finland 2012 Email: christer.holmberg@ericsson.com