idnits 2.17.1 draft-ietf-mmusic-trickle-ice-sip-16.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 7, 2018) is 2149 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 1626, but not defined == Unused Reference: 'RFC8085' is defined on line 1955, but no explicit reference was found in the text == Unused Reference: 'RFC3725' is defined on line 1969, 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 9, 2018 Unaffiliated 6 E. Marocco 7 Telecom Italia 8 C. Holmberg 9 Ericsson 10 June 7, 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-16 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), defines a new SIP Info Package to 30 support this usage together with the corresponding media type, SDP 31 attribute and SIP option tag. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 9, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Discovery issues . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Relationship with the Offer/Answer Model . . . . . . . . 6 72 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 7 73 4.1. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8 74 4.1.1. Sending the Initial Offer . . . . . . . . . . . . . . 8 75 4.1.2. Receiving the Initial Offer . . . . . . . . . . . . . 9 76 4.1.3. Sending the Initial Answer . . . . . . . . . . . . . 9 77 4.1.4. Receiving the Initial Answer . . . . . . . . . . . . 10 78 4.2. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10 79 4.3. Establishing the Dialog . . . . . . . . . . . . . . . . . 10 80 4.3.1. Establishing Dialog State through Reliable 81 Offer/Answer Delivery . . . . . . . . . . . . . . . . 11 82 4.3.2. Establishing Dialog State through Unreliable 83 Offer/Answer Delivery . . . . . . . . . . . . . . . . 12 84 4.3.3. Initiating Trickle ICE without an SDP Answer . . . . 14 85 4.4. Delivering Candidates in INFO Requests . . . . . . . . . 16 86 5. Initial Discovery of Trickle ICE Support . . . . . . . . . . 20 87 5.1. Provisioning Support for Trickle ICE . . . . . . . . . . 21 88 5.2. Trickle ICE Discovery with Globally Routable User Agent 89 URIs (GRUU) . . . . . . . . . . . . . . . . . . . . . . . 21 90 5.3. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 22 91 6. Considerations for RTP and RTCP Multiplexing . . . . . . . . 24 92 7. Considerations for Media Multiplexing . . . . . . . . . . . . 26 93 8. SDP 'end-of-candidates' Attribute . . . . . . . . . . . . . . 28 94 8.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 28 95 8.2. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 29 96 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 29 97 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 29 98 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 29 99 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 32 100 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 32 101 10.2. Overall Description . . . . . . . . . . . . . . . . . . 33 102 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 33 103 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 34 104 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 34 105 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 34 106 10.7. Info Request Body Parts . . . . . . . . . . . . . . . . 34 107 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 34 108 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 34 109 10.10. Info Package Security Considerations . . . . . . . . . . 35 110 11. Deployment Considerations . . . . . . . . . . . . . . . . . . 35 111 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 112 12.1. SDP 'end-of-candidates' Attribute . . . . . . . . . . . 35 113 12.2. Media Type 'application/trickle-ice-sdpfrag' . . . . . . 36 114 12.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 38 115 12.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 38 116 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 117 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 118 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 119 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 120 16.1. Normative References . . . . . . . . . . . . . . . . . . 43 121 16.2. Informative References . . . . . . . . . . . . . . . . . 46 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 124 1. Introduction 126 The Interactive Connectivity Establishment (ICE) protocol 127 [I-D.ietf-ice-rfc5245bis] describes a mechanism for Network Address 128 Translator (NAT) traversal that consists of three main phases. 130 During the first phase an agent gathers a set of candidate transport 131 addresses (source IP address, port and transport protocol). This is 132 followed by a second phase where these candidates are sent to a 133 remote agent within the Session Description Protocol (SDP) body of a 134 SIP message. At the remote agent the gathering procedure is repeated 135 and candidates are sent to the first agent. Once the candidate 136 information is available, a third phase starts in parallel where 137 connectivity between all candidates in both sets is checked 138 (connectivity checks). Once these phases have been completed, and 139 only then, both agents can begin communication. 141 According to [I-D.ietf-ice-rfc5245bis] the three phases above happen 142 consecutively, in a blocking way, which can introduce undesirable 143 setup delay during session establishment. The Trickle ICE extension 144 [I-D.ietf-ice-trickle] defines generic semantics required for these 145 ICE phases to happen in a parallel, non-blocking way and hence speed 146 up session establishment. 148 This specification defines a usage of Trickle ICE with the Session 149 Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates 150 are to be exchanged incrementally using SIP INFO requests [RFC6086] 151 and how the Half Trickle and Full Trickle modes defined in 152 [I-D.ietf-ice-trickle] are to be used by SIP User Agents (UAs) 153 depending on their expectations for support of Trickle ICE by a 154 remote agent. 156 This document defines a new Info Package as specified in [RFC6086] 157 for use with Trickle ICE together with the corresponding media type, 158 SDP attribute and SIP option tag. 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119], [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 This specification makes use of terminology defined by the protocol 169 for Interactive Connectivity Establishment in 170 [I-D.ietf-ice-rfc5245bis] and its Trickle ICE extension 171 [I-D.ietf-ice-trickle]. It is assumed that the reader is familiar 172 with the terminology from both documents. 174 [I-D.ietf-ice-rfc5245bis] also describes how ICE makes use of the 175 Session Traversal Utilities for NAT (STUN) protocol [RFC5389] and its 176 extension Traversal Using Relay NAT (TURN) [RFC5766]. 178 3. Protocol Overview 180 When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the 181 ICE candidates are exchanged solely via SDP Offer/Answer as per 182 [RFC3264]. This specification defines an additional mechanism where 183 candidates can be exchanged using SIP INFO messages and a newly 184 defined Info Package [RFC6086]. This allows ICE candidates also to 185 be sent in parallel to an ongoing Offer/Answer negotiation and/or 186 after the completion of the Offer/Answer negotiation. 188 Typically, in cases where Trickle ICE is fully supported, the Offerer 189 sends an INVITE request containing a subset of candidates. Once an 190 early dialog is established the Offerer can continue sending 191 candidates in INFO requests within that dialog. 193 Similarly, an Answerer can send ICE candidates using INFO requests 194 within the dialog established by its 18x provisional response. 195 Figure 1 shows such a sample exchange: 197 STUN/Turn STUN/TURN 198 Servers Alice Bob Servers 199 | | | | 200 | STUN Bi.Req. | INVITE (Offer) | | 201 |<--------------|------------------------>| | 202 | | 183 (Answer) | TURN Alloc Req | 203 | STUN Bi.Resp. |<------------------------|--------------->| 204 |-------------->| INFO/OK (SRFLX Cand.) | | 205 | |------------------------>| TURN Alloc Resp| 206 | | INFO/OK (Relay Cand.) |<---------------| 207 | |<------------------------| | 208 | | | | 209 | | More Cands & ConnChecks| | 210 | |<=======================>| | 211 | | | | 212 | | 200 OK | | 213 | |<------------------------| | 214 | | ACK | | 215 | |------------------------>| | 216 | | | | 217 | |<===== MEDIA FLOWS =====>| | 218 | | | | 220 Note: SRFLX denotes server-reflexive candidates 222 Figure 1: Sample Trickle ICE scenario with SIP 224 3.1. Discovery issues 226 In order to benefit from Trickle ICE's full potential and reduce 227 session establishment latency to a minimum, Trickle ICE agents need 228 to generate SDP Offers and Answers that contain incomplete, 229 potentially empty sets of candidates. Such Offers and Answers can 230 only be handled meaningfully by agents that actually support 231 incremental candidate provisioning, which implies the need to confirm 232 such support before using it. 234 Contrary to other protocols, where "in advance" capability discovery 235 is widely implemented, the mechanisms that allow this for SIP (i.e., 236 a combination of UA Capabilities [RFC3840] and Globally Routable User 237 Agent URIs (GRUU) [RFC5627]) have only seen low levels of adoption. 238 This presents an issue for Trickle ICE implementations as SIP UAs do 239 not have an obvious means of verifying that their peer will support 240 incremental candidate provisioning. 242 The Half Trickle mode of operation defined in the Trickle ICE 243 specification [I-D.ietf-ice-trickle] provides one way around this, by 244 requiring the first Offer to contain a complete set of local ICE 245 candidates and only using incremental provisioning of remote 246 candidates for the rest of the session. 248 While using Half Trickle does provide a working solution it also 249 comes at the price of increased latency. Section 5 therefore makes 250 several alternative suggestions that enable SIP UAs to engage in Full 251 Trickle right from their first Offer: Section 5.1 discusses the use 252 of on-line provisioning as a means of allowing use of Trickle ICE for 253 all endpoints in controlled environments. Section 5.2 describes 254 anticipatory discovery for implementations that actually do support 255 GRUU and UA Capabilities and Section 5.3 discusses the implementation 256 and use of Half Trickle by SIP UAs where none of the above are an 257 option. 259 3.2. Relationship with the Offer/Answer Model 261 From the perspective of SIP middle boxes and proxies the Offer/Answer 262 exchange for Trickle ICE looks partly similar to the Offer/Answer 263 exchange for regular ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. 264 However, in order to have the full picture of the candidate exchange, 265 the newly introduced INFO messages need to be considered as well. 267 +-------------------------------+ +-------------------------------+ 268 | Alice +--------------+ | | +--------------+ Bob | 269 | | Offer/Answer | | | | Offer/Answer | | 270 | +--------+ | Module | | | | Module | +--------+ | 271 | | ICE | +--------------+ | | +--------------+ | ICE | | 272 | | Module | | | | | | Module | | 273 | +--------+ | | | | +--------+ | 274 +-------------------------------+ +-------------------------------+ 275 | | | | 276 | | INVITE (Offer) | | 277 | |--------------------->| | 278 | | 183 (Answer) | | 279 | |<---------------------| | 280 | | | | 281 | | 282 | SIP INFO (more candidates) | 283 |----------------------------------------------------->| 284 | SIP INFO (more candidates) | 285 |<-----------------------------------------------------| 286 | | 287 | STUN Binding Requests/Responses | 288 |----------------------------------------------------->| 289 | STUN Binding Requests/Responses | 290 |<-----------------------------------------------------| 291 | | 293 Figure 2: Distinguishing between Trickle ICE and traditional 294 signaling. 296 From an architectural viewpoint, as displayed in Figure 2, exchanging 297 candidates through SIP INFO requests could be represented as 298 signaling between ICE modules and not between Offer/Answer modules of 299 SIP User Agents. Then, such INFO requests do not impact the state of 300 the Offer/Answer transaction other than providing additional 301 candidates. Consequently, INFO requests are not considered Offers or 302 Answers. Nevertheless, candidates that have been exchanged using 303 INFO requests SHALL be included in subsequent Offers or Answers. The 304 version number in the "o=" line of that subsequent Offer needs to be 305 incremented by 1 per the rules in [RFC3264]. 307 4. Incremental Signaling of ICE candidates 309 Trickle ICE Agents will exchange ICE descriptions compliant to 310 [I-D.ietf-ice-trickle] via Offer/Answer procedures and/or INFO 311 request bodies. This requires the following SIP-specific extensions: 313 1. Trickle ICE Agents MUST indicate support for Trickle ICE by 314 including the SIP option-tag 'trickle-ice' in a SIP Supported: 315 header field within all SIP INVITE requests and responses. 317 2. Trickle ICE Agents MUST indicate support for Trickle ICE by 318 including the ice-option 'trickle' within all SDP Offers and 319 Answers in accordance to [I-D.ietf-ice-trickle]. 321 3. Trickle ICE Agents MAY include any number of ICE candidates, i.e. 322 from zero to the complete set of candidates, in their initial 323 Offer or Answer. If the complete candidate set is included 324 already in the initial Offer, this is called Half-Trickle. 326 4. Trickle ICE Agents MAY exchange additional ICE candidates using 327 INFO requests within an existing INVITE dialog usage (including 328 an early dialog) as specified in [RFC6086]. The INFO requests 329 carry an Info-Package: trickle-ice. Trickle ICE Agents MUST be 330 prepared to receive INFO requests within that same dialog usage, 331 containing additional candidates and/or an indication that 332 trickling of such candidates has ended. 334 5. Trickle ICE Agents MAY exchange additional ICE candidates before 335 the Answerer has sent the Answer provided that an invite dialog 336 usage is established at both Trickle ICE Agents. Note that in 337 case of forking multiple early dialogs may exist. 339 The following sections provide further details on how Trickle ICE 340 Agents perform the initial Offer/Answer exchange (Section 4.1), 341 perform subsequent Offer/Answer exchanges (Section 4.2) and establish 342 the INVITE dialog usage (Section 4.3) such that they can 343 incrementally trickle candidates (Section 4.4). 345 4.1. Initial Offer/Answer Exchange 347 4.1.1. Sending the Initial Offer 349 If the Offerer includes candidates in its initial Offer, it MUST 350 encode these candidates as specified in 351 [I-D.ietf-mmusic-ice-sip-sdp]. 353 If the Offerer wants to send its initial Offer before knowing any 354 candidate for one or more media descriptions, it MUST set the port to 355 the default value '9' for these media descriptions. If the Offerer 356 does not want to include the host IP address in the corresponding 357 c-line, e.g. due to privacy reasons, it SHOULD include a default 358 address in the c-line, which is set to the IPv4 address 0.0.0.0 or to 359 the IPv6 equivalent ::. 361 In this case, the Offerer obviously cannot know the RTCP transport 362 address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. 363 This avoids potential ICE mismatch (see 364 [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. 366 If the Offerer wants to use RTCP multiplexing [RFC5761] and/or 367 exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still 368 will include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in 369 the initial Offer. 371 In any case, the Offerer MUST include the attribute "a=ice- 372 options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST 373 include in each "m="-line a "a=mid:" attribute in accordance to 374 [RFC5888]. The "a=mid:" attribute identifies the "m="-line to which 375 a candidate belongs and helps in case of multiple "m="-lines, when 376 candidates gathering could occur in a order different from the order 377 of the "m="-lines. 379 4.1.2. Receiving the Initial Offer 381 If the initial Offer included candidates, the Answerer uses these 382 candidates to start ICE processing as specified in 383 [I-D.ietf-ice-trickle]. 385 If the initial Offer included the attribute a=ice-options:trickle, 386 the Answerer MUST be prepared for receiving trickled candidates later 387 on. 389 In case of a "m/c=" line with default values none of the eventually 390 trickled candidates will match the default destination. This 391 situation MUST NOT cause an ICE mismatch (see 392 [I-D.ietf-mmusic-ice-sip-sdp]). 394 4.1.3. Sending the Initial Answer 396 If the Answerer includes candidates in its initial Answer, it MUST 397 encode these candidates as specified in 398 [I-D.ietf-mmusic-ice-sip-sdp]. 400 If the Answerer wants to send its initial Answer before knowing any 401 candidate for one or more media descriptions, it MUST set the port to 402 the default value '9' for these media descriptions. If the Answerer 403 does not want to include the host IP address in the corresponding 404 c-line, e.g. due to privacy reasons, it SHOULD include a default 405 address in the c-line, which is set to the IPv4 address 0.0.0.0 or to 406 the IPv6 equivalent ::. 408 In this case, the Answerer obviously cannot know the RTCP transport 409 address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. 410 This avoids potential ICE mismatch (see 411 [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. 413 If the Answerer accepts to use RTCP multiplexing [RFC5761] and/or 414 exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it will 415 include the "a=rtcp-mux" attribute in the initial Answer. 417 In any case, the Answerer MUST include the attribute "a=ice- 418 options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST 419 include in each "m="-line a "a=mid:" attribute in accordance to 420 [RFC5888]. 422 4.1.4. Receiving the Initial Answer 424 If the initial Answer included candidates, the Offerer uses these 425 candidates to start ICE processing as specified in 426 [I-D.ietf-ice-trickle]. 428 In case of a "m/c=" line with default values none of the eventually 429 trickled candidates will match the default destination. This 430 situation MUST NOT cause an ICE mismatch (see 431 [I-D.ietf-mmusic-ice-sip-sdp]). 433 4.2. Subsequent Offer/Answer Exchanges 435 Subsequent Offer/Answer exchanges are handled as for regular ICE (see 436 section 4.2 of [I-D.ietf-mmusic-ice-sip-sdp]). 438 If an Offer or Answer needs to be sent while the ICE agents are in 439 the middle of trickling section 3.2 of [I-D.ietf-mmusic-ice-sip-sdp]) 440 applies. This means that an ICE agent includes candidate attributes 441 for all local candidates it had trickled previously for a specific 442 media stream. 444 [RFC EDITOR NOTE: The section 3.2 in above sentence is correct for 445 version 20 of said I-D. Authors need to cross-check during Auth48 446 since it could have have changed in the meantime.] 448 4.3. Establishing the Dialog 450 In order to be able to start trickling, the following two conditions 451 need to be satisfied at the SIP UAs: 453 o Trickle ICE support at the peer agent MUST be confirmed. 455 o A dialog MUST have been created between the peers. 457 Section 5 discusses in detail the various options for satisfying the 458 first of the above conditions. Regardless of those mechanisms, 459 however, agents are certain to have a clear understanding of whether 460 their peers support trickle ICE once an Offer and an Answer have been 461 exchanged, which also allows for ICE processing to commence (see 462 Figure 3). 464 4.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery 466 Alice Bob 467 | | 468 | INVITE (Offer) | 469 |------------------------>| 470 | 183 (Answer) | 471 |<------------------------| 472 | PRACK/OK | 473 |------------------------>| 474 | | 475 +----------------------------------------+ 476 |Alice and Bob know that both can trickle| 477 |and know that the dialog is in the early| 478 |state. Send INFO! | 479 +----------------------------------------+ 480 | | 481 | INFO/OK (+SRFLX Cand.) | 482 |------------------------>| 483 | INFO/OK (+SRFLX Cand.) | 484 |<------------------------| 485 | | 487 Note: SRFLX denotes server-reflexive candidates 489 Figure 3: SIP Offerer can freely trickle as soon as it receives an 490 Answer. 492 As shown in Figure 3 satisfying both conditions is relatively trivial 493 for ICE Agents that have sent an Offer in an INVITE and that have 494 received an Answer in a reliable provisional response. It is 495 guaranteed to have confirmed support for Trickle ICE at the Answerer 496 (or lack thereof) and to have fully initialized the SIP dialog at 497 both ends. Offerers and Answerers (after receipt of the PRACK 498 request) in the above situation can therefore freely commence 499 trickling within the newly established dialog. 501 4.3.2. Establishing Dialog State through Unreliable Offer/Answer 502 Delivery 504 The situation is a bit more delicate for agents that have received an 505 Offer in an INVITE request and have sent an Answer in an unreliable 506 provisional response because, once the response has been sent, the 507 Answerer does not know when or if it has been received (Figure 4). 509 Alice Bob 510 | | 511 | INVITE (Offer) | 512 |------------------------>| 513 | 183 (Answer) | 514 |<------------------------| 515 | | 516 | +----------------------+ 517 | |Bob: I don't know if | 518 | |Alice got my 183 or if| 519 | |her dialog is already | 520 | |in the early state. | 521 | | Can I send INFO??? | 522 | +----------------------+ 523 | | 525 Figure 4: A SIP UA that sent an Answer in an unreliable provisional 526 response does not know if it was received and if the dialog at the 527 side of the Offerer has entered the early state 529 In order to clear this ambiguity as soon as possible, the Answerer 530 needs to retransmit the provisional response with the exponential 531 back-off timers described in [RFC3262]. These retransmissions MUST 532 cease on receipt of an INFO request carrying a 'trickle-ice' Info 533 Package body, on receipt of any other in-dialog request from the 534 offerer or on transmission of the Answer in a 2xx response. The 535 offerer cannot send in-dialog requests until it receives a response, 536 so the arrival of such a request proves that the response has 537 arrived. Using the INFO request for dialog confirmation is similar 538 to the procedure described in section 6.1.1 of 539 [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding Request is 540 replaced by the INFO request. 542 [RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for 543 version 20 of said I-D. Authors need to cross-check during Auth48 544 since it could have have changed in the meantime.] 546 The Offerer MUST send a Trickle ICE INFO request as soon as it 547 receives an SDP Answer in an unreliable provisional response. This 548 INFO request MUST repeat the candidates that were already provided in 549 the Offer (as would be the case when Half Trickle is performed or 550 when new candidates have not been learned since then). The first 551 case could happen when Half Trickle is used and all candidate were 552 already in the initial offer. The second case could happen when Full 553 Trickle is used and the offerer is currently gathering additional 554 candidates, but did not yet get them. Also, if the initial Offer did 555 not contain any candidates, depending on how the Offerer gathers its 556 candidates and how long it takes to do so, this INFO could still 557 contain no candidates. 559 When Full Trickle is used and if newly learned candidates are 560 available, the Offerer SHOULD also deliver these candidates in said 561 INFO request, unless it wants to hold back some candidates in 562 reserve, e.g. in case that these candidates are expensive to use and 563 would only be trickled if all other candidates failed. 565 The Offerer SHOULD include an end-of-candidates attribute in case 566 candidate discovery has ended in the mean time and no further 567 candidates are to be trickled. 569 As soon as an Answerer has received such an INFO request, the 570 Answerer has an indication that a dialog is established at both ends 571 and can begin trickling (Figure 5). 573 Note: The +SRFLX in Figure 5 indicates that additionally newly 574 learned server-reflexive candidates are included. 576 Alice Bob 577 | | 578 | INVITE (Offer) | 579 |------------------------>| 580 | 183 (Answer) | 581 |<------------------------| 582 | INFO/OK (+SRFLX Cand.) | 583 |------------------------>| 584 | | 585 | +----------------------+ 586 | |Bob: Now I know Alice| 587 | | is ready. Send INFO! | 588 | +----------------------+ 589 | INFO/OK (+SRFLX Cand.) | 590 |<------------------------| 591 | | 592 | 200/ACK (Answer) | 593 |<------------------------| 595 Note: SRFLX denotes server-reflexive candidates 597 Figure 5: A SIP UA that received an INFO request after sending an 598 unreliable provisional response knows that the dialog at the side of 599 the receiver has entered the early state 601 When sending the Answer in the 200 OK response to the INVITE request, 602 the Answerer needs to repeat exactly the same Answer that was 603 previously sent in the unreliable provisional response in order to 604 fulfill the corresponding requirements in [RFC3264]. Thus, the 605 Offerer needs to be prepared for receiving a different number of 606 candidates in that repeated Answer than previously exchanged via 607 trickling and MUST ignore the candidate information in that 200 OK 608 response. 610 4.3.3. Initiating Trickle ICE without an SDP Answer 612 The ability to convey arbitrary candidates in INFO message bodies 613 allows ICE Agents to initiate trickling without actually sending an 614 Answer. Trickle ICE Agents can therefore respond to an INVITE 615 request with provisional responses without an SDP Answer [RFC3261]. 616 Such provisional responses serve for establishing an early dialog. 618 Agents that choose to establish the dialog in this way, MUST 619 retransmit these responses with the exponential back-off timers 620 described in [RFC3262]. These retransmissions MUST cease on receipt 621 of an INFO request carrying a 'trickle-ice' Info Package body, on 622 receipt any in-dialog request from the offerer or on transmission of 623 the Answer in a 2xx response. The offerer cannot send in-dialog 624 requests until it receives a response, so the arrival of such a 625 request proves that the response has arrived. This is again similar 626 to the procedure described in section 6.1.1 of 627 [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is not yet 628 provided. 630 [RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for 631 version 20 of said I-D. Authors need to cross-check during Auth48 632 since it could have have changed in the meantime.] 634 Note: The +SRFLX in Figure 6 indicates that additionally newly 635 learned server-reflexive candidates are included. 637 Alice Bob 638 | | 639 | INVITE (Offer) | 640 |------------------------>| 641 | 183 (-) | 642 |<------------------------| 643 | INFO/OK (SRFLX Cand.) | 644 |------------------------>| 645 | | 646 | +----------------------+ 647 | |Bob: Now I know again| 648 | | that Alice is ready. | 649 | | Send INFO! | 650 | +----------------------+ 651 | INFO/OK (SRFLX Cand.) | 652 |<------------------------| 653 | 183 (Answer) opt. | 654 |<------------------------| 655 | INFO/OK (SRFLX Cand.) | 656 |<------------------------| 657 | 200/ACK (Answer) | 658 |<------------------------| 660 Note: SRFLX denotes server-reflexive candidates 662 Figure 6: A SIP UA sends an unreliable provisional response without 663 an Answer for establishing an early dialog 665 When sending the Answer, the agent MUST repeat all currently known 666 and used candidates, if any, and MAY include all newly gathered 667 candidates since the last INFO request was sent. However, if that 668 Answer was already sent in a unreliable provisional response, the 669 Answerers MUST repeat exactly the same Answer in the 200 OK response 670 to the INVITE request in order to fulfill the corresponding 671 requirements in [RFC3264]. In case that trickling continued, an 672 Offerer needs to be prepared for receiving fewer candidates in that 673 repeated Answer than previously exchanged via trickling and MUST 674 ignore the candidate information in that 200 OK response. 676 4.4. Delivering Candidates in INFO Requests 678 Whenever new ICE candidates become available for sending, agents 679 encode them in "a=candidate:" attributes as described by 680 [I-D.ietf-mmusic-ice-sip-sdp]. For example: 682 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx 683 raddr 2001:db8:a0b:12f0::1 rport 8998 685 The use of SIP INFO requests happens within the context of the Info 686 Package as defined Section 10. The Media Type [RFC6838] for their 687 payload MUST be set to 'application/trickle-ice-sdpfrag' as defined 688 in Section 9. The Info request body adheres to the grammar as 689 specified in Section 9.2. 691 Since neither the "a=candidate:" nor the "a=end-of-candidates" 692 attributes contain information that would allow correlating them to a 693 specific "m=" line, this is handled through the use of pseudo "m=" 694 lines. 696 Pseudo "m=" lines follow the SDP syntax for "m=" lines as defined in 697 [RFC4566] It is linked to the corresponding "m=" line in the SDP 698 Offer or Answer via the identification tag in a "a=mid:" attribute 699 which is defined in [RFC5888]. A pseudo "m=" line does not provide 700 semantics other than indicating to which "m=" line a candidate 701 belongs. Consequently, the receiving agent MUST ignore any remaining 702 content of the pseudo "m=" line, which is not defined in this 703 document. This guarantees that the 'application/trickle-ice-sdpfrag' 704 bodies do not interfere with the Offer/Answer procedures as specified 705 in [RFC3264]. 707 When sending the INFO request, the agent MAY, if already known to the 708 agent, include the same content into the pseudo "m=" line as for the 709 "m=" line in the corresponding Offer or Answer. However, since 710 Trickle-ICE might be decoupled from the Offer/Answer negotiation this 711 content might be unknown to the agent. In this case, the agent MUST 712 include the following default values. 714 o The media field is set to 'audio'. 716 o The port value is set to '9'. 718 o The proto value is set to 'RTP/AVP'. 720 o The fmt field MUST appear only once and is set to '0' 722 Agents MUST include a pseudo "m=" line and an identification tag in a 723 "a=mid:" attribute for every "m=" line whose candidate list they 724 intend to update. Such "a=mid:" attributes MUST immediately precede 725 the list of candidates for that specific "m=" line. 727 All "a=candidate:" or "a=end-of-candidates" attributes following an 728 "a=mid:" attribute, up until (and excluding) the next occurrence of a 729 pseudo "m=" line, pertain to the "m=" line identified by that 730 identification tag. 732 Note, that there is no requirement that the Info request body 733 contains as many pseudo m= lines as the Offer/Answer contains 734 m=lines, nor that the pseudo m= lines be in the same order as the 735 m=lines that they pertain to. The correspondence can be made via the 736 "a=mid:" attributes since candidates are grouped in sections headed 737 by "pseudo" m=lines. These sections contain "a=mid:" attribute 738 values which point back to the true m=line. 740 An "a=end-of-candidates" attribute, preceding the first pseudo "m=" 741 line, indicates the end of all trickling from that agent, as opposed 742 to end of trickling for a specific "m=" line, which would be 743 indicated by a media level "a=end-of-candidates" attribute. 745 Refer to Figure 7 for an example of the INFO request content. 747 The use of pseudo "m=" lines allows for a structure similar to the 748 one in SDP Offers and Answers where separate media-level and session- 749 level sections can be distinguished. In the current case, lines 750 preceding the first pseudo "m=" line are considered to be session- 751 level. Lines appearing in between or after pseudo "m=" lines will be 752 interpreted as media-level. 754 Note that while this specification uses the "a=mid:" attribute 755 from [RFC5888], it does not define any grouping semantics. 757 All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" 758 attributes that allow mapping them to a specific ICE generation. An 759 agent MUST discard any received INFO requests containing "a=ice-pwd:" 760 and "a=ice-ufrag:" attributes that do not match those of the current 761 ICE Negotiation Session. 763 The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the 764 same level as the ones in the Offer/Answer exchange. In other words, 765 if they were present as session-level attributes, they will also 766 appear at the beginning of all INFO request payloads, i.e. preceding 767 the first pseudo "m=" line. If they were originally exchanged as 768 media level attributes, potentially overriding session-level values, 769 then they will also be included in INFO request payloads following 770 the corresponding pseudo "m=" lines. 772 Note that [I-D.ietf-ice-trickle] requires that when candidates are 773 trickled, each candidate must be delivered to the receiving Trickle 774 ICE implementation not more than once and in the same order as it was 775 conveyed. If the signaling protocol provides any candidate 776 retransmissions, they need to be hidden from the ICE implementation. 777 This requirement is fulfilled as follows. 779 Since the agent is not fully aware of the state of the ICE 780 Negotiation Session at its peer it MUST include all currently known 781 and used local candidates in every INFO request. I.e. the agent MUST 782 repeat in the INFO request body all candidates that were previously 783 sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in 784 the same order as they were sent before. In other words, the 785 sequence of a previously sent list of candidates MUST NOT change in 786 subsequent INFO requests and newly gathered candidates MUST be added 787 at the end of that list. Although repeating all candidates creates 788 some overhead, it also allows easier handling of problems that could 789 arise from unreliable transports, like e.g. loss of messages and 790 reordering, which can be detected through the CSeq: header field in 791 the INFO request. 793 In addition, an ICE agent needs to adhere to section 17 of 794 [I-D.ietf-ice-trickle] on preserving candidate order while trickling. 796 When receiving INFO requests carrying any candidates, agents MUST 797 therefore first identify and discard the attribute lines containing 798 candidates they have already received in previous INFO requests or in 799 the Offer/Answer exchange preceding them. 801 Such candidates are considered to be equal if their IP address port, 802 transport and component ID are the same. After identifying and 803 discarding the known candidates, the agents MUST forward the actually 804 new candidates to the ICE Agents in the same order as they were 805 received in the INFO request body. The ICE Agents will then process 806 the new candidates according to the rules described in 807 [I-D.ietf-ice-trickle]. 809 Receiving an "a=end-of-candidates" attribute in an INFO request body 810 - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the 811 current ICE generation - is an indication from the peer agent that it 812 will not send any further candidates. When included at session 813 level, i.e. before any pseudo "m=" line, this indication applies to 814 the whole session; when included at media level the indication 815 applies only to the corresponding "m=" line. Handling of such end- 816 of-candidates indications is defined in [I-D.ietf-ice-trickle]. 818 The example in Figure 7 shows the content of a candidate delivering 819 INFO request. In the example the "a=end-of-candidates" attributes 820 indicate that the candidate gathering is finished and that no further 821 INFO requests follow. 823 INFO sip:alice@example.com SIP/2.0 824 ... 825 Info-Package: trickle-ice 826 Content-type: application/trickle-ice-sdpfrag 827 Content-Disposition: Info-Package 828 Content-length: 862 830 a=ice-pwd:asd88fgpdd777uzjYhagZg 831 a=ice-ufrag:8hhY 832 m=audio 9 RTP/AVP 0 833 a=mid:1 834 a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host 835 a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host 836 a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host 837 a=candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host 838 a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx 839 raddr 192.0.2.1 rport 8998 840 a=candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx 841 raddr 192.0.2.1 rport 8998 842 a=end-of-candidates 843 m=audio 9 RTP/AVP 0 844 a=mid:2 845 a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host 846 a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host 847 a=candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host 848 a=candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host 849 a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx 850 raddr 192.0.2.1 rport 9998 851 a=candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx 852 raddr 192.0.2.1 rport 9998 853 a=end-of-candidates 855 Note: In a real INFO request there will be no line breaks 856 in the a=candidate: attributes 858 Figure 7: An Example for the Content of an INFO Request 860 5. Initial Discovery of Trickle ICE Support 862 SIP User Agents (UAs) that support and intend to use trickle ICE are 863 required by [I-D.ietf-ice-trickle] to indicate that in their Offers 864 and Answers using the attribute "a=ice-options:trickle" and MUST 865 include the SIP option-tag "trickle-ice" in a SIP Supported: or 866 Require: header field. This makes discovery fairly straightforward 867 for Answerers or for cases where Offers need to be generated within 868 existing dialogs (i.e., when sending UPDATE or re-INVITE requests). 870 In both scenarios prior SDP bodies will have provided the necessary 871 information. 873 Obviously, such information is not available at the time a first 874 Offer is being constructed and it is therefore impossible for ICE 875 Agents to determine support for incremental provisioning that way. 876 The following options are suggested as ways of addressing this issue. 878 5.1. Provisioning Support for Trickle ICE 880 In certain situations it may be possible for integrators deploying 881 Trickle ICE to know in advance that some or all endpoints reachable 882 from within the deployment will support Trickle ICE. This is the 883 case, for example, if Session Border Controllers (SBC) with support 884 for this specification are used to connect to UAs that do not support 885 Trickle ICE. 887 While the exact mechanism for allowing such provisioning is out of 888 scope here, this specification encourages trickle ICE implementations 889 to allow the option in the way they find most appropriate. 891 However, an Offerer assuming Trickle ICE support MUST include a SIP 892 Require: trickle-ice header field. That way, if the provisioned 893 assumption of Trickle ICE support ends up being incorrect, the 894 failure is (a) operationally easy to track down, and (b) recoverable 895 by the client, i.e., they can re-send the request without the SIP 896 Require: header field and without the assumption of Trickle ICE 897 support. 899 5.2. Trickle ICE Discovery with Globally Routable User Agent URIs 900 (GRUU) 902 [RFC3840] provides a way for SIP User Agents to query for support of 903 specific capabilities using, among others, OPTIONS requests. Support 904 for GRUU according to [RFC5627] on the other hand allows SIP requests 905 to be addressed to specific UAs (as opposed to arbitrary instances of 906 an address of record). Combining the two and using the "trickle-ice" 907 option tag defined in Section 10.6 provides SIP UAs with a way of 908 learning the capabilities of specific SIP UA instances and then 909 addressing them directly with INVITE requests that require Trickle 910 ICE support. 912 Such learning of capabilities may happen in different ways. One 913 option for a SIP UA is to learn the GRUU instance ID of a peer 914 through presence and then to query its capabilities with an OPTIONS 915 request. Alternatively, it can also just send an OPTIONS request to 916 the Address of Record (AOR) it intends to contact and then inspect 917 the returned response(s) for support of both GRUU and Trickle ICE 918 (Figure 8). It is noted that using the GRUU means that the INVITE 919 request can go only to that particular device. This prevents the use 920 of forking for that request. 922 Alice Bob 923 | | 924 | OPTIONS sip:b1@example.com SIP/2.0 | 925 |-------------------------------------------------->| 926 | | 927 | 200 OK | 928 | Contact: sip:b1@example.com;gr=hha9s8d-999a | 929 | ;audio;video|;trickle-ice;... | 930 |<--------------------------------------------------| 931 | | 932 | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | 933 | Supported: trickle-ice | 934 | (Offer) | 935 |-------------------------------------------------->| 936 | | 937 | 183 (Answer) | 938 |<--------------------------------------------------| 939 | INFO/OK (Trickling) | 940 |<------------------------------------------------->| 941 | | 942 | ... | 943 | | 945 Figure 8: Trickle ICE support discovery with OPTIONS and GRUU 947 Confirming support for Trickle ICE through [RFC3840] gives SIP UAs 948 the options to engage in Full Trickle negotiation (as opposed to the 949 more lengthy Half Trickle) from the very first Offer they send. 951 5.3. Fall-back to Half Trickle 953 In cases where none of the other mechanisms in this section are 954 acceptable, SIP UAs should use the Half Trickle mode defined in 955 [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions 956 the same way they would when using ICE for SIP 957 [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually 958 sending an Offer, agents first gather ICE candidates in a blocking 959 way and then send them all in that Offer. The blocking nature of the 960 process implies that some amount of latency will be accumulated and 961 it is advised that agents try to anticipate it where possible, for 962 example, when user actions indicate a high likelihood for an imminent 963 call (e.g., activity on a keypad or a phone going off-hook). 965 Using Half Trickle results in Offers that are compatible with both 966 ICE SIP endpoints and legacy [RFC3264] endpoints. 968 STUN/Turn STUN/TURN 969 Servers Alice Bob Servers 970 | | | | 971 |<--------------| | | 972 | | | | 973 | | | | 974 | Candidate | | | 975 | | | | 976 | | | | 977 | Discovery | | | 978 | | | | 979 | | | | 980 |-------------->| INVITE (Offer) | | 981 | |---------------------------->| | 982 | | 183 (Answer) |-------------->| 983 | |<----------------------------| | 984 | | INFO (repeated candidates) | | 985 | |---------------------------->| | 986 | | | | 987 | | INFO (more candidates) | Candidate | 988 | |<----------------------------| | 989 | | Connectivity Checks | | 990 | |<===========================>| Discovery | 991 | | INFO (more candidates) | | 992 | |<----------------------------| | 993 | | Connectivity Checks |<--------------| 994 | |<===========================>| | 995 | | | | 996 | | 200 OK | | 997 | |<----------------------------| | 998 | | | | 999 | |<======= MEDIA FLOWS =======>| | 1000 | | | | 1002 Figure 9: Example - A typical (Half) Trickle ICE exchange with SIP 1004 It is worth reminding that once a single Offer or Answer had been 1005 exchanged within a specific dialog, support for Trickle ICE will have 1006 been determined. No further use of Half Trickle will therefore be 1007 necessary within that same dialog and all subsequent exchanges can 1008 use the Full Trickle mode of operation. 1010 6. Considerations for RTP and RTCP Multiplexing 1012 The following consideration describe options for Trickle-ICE in order 1013 to give some guidance to implementors on how trickling can be 1014 optimized with respect to providing RTCP candidates. 1016 Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" 1017 attribute for RTP/RTCP multiplexing [RFC5761] is already considered 1018 in section 5.1.1.1. of [I-D.ietf-ice-rfc5245bis] and as well in 1019 [RFC5761] itself. These considerations are still valid for Trickle 1020 ICE, however, trickling provides more flexibility for the sequence of 1021 candidate exchange in case of RTCP multiplexing. 1023 [RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct 1024 for version 17 of said I-D. Authors need to cross-check during 1025 Auth48 since it could have have changed in the meantime.] 1027 If the Offerer supports RTP/RTCP multiplexing exclusively as 1028 specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that 1029 document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" 1030 and the "a=rtcp-mux" attributes. 1032 While a Half Trickle Offerer has to send an Offer compliant to 1033 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for 1034 all components, the flexibility of a Full Trickle Offerer allows to 1035 send only RTP candidates (component 1) in the initial Offer assuming 1036 that RTCP multiplexing is supported by the Answerer. A Full Trickle 1037 Offerer would need to start gathering and trickling RTCP candidates 1038 (component 2) only after having received an indication in the Answer 1039 that the Answerer unexpectedly does not support RTCP multiplexing. 1041 A Trickle Answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in 1042 the application/trickle-ice-sdpfrag body if it supports and uses RTP 1043 and RTCP multiplexing. The Trickle Answerer needs to follow the 1044 guidance on the usage of the "a=rtcp" attribute as given in 1045 [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]. Receipt of this 1046 attribute at the Offerer in an INFO request prior to the Answer 1047 indicates that the Answerer supports and uses RTP and RTCP 1048 multiplexing. The Offerer can use this information e.g. for stopping 1049 gathering of RTCP candidates and/or for freeing corresponding 1050 resources. 1052 This behavior is illustrated by the following example Offer that 1053 indicates support for RTP and RTCP multiplexing. 1055 v=0 1056 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com 1057 s= 1058 c=IN IP6 2001:db8:a0b:12f0::3 1059 t=0 0 1060 a=ice-pwd:777uzjYhagZgasd88fgpdd 1061 a=ice-ufrag:Yhh8 1062 m=audio 5000 RTP/AVP 0 1063 a=mid:1 1064 a=rtcp-mux 1065 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host 1067 Once the dialog is established as described in section Section 4.3 1068 the Answerer sends the following INFO request. 1070 INFO sip:alice@example.com SIP/2.0 1071 ... 1072 Info-Package: trickle-ice 1073 Content-type: application/trickle-ice-sdpfrag 1074 Content-Disposition: Info-Package 1075 Content-length: 161 1077 a=ice-pwd:asd88fgpdd777uzjYhagZg 1078 a=ice-ufrag:8hhY 1079 m=audio 9 RTP/AVP 0 1080 a=mid:1 1081 a=rtcp-mux 1082 a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host 1084 This INFO request indicates that the Answerer supports and uses RTP 1085 and RTCP multiplexing as well. It allows the Offerer to omit 1086 gathering of RTCP candidates or releasing already gathered RTCP 1087 candidates. If the INFO request did not contain the a=rtcp-mux 1088 attribute, the Offerer has to gather RTCP candidates unless it wants 1089 to wait until receipt of an Answer that eventually confirms support 1090 or non-support for RTP and RTCP multiplexing. In case the Offerer 1091 had sent RTCP candidates in a previous INFO request, it still needs 1092 to repeat them in subsequent INFO requests, even in case that support 1093 for RTCP multiplexing was confirmed by the Answerer and the Offerer 1094 has released its RTCP candidates. 1096 7. Considerations for Media Multiplexing 1098 The following considerations describe options for Trickle-ICE in 1099 order to give some guidance to implementors on how trickling can be 1100 optimized with respect to providing candidates in case of Media 1101 Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed 1102 that the reader is familiar with 1103 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 1105 ICE candidate exchange is already considered in section 11 of 1106 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are 1107 still valid for Trickle ICE, however, trickling provides more 1108 flexibility for the sequence of candidate exchange, especially in 1109 Full Trickle mode. 1111 Except for bundle-only "m=" lines, a Half Trickle Offerer has to send 1112 an Offer with candidates for all bundled "m=" lines. The additional 1113 flexibility, however, allows a Full Trickle Offerer to initially send 1114 only candidates for the "m=" line with the suggested Offerer BUNDLE 1115 address. 1117 On receipt of the Answer, the Offerer will detect if BUNDLE is 1118 supported by the Answerer and if the suggested Offerer BUNDLE address 1119 was selected. In this case, the Offerer does not need to trickle 1120 further candidates for the remaining "m=" lines in a bundle. 1121 However, if BUNDLE is not supported, the Full Trickle Offerer needs 1122 to gather and trickle candidates for the remaining "m=" lines as 1123 necessary. If the Answerer selects an Offerer BUNDLE address 1124 different from the suggested Offerer BUNDLE address, the Full Trickle 1125 Offerer needs to gather and trickle candidates for the "m=" line that 1126 carries the selected Offerer BUNDLE address. 1128 A Trickle Answerer SHOULD include an "a=group:BUNDLE" attribute 1129 [I-D.ietf-mmusic-sdp-bundle-negotiation] at session level in the 1130 application/trickle-ice-sdpfrag body if it supports and uses 1131 bundling. When doing so, the Answerer MUST include all 1132 identification-tags in the same order that is used or will be used in 1133 the Answer. 1135 Receipt of this attribute at the Offerer in an INFO request prior to 1136 the Answer indicates that the Answerer supports and uses bundling. 1137 The Offerer can use this information e.g. for stopping the gathering 1138 of candidates for the remaining "m=" lines in a bundle and/or for 1139 freeing corresponding resources. 1141 This behaviour is illustrated by the following example Offer that 1142 indicates support for Media Multiplexing. 1144 In case the Offerer had sent already candidates for "m="-lines in a 1145 bundle in a previous INFO request, it still needs to repeat them in 1146 subsequent INFO requests, even in case that support for bundling was 1147 confirmed by the Answerer and the Offerer has released no longer 1148 needed candidates. 1150 v=0 1151 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com 1152 s= 1153 c=IN IP6 2001:db8:a0b:12f0::3 1154 t=0 0 1155 a=group:BUNDLE foo bar 1156 a=ice-pwd:777uzjYhagZgasd88fgpdd 1157 a=ice-ufrag:Yhh8 1158 m=audio 10000 RTP/AVP 0 1159 a=mid:foo 1160 a=rtcp-mux 1161 a=rtpmap:0 PCMU/8000 1162 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1163 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host 1164 m=video 10002 RTP/AVP 31 1165 a=mid:bar 1166 a=rtcp-mux 1167 a=rtpmap:31 H261/90000 1168 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid 1170 The example Offer indicates support for RTP and RTCP multiplexing and 1171 contains a "a=candidate:" attribute only for the "m="-line with the 1172 suggested Offerer bundle address. Once the dialog is established as 1173 described in Section 4.3 the Answerer sends the following INFO 1174 request. 1176 INFO sip:alice@example.com SIP/2.0 1177 ... 1178 Info-Package: trickle-ice 1179 Content-type: application/trickle-ice-sdpfrag 1180 Content-Disposition: Info-Package 1181 Content-length: 219 1183 a=group:BUNDLE foo bar 1184 a=ice-pwd:asd88fgpdd777uzjYhagZg 1185 a=ice-ufrag:8hhY 1186 m=audio 9 RTP/AVP 0 1187 a=mid:foo 1188 a=rtcp-mux 1189 a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host 1191 This INFO request indicates that the Answerer supports and uses Media 1192 Multiplexing as well. Note that the Answerer only includes a single 1193 pseudo "m="-line since candidates matching those from the second 1194 "m="-line in the offer are not needed from the Answerer. 1196 The INFO request also indicates that the Answerer accepted the 1197 suggested Offerer Bundle Address. This allows the Offerer to omit 1198 gathering of RTP and RTCP candidates for the other "m=" lines or 1199 releasing already gathered candidates. If the INFO request did not 1200 contain the a=group:BUNDLE attribute, the Offerer has to gather RTP 1201 and RTCP candidates for the other "m=" lines unless it wants to wait 1202 until receipt of an Answer that eventually confirms support or non- 1203 support for Media Multiplexing. 1205 Independent of using Full Trickle or Half Trickle mode, the rules 1206 from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and 1207 Answerer, when putting attributes as specified in Section 9.2 in the 1208 application/trickle-ice-sdpfrag body. 1210 8. SDP 'end-of-candidates' Attribute 1212 8.1. Definition 1214 This section defines a new SDP media-level and session-level 1215 attribute [RFC4566] 'end-of-candidates'. 'end-of-candidates' is a 1216 property attribute [RFC4566], and hence has no value. By including 1217 this attribute in an Offer or Answer the sending agent indicates that 1218 it will not trickle further candidates. When included at session 1219 level this indication applies to the whole session, when included at 1220 media level the indication applies only to the corresponding media 1221 description. 1223 Name: end-of-candidates 1225 Value: N/A 1227 Usage Level: media and session-level 1229 Charset Dependent: no 1231 Mux Category: IDENTICAL 1233 Example: a=end-of-candidates 1235 8.2. Offer/Answer Procedures 1237 The Offerer or Answerer MAY include an "a=end-of-candidates" 1238 attribute in case candidate discovery has ended and no further 1239 candidates are to be trickled. The Offerer or Answerer MUST provide 1240 the "a=end-of-candidates" attribute together with the "a=ice-ufrag" 1241 and "a=ice-pwd" attributes of the current ICE generation as required 1242 by [I-D.ietf-ice-trickle]. When included at session level this 1243 indication applies to the whole session; when included at media level 1244 the indication applies only to the corresponding media description. 1246 Receipt of an "a=end-of-candidates" attribute at an Offerer or 1247 Answerer - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching 1248 the current ICE generation - indicates that gathering of candidates 1249 has ended at the peer, either for the session or only for the 1250 corresponding media description as specified above. The receiving 1251 agent forwards an end-of-candidates indication to the ICE Agent, 1252 which in turn acts as specified in [I-D.ietf-ice-trickle]. 1254 9. Content Type 'application/trickle-ice-sdpfrag' 1256 9.1. Overall Description 1258 A application/trickle-ice-sdpfrag body is used exclusively by the 1259 'trickle-ice' Info Package. Other SDP related applications need to 1260 define their own media type. The INFO request body uses a subset of 1261 the possible SDP lines as defined by the grammar defined in 1262 [RFC4566]. A valid body uses only pseudo "m=" lines and certain 1263 attributes that are needed and/or useful for trickling candidates. 1264 The content adheres to the following grammar. 1266 9.2. Grammar 1268 The grammar of an 'application/trickle-ice-sdpfrag' body is based on 1269 the following ABNF [RFC5234]. It specifies the subset of existing 1270 SDP attributes, that is needed or useful for trickling candidates. 1272 The grammar uses the indicator for case-sensitivity %s as defined in 1273 [RFC7405], but also imports grammars for other SDP attributes that 1274 precede the production of [RFC7405]. A sender SHOULD use lower-case 1275 for attributes from such earlier grammars, but a receiver MUST treat 1276 them case-insensitively. 1278 ; Syntax 1279 trickle-ice-sdpfrag = session-level-fields 1280 pseudo-media-descriptions 1281 session-level-fields = *(session-level-field CRLF) 1283 session-level-field = ice-lite-attribute / 1284 ice-pwd-attribute / 1285 ice-ufrag-attribute / 1286 ice-options-attribute / 1287 ice-pacing-attribute / 1288 end-of-candidates-attribute / 1289 bundle-group-attribute / 1290 extension-attribute-fields 1291 ; for future extensions 1293 ice-lite-attribute = %s"a" "=" ice-lite 1294 ice-pwd-attribute = %s"a" "=" ice-pwd-att 1295 ice-ufrag-attribute = %s"a" "=" ice-ufrag-att 1296 ice-pacing-attribute = %s"a" "=" ice-pacing-att 1297 ice-options-attribute = %s"a" "=" ice-options 1298 end-of-candidates-attribute = %s"a" "=" end-of-candidates 1299 end-of-candidates = %s"end-of-candidates" 1300 bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics 1301 *(SP identification-tag) 1302 bundle-semantics = "BUNDLE" 1303 extension-attribute-fields = attribute-fields 1305 pseudo-media-descriptions = *( media-field 1306 trickle-ice-attribute-fields ) 1307 trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF) 1308 trickle-ice-attribute-field = mid-attribute / 1309 candidate-attributes / 1310 ice-pwd-attribute / 1311 ice-ufrag-attribute / 1312 remote-candidate-attribute / 1313 end-of-candidates-attribute / 1314 rtcp-attribute / 1315 rtcp-mux-attribute / 1316 rtcp-mux-only-attribute / 1317 extension-attribute-fields 1318 ; for future extensions 1320 rtcp-attribute = %s"a" "=" %s"rtcp" 1321 rtcp-mux-attribute = %s"a" "=" %s"rtcp-mux" 1322 rtcp-mux-only-attribute = %s"a" "=" %s"rtcp-mux-only" 1323 candidate-attributes = %s"a" "=" candidate-attribute 1324 remote-candidate-attribute = %s"a" "=" remote-candidate-att 1326 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- 1327 pacing-att, ice-options, candidate-attribute remote-candidate-att 1328 from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute 1329 ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The 1330 "a=rtcp" attribute is defined in [RFC3605], the "a=rtcp-mux" 1331 attribute in [RFC5761] and the "a=rtcp-mux-only" attribute in 1332 [I-D.ietf-mmusic-mux-exclusive]. The latter attributes lack a formal 1333 grammar in their corresponding RFC and are reproduced here. 1335 The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the 1336 same level as the ones in the Offer/Answer exchange. In other words, 1337 if they were present as session-level attributes, they will also 1338 appear at the beginning of all INFO request payloads, i.e. preceding 1339 all pseudo "m=" lines. If they were originally exchanged as media 1340 level attributes, potentially overriding session-level values, then 1341 they will also be included in INFO request payloads following the 1342 corresponding pseudo "m=" lines. 1344 An Agent MUST ignore any received unknown extension-attribute-fields. 1346 10. Info Package 1348 10.1. Rationale - Why INFO? 1350 The decision to use SIP INFO requests as a candidate transport method 1351 is based primarily on their lightweight nature. Once a dialog has 1352 been established, INFO requests can be exchanged both ways with no 1353 restrictions on timing and frequency and no risk of collision. 1355 A critical fact is that the sending of Trickle ICE candidates in one 1356 direction is entirely uncoupled from sending candidates in the other 1357 direction. Thus, the sending of candidates in each direction can be 1358 done by a stream of INFO requests that is not correlated with the 1359 stream of INFO requests in the other direction. And since each INFO 1360 request cumulatively includes the contents of all previous INFO 1361 requests in that direction, ordering between INFO requests need not 1362 be preserved. All of this permits using largely-independent INFO 1363 requests. 1365 Contrarily, UPDATE or other offer/answer mechanisms assume that the 1366 messages in each direction are tightly coupled with messages in the 1367 other direction. Using Offer/Answer and UPDATE requests [RFC3311] 1368 would introduce the following complications: 1370 Blocking of messages: [RFC3264] defines Offer/Answer as a strictly 1371 sequential mechanism. There can only be a maximum of one active 1372 exchange at any point of time. Both sides cannot simultaneously 1373 send Offers nor can they generate multiple Offers prior to 1374 receiving an Answer. Using UPDATE requests for candidate 1375 transport would therefore imply the implementation of a candidate 1376 pool at every agent where candidates can be stored until it is 1377 once again that agent's "turn" to emit an Answer or a new Offer. 1378 Such an approach would introduce non-negligible complexity for no 1379 additional value. 1381 Elevated risk of glare: The sequential nature of Offer/Answer also 1382 makes it impossible for both sides to send Offers simultaneously. 1383 What's worse is that there are no mechanisms in SIP to actually 1384 prevent that. [RFC3261], where the situation of Offers crossing 1385 on the wire is described as "glare", only defines a procedure for 1386 addressing the issue after it has occurred. According to that 1387 procedure both Offers are invalidated and both sides need to retry 1388 the negotiation after a period between 0 and 4 seconds. The high 1389 likelihood for glare to occur and the average two second back-off 1390 intervals implies that the duration of Trickle ICE processing 1391 would not only fail to improve but actually exceed those of 1392 regular ICE. 1394 INFO messages decouple the exchange of candidates from the Offer/ 1395 Answer negotiation and are subject to none of the glare issues 1396 described above, which makes them a very convenient and lightweight 1397 mechanism for asynchronous delivery of candidates. 1399 Using in-dialog INFO messages also provides a way of guaranteeing 1400 that candidates are delivered end-to-end, between the same entities 1401 that are actually in the process of initiating a session. Out-of- 1402 dialog alternatives would have implied requiring support for Globally 1403 Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low 1404 adoption levels, would have constituted too strong of a constraint to 1405 the adoption of Trickle ICE. 1407 10.2. Overall Description 1409 This specification defines an Info Package for use by SIP User Agents 1410 implementing Trickle ICE. INFO requests carry ICE candidates 1411 discovered after the peer user agents have confirmed mutual support 1412 for Trickle ICE. 1414 10.3. Applicability 1416 The purpose of the ICE protocol is to establish a media path in the 1417 presence of NAT and firewalls. The candidates are transported in 1418 INFO requests and are part of this establishment. 1420 Candidates sent by a Trickle ICE Agent after the Offer, follow the 1421 same signaling path and reach the same entity as the Offer itself. 1423 While it is true that GRUUs can be used to achieve this, one of the 1424 goals of this specification is to allow operation of Trickle ICE in 1425 as many environments as possible including those without GRUU 1426 support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not 1427 satisfy this goal. 1429 10.4. Info Package Name 1431 This document defines a SIP Info Package as per [RFC6086]. The Info 1432 Package token name for this package is "trickle-ice" 1434 10.5. Info Package Parameters 1436 This document does not define any Info Package parameters. 1438 10.6. SIP Option Tags 1440 [RFC6086] allows Info Package specifications to define SIP option- 1441 tags. This specification extends the option-tag construct of the SIP 1442 grammar as follows: 1444 option-tag /= "trickle-ice" 1446 SIP entities that support this specification MUST place the 'trickle- 1447 ice' option-tag in a SIP Supported: or Require: header field within 1448 all SIP INVITE requests and responses. 1450 When responding to, or generating a SIP OPTIONS request a SIP entity 1451 MUST also include the 'trickle-ice' option-tag in a SIP Supported: or 1452 Require: header field. 1454 10.7. Info Request Body Parts 1456 Entities implementing this specification MUST include a payload of 1457 type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 in 1458 SIP INFO requests. The payload is used to convey SDP-encoded ICE 1459 candidates. 1461 10.8. Info Package Usage Restrictions 1463 This document does not define any Info Package Usage Restrictions. 1465 10.9. Rate of INFO Requests 1467 Given that IP addresses may be gathered rapidly a Trickle ICE Agent 1468 with many network interfaces might create a high rate of INFO 1469 requests if every newly detected candidate is trickled individually 1470 without aggregation. An implementation MUST aggregate ICE candidates 1471 in case that an unreliable transport protocol such as UDP is used. A 1472 Trickle ICE agent MUST NOT have more than one INFO request pending at 1473 any one time. When INFO messages are sent over an unreliable 1474 transport, they are retransmitted according to the rules specified in 1475 [RFC3261] section 17.1.2.1." 1477 If the INFO requests are sent on top of TCP, which is probably the 1478 standard way, this is not an issue for the network anymore, but it 1479 can remain one for SIP proxies and other intermediaries forwarding 1480 the SIP INFO messages. Also, an endpoint may not be able to tell 1481 that it has congestion controlled transport all the way. 1483 10.10. Info Package Security Considerations 1485 See Section 13 1487 11. Deployment Considerations 1489 Trickle ICE uses two mechanisms for exchange of candidate 1490 information. This imposes new requirements to certain middleboxes 1491 that are used in some networks, e.g. for monitoring purposes. While 1492 the first mechanism, SDP Offers and Answers, is already used by 1493 regular ICE and is assumed to be supported, the second mechanism, 1494 INFO request bodies, needs to be considered by such middleboxes as 1495 well when trickle ICE is used. Such middleboxes need to make sure 1496 that they remain in the signaling path of the INFO requests and need 1497 to understand the INFO request body. 1499 12. IANA Considerations 1501 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 1502 document. ] 1504 12.1. SDP 'end-of-candidates' Attribute 1506 This section defines a new SDP media-level and session-level 1507 attribute [RFC4566] , 'end-of-candidates'. 'end-of-candidates' is a 1508 property attribute [RFC4566] , and hence has no value. 1510 Name: end-of-candidates 1512 Value: N/A 1514 Usage Level: media and session 1516 Charset Dependent: no 1518 Purpose: The sender indicates that it will not trickle 1519 further ICE candidates. 1521 O/A Procedures: RFCXXX defines the detailed 1522 SDP Offer/Answer procedures for 1523 the 'end-of-candidates' attribute. 1525 Mux Category: IDENTICAL 1527 Reference: RFCXXXX 1529 Example: 1531 a=end-of-candidates 1533 12.2. Media Type 'application/trickle-ice-sdpfrag' 1535 This document defines a new Media Type 'application/trickle-ice- 1536 sdpfrag' in accordance with [RFC6838]. 1538 Type name: application 1540 Subtype name: trickle-ice-sdpfrag 1542 Required parameters: None. 1544 Optional parameters: None. 1546 Encoding considerations: 1548 The media contents follow the same rules as SDP, except as 1549 noted in this document. The media contents are text, with the 1550 grammar specified in Section 9.2. 1552 Although the initially defined content of a trickle-ice-sdpfrag 1553 body does only include ASCII characters, UTF-8 encoded content 1554 might be introduced via extension attributes. The "a=charset:" 1555 attribute may be used to signal the presence of other character 1556 sets in certain parts of a trickle-ice-sdpfrag body (see 1557 [RFC4566]). Arbitrary binary content cannot be directly 1558 represented in SDP or a trickle-ice-sdpfrag body. 1560 Security considerations: 1562 See [RFC4566] and RFCXXXX 1564 Interoperability considerations: 1566 See RFCXXXX 1568 Published specification: 1570 See RFCXXXX 1572 Applications which use this Media Type: 1574 Trickle-ICE 1576 Fragment identifier considerations: N/A 1578 Additional information: 1580 Deprecated alias names for this type: N/A 1582 Magic number(s): N/A 1584 File extension(s): N/A 1586 Macintosh File Type Code(s): N/A 1588 Person and email address to contact for further information: 1590 The IESG (iesg@ietf.org) 1592 Intended usage: 1594 Trickle-ICE for SIP as specified in RFCXXXX. 1596 Restrictions on usage: N/A 1598 Author/Change controller: 1600 The IESG (iesg@ietf.org) 1602 Provisional registration? (standards tree only): N/A 1604 12.3. SIP Info Package 'trickle-ice' 1606 This document defines a new SIP Info Package named 'trickle-ice' and 1607 updates the Info Packages Registry with the following entry. 1609 +-------------+-----------+ 1610 | Name | Reference | 1611 +-------------+-----------+ 1612 | trickle-ice | [RFCXXXX] | 1613 | | | 1614 +-------------+-----------+ 1616 12.4. SIP Option Tag 'trickle-ice' 1618 This specification registers a new SIP option tag 'trickle-ice' as 1619 per the guidelines in Section 27.1 of [RFC3261] and updates the 1620 "Option Tags" section of the SIP Parameter Registry with the 1621 following entry: 1623 +-------------+-------------------------------------+-----------+ 1624 | Name | Description | Reference | 1625 +-------------+-------------------------------------+-----------+ 1626 | trickle-ice | This option tag is used to indicate | [RFCXXXX] | 1627 | | that a UA supports and understands | | 1628 | | Trickle-ICE. | | 1629 +-------------+-------------------------------------+-----------+ 1631 13. Security Considerations 1633 The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], 1634 [RFC6086] and [I-D.ietf-ice-trickle] apply. This document clarifies 1635 how the above specifications are used together for trickling 1636 candidates and does not create additional security risks. 1638 The new Info Package 'trickle-ice' and the new Media Type 1639 'application/trickle-ice-sdpfrag' do not introduce additional 1640 security considerations when used in the context of Trickle ICE. 1641 Both are not intended to be used for other applications, so any 1642 security considerations for its use in other contexts is out of the 1643 scope of this document 1645 14. Acknowledgements 1647 The authors like to thank Flemming Andreasen, Ayush Jain, Paul 1648 Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount and Martin 1649 Thomson for reviewing and/or making various suggestions for 1650 improvements and optimizations. 1652 The authors also like to thank Flemming Andreasen for shepherding 1653 this document and Ben Campbell for his AD review and suggestions. In 1654 addition, the author like to thank Benjamin Kaduk, Adam Roach, Mirja 1655 Kuehlewind and Eric Rescorla for their comments and/or text proposals 1656 for improving the document during IESG review. 1658 Many thanks to Dale Worley for Gen-Art review and proposed 1659 enhancements for several sections. 1661 Many thanks to Joerg Ott for TSV-Art review and suggested 1662 improvements. 1664 The authors thank Shawn Emery for Security Directorate review. 1666 15. Change Log 1668 [RFC EDITOR NOTE: Please remove this section when publishing]. 1670 Changes from draft-ietf-mmusic-trickle-ice-sip-01 1672 o Editorial Clean up 1674 o IANA Consideration added 1676 o Security Consideration added 1678 o RTCP and BUNDLE Consideration added with rules for including 1679 "a=rtcp-mux" and "a=group: BUNDLLE" attributes 1681 o 3PCC Consideration added 1682 o Clarified that 18x w/o answer is sufficient to create a dialog 1683 that allows for trickling to start 1685 o Added remaining Info Package definition sections as outlined in 1686 section 10 of [RFC6086] 1688 o Added definition of application/sdpfrag making draft-ivov-mmusic- 1689 sdpfrag obsolete 1691 o Added pseudo m-lines as additional separator in sdpfrag bodies for 1692 Trickle ICE 1694 o Added ABNF for sdp-frag bodies and Trickle-ICE package 1696 Changes from draft-ietf-mmusic-trickle-ice-sip-02 1698 o Removed definition of application/sdpfrag 1700 o Replaced with new type application/trickle-ice-sdpfrag 1702 o RTCP and BUNDLE Consideration enhanced with some examples 1704 o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to 1705 normative reference 1707 o Removed reference to 4566bis 1709 o Addressed review comment from Simon Perreault 1711 Changes from draft-ietf-mmusic-trickle-ice-sip-03 1713 o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis 1714 and draft-ietf-mmusic-ice-sip-sdp 1716 o Corrected Figure 10, credits to Ayush Jain for finding the bug 1718 o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- 1719 ice-sip-sdp 1721 o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- 1722 mux-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive 1724 o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for 1725 the application/trickle-ice-sdpfrag body 1727 Changes from draft-ietf-mmusic-trickle-ice-sip-04 1729 o considered comments from Christer Holmberg 1730 o corrected grammar for INFO package, such that ice-ufrag/pwd are 1731 also allowed on media-level as specified in 1732 [I-D.ietf-mmusic-ice-sip-sdp] 1734 o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] 1736 o Added formal definition for the end-of-candidates attribute 1738 Changes from draft-ietf-mmusic-trickle-ice-sip-05 1740 o considered further comments from Christer Holmberg 1742 o editorial comments on section 3 addressed 1744 o moved section 3.1 to section 10.1 and applied some edits 1746 o replaced the term "previously sent candidates" with "currently 1747 known and used candidates". 1749 Changes from draft-ietf-mmusic-trickle-ice-sip-06 1751 o editorial fixes 1753 o additional text on the content of the INFO messages. 1755 o recommendation on what to do if a previously sent candidate is 1756 unexpectedly missing in a subsequent INFO 1758 o terminology alignment with draft-ietf-ice-trickle-07 1760 Changes from draft-ietf-mmusic-trickle-ice-sip-07 1762 o editorial fixes 1764 o clarification on ordering of candidates for alignment with draft- 1765 ietf-ice-trickle-12 1767 o O/A procedures for end-of-candidates attribute described here 1768 after corresponding procedures have been removed from draft-ietf- 1769 ice-trickle-11 1771 o using IPv6 addresses in examples 1773 Changes from draft-ietf-mmusic-trickle-ice-sip-08 1775 o editorial fixes/clarification based on Flemmings review 1776 o Description of Trickle specifics in O/A procedures for initial O/A 1777 exchange and specification of ICE mismatch exception 1779 Changes from draft-ietf-mmusic-trickle-ice-sip-09 1781 o editorial fixes/correction of references 1783 o adding missing Ref to RFC3605 in section 6, 5th para 1785 o replaced remaining IPv4 adresses with IPv6 1787 o Added text for handling a=rtcp in case of default RTP address 1788 0.0.0.0:9 based on comment from Roman Shpount. 1790 Changes from draft-ietf-mmusic-trickle-ice-sip-10 1792 o editorial fixes due to idnits output 1794 Changes from draft-ietf-mmusic-trickle-ice-sip-11 1796 o addressing comments from Ben Campell's AD review and Christer's 1797 review 1799 o Numerous editorial improvements/corrections 1801 o Added [RFC8174] boiler plate and adapted usage of normative 1802 language 1804 o Clarified terminology ICE modules .vs. ICE agent 1806 o Added more detailed OA procedures 1808 o Corrected default values in m-line and usage of "a=mid:" attribute 1809 explicitly mentioned for offer/answer 1811 o Removed explicit mentioning of XMPP 1813 o Added Deployment Considerations section 1815 o Fixed ref for rfc5245bis 1817 Changes from draft-ietf-mmusic-trickle-ice-sip-12 1819 o addressing comments from Gen-Art review, TSV-Art review and 1820 Security Directorate review 1822 o Numerous editorial improvements/corrections/clarifications 1823 Changes from draft-ietf-mmusic-trickle-ice-sip-13 1825 o added expansions for SDP,GRUU, AOR, STUN, TURN 1827 o some editorial corrections 1829 Changes from draft-ietf-mmusic-trickle-ice-sip-14 1831 Addressing comments from IESG review 1833 o Clarification/enhancement in section 5 and Fig. 10 based on 1834 comments from Benjamin Kaduk 1836 o Clarification on sequence for sending candidates, definition of 1837 pseudo m-lines, usage of a=mid attribute, usage of INFO as ACK for 1838 receipt of 18x based on comments from Eric Rescorla 1840 o Removal of 3PCC Section 3.4, removal of NATted IPv6 addresses, 1841 adding more flexibility to in the grammar, explicit mentioning of 1842 Require: header field, usage of Require: header field in case of 1843 provisioning, text on repetition of candidates in case of RTCP mux 1844 and Bundle, various other editorial improvements/corrections based 1845 on comments from Adam Roach 1847 o Modified text on rate limitation of INFO requests based on 1848 comments of Mirja Kuehlewind, Adam Roach and Roman Shpount 1850 o some editorial corrections 1852 Changes from draft-ietf-mmusic-trickle-ice-sip-15 1854 Corrections in section 7 on Media Multiplexing 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-20 (work in progress), March 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-21 (work in progress), 1871 April 2018. 1873 [I-D.ietf-mmusic-ice-sip-sdp] 1874 Petit-Huguenin, M., Nandakumar, S., and A. Keranen, 1875 "Session Description Protocol (SDP) Offer/Answer 1876 procedures for Interactive Connectivity Establishment 1877 (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in 1878 progress), April 2018. 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-52 (work in progress), May 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-17 1894 (work in progress), February 2018. 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 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1956 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1957 March 2017, . 1959 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1960 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1961 May 2017, . 1963 16.2. Informative References 1965 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1966 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1967 2002, . 1969 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1970 Camarillo, "Best Current Practices for Third Party Call 1971 Control (3pcc) in the Session Initiation Protocol (SIP)", 1972 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 1973 . 1975 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1976 "Indicating User Agent Capabilities in the Session 1977 Initiation Protocol (SIP)", RFC 3840, 1978 DOI 10.17487/RFC3840, August 2004, 1979 . 1981 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1982 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1983 DOI 10.17487/RFC5389, October 2008, 1984 . 1986 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1987 Agent URIs (GRUUs) in the Session Initiation Protocol 1988 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 1989 . 1991 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1992 Relays around NAT (TURN): Relay Extensions to Session 1993 Traversal Utilities for NAT (STUN)", RFC 5766, 1994 DOI 10.17487/RFC5766, April 2010, 1995 . 1997 Authors' Addresses 1999 Emil Ivov 2000 Jitsi 2001 Strasbourg 67000 2002 France 2004 Phone: +33 6 72 81 15 55 2005 Email: emcho@jitsi.org 2006 Thomas Stach 2007 Unaffiliated 2008 Vienna 1130 2009 Austria 2011 Email: thomass.stach@gmail.com 2013 Enrico Marocco 2014 Telecom Italia 2015 Via G. Reiss Romoli, 274 2016 Turin 10148 2017 Italy 2019 Email: enrico.marocco@telecomitalia.it 2021 Christer Holmberg 2022 Ericsson 2023 Hirsalantie 11 2024 Jorvas 02420 2025 Finland 2027 Email: christer.holmberg@ericsson.com