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