idnits 2.17.1 draft-ietf-ice-trickle-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 9, 2017) is 2515 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) == Outdated reference: A later version (-18) exists of draft-ietf-mmusic-trickle-ice-sip-07 -- Obsolete informational reference (is this intentional?): 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) -- Obsolete informational reference (is this intentional?): RFC 6336 (Obsoleted by RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft Atlassian 4 Intended status: Standards Track E. Rescorla 5 Expires: November 10, 2017 RTFM, Inc. 6 J. Uberti 7 Google 8 P. Saint-Andre 9 Filament 10 May 9, 2017 12 Trickle ICE: Incremental Provisioning of Candidates for the Interactive 13 Connectivity Establishment (ICE) Protocol 14 draft-ietf-ice-trickle-10 16 Abstract 18 This document describes "Trickle ICE", an extension to the 19 Interactive Connectivity Establishment (ICE) protocol that enables 20 ICE agents to send and receive candidates incrementally rather than 21 exchanging complete lists. With such incremental provisioning, ICE 22 agents can begin connectivity checks while they are still gathering 23 candidates and considerably shorten the time necessary for ICE 24 processing to complete. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 10, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Determining Support for Trickle ICE . . . . . . . . . . . . . 5 63 4. Conveying the Initial ICE Parameters . . . . . . . . . . . . 6 64 5. Receiving the Initial ICE Parameters . . . . . . . . . . . . 7 65 5.1. Conveying the Initial Response . . . . . . . . . . . . . 7 66 5.2. Forming Check Lists and Beginning Connectivity 67 Checks . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Receiving the Initial Answer . . . . . . . . . . . . . . . . 8 69 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 8 70 7.1. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 8 71 7.2. Check List and Timer State Updates . . . . . . . . . . . 9 72 8. Discovering and Conveying Additional Local Candidates . . . . 10 73 8.1. Pairing Newly Learned Candidates and Updating 74 Check Lists . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.1.1. Inserting a New Pair in a Check List . . . . . . . . 12 76 8.2. Announcing End of Candidates . . . . . . . . . . . . . . 16 77 9. Receiving Additional Remote Candidates . . . . . . . . . . . 17 78 10. Receiving an End-Of-Candidates Notification . . . . . . . . . 18 79 11. Trickle ICE and Peer Reflexive Candidates . . . . . . . . . . 18 80 12. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 18 81 13. Subsequent Exchanges . . . . . . . . . . . . . . . . . . . . 18 82 14. Unilateral Use of Trickle ICE (Half Trickle) . . . . . . . . 19 83 15. Requirements for Signaling Protocols . . . . . . . . . . . . 20 84 16. Preserving Candidate Order while Trickling . . . . . . . . . 20 85 17. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . 21 86 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 87 19. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 89 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 21.1. Normative References . . . . . . . . . . . . . . . . . . 23 91 21.2. Informative References . . . . . . . . . . . . . . . . . 23 92 Appendix A. Interaction with Regular ICE . . . . . . . . . . . . 24 93 Appendix B. Interaction with ICE Lite . . . . . . . . . . . . . 26 94 Appendix C. Changes from Earlier Versions . . . . . . . . . . . 27 95 C.1. Changes from draft-ietf-ice-trickle-09 . . . . . . . . . 27 96 C.2. Changes from draft-ietf-ice-trickle-08 . . . . . . . . . 27 97 C.3. Changes from draft-ietf-ice-trickle-07 . . . . . . . . . 28 98 C.4. Changes from draft-ietf-ice-trickle-06 . . . . . . . . . 28 99 C.5. Changes from draft-ietf-ice-trickle-05 . . . . . . . . . 28 100 C.6. Changes from draft-ietf-ice-trickle-04 . . . . . . . . . 28 101 C.7. Changes from draft-ietf-ice-trickle-03 . . . . . . . . . 28 102 C.8. Changes from draft-ietf-ice-trickle-03 . . . . . . . . . 28 103 C.9. Changes from draft-ietf-ice-trickle-02 . . . . . . . . . 28 104 C.10. Changes from draft-ietf-ice-trickle-01 . . . . . . . . . 28 105 C.11. Changes from draft-ietf-ice-trickle-00 . . . . . . . . . 29 106 C.12. Changes from draft-mmusic-trickle-ice-02 . . . . . . . . 29 107 C.13. Changes from draft-ivov-01 and draft-mmusic-00 . . . . . 29 108 C.14. Changes from draft-ivov-00 . . . . . . . . . . . . . . . 30 109 C.15. Changes from draft-rescorla-01 . . . . . . . . . . . . . 30 110 C.16. Changes from draft-rescorla-00 . . . . . . . . . . . . . 31 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 113 1. Introduction 115 The Interactive Connectivity Establishment (ICE) protocol 116 [rfc5245bis] describes mechanisms for gathering candidates, 117 prioritizing them, choosing default ones, exchanging them with a 118 remote party, pairing them, and ordering them into check lists. Once 119 all of these actions have been completed (and only then), the parties 120 can begin a phase of connectivity checks and eventually select the 121 pair of candidates that will be used in a media session or for a 122 given media stream. 124 Although the sequence described above has the advantage of being 125 relatively straightforward to implement and debug once deployed, it 126 can also be rather lengthy. Candidate gathering often involves 127 things like querying STUN [RFC5389] servers and allocating relayed 128 candidates at TURN [RFC5766] servers. All of these actions can be 129 delayed for a noticeable amount of time; although they can be run in 130 parallel, they still need to respect the pacing requirements from 131 [rfc5245bis], which is likely to delay them even further. Some or 132 all of these actions also need be completed by the remote agent. 133 Both agents would next perform connectivity checks and only then 134 would they be ready to begin streaming media. 136 These factors can lead to relatively lengthy session establishment 137 times and thus to a degraded user experience. 139 This document defines an alternative or supplementary mode of 140 operation for ICE implementations, known as "Trickle ICE", in which 141 candidates can be exchanged incrementally. This enables ICE agents 142 to exchange candidates as soon as an ICE session has been initiated. 144 Connectivity checks for a media stream can also start as soon as the 145 first candidates for that stream become available. 147 Trickle ICE can reduce session establishment times in cases where 148 connectivity is confirmed for the first exchanged candidates (e.g., 149 where candidates for one of the agents are directly reachable from 150 the second agent, such as candidates at a media relay). Even when 151 this is not the case, performing candidate gathering for both agents 152 and connectivity checks in parallel can considerably shorten ICE 153 processing times. 155 It is worth noting that there is quite a bit of operational 156 experience with the Trickle ICE technique, going back as far as 2005 157 (when the XMPP Jingle extension defined a "dribble mode" as specified 158 in [XEP-0176]); this document incorporates feedback from those who 159 have implemented and deployed the technique. 161 In addition to the basics of Trickle ICE, this document also 162 describes how to discover support for Trickle ICE, how regular ICE 163 processing needs to be modified when building and updating check 164 lists, and how Trickle ICE implementations interoperate with agents 165 that only implement regular ICE processing as defined in 166 [rfc5245bis]. 168 This specification does not define the usage of Trickle ICE with any 169 specific signaling protocol (however, see 170 [I-D.ietf-mmusic-trickle-ice-sip] for usage with SIP [RFC3261] and 171 [XEP-0176] for usage with XMPP [RFC6120]). Similarly, it does not 172 define Trickle ICE in terms of the Session Description Protocol (SDP) 173 [RFC4566] or the offer/answer model [RFC3264] because the technique 174 can be and already is used in application protocols that are not tied 175 to SDP or to offer/answer semantics. However, because SDP and the 176 offer/answer model are familiar to most readers of this 177 specification, some examples in this document use those particulars 178 in order to explain the underlying concepts. 180 2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 This specification makes use of all terminology defined for 187 Interactive Connectivity Establishment in [rfc5245bis]. In addition, 188 it defines the following terms: 190 Candidate Gatherer: A module used by an ICE agent to obtain local 191 candidates. Candidate gatherers use different mechanisms for 192 discovering local candidates, such as STUN and TURN. 194 Generation: All of the candidates conveyed within an ICE session; 195 these are the candidates that are associated with a specific 196 local/remote ufrag pair (which will change on ICE restart, if any 197 occurs). 199 ICE Parameters: Any session-related (as opposed to candidate- 200 related) attributes required to configure an ICE agent. These 201 include but are not limited to the username fragment, password, 202 and other options. 204 Trickled Candidates: Candidates that a Trickle ICE agent conveys 205 after conveying initial ICE parameters or responding to initial 206 ICE parameters, but within the same ICE session. Trickled 207 candidates can be conveyed in parallel with candidate gathering 208 and connectivity checks. 210 Trickling: The act of conveying trickled candidates. 212 Half Trickle: A Trickle ICE mode of operation where the initiator 213 gathers a full generation of candidates strictly before creating 214 and conveying the initial ICE parameters. Once conveyed, this 215 candidate information can be processed by regular ICE agents, 216 which do not require support for this specification. It also 217 allows Trickle ICE capable responders to still gather candidates 218 and perform connectivity checks in a non-blocking way, thus 219 roughly providing "half" the advantages of Trickle ICE. The 220 mechanism is mostly meant for use in cases where the remote 221 agent's support for Trickle ICE cannot be confirmed prior to 222 conveying the initial ICE parameters. 224 Full Trickle: The typical mode of operation for Trickle ICE agents, 225 in which the initial ICE parameters can include any number of 226 candidates (even zero candidates) and does not need to include a 227 full generation of candidates as in half trickle. 229 3. Determining Support for Trickle ICE 231 To fully support Trickle ICE, applications SHOULD incorporate one of 232 the following mechanisms to enable implementations to determine 233 whether Trickle ICE is supported: 235 1. Provide a capabilities discovery method so that agents can verify 236 support of Trickle ICE prior to initiating a session (XMPP's 237 Service Discovery [XEP-0030] is one such mechanism). 239 2. Make support for Trickle ICE mandatory so that user agents can 240 assume support. 242 If an application protocol does not provide a method of determining 243 ahead of time whether Trickle ICE is supported, agents can make use 244 of the half trickle procedure described in Section 14. 246 Prior to conveying the initial ICE parameters, agents using signaling 247 protocols that support capabilities discovery can attempt to verify 248 whether or not the remote party supports Trickle ICE. If an agent 249 determines that the remote party does not support Trickle ICE, it 250 MUST fall back to using regular ICE or abandon the entire session. 252 Even if a signaling protocol does not include a capabilities 253 discovery method, a user agent can provide an indication within the 254 ICE parameters that it supports Trickle ICE using a token of 255 "trickle" in the ice-options attribute. This token MUST be provided 256 either at the session level or, if at the media stream level, for 257 every media stream (an agent MUST NOT specify Trickle ICE support for 258 some media streams but not others). 260 Dedicated discovery semantics and half trickle are needed only prior 261 to session initiation. After a session is established and Trickle 262 ICE support is confirmed for both parties, either agent can use full 263 trickle for subsequent exchanges. 265 4. Conveying the Initial ICE Parameters 267 An agent can start gathering candidates as soon as it has an 268 indication that communication is imminent (e.g., a user interface cue 269 or an explicit request to initiate a session). Unlike in regular 270 ICE, in Trickle ICE implementations do not need to gather candidates 271 in a blocking manner. Therefore, unless half trickle is being used, 272 agents SHOULD generate and transmit their initial ICE parameters as 273 early as possible, so that the remote party can start gathering and 274 trickling candidates. 276 Trickle ICE agents MAY include any mix of candidates when conveying 277 initial ICE parameters. This includes the possibility of conveying 278 ICE paramters that contain all the candidates the agent plans to use 279 (as in half trickle mode), conveying ICE parameters that contain only 280 a publicly-reachable IP address (e.g., a candidate at a media relay 281 that is known to not be behind a firewall), or conveying ICE 282 parameters with no candidates at all (in which case the initiator can 283 obtain the responder's initial candidate list sooner and the 284 responder can begin candidate gathering more quickly). 286 Methods for calculating priorities and foundations, as well as 287 determining redundancy of candidates, work just as with regular ICE 288 (with the exception of pruning of duplicate peer reflexive candidates 289 as described under Section 5.2). 291 5. Receiving the Initial ICE Parameters 293 When a responder receives initial ICE parameters, it will first check 294 if the ICE parameters or initiator indicates support for Trickle ICE 295 as explained in Section 3. If this is not the case, the agent MUST 296 process the ICE parameters according to regular ICE procedures 297 [rfc5245bis] (or, if no ICE support is detected at all, according to 298 relevant processing rules for the underlying signaling protocol, such 299 as offer/answer processing rules [RFC3264]). 301 If support for Trickle ICE is confirmed, an agent will automatically 302 assume support for regular ICE as well even if the support 303 verification procedure in [rfc5245bis] indicates otherwise. 304 Specifically, the rules from [rfc5245bis] would imply that ICE itself 305 is not supported if the initial ICE parameters include no candidates; 306 however, such a conclusion is not warranted if the responder can 307 confirm that the initiator supports Trickle ICE; in this case, 308 fallback to [RFC3264] is not necessary. 310 If the initial ICE parameters do indicate support for Trickle ICE, 311 the agent will determine its role and start gathering and 312 prioritizing candidates; while doing so, it will also respond by 313 conveying its own ICE parameters, so that both agents can start 314 forming check lists and begin connectivity checks. 316 5.1. Conveying the Initial Response 318 An agent can respond to initial ICE parameters at any point while 319 gathering candidates. Here again the ICE parameters MAY contain any 320 set of candidates, including all candidates or no candidates. (The 321 benefit of including no candidates is to convey the ICE parameters as 322 quickly as possible, so that both parties can consider the overall 323 session to be under active negotiation as soon as possible.) 325 As noted in Section 3, in application protocols that use SDP the 326 responder's ICE parameters can indicate support for Trickle ICE by 327 including a token of "trickle" in the ice-options attribute. 329 5.2. Forming Check Lists and Beginning Connectivity Checks 331 After the initiator and responder exchange ICE parameters, and as 332 soon as they have obtained local and remote candidates, agents begin 333 forming candidate pairs, computing candidate pair priorities, 334 ordering candidate pairs, pruning duplicate pairs, and creating check 335 lists according to regular ICE procedures [rfc5245bis]. 337 According to those procedures, in order for candidate pairing to be 338 possible and for duplicate candidates to be pruned, the candidates 339 would need to be provided in the relevant ICE parameters. Under 340 Trickle ICE, check lists can be empty until candidate pairs are 341 conveyed or received. Therefore Trickle ICE agents handle check 342 lists and candidate pairing in a slightly different way than regular 343 ICE agents: the agents still create the check lists, but they 344 populate the check lists only after they actually have the candidate 345 pairs. 347 A Trickle ICE agent initially considers all check lists to be frozen. 348 It then inspects the first check list and attempts to unfreeze all 349 candidate pairs it has received so far that belong to the first 350 component on the first media stream (i.e., the first media stream 351 that was reported to the ICE implementation from the using 352 application). If that first component of the first media stream does 353 not contain candidates for one or more of the currently known pair 354 foundations, and if candidate pairs already exist for that foundation 355 in one of the following components or media streams, then the agent 356 unfreezes the first of those candidate pairs. 358 With regard to pruning of duplicate candidate pairs, a Trickle ICE 359 agent SHOULD follow a policy of keeping the higher priority candidate 360 unless it is peer reflexive. 362 6. Receiving the Initial Answer 364 When processing initial ICE parameters from a responder, the 365 initiator follows regular ICE procedures to determine its role, after 366 which it forms check lists (as described in Section 5.2) and begins 367 connectivity checks. 369 7. Performing Connectivity Checks 371 For the most part, Trickle ICE agents perform connectivity checks 372 following regular ICE procedures. However, the fact that gathering 373 and communicating candidates is asynchronous in Trickle ICE imposes a 374 number of changes as described in the following sections. 376 7.1. Scheduling Checks 378 The ICE specification [rfc5245bis], Section 5.1.5, requires that 379 agents terminate the timer for a triggered check in relation to an 380 active check list once the agent has exhausted all frozen pairs in 381 the check list. This will not work with Trickle ICE, because more 382 pairs will be added to the check list incrementally. 384 Therefore, a Trickle ICE agent SHOULD NOT terminate the timer until 385 the state of the check list is Completed or Failed as specified 386 herein (see Section 8.2). 388 7.2. Check List and Timer State Updates 390 The ICE specification [rfc5245bis], Section 6.1.2.4.3, requires that 391 agents update check lists and timer states upon completing a 392 connectivity check transaction. During such an update, regular ICE 393 agents would set the state of a check list to Failed if both of the 394 following two conditions are satisfied: 396 o all of the pairs in the check list are either in the Failed state 397 or Succeeded state; and 399 o there is not a pair in the valid list for each component of the 400 media stream. 402 With Trickle ICE, the above situation would often occur when 403 candidate gathering and trickling are still in progress, even though 404 it is quite possible that future checks will succeed. For this 405 reason, Trickle ICE agents add the following conditions to the above 406 list: 408 o all candidate gatherers have completed and the agent is not 409 expecting to discover any new local candidates; 411 o the remote agent has conveyed an end-of-candidates indication for 412 that check list as described in Section 8.2. 414 When a check list is set to Failed as described above, regular ICE 415 requires the agent to update all other check lists, placing one pair 416 from each check list into the Waiting state - effectively unfreezing 417 all remaining check lists. However, under Trickle ICE other check 418 lists might still be empty at this point (because candidates have not 419 yet been received), and following only the rules from regular ICE 420 would prevent the agent from unfreezing those check lists (because 421 the state of a check list depends on the state of the candidate pairs 422 in that check list, but there are none yet). Therefore a Trickle ICE 423 agent needs to monitor whether a check list is active or frozen 424 independently of the state of the candidate pairs in the check list 425 (since there might not be any pairs yet). With regard to empty check 426 lists, by default a Trickle ICE agent MAY consider an empty check 427 list to be either active or frozen. When a Trickle ICE agent 428 considers an empty check list to be frozen, during the candidate 429 checking process it SHOULD change the check list to active if 430 checking of another check list is completely finished (i.e., if every 431 pair in the other check list is either Successful or Failed), if 432 another check list has a valid candidate pair for all components, or 433 if it adds a candidate pair to the check list (because, in accordance 434 with Section 8.1.1, when inserting a new candidate pair into an empty 435 check list, the agent sets the pair to a state of Waiting). 437 8. Discovering and Conveying Additional Local Candidates 439 After candidate information has been conveyed, agents will most 440 likely continue discovering new local candidates as STUN, TURN, and 441 other non-host candidate gathering mechanisms begin to yield results. 442 Whenever an agent discovers such a new candidate it will compute its 443 priority, type, foundation and component ID according to regular ICE 444 procedures. 446 The new candidate is then checked for redundancy against the existing 447 list of local candidates. If its transport address and base match 448 those of an existing candidate, it will be considered redundant and 449 will be ignored. This would often happen for server reflexive 450 candidates that match the host addresses they were obtained from 451 (e.g., when the latter are public IPv4 addresses). Contrary to 452 regular ICE, Trickle ICE agents will consider the new candidate 453 redundant regardless of its priority. 455 Next the agent "trickles" the newly discovered candidate(s) to the 456 remote agent. The actual delivery of the new candidates is handled 457 by a signaling protocol such as SIP or XMPP. Trickle ICE imposes no 458 restrictions on the way this is done (e.g., some applications may 459 choose not to trickle updates for server reflexive candidates and 460 instead rely on the discovery of peer reflexive ones). 462 When candidates are trickled, each candidate MUST be delivered to the 463 receiving Trickle ICE implementation not more than once and in the 464 same order it was conveyed. If the signaling protocol provides any 465 candidate retransmissions, they need to be hidden from the ICE 466 implementation. 468 Also, candidate trickling needs to be correlated to a specific ICE 469 session, so that if there is an ICE restart, any delayed updates for 470 a previous session can be recognized as such and ignored by the 471 receiving party. For example, applications that choose to signal 472 candidates via SDP may include a ufrag value in the corresponding 473 a=candidate line such as: 475 a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY 477 Or as another example, WebRTC implementations may include a ufrag in 478 the JavaScript objects that represent candidates. 480 Note: The signaling protocol needs to provide a mechanism for both 481 parties to indicate and agree on the ICE session in force (as 482 identified by the ufrag) so that they have a consistent view of which 483 candidates are to be paired. This is especially important in the 484 case of ICE restarts (see Section 13). 486 Once the candidate has been conveyed to the remote party, the agent 487 checks if any remote candidates are currently known for this same 488 stream and component. If not, the new candidate will simply be added 489 to the list of local candidates. 491 Otherwise, if the agent has already learned of one or more remote 492 candidates for this stream and component, it will begin pairing the 493 new local candidates with them and adding the pairs to the existing 494 check lists according to their priority. 496 Note: A Trickle ICE agent MUST NOT pair a local candidate until it 497 has been trickled to the remote agent. 499 8.1. Pairing Newly Learned Candidates and Updating Check Lists 501 Forming candidate pairs works as described in the ICE specification 502 [rfc5245bis]. However, actually adding the new pair to a check list 503 happens according to the rules described below. 505 If the check list where the pair is to be added already contains the 506 maximum number of candidate pairs (100 by default as per 507 [rfc5245bis]), the new pair is discarded. 509 If the new pair's local candidate is server reflexive, the server 510 reflexive candidate MUST be replaced by its base before adding the 511 pair to the list. 513 Once this is done, the agent examines the check list looking for 514 another pair that would be redundant with the new one. If such a 515 pair exists and the type of its remote candidate is not peer 516 reflexive, the pair with the higher priority is kept and the one with 517 the lower priority is discarded. If, on the other hand, the type of 518 the remote candidate in the pre-existing pair is peer reflexive, the 519 agent MUST replace it with the newly formed pair (regardless of their 520 respective priorities); this is done by setting the priority of the 521 new candidate to the priority of the pre-existing candidate and then 522 re-sorting the check list. 524 For all other pairs, including those with a server reflexive local 525 candidate that were not found to be redundant, the rules specified in 526 the following section apply. 528 8.1.1. Inserting a New Pair in a Check List 530 Consider the following tabular representation of all check lists in 531 an agent (note that initially for one of the foundations, i.e., f5, 532 there are no candidate pairs): 534 +-----------------+------+------+------+------+------+ 535 | | f1 | f2 | f3 | f4 | f5 | 536 +-----------------+------+------+------+------+------+ 537 | m1 (Audio.RTP) | F | F | F | | | 538 +-----------------+------+------+------+------+------+ 539 | m2 (Audio.RTCP) | F | F | F | F | | 540 +-----------------+------+------+------+------+------+ 541 | m3 (Video.RTP) | F | | | | | 542 +-----------------+------+------+------+------+------+ 543 | m4 (Video.RTCP) | F | | | | | 544 +-----------------+------+------+------+------+------+ 546 Figure 1: Example of Check List State 548 Each row in the table represents a component for a given media stream 549 (e.g., m1 and m2 might be the RTP and RTCP components for audio). 550 Each column represents one foundation. Each cell represents one 551 candidate pair. In the foregoing table, "F" stands for "frozen"; in 552 the tables below, "W" stands for "waiting" and "S" stands for 553 "succeeded". 555 When an agent commences ICE processing, in accordance with 556 Section 5.1.3.6 of [rfc5245bis] it will unfreeze (i.e., place in the 557 Waiting state) the topmost candidate pair in every column (i.e., the 558 pair with the lowest component ID). This state is shown in the 559 following table, with candidate pairs in the Waiting state marked by 560 "W". 562 +-----------------+------+------+------+------+------+ 563 | | f1 | f2 | f3 | f4 | f5 | 564 +-----------------+------+------+------+------+------+ 565 | m1 (Audio.RTP) | W | W | W | | | 566 +-----------------+------+------+------+------+------+ 567 | m2 (Audio.RTCP) | F | F | F | W | | 568 +-----------------+------+------+------+------+------+ 569 | m3 (Video.RTP) | F | | | | | 570 +-----------------+------+------+------+------+------+ 571 | m4 (Video.RTCP) | F | | | | | 572 +-----------------+------+------+------+------+------+ 574 Figure 2: Initial Check List State 576 Then, as the checks proceed (see Section 6.1.2.4.2.3 of 577 [rfc5245bis]), for each pair that enters the Succeeded state (denoted 578 here by "S"), the agent will unfreeze all pairs for the same media 579 stream and foundation (e.g., if the pair in column 1, row 1 succeeds 580 then the agent will unfreeze the pair in column 1, row 2). 582 +-----------------+------+------+------+------+------+ 583 | | f1 | f2 | f3 | f4 | f5 | 584 +-----------------+------+------+------+------+------+ 585 | m1 (Audio.RTP) | S | W | W | | | 586 +-----------------+------+------+------+------+------+ 587 | m2 (Audio.RTCP) | W | F | F | W | | 588 +-----------------+------+------+------+------+------+ 589 | m3 (Video.RTP) | F | | | | W | 590 +-----------------+------+------+------+------+------+ 591 | m4 (Video.RTCP) | F | | | | F | 592 +-----------------+------+------+------+------+------+ 594 Figure 3: Check List State after Succeeded Check 596 ICE also specifies that, if all the pairs in a media stream for one 597 foundation are unfrozen (e.g., column 1, rows 1 and 2 representing 598 both components for the audio stream), then all of the candidate 599 pairs in the entire column are unfrozen (e.g., column 1, rows 3 and 600 4). 602 +-----------------+------+------+------+------+------+ 603 | | f1 | f2 | f3 | f4 | f5 | 604 +-----------------+------+------+------+------+------+ 605 | m1 (Audio.RTP) | S | W | W | | | 606 +-----------------+------+------+------+------+------+ 607 | m2 (Audio.RTCP) | W | F | F | W | | 608 +-----------------+------+------+------+------+------+ 609 | m3 (Video.RTP) | W | | | | W | 610 +-----------------+------+------+------+------+------+ 611 | m4 (Video.RTCP) | W | | | | F | 612 +-----------------+------+------+------+------+------+ 614 Figure 4: Check List State with Unfrozen Media Stream 616 Trickle ICE preserves all of these rules as they apply to what we 617 might call "static" check list sets. This implies that if, for some 618 reason, a Trickle agent were to begin connectivity checks with all of 619 its pairs already present, the way that pair states change is 620 indistinguishable from that of a regular ICE agent. 622 Of course, the major difference with Trickle ICE is that check list 623 sets can be dynamically updated because candidates can arrive after 624 connectivity checks have started. When this happens, an agent sets 625 the state of the newly formed pair as described below. 627 Case 1: If the newly formed pair is the topmost pair in this column 628 (i.e. the topmost pair among all the check lists for this 629 foundation), set the state to Waiting (e.g., this would be the case 630 if the newly formed pair were placed in column 5, row 1). 632 +-----------------+------+------+------+------+------+ 633 | | f1 | f2 | f3 | f4 | f5 | 634 +-----------------+------+------+------+------+------+ 635 | m1 (Audio.RTP) | S | W | W | | W | 636 +-----------------+------+------+------+------+------+ 637 | m2 (Audio.RTCP) | W | F | F | W | | 638 +-----------------+------+------+------+------+------+ 639 | m3 (Video.RTP) | W | | | | | 640 +-----------------+------+------+------+------+------+ 641 | m4 (Video.RTCP) | W | | | | | 642 +-----------------+------+------+------+------+------+ 644 Figure 5: Check List State with Newly Formed Pair, Case 1 646 Case 2: If the pair immediately above the newly formed pair in this 647 column is in the Succeeded state, set the state to Waiting (e.g., 648 this would be the case if the pair in column 5, row 1 succeeded and 649 the newly formed pair were placed in column 5, row 2); 651 +-----------------+------+------+------+------+------+ 652 | | f1 | f2 | f3 | f4 | f5 | 653 +-----------------+------+------+------+------+------+ 654 | m1 (Audio.RTP) | S | W | W | | S | 655 +-----------------+------+------+------+------+------+ 656 | m2 (Audio.RTCP) | W | F | F | W | W | 657 +-----------------+------+------+------+------+------+ 658 | m3 (Video.RTP) | W | | | | | 659 +-----------------+------+------+------+------+------+ 660 | m4 (Video.RTCP) | W | | | | | 661 +-----------------+------+------+------+------+------+ 663 Figure 6: Check List State with Newly Formed Pair, Case 2 665 Case 3: If there is at least one Succeeded pair in this column above 666 the row of the newly formed pair, set the state to Waiting (e.g., 667 this would be the case if the pair in column 5, row 1 succeeded and 668 two newly formed pairs were placed in column 5, rows 3 and 4). 670 +-----------------+------+------+------+------+------+ 671 | | f1 | f2 | f3 | f4 | f5 | 672 +-----------------+------+------+------+------+------+ 673 | m1 (Audio.RTP) | S | W | W | | S | 674 +-----------------+------+------+------+------+------+ 675 | m2 (Audio.RTCP) | W | F | F | W | W | 676 +-----------------+------+------+------+------+------+ 677 | m3 (Video.RTP) | W | | | | W | 678 +-----------------+------+------+------+------+------+ 679 | m4 (Video.RTCP) | W | | | | W | 680 +-----------------+------+------+------+------+------+ 682 Figure 7: Check List State with Newly Formed Pair, Case 3 684 Case 4: In all other cases, set the state to Frozen. 686 8.2. Announcing End of Candidates 688 Once all candidate gathering is completed or expires for a specific 689 media stream, the agent will generate an "end-of-candidates" 690 indication for that stream and convey it to the remote agent via the 691 signaling channel. The exact form of the indication depends on the 692 application protocol. The indication can be conveyed in the 693 following ways: 695 o As part of an initiation request (which would typically be the 696 case with initial ICE parameters for half trickle) 698 o Along with the last candidate an agent can send for a stream 700 o As a standalone notification (e.g., after STUN Binding requests or 701 TURN Allocate requests to a server time out and the agent has no 702 other active gatherers) 704 Conveying an end-of-candidates indication in a timely manner is 705 important in order to avoid ambiguities and speed up the conclusion 706 of ICE processing. In particular: 708 o A controlled Trickle ICE agent SHOULD convey an end-of-candidates 709 indication after it has completed gathering for a media stream, 710 unless ICE processing terminates before the agent has had a chance 711 to complete gathering. 713 o A controlling agent MAY conclude ICE processing prior to conveying 714 end-of-candidates indications for all streams. However, it is 715 RECOMMENDED for a controlling agent to convey end-of-candidates 716 indications whenever possible for the sake of consistency and to 717 keep middleboxes and controlled agents up-to-date on the state of 718 ICE processing. 720 When conveying an end-of-candidates indication during trickling 721 (rather than as a part of initial ICE parameters or a response 722 thereto), it is the responsibility of the using protocol to define 723 methods for relating the indication to one or more specific media 724 streams. 726 Receiving an end-of-candidates indication enables an agent to update 727 check list states and, in case valid pairs do not exist for every 728 component in every media stream, determine that ICE processing has 729 failed. It also enables agents to speed up the conclusion of ICE 730 processing when a candidate pair has been validated but it involves 731 the use of lower-preference transports such as TURN. In such 732 situations, an implementation MAY choose to wait and see if higher- 733 priority candidates are received; in this case the end-of-candidates 734 indication provides a notification that such candidates are not 735 forthcoming. 737 An agent MAY also choose to generate an end-of-candidates indication 738 before candidate gathering has actually completed, if the agent 739 determines that gathering has continued for more than an acceptable 740 period of time. However, an agent MUST NOT convey any more 741 candidates after it has conveyed an end-of-candidates indication. 743 When performing half trickle, an agent SHOULD convey an end-of- 744 candidates indication together with its initial ICE parameters unless 745 it is planning to potentially trickle additional candidates (e.g., in 746 case the remote party turns out to support Trickle ICE). 748 After an agent conveys the end-of-candidates indication, it will 749 update the state of the corresponding check list as explained in 750 Section 7.2. Past that point, an agent MUST NOT trickle any new 751 candidates within this ICE session. After an agent has received an 752 end-of-candidates indication, it MUST also ignore any newly received 753 candidates for that media stream or media session. Therefore, adding 754 new candidates to the negotiation is possible only through an ICE 755 restart (see Section 13). 757 This specification does not override regular ICE semantics for 758 concluding ICE processing. Therefore, even if end-of-candidates 759 indications are conveyed, agents will still have to go through pair 760 nomination. Also, if pairs have been nominated for components and 761 media streams, ICE processing MAY still conclude even if end-of- 762 candidates indications have not been received for all streams. 764 9. Receiving Additional Remote Candidates 766 At any time during ICE processing, a Trickle ICE agent might receive 767 new candidates from the remote agent. When this happens and no local 768 candidates are currently known for this same stream, the new remote 769 candidates are added to the list of remote candidates. 771 Otherwise, the new candidates are used for forming candidate pairs 772 with the pool of local candidates and they are added to the local 773 check lists as described in Section 8.1. 775 Once the remote agent has completed candidate gathering, it will 776 convey an end-of-candidates indication. Upon receiving such an 777 indication, the local agent MUST update check list states as per 778 Section 7.2. This might lead to some check lists being marked as 779 Failed. 781 10. Receiving an End-Of-Candidates Notification 783 When an agent receives an end-of-candidates indication for a specific 784 media stream, it will update the state of the relevant check list as 785 per Section 7.2. If the check list is still in the Active state 786 after the update, the agent will persist the fact that an end-of- 787 candidates indication has been received and take it into account in 788 future updates to the check list. 790 11. Trickle ICE and Peer Reflexive Candidates 792 Even though Trickle ICE does not explicitly modify the procedures for 793 handling peer-reflexive candidates, use of Trickle ICE can have an 794 impact on how they are processed. With Trickle ICE, it is possible 795 that server reflexive candidates can be discovered as peer reflexive 796 in cases where incoming connectivity checks are received from these 797 candidates before the trickle updates that carry them. 799 While this would certainly increase the number of cases where ICE 800 processing nominates and selects candidates discovered as peer- 801 reflexive, it does not require any change in processing. 803 It is also likely that some applications would prefer not to trickle 804 server reflexive candidates to entities that are known to be publicly 805 accessible and where sending a direct STUN binding request is likely 806 to reach the destination faster than the trickle update that travels 807 through the signaling path. 809 12. Concluding ICE Processing 811 This specification does not directly modify the procedures for ending 812 ICE processing described in Section 6.2 of [rfc5245bis], and Trickle 813 ICE implementations follow the same rules. 815 13. Subsequent Exchanges 817 Either agent MAY convey subsequent candidate information at any time 818 allowed by the signaling protocol in use. When this happens agents 819 will use [rfc5245bis] semantics to determine whether or not the new 820 candidate information require an ICE restart. If an ICE restart 821 occurs, the user agents can assume that Trickle ICE is still 822 supported if support was determined previously, and thus can engage 823 in Trickle ICE behavior as they would in an initial exchange of ICE 824 parameters where support was determined through a capabilities 825 discovery method. 827 14. Unilateral Use of Trickle ICE (Half Trickle) 829 In half trickle mode, the initiator conveys initial ICE parameters 830 with a full generation of candidates. This ensures that the ICE 831 parameters can be processed by a regular ICE responder and is mostly 832 meant for use in cases where support for Trickle ICE cannot be 833 confirmed prior to conveying initial ICE parameters. The initial ICE 834 parameters indicate support for Trickle ICE, which means the 835 responder can respond with something less than a full generation of 836 candidates and then trickle the rest. Initial ICE parameters for 837 half trickle would typically contain an end-of-candidates indication, 838 although this is not mandatory because if trickle support is 839 confirmed then the initiator can choose to trickle additional 840 candidates before it conveys an end-of-candidates indication. 842 The half trickle mechanism can be used in cases where there is no way 843 for an agent to verify in advance whether a remote party supports 844 Trickle ICE. Because the initial ICE parameters contain a full 845 generation of candidates, it can thus be handled by a regular ICE 846 agent, while still allowing a Trickle ICE agent to use the 847 optimization defined in this specification. This prevents 848 negotiation from failing in the former case while still giving 849 roughly half the Trickle ICE benefits in the latter (hence the name 850 of the mechanism). 852 Use of half trickle is only necessary during an initial exchange of 853 ICE parameters. After both parties have received ICE parameters from 854 their peer, they can each reliably determine Trickle ICE support and 855 use it for all subsequent exchanges. 857 In some instances, using half trickle might bring more than just half 858 the improvement in terms of user experience. This can happen when an 859 agent starts gathering candidates upon user interface cues that the 860 user will soon be initiating an interaction, such as activity on a 861 keypad or the phone going off hook. This would mean that some or all 862 of the candidate gathering could be completed before the agent 863 actually needs to convey the candidate information. Because the 864 responder will be able to trickle candidates, both agents will be 865 able to start connectivity checks and complete ICE processing earlier 866 than with regular ICE and potentially even as early as with full 867 trickle. 869 However, such anticipation is not always possible. For example, a 870 multipurpose user agent or a WebRTC web page where communication is a 871 non-central feature (e.g., calling a support line in case of a 872 problem with the main features) would not necessarily have a way of 873 distinguishing between call intentions and other user activity. In 874 such cases, using full trickle is most likely to result in an ideal 875 user experience. Even so, using half trickle would be an improvement 876 over regular ICE because it would result in a better experience for 877 responders. 879 15. Requirements for Signaling Protocols 881 In order to fully enable the use of Trickle ICE, this specification 882 defines the following requirements for signaling protocols. 884 o A signaling protocol SHOULD provide a way for parties to advertise 885 and discover support for Trickle ICE before an ICE session begins 886 (see Section 3). 888 o A signaling protocol MUST provide methods for incrementally 889 conveying (i.e., "trickling") additional candidates after 890 conveying the initial ICE parameters (see Section 8). 892 o A signaling protocol MUST deliver each trickled candidate not more 893 than once and in the same order it was conveyed (see Section 8). 895 o A signaling protocol MUST provide a mechanism for both parties to 896 indicate and agree on the ICE session in force (see Section 8). 898 o A signaling protocol MUST provide a way for parties to communicate 899 the end-of-candidates indication (see Section 8.2). 901 16. Preserving Candidate Order while Trickling 903 One important aspect of regular ICE is that connectivity checks for a 904 specific foundation and component are attempted simultaneously by 905 both agents, so that any firewalls or NATs fronting the agents would 906 whitelist both endpoints and allow all except for the first 907 ("suicide") packets to go through. This is also important to 908 unfreezing candidates at the right time. While not crucial, 909 preserving this behavior in Trickle ICE is likely to improve ICE 910 performance. 912 To achieve this, when trickling candidates, agents MUST respect the 913 order in which the components and streams appear (implicitly or 914 explicitly) as they have been negotiated by means of the relevant 915 candidate information. Therefore a candidate for a specific 916 component MUST NOT be conveyed prior to candidates for other 917 components within the same foundation. In addition, candidates MUST 918 be paired, following the procedures in Section 8.1.1, in the same 919 order they are conveyed. 921 For example, the following SDP description contains two components 922 (RTP and RTCP) and two foundations (host and server reflexive): 924 v=0 925 o=jdoe 2890844526 2890842807 IN IP6 2001:db8:a0b:12f0::1 926 s= 927 c=IN IP4 2001:db8:a0b:12f0::1 928 t=0 0 929 a=ice-pwd:asd88fgpdd777uzjYhagZg 930 a=ice-ufrag:8hhY 931 m=audio 5000 RTP/AVP 0 932 a=rtpmap:0 PCMU/8000 933 a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host 934 a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host 935 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx 936 raddr 2001:db8:a0b:12f0::1 rport 8998 937 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx 938 raddr 2001:db8:a0b:12f0::1 rport 8998 940 For this candidate information the RTCP host candidate MUST NOT be 941 conveyed prior to the RTP host candidate. Similarly the RTP server 942 reflexive candidate MUST be conveyed together with or prior to the 943 RTCP server reflexive candidate. 945 Similar considerations apply at the level of media streams in 946 addition to foundations; this is covered by the requirement to always 947 start unfreezing candidates starting from the first media stream as 948 described under Section 5.2. 950 17. Example Flow 952 As an example, a typical successful Trickle ICE exchange with a 953 signaling protocol that follows the offer/answer model would look 954 this way: 956 Alice Bob 957 | Offer | 958 |---------------------------------------------->| 959 | Additional Candidates | 960 |---------------------------------------------->| 961 | | 962 | Answer | 963 |<----------------------------------------------| 964 | Additional Candidates | 965 |<----------------------------------------------| 966 | | 967 | Additional Candidates and Connectivity Checks | 968 |<--------------------------------------------->| 969 | | 970 |<=============== MEDIA FLOWS =================>| 972 Figure 8: Example 974 18. IANA Considerations 976 IANA is requested to register the following ICE option in the "ICE 977 Options" sub-registry of the "Interactive Connectivity Establishment 978 (ICE) registry", following the procedures defined in [RFC6336]. 980 ICE Option: trickle 982 Contact: Emil Ivov, eivov@atlassian.com 984 Change control: IESG 986 Description: An ICE option of "trickle" indicates support for 987 incremental communication of ICE candidates. 989 Reference: RFC XXXX 991 19. Security Considerations 993 This specification inherits most of its semantics from [rfc5245bis] 994 and as a result all security considerations described there apply to 995 Trickle ICE. 997 If the privacy implications of revealing host addresses on an 998 endpoint device are a concern, agents can generate ICE parameters 999 that contain no candidates and then only trickle candidates that do 1000 not reveal host addresses (e.g., relayed candidates). 1002 20. Acknowledgements 1004 The authors would like to thank Bernard Aboba, Flemming Andreasen, 1005 Rajmohan Banavi, Taylor Brandstetter, Philipp Hancke, Christer 1006 Holmberg, Ari Keranen, Paul Kyzivat, Jonathan Lennox, Enrico Marocco, 1007 Pal Martinsen, Thomas Stach, Peter Thatcher, Martin Thomson, Dale R. 1008 Worley, and Brandon Williams for their reviews and suggestions on 1009 improving this document. Thanks also to Ari Keranen and Peter 1010 Thatcher for chairing the ICE Working Group. 1012 21. References 1014 21.1. Normative References 1016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1017 Requirement Levels", BCP 14, RFC 2119, 1018 DOI 10.17487/RFC2119, March 1997, 1019 . 1021 [rfc5245bis] 1022 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1023 Connectivity Establishment (ICE): A Protocol for Network 1024 Address Translator (NAT) Traversal", draft-ietf-ice- 1025 rfc5245bis-09 (work in progress), April 2017. 1027 21.2. Informative References 1029 [I-D.ietf-mmusic-trickle-ice-sip] 1030 Ivov, E., Thomas, T., Marocco, E., and C. Holmberg, "A 1031 Session Initiation Protocol (SIP) usage for Trickle ICE", 1032 draft-ietf-mmusic-trickle-ice-sip-07 (work in progress), 1033 March 2017. 1035 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1036 and E. Lear, "Address Allocation for Private Internets", 1037 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1038 . 1040 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1041 A., Peterson, J., Sparks, R., Handley, M., and E. 1042 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1043 DOI 10.17487/RFC3261, June 2002, 1044 . 1046 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1047 with Session Description Protocol (SDP)", RFC 3264, 1048 DOI 10.17487/RFC3264, June 2002, 1049 . 1051 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1052 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1053 July 2006, . 1055 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 1056 Translation (NAT) Behavioral Requirements for Unicast 1057 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 1058 2007, . 1060 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1061 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1062 DOI 10.17487/RFC5389, October 2008, 1063 . 1065 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1066 Relays around NAT (TURN): Relay Extensions to Session 1067 Traversal Utilities for NAT (STUN)", RFC 5766, 1068 DOI 10.17487/RFC5766, April 2010, 1069 . 1071 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1072 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1073 March 2011, . 1075 [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for 1076 Interactive Connectivity Establishment (ICE) Options", 1077 RFC 6336, DOI 10.17487/RFC6336, July 2011, 1078 . 1080 [XEP-0030] 1081 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 1082 Andre, "XEP-0030: Service Discovery", XEP XEP-0030, June 1083 2008. 1085 [XEP-0176] 1086 Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., 1087 Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP 1088 Transport Method", XEP XEP-0176, June 2009. 1090 Appendix A. Interaction with Regular ICE 1092 The ICE protocol was designed to be flexible enough to work in and 1093 adapt to as many network environments as possible. Despite that 1094 flexibility, ICE as specified in [rfc5245bis] does not by itself 1095 support trickle ICE. This section describes how trickling of 1096 candidates interacts with ICE. 1098 [rfc5245bis] describes the conditions required to update check lists 1099 and timer states while an ICE agent is in the Running state. These 1100 conditions are verified upon transaction completion and one of them 1101 stipulates that: 1103 If there is not a pair in the valid list for each component of the 1104 media stream, the state of the check list is set to Failed. 1106 This could be a problem and cause ICE processing to fail prematurely 1107 in a number of scenarios. Consider the following case: 1109 1. Alice and Bob are both located in different networks with Network 1110 Address Translation (NAT). Alice and Bob themselves have 1111 different address but both networks use the same private internet 1112 block (e.g., the "20-bit block" 172.16/12 specified in 1113 [RFC1918]). 1115 2. Alice conveys Bob the candidate 172.16.0.1 which also happens to 1116 correspond to an existing host on Bob's network. 1118 3. Bob creates a check list consisting solely of 172.16.0.1 and 1119 starts checks. 1121 4. These checks reach the host at 172.16.0.1 in Bob's network, which 1122 responds with an ICMP "port unreachable" error; per [rfc5245bis] 1123 Bob marks the transaction as Failed. 1125 At this point the check list only contains Failed candidates and the 1126 valid list is empty. This causes the media stream and potentially 1127 all ICE processing to fail. 1129 A similar race condition would occur if the initial ICE parameters 1130 from Alice contain only candidates that can be determined as 1131 unreachable from any of the candidates that Bob has gathered (e.g., 1132 this would be the case if Bob's candidates only contain IPv4 1133 addresses and the first candidate that he receives from Alice is an 1134 IPv6 one). 1136 Another potential problem could arise when a non-trickle ICE 1137 implementation initiates an interaction with a Trickle ICE 1138 implementation. Consider the following case: 1140 1. Alice's client has a non-Trickle ICE implementation. 1142 2. Bob's client has support for Trickle ICE. 1144 3. Alice and Bob are behind NATs with address-dependent filtering 1145 [RFC4787]. 1147 4. Bob has two STUN servers but one of them is currently 1148 unreachable. 1150 After Bob's agent receives Alice's initial ICE parameters it would 1151 immediately start connectivity checks. It would also start gathering 1152 candidates, which would take a long time because of the unreachable 1153 STUN server. By the time Bob's answer is ready and conveyed to 1154 Alice, Bob's connectivity checks may well have failed: until Alice 1155 gets Bob's answer, she won't be able to start connectivity checks and 1156 punch holes in her NAT. The NAT would hence be filtering Bob's 1157 checks as originating from an unknown endpoint. 1159 Appendix B. Interaction with ICE Lite 1161 The behavior of ICE lite agents that are capable of Trickle ICE does 1162 not require any particular rules other than those already defined in 1163 this specification and [rfc5245bis]. This section is hence provided 1164 only for informational purposes. 1166 An ICE lite agent would generate candidate information as per 1167 [rfc5245bis] and would indicate support for Trickle ICE. Given that 1168 the candidate information will contain a full generation of 1169 candidates, it would also be accompanied by an end-of-candidates 1170 indication. 1172 When performing full trickle, a full ICE implementation could 1173 conveying initial ICE parameters or response thereto with no 1174 candidates. After receiving a response that identifies the remote 1175 agent as an ICE lite implementation, the initiator can choose to not 1176 trickle any additional candidates. The same is also true in the case 1177 when the ICE lite agent initiates the interaction and the full ICE 1178 agent is the responder. In these cases the connectivity checks would 1179 be enough for the ICE lite implementation to discover all potentially 1180 useful candidates as peer reflexive. The following example 1181 illustrates one such ICE session using SDP syntax: 1183 ICE Lite Bob 1184 Agent 1185 | Offer (a=ice-lite a=ice-options:trickle) | 1186 |---------------------------------------------->| 1187 | |no cand 1188 | Answer (a=ice-options:trickle) |trickling 1189 |<----------------------------------------------| 1190 | Connectivity Checks | 1191 |<--------------------------------------------->| 1192 peer rflx| | 1193 cand disco| | 1194 | | 1195 |<=============== MEDIA FLOWS =================>| 1197 Figure 9: Example 1199 In addition to reducing signaling traffic this approach also removes 1200 the need to discover STUN bindings or make TURN allocations, which 1201 may considerably lighten ICE processing. 1203 Appendix C. Changes from Earlier Versions 1205 Note to the RFC-Editor: please remove this section prior to 1206 publication as an RFC. 1208 C.1. Changes from draft-ietf-ice-trickle-09 1210 o Removed immediate unfreeze upon Fail. 1212 o Specified MUST NOT regarding ice-options. 1214 o Changed terminology regarding initial ICE parameters to avoid 1215 implementer confusion. 1217 C.2. Changes from draft-ietf-ice-trickle-08 1219 o Reinstated text about in-order processing of messages as a 1220 requirement for signaling protocols. 1222 o Added IANA registration template for ICE option. 1224 o Corrected Case 3 rule in Section 8.1.1 to ensure consistency with 1225 regular ICE rules. 1227 o Added tabular representations to Section 8.1.1 in order to 1228 illustrate the new pair rules. 1230 C.3. Changes from draft-ietf-ice-trickle-07 1232 o Changed "ICE description" to "candidate information" for 1233 consistency with 5245bis. 1235 C.4. Changes from draft-ietf-ice-trickle-06 1237 o Addressed editorial feedback from chairs review. 1239 o Clarified terminology regarding generations. 1241 C.5. Changes from draft-ietf-ice-trickle-05 1243 o Rewrote the text on inserting a new pair into a check list. 1245 C.6. Changes from draft-ietf-ice-trickle-04 1247 o Removed dependency on SDP and offer/answer model. 1249 o Removed mentions of aggressive nomination, since it is deprecated 1250 in 5245bis. 1252 o Added section on requirements for signaling protocols. 1254 o Clarified terminology. 1256 o Addressed various WG feedback. 1258 C.7. Changes from draft-ietf-ice-trickle-03 1260 o Copy edit. 1262 C.8. Changes from draft-ietf-ice-trickle-03 1264 o Provided more detailed description of unfreezing behavior, 1265 specifically how to replace pre-existing peer-reflexive candidates 1266 with higher-priority ones received via trickling. 1268 C.9. Changes from draft-ietf-ice-trickle-02 1270 o Adjusted unfreezing behavior when there are disparate foundations. 1272 C.10. Changes from draft-ietf-ice-trickle-01 1274 o Changed examples to use IPv6. 1276 C.11. Changes from draft-ietf-ice-trickle-00 1278 o Removed dependency on SDP (which is to be provided in a separate 1279 specification). 1281 o Clarified text about the fact that a check list can be empty if no 1282 candidates have been sent or received yet. 1284 o Clarified wording about check list states so as not to define new 1285 states for "Active" and "Frozen" because those states are not 1286 defined for check lists (only for candidate pairs) in ICE core. 1288 o Removed open issues list because it was out of date. 1290 o Completed a thorough copy edit. 1292 C.12. Changes from draft-mmusic-trickle-ice-02 1294 o Addressed feedback from Rajmohan Banavi and Brandon Williams. 1296 o Clarified text about determining support and about how to proceed 1297 if it can be determined that the answering agent does not support 1298 Trickle ICE. 1300 o Clarified text about check list and timer updates. 1302 o Clarified when it is appropriate to use half trickle or to send no 1303 candidates in an offer or answer. 1305 o Updated the list of open issues. 1307 C.13. Changes from draft-ivov-01 and draft-mmusic-00 1309 o Added a requirement to trickle candidates by order of components 1310 to avoid deadlocks in the unfreezing algorithm. 1312 o Added an informative note on peer-reflexive candidates explaining 1313 that nothing changes for them semantically but they do become a 1314 more likely occurrence for Trickle ICE. 1316 o Limit the number of pairs to 100 to comply with 5245. 1318 o Added clarifications on the non-importance of how newly discovered 1319 candidates are trickled/sent to the remote party or if this is 1320 done at all. 1322 o Added transport expectations for trickled candidates as per Dale 1323 Worley's recommendation. 1325 C.14. Changes from draft-ivov-00 1327 o Specified that end-of-candidates is a media level attribute which 1328 can of course appear as session level, which is equivalent to 1329 having it appear in all m-lines. Also made end-of-candidates 1330 optional for cases such as aggressive nomination for controlled 1331 agents. 1333 o Added an example for ICE lite and Trickle ICE to illustrate how, 1334 when talking to an ICE lite agent doesn't need to send or even 1335 discover any candidates. 1337 o Added an example for ICE lite and Trickle ICE to illustrate how, 1338 when talking to an ICE lite agent doesn't need to send or even 1339 discover any candidates. 1341 o Added wording that explicitly states ICE lite agents have to be 1342 prepared to receive no candidates over signaling and that they 1343 should not freak out if this happens. (Closed the corresponding 1344 open issue). 1346 o It is now mandatory to use MID when trickling candidates and using 1347 m-line indexes is no longer allowed. 1349 o Replaced use of 0.0.0.0 to IP6 :: in order to avoid potential 1350 issues with RFC2543 SDP libraries that interpret 0.0.0.0 as an on- 1351 hold operation. Also changed the port number here from 1 to 9 1352 since it already has a more appropriate meaning. (Port change 1353 suggested by Jonathan Lennox). 1355 o Closed the Open Issue about use about what to do with cands 1356 received after end-of-cands. Solution: ignore, do an ICE restart 1357 if you want to add something. 1359 o Added more terminology, including trickling, trickled candidates, 1360 half trickle, full trickle, 1362 o Added a reference to the SIP usage for Trickle ICE as requested at 1363 the Boston interim. 1365 C.15. Changes from draft-rescorla-01 1367 o Brought back explicit use of Offer/Answer. There are no more 1368 attempts to try to do this in an O/A independent way. Also 1369 removed the use of ICE Descriptions. 1371 o Added SDP specification for trickled candidates, the trickle 1372 option and 0.0.0.0 addresses in m-lines, and end-of-candidates. 1374 o Support and Discovery. Changed that section to be less abstract. 1375 As discussed in IETF85, the draft now says implementations and 1376 usages need to either determine support in advance and directly 1377 use trickle, or do half trickle. Removed suggestion about use of 1378 discovery in SIP or about letting implementing protocols do what 1379 they want. 1381 o Defined Half Trickle. Added a section that says how it works. 1382 Mentioned that it only needs to happen in the first o/a (not 1383 necessary in updates), and added Jonathan's comment about how it 1384 could, in some cases, offer more than half the improvement if you 1385 can pre-gather part or all of your candidates before the user 1386 actually presses the call button. 1388 o Added a short section about subsequent offer/answer exchanges. 1390 o Added a short section about interactions with ICE Lite 1391 implementations. 1393 o Added two new entries to the open issues section. 1395 C.16. Changes from draft-rescorla-00 1397 o Relaxed requirements about verifying support following a 1398 discussion on MMUSIC. 1400 o Introduced ICE descriptions in order to remove ambiguous use of 1401 3264 language and inappropriate references to offers and answers. 1403 o Removed inappropriate assumption of adoption by RTCWEB pointed out 1404 by Martin Thomson. 1406 Authors' Addresses 1408 Emil Ivov 1409 Atlassian 1410 303 Colorado Street, #1600 1411 Austin, TX 78701 1412 USA 1414 Phone: +1-512-640-3000 1415 Email: eivov@atlassian.com 1416 Eric Rescorla 1417 RTFM, Inc. 1418 2064 Edgewood Drive 1419 Palo Alto, CA 94303 1420 USA 1422 Phone: +1 650 678 2350 1423 Email: ekr@rtfm.com 1425 Justin Uberti 1426 Google 1427 747 6th St S 1428 Kirkland, WA 98033 1429 USA 1431 Phone: +1 857 288 8888 1432 Email: justin@uberti.name 1434 Peter Saint-Andre 1435 Filament 1436 P.O. Box 787 1437 Parker, CO 80134 1438 USA 1440 Phone: +1 720 256 6756 1441 Email: peter@filament.com 1442 URI: https://filament.com/