idnits 2.17.1 draft-ietf-ice-trickle-06.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 date (February 22, 2017) is 2612 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-06 -- 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) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: August 26, 2017 RTFM, Inc. 6 J. Uberti 7 Google 8 P. Saint-Andre 9 Filament 10 February 22, 2017 12 Trickle ICE: Incremental Provisioning of Candidates for the Interactive 13 Connectivity Establishment (ICE) Protocol 14 draft-ietf-ice-trickle-06 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 August 26, 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. Sending the Initial ICE Description . . . . . . . . . . . . . 6 64 5. Receiving the Initial ICE Description . . . . . . . . . . . . 7 65 5.1. Sending 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 Sending Additional Local Candidates . . . . . 9 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 . . . . . . . . . . . . . . 13 77 9. Receiving Additional Remote Candidates . . . . . . . . . . . 14 78 10. Receiving an End-Of-Candidates Notification . . . . . . . . . 15 79 11. Trickle ICE and Peer Reflexive Candidates . . . . . . . . . . 15 80 12. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 15 81 13. Subsequent Exchanges . . . . . . . . . . . . . . . . . . . . 15 82 14. Unilateral Use of Trickle ICE (Half Trickle) . . . . . . . . 16 83 15. Requirements for Signaling Protocols . . . . . . . . . . . . 17 84 16. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . 17 85 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 18. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 88 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 20.1. Normative References . . . . . . . . . . . . . . . . . . 19 90 20.2. Informative References . . . . . . . . . . . . . . . . . 19 91 Appendix A. Interaction with Regular ICE . . . . . . . . . . . . 20 92 Appendix B. Interaction with ICE Lite . . . . . . . . . . . . . 21 93 Appendix C. Preserving Candidate Order while Trickling . . . . . 22 94 Appendix D. Changes from Earlier Versions . . . . . . . . . . . 23 95 D.1. Changes from draft-ietf-ice-trickle-04 . . . . . . . . . 23 96 D.2. Changes from draft-ietf-ice-trickle-03 . . . . . . . . . 24 97 D.3. Changes from draft-ietf-ice-trickle-03 . . . . . . . . . 24 98 D.4. Changes from draft-ietf-ice-trickle-02 . . . . . . . . . 24 99 D.5. Changes from draft-ietf-ice-trickle-01 . . . . . . . . . 24 100 D.6. Changes from draft-ietf-ice-trickle-00 . . . . . . . . . 24 101 D.7. Changes from draft-mmusic-trickle-ice-02 . . . . . . . . 24 102 D.8. Changes from draft-ivov-01 and draft-mmusic-00 . . . . . 25 103 D.9. Changes from draft-ivov-00 . . . . . . . . . . . . . . . 25 104 D.10. Changes from draft-rescorla-01 . . . . . . . . . . . . . 26 105 D.11. Changes from draft-rescorla-00 . . . . . . . . . . . . . 27 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 108 1. Introduction 110 The Interactive Connectivity Establishment (ICE) protocol 111 [rfc5245bis] describes mechanisms for gathering candidates, 112 prioritizing them, choosing default ones, exchanging them with a 113 remote party, pairing them, and ordering them into check lists. Once 114 all of these actions have been completed (and only then), the parties 115 can begin a phase of connectivity checks and eventually select the 116 pair of candidates that will be used in a media session or for a 117 given media stream. 119 Although the sequence described above has the advantage of being 120 relatively straightforward to implement and debug once deployed, it 121 can also be rather lengthy. Candidate gathering often involves 122 things like querying STUN [RFC5389] servers and allocating relayed 123 candidates at TURN [RFC5766] servers. All of these actions can be 124 delayed for a noticeable amount of time; although they can be run in 125 parallel, they still need to respect the pacing requirements from 126 [rfc5245bis], which is likely to delay them even further. Some or 127 all of these actions also need be completed by the remote agent. 128 Both agents would next perform connectivity checks and only then 129 would they be ready to begin streaming media. 131 These factors can lead to relatively lengthy session establishment 132 times and thus to a degraded user experience. 134 This document defines an alternative or supplementary mode of 135 operation for ICE implementations, known as "Trickle ICE", in which 136 candidates can be exchanged incrementally. This enables ICE agents 137 to exchange candidates as soon as an ICE negotiation session has been 138 initiated. Connectivity checks for a media stream can also start as 139 soon as the first candidates for that stream become available. 141 Trickle ICE can reduce session establishment times in cases where 142 connectivity is confirmed for the first exchanged candidates (e.g., 143 where candidates for one of the agents are directly reachable from 144 the second agent, such as candidates at a media relay). Even when 145 this is not the case, performing candidate gathering for both agents 146 and connectivity checks in parallel can considerably shorten ICE 147 processing times. 149 It is worth noting that there is quite a bit of operational 150 experience with the Trickle ICE technique, going back as far as 2005 151 (when the XMPP Jingle extension defined a "dribble mode" as specified 152 in [XEP-0176]); this document incorporates feedback from those who 153 have implemented and deployed the technique. 155 In addition to the basics of Trickle ICE, this document also 156 describes how to discover support for Trickle ICE, how regular ICE 157 processing needs to be modified when building and updating check 158 lists, and how Trickle ICE implementations interoperate with agents 159 that only implement regular ICE processing as defined in 160 [rfc5245bis]. 162 This specification does not define the usage of Trickle ICE with any 163 specific signaling protocol (however, see 164 [I-D.ietf-mmusic-trickle-ice-sip] for usage with SIP [RFC3261] and 165 [XEP-0176] for usage with XMPP [RFC6120]). Similarly, it does not 166 define Trickle ICE in terms of the Session Description Protocol (SDP) 167 [RFC4566] or the offer/answer model [RFC3264] because the technique 168 can be and already is used in application protocols that are not tied 169 to SDP or to offer/answer semantics. However, because SDP and the 170 offer/answer model are familiar to most readers of this 171 specification, some examples in this document use those particulars 172 in order to explain the underlying concepts. 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 This specification makes use of all terminology defined for 181 Interactive Connectivity Establishment in [rfc5245bis]. In addition, 182 it defines the following terms: 184 Candidate Gatherer: A module used by an ICE agent to obtain local 185 candidates. Candidate gatherers use different mechanisms for 186 discovering local candidates, such as STUN and TURN. 188 Generation: The complete set of candidates sent within an ICE 189 negotiation session. 191 ICE Description: Any session-related (as opposed to candidate- 192 related) attributes required to configure an ICE agent. These 193 include but are not limited to "ice-ufrag", "ice-pwd", and "ice- 194 options". 196 ICE Negotiation Session: A virtual session involving all of the 197 interactions between ICE agents up until an ICE restart (if any). 199 Initiator: The ICE agent that starts an ICE negotiation session. 201 Responder: The ICE agent with which an initiator starts an ICE 202 negotiation session. 204 Trickled Candidates: Candidates that a Trickle ICE agent sends after 205 sending an initial ICE description or responding to an initial ICE 206 description, but within the same ICE negotiation session. 207 Trickled candidates can be sent in parallel with candidate 208 gathering and connectivity checks. 210 Trickling: The act of sending trickled candidates. 212 Half Trickle: A Trickle ICE mode of operation where the initiator 213 gathers its first generation of candidates strictly before 214 creating and sending the initial ICE description. Once sent, that 215 ICE description can be processed by regular ICE agents and does 216 not require support for this specification. It also allows 217 Trickle ICE capable responders to still gather candidates and 218 perform connectivity checks in a non-blocking way, thus roughly 219 providing "half" the advantages of Trickle ICE. The mechanism is 220 mostly meant for use in cases where the remote agent's support for 221 Trickle ICE cannot be confirmed prior to sending an initial ICE 222 description. 224 Full Trickle: The typical mode of operation for Trickle ICE agents, 225 in which an initial ICE description can include any number of 226 candidates (even zero candidates) and does not need to include the 227 entire first 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 sending an initial ICE description, 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 description that it supports Trickle ICE (e.g., in SDP this would 255 be a token of "trickle" in the ice-options attribute). 257 Dedicated discovery semantics and half trickle are needed only prior 258 to session initiation. After a session is established and Trickle 259 ICE support is confirmed for both parties, either agent can use full 260 trickle for subsequent exchanges. 262 4. Sending the Initial ICE Description 264 An agent can start gathering candidates as soon as it has an 265 indication that communication is imminent (e.g., a user interface cue 266 or an explicit request to initiate a session). Unlike in regular 267 ICE, in Trickle ICE implementations do not need to gather candidates 268 in a blocking manner. Therefore, unless half trickle is being used, 269 agents SHOULD generate and transmit their initial ICE description as 270 early as possible, so that the remote party can start gathering and 271 trickling candidates. 273 Trickle ICE agents MAY include any mix of candidates in an ICE 274 description. This includes the possibility of sending an ICE 275 description that contains all the candidates that the agent plans to 276 use (as in half trickle mode), sending an ICE description that 277 contains only a publicly-reachable IP address (e.g., a candidate at a 278 media relay that is known to not be behind a firewall), or sending an 279 ICE description with no candidates at all (in which case the 280 initiator can obtain the responder's initial candidate list sooner 281 and the responder can begin candidate gathering more quickly). 283 Methods for calculating priorities and foundations, as well as 284 determining redundancy of candidates, work just as with regular ICE 285 (with the exception of pruning of duplicate peer reflexive candidates 286 as described under Section 5.2). 288 5. Receiving the Initial ICE Description 290 When a responder receives an initial ICE description, it will first 291 check if the ICE description or initiator indicates support for 292 Trickle ICE as explained in Section 3. If this is not the case, the 293 agent MUST process the ICE description according to regular ICE 294 procedures [rfc5245bis] (or, if no ICE support is detected at all, 295 according to relevant processing rules for the underlying signaling 296 protocol, such as offer/answer processing rules [RFC3264]). 298 If support for Trickle ICE is confirmed, an agent will automatically 299 assume support for regular ICE as well even if the support 300 verification procedure in [rfc5245bis] indicates otherwise. 301 Specifically, the rules from [rfc5245bis] would imply that ICE itself 302 is not supported if the initial ICE description includes no 303 candidates; however, such a conclusion is not warranted if the 304 responder can confirm that the initiator supports Trickle ICE; in 305 this case, fallback to [RFC3264] is not necessary. 307 If the initial ICE description does indicate support for Trickle ICE, 308 the agent will determine its role and start gathering and 309 prioritizing candidates; while doing so, it will also respond by 310 sending its own ICE description, so that both agents can start 311 forming check lists and begin connectivity checks. 313 5.1. Sending the Initial Response 315 An agent can respond to an initial ICE description at any point while 316 gathering candidates. Here again the ICE description MAY contain any 317 set of candidates, including all candidates or no candidates. (The 318 benefit of including no candidates is to send the ICE description as 319 quickly as possible, so that both parties can consider the overall 320 session to be under active negotiation as soon as possible.) 322 As noted in Section 3, in application protocols that use SDP the 323 responder's ICE description can indicate support for Trickle ICE by 324 including a token of "trickle" in the ice-options attribute. 326 5.2. Forming Check Lists and Beginning Connectivity Checks 328 After the initiator and responder exchange ICE descriptions, and as 329 soon as they have obtained local and remote candidates, agents begin 330 forming candidate pairs, computing candidate pair priorities, 331 ordering candidate pairs, pruning duplicate pairs, and creating check 332 lists according to regular ICE procedures [rfc5245bis]. 334 According to those procedures, in order for candidate pairing to be 335 possible and for duplicate candidates to be pruned, the candidates 336 would need to be provided in the relevant ICE descriptions. Under 337 Trickle ICE, check lists can be empty until candidate pairs are sent 338 or received. Therefore Trickle ICE agents handle check lists and 339 candidate pairing in a slightly different way than regular ICE 340 agents: the agents still create the check lists, but they populate 341 the check lists only after they actually have the candidate pairs. 343 A Trickle ICE agent initially considers all check lists to be frozen. 344 It then inspects the first check list and attempts to unfreeze all 345 candidate pairs it has received so far that belong to the first 346 component on the first media stream (i.e., the first media stream 347 that was reported to the ICE implementation from the using 348 application). If that first component of the first media stream does 349 not contain candidates for one or more of the currently known pair 350 foundations, and if candidate pairs already exist for that foundation 351 in one of the following components or media streams, then the agent 352 unfreezes the first of those candidate pairs. 354 With regard to pruning of duplicate candidate pairs, a Trickle ICE 355 agent SHOULD follow a policy of "highest priority wins, except for 356 peer reflexive candidates". 358 6. Receiving the Initial Answer 360 When processing an ICE description from a responder, the initiator 361 follows regular ICE procedures to determine its role, after which it 362 forms check lists (as described in Section 5.2) and begins 363 connectivity checks. 365 7. Performing Connectivity Checks 367 For the most part, Trickle ICE agents perform connectivity checks 368 following regular ICE procedures. However, the fact that gathering 369 and communicating candidates is asynchronous in Trickle ICE imposes a 370 number of changes as described in the following sections. 372 7.1. Scheduling Checks 374 The ICE specification [rfc5245bis], Section 5.8, requires that agents 375 terminate the timer for a triggered check in relation to an active 376 check list once the agent has exhausted all frozen pairs in the check 377 list. This will not work with Trickle ICE, because more pairs will 378 be added to the check list incrementally. 380 Therefore, a Trickle ICE agent SHOULD NOT terminate the timer until 381 the state of the check list is Completed or Failed as specified 382 herein (see Section 8.2). 384 7.2. Check List and Timer State Updates 386 The ICE specification [rfc5245bis], Section 7.1.3.3, requires that 387 agents update check lists and timer states upon completing a 388 connectivity check transaction. During such an update, regular ICE 389 agents would set the state of a check list to Failed if both of the 390 following two conditions are satisfied: 392 o all of the pairs in the check list are either in the Failed state 393 or Succeeded state; and 395 o there is not a pair in the valid list for each component of the 396 media stream. 398 With Trickle ICE, the above situation would often occur when 399 candidate gathering and trickling are still in progress, even though 400 it is quite possible that future checks will succeed. For this 401 reason, Trickle ICE agents add the following conditions to the above 402 list: 404 o all candidate gatherers have completed and the agent is not 405 expecting to discover any new local candidates; 407 o the remote agent has sent an end-of-candidates indication for that 408 check list as described in Section 8.2. 410 Regular ICE requires that agents then update all other check lists, 411 placing one pair from each of them into the Waiting state, 412 effectively unfreezing all remaining check lists. However, under 413 Trickle ICE other check lists might still be empty at that point. 414 Therefore a Trickle ICE agent MUST monitor whether a check list is 415 active or frozen independently of the state of the candidate pairs 416 that the check list contains, and MUST consider a check list to be 417 active when unfreezing the first candidate pair in the check list. 418 When there is no candidate pair in a check list (i.e., when the check 419 list is empty), a Trickle ICE agent MAY consider it to be either 420 active or frozen. An empty frozen check list SHOULD be changed to 421 active if another check list is completely finished (i.e., every pair 422 is either Successful or Failed), or if another checklist has a valid 423 candidate pair for all components. 425 8. Discovering and Sending Additional Local Candidates 427 After ICE descriptions have been sent, agents will most likely 428 continue discovering new local candidates as STUN, TURN, and other 429 non-host candidate gathering mechanisms begin to yield results. 430 Whenever an agent discovers such a new candidate it will compute its 431 priority, type, foundation and component ID according to regular ICE 432 procedures. 434 The new candidate is then checked for redundancy against the existing 435 list of local candidates. If its transport address and base match 436 those of an existing candidate, it will be considered redundant and 437 will be ignored. This would often happen for server reflexive 438 candidates that match the host addresses they were obtained from 439 (e.g., when the latter are public IPv4 addresses). Contrary to 440 regular ICE, Trickle ICE agents will consider the new candidate 441 redundant regardless of its priority. 443 Next the agent sends (i.e., trickles) the newly discovered 444 candidate(s) to the remote agent. The actual delivery of the new 445 candidates is handled by a signaling protocol such as SIP or XMPP. 446 Trickle ICE imposes no restrictions on the way this is done (e.g., 447 some applications may choose not to send trickle updates for server 448 reflexive candidates and instead rely on the discovery of peer 449 reflexive ones). 451 When trickle updates are sent, each candidate MUST be delivered to 452 the receiving Trickle ICE implementation not more than once. If 453 there are any candidate retransmissions, they need to be hidden from 454 the ICE implementation. 456 Also, candidate trickling needs to be correlated to a specific ICE 457 negotiation session, so that if there is an ICE restart, any delayed 458 updates for a previous session can be recognized as such and ignored 459 by the receiving party. For example, applications that choose to 460 signal candidates via SDP may include a ufrag value in the 461 corresponding a=candidate line such as: 463 a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY 465 Or as another example, WebRTC implementations may include a ufrag in 466 the JavaScript objects that represent candidates. 468 Note: The signaling protocol needs to provide a mechanism for both 469 parties to indicate and agree on the ICE negotiation session in force 470 (as identified by the ufrag) so that they have a consistent view of 471 which candidates are to be paired. This is especially important in 472 the case of ICE restarts (see Section 13). 474 Once the candidate has been sent to the remote party, the agent 475 checks if any remote candidates are currently known for this same 476 stream. If not, the new candidate will simply be added to the list 477 of local candidates. 479 Otherwise, if the agent has already learned of one or more remote 480 candidates for this stream and component, it will begin pairing the 481 new local candidates with them and adding the pairs to the existing 482 check lists according to their priority. 484 Note: A Trickle ICE agent MUST NOT pair a local candidate until it 485 has been trickled to the remote agent. 487 8.1. Pairing Newly Learned Candidates and Updating Check Lists 489 Forming candidate pairs works as described in the ICE specification 490 [rfc5245bis]. However, actually adding the new pair to a check list 491 happens according to the rules described below. 493 If the check list where the pair is to be added already contains the 494 maximum number of candidate pairs (100 by default as per 495 [rfc5245bis]), the new pair is discarded. 497 If the new pair's local candidate is server reflexive, the server 498 reflexive candidate MUST be replaced by its base before adding the 499 pair to the list. 501 Once this is done, the agent examines the check list looking for 502 another pair that would be redundant with the new one. If such a 503 pair exists and the type of its remote candidate is not peer 504 reflexive, the pair with the higher priority is kept and the one with 505 the lower priority is discarded. If, on the other hand, the type of 506 the remote candidate in the pre-existing pair is peer reflexive, the 507 agent MUST replace it with the newly formed pair (regardless of their 508 respective priorities); this is done by setting the priority of the 509 new candidate to the priority of the pre-existing candidate and then 510 re-sorting the check list. 512 Note: So that both agents will have the same view of candidate 513 priorities, it is important to replacing existing pairs with 514 seemingly equivalent higher-priority ones and to always update 515 peer-reflexive candidates if equivalent alternatives are received 516 through signaling. 518 For all other pairs, including those with a server reflexive local 519 candidate that were not found to be redundant, the rules specified in 520 the following section apply. 522 8.1.1. Inserting a New Pair in a Check List 524 Consider the following tabular representation of all checklists in an 525 agent: 527 +------------+------+------+------+------+------+ 528 | | f1 | f2 | f3 | f4 | f5 | 529 +------------+------+------+------+------+------+ 530 | Audio.RTP | cp | cp | cp | | | 531 +------------+------+------+------+------+------+ 532 | Audio.RTCP | cp | cp | cp | cp | | 533 +------------+------+------+------+------+------+ 534 | Video.RTP | cp | | | | cp | 535 +------------+------+------+------+------+------+ 536 | Video.RTCP | cp | | | | cp | 537 +------------+------+------+------+------+------+ 539 Figure 1: Trickle State Updates 541 Each row in the table represents a component for a given media 542 stream. Each column represents one foundation. Each cell represents 543 one candidate pair. 545 When an agent commences ICE processing as per [rfc5245bis], it will 546 unfreeze (i.e., place in the Waiting state) the topmost candidate 547 pair in every column. Then, as the checks proceed, for each pair 548 that enters the Succeeded state the agent will unfreeze the pair that 549 is immediately underneath the pair that succeeded (e.g., if the pair 550 in column 1, row 1 succeeds then the agent will unfreeze the pair in 551 column 1, row 2). ICE also specifies that, if all the pairs in a 552 media stream for one foundation are unfrozen (e.g., column 1, rows 1 553 and 2 representing both components for the audio stream), then all of 554 the candidate pairs in the entire column are unfrozen (e.g., column 555 1, rows 3 and 4). 557 Trickle ICE preserves all of these rules. This implies that if, for 558 some reason, a Trickle agent were to begin connectivity checks with 559 all of its pairs already present, the way that pair states change is 560 indistinguishable from that of a regular ICE agent. 562 Of course, the major difference with Trickle ICE is that candidates 563 can arrive after connectivity checks have started. When this 564 happens, an agent sets the state of the newly formed pair as follows: 566 Waiting: if the newly formed pair is the topmost pair in this 567 column; 569 Waiting: if the pair immediately above the newly formed pair in 570 this column is in the Succeeded state; 572 Waiting: if there is at least one pair in this column below the row 573 of the newly formed pair whose state is either Succeeded or 574 Failed. 576 Frozen: in all other cases. 578 8.2. Announcing End of Candidates 580 Once all candidate gathering is completed or expires for a specific 581 media stream, the agent will generate an "end-of-candidates" 582 indication for that stream and send it to the remote agent via the 583 signaling channel. The exact form of the indication depends on the 584 application protocol. The indication can be sent in the following 585 ways: 587 o As part of an initiation request (which would typically be the 588 case with an initial ICE description for half trickle) 590 o Along with the last candidate an agent can send for a stream 592 o As a standalone notification (e.g., after STUN Binding requests or 593 TURN Allocate requests to a server time out and the agent has no 594 other active gatherers) 596 Sending an end-of-candidates indication in a timely manner is 597 important in order to avoid ambiguities and speed up the conclusion 598 of ICE processing. In particular: 600 o A controlled Trickle ICE agent SHOULD send an end-of-candidates 601 indication after it has completed gathering for a media stream, 602 unless ICE processing terminates before the agent has had a chance 603 to complete gathering. 605 o A controlling agent MAY conclude ICE processing prior to sending 606 end-of-candidates indications for all streams. However, it is 607 RECOMMENDED for a controlling agent to send end-of-candidates 608 indications whenever possible for the sake of consistency and to 609 keep middleboxes and controlled agents up-to-date on the state of 610 ICE processing. 612 When sending an end-of-candidates indication during trickling (rather 613 than as a part of an initial ICE description or response), it is the 614 responsibility of the using protocol to define methods for relating 615 the indication to one or more specific media streams. 617 Receiving an end-of-candidates indication enables an agent to update 618 check list states and, in case valid pairs do not exist for every 619 component in every media stream, determine that ICE processing has 620 failed. It also enables agents to speed up the conclusion of ICE 621 processing when a candidate pair has been validated but it involves 622 the use of lower-preference transports such as TURN. In such 623 situations, an implementation MAY choose to wait and see if higher- 624 priority candidates are received; in this case the end-of-candidates 625 indication provides a notification that such candidates are not 626 forthcoming. 628 An agent MAY also choose to generate an end-of-candidates indication 629 before candidate gathering has actually completed, if the agent 630 determines that gathering has continued for more than an acceptable 631 period of time. However, an agent MUST NOT send any more candidates 632 after it has sent an end-of-candidates indication. 634 When performing half trickle, an agent SHOULD send an end-of- 635 candidates indication together with its initial ICE description 636 unless it is planning to potentially send additional candidates 637 (e.g., in case the remote party turns out to support Trickle ICE). 639 After an agent sends the end-of-candidates indication, it will update 640 the state of the corresponding check list as explained in 641 Section 7.2. Past that point, an agent MUST NOT send any new 642 candidates within this ICE negotiation session. After an agent has 643 received an end-of-candidates indication, it MUST also ignore any 644 newly received candidates for that media stream or media session. 645 Therefore, adding new candidates to the negotiation is possible only 646 through an ICE restart (see Section 13). 648 This specification does not override regular ICE semantics for 649 concluding ICE processing. Therefore, even if end-of-candidates 650 indications are sent, agents will still have to go through pair 651 nomination. Also, if pairs have been nominated for components and 652 media streams, ICE processing MAY still conclude even if end-of- 653 candidates indications have not been received for all streams. 655 9. Receiving Additional Remote Candidates 657 At any time during ICE processing, a Trickle ICE agent might receive 658 new candidates from the remote agent. When this happens and no local 659 candidates are currently known for this same stream, the new remote 660 candidates are added to the list of remote candidates. 662 Otherwise, the new candidates are used for forming candidate pairs 663 with the pool of local candidates and they are added to the local 664 check lists as described in Section 8.1. 666 Once the remote agent has completed candidate gathering, it will send 667 an end-of-candidates indication. Upon receiving such an indication, 668 the local agent MUST update check list states as per Section 7.2. 669 This might lead to some check lists being marked as Failed. 671 10. Receiving an End-Of-Candidates Notification 673 When an agent receives an end-of-candidates indication for a specific 674 media stream, it will update the state of the relevant check list as 675 per Section 7.2. If the check list is still in the Active state 676 after the update, the agent will persist the fact that an end-of- 677 candidates indication has been received and take it into account in 678 future updates to the check list. 680 11. Trickle ICE and Peer Reflexive Candidates 682 Even though Trickle ICE does not explicitly modify the procedures for 683 handling peer-reflexive candidates, use of Trickle ICE can have an 684 impact on how they are processed. With Trickle ICE, it is possible 685 that server reflexive candidates can be discovered as peer reflexive 686 in cases where incoming connectivity checks are received from these 687 candidates before the trickle updates that carry them. 689 While this would certainly increase the number of cases where ICE 690 processing nominates and selects candidates discovered as peer- 691 reflexive, it does not require any change in processing. 693 It is also likely that some applications would prefer not to trickle 694 server reflexive candidates to entities that are known to be publicly 695 accessible and where sending a direct STUN binding request is likely 696 to reach the destination faster than the trickle update that travels 697 through the signaling path. 699 12. Concluding ICE Processing 701 This specification does not directly modify the procedures for ending 702 ICE processing described in Section 8 of [rfc5245bis], and Trickle 703 ICE implementations follow the same rules. 705 13. Subsequent Exchanges 707 Either agent MAY generate a subsequent ICE description at any time 708 allowed by [RFC3264]. When this happens agents will use [rfc5245bis] 709 semantics to determine whether or not the new ICE description 710 requires an ICE restart. If an ICE restart occurs, the user agents 711 can assume that Trickle ICE is still supported if support was 712 determined previously, and thus can engage in Trickle ICE behavior as 713 they would in an initial exchange of ICE descriptions where support 714 was determined through a capabilities discovery method. 716 14. Unilateral Use of Trickle ICE (Half Trickle) 718 In half trickle mode, the initiator sends a regular ICE description 719 with a complete generation of candidates. This ensures that the ICE 720 description can be processed by a regular ICE responder and is mostly 721 meant for use in cases where support for Trickle ICE cannot be 722 confirmed prior to sending an initial ICE description. The initial 723 ICE description indicates support for Trickle ICE, which means the 724 responder can respond with an incomplete generation of candidates and 725 continue trickling the rest. A half trickle ICE description would 726 typically contain an end-of-candidates indication, although this is 727 not mandatory because if trickle support is confirmed then the 728 initiator can choose to trickle additional candidates before it sends 729 an end-of-candidates indication. 731 The half trickle mechanism can be used in cases where there is no way 732 for an agent to verify in advance whether a remote party supports 733 Trickle ICE. Because the initial ICE description contains a full 734 generation of candidates, it can thus be handled by a regular ICE 735 agent, while still allowing a Trickle ICE agent to use the 736 optimization defined in this specification. This prevents 737 negotiation from failing in the former case while still giving 738 roughly half the Trickle ICE benefits in the latter (hence the name 739 of the mechanism). 741 Use of half trickle is only necessary during an initial exchange of 742 ICE descriptions. After both parties have received a session 743 description from their peer, they can each reliably determine Trickle 744 ICE support and use it for all subsequent exchanges. 746 In some instances, using half trickle might bring more than just half 747 the improvement in terms of user experience. This can happen when an 748 agent starts gathering candidates upon user interface cues that the 749 user will soon be initiating an interaction, such as activity on a 750 keypad or the phone going off hook. This would mean that some or all 751 of the candidate gathering could be completed before the agent 752 actually needs to send the ICE description. Because the responder 753 will be able to trickle candidates, both agents will be able to start 754 connectivity checks and complete ICE processing earlier than with 755 regular ICE and potentially even as early as with full trickle. 757 However, such anticipation is not always possible. For example, a 758 multipurpose user agent or a WebRTC web page where communication is a 759 non-central feature (e.g., calling a support line in case of a 760 problem with the main features) would not necessarily have a way of 761 distinguishing between call intentions and other user activity. In 762 such cases, using full trickle is most likely to result in an ideal 763 user experience. Even so, using half trickle would be an improvement 764 over regular ICE because it would result in a better experience for 765 responders. 767 15. Requirements for Signaling Protocols 769 In order to fully enable the use of Trickle ICE, this specification 770 defines the following requirements for signaling protocols. 772 o A signaling protocol SHOULD provide a way for parties to advertise 773 and discover support for Trickle ICE before an ICE negotiation 774 session begins (see Section 3). 776 o A signaling protocol MUST provide methods for incrementally 777 sending (i.e., "trickling") additional candidates after sending 778 the initial ICE description (see Section 8). 780 o A signaling protocol MUST provide a mechanism for both parties to 781 indicate and agree on the ICE negotiation session in force (see 782 Section 8). 784 o A signaling protocol MUST provide a way for parties to communicate 785 the end-of-candidates indication (see Section 8.2). 787 16. Example Flow 789 As an example, a typical successful Trickle ICE exchange with a 790 signaling protocol that follows the offer/answer model would look 791 this way: 793 Alice Bob 794 | Offer | 795 |---------------------------------------------->| 796 | Additional Candidates | 797 |---------------------------------------------->| 798 | | 799 | Answer | 800 |<----------------------------------------------| 801 | Additional Candidates | 802 |<----------------------------------------------| 803 | | 804 | Additional Candidates and Connectivity Checks | 805 |<--------------------------------------------->| 806 | | 807 |<=============== MEDIA FLOWS =================>| 809 Figure 2: Example 811 17. IANA Considerations 813 This specification requests no actions from IANA. 815 18. Security Considerations 817 This specification inherits most of its semantics from [rfc5245bis] 818 and as a result all security considerations described there apply to 819 Trickle ICE. 821 If the privacy implications of revealing host addresses on an 822 endpoint device are a concern, agents can generate an ICE description 823 that contains no candidates and then only trickle candidates that do 824 not reveal host addresses (e.g., relayed candidates). 826 19. Acknowledgements 828 The authors would like to thank Bernard Aboba, Flemming Andreasen, 829 Rajmohan Banavi, Taylor Brandstetter, Christer Holmberg, Jonathan 830 Lennox, Enrico Marocco, Pal Martinsen, Martin Thomson, Dale R. 831 Worley, and Brandon Williams for their reviews and suggestions on 832 improving this document. 834 20. References 835 20.1. Normative References 837 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 838 Requirement Levels", BCP 14, RFC 2119, March 1997. 840 [rfc5245bis] 841 Keranen, A., Keranen, A., and J. Rosenberg, "Interactive 842 Connectivity Establishment (ICE): A Protocol for Network 843 Address Translator (NAT) Traversal", draft-ietf-ice- 844 rfc5245bis-08 (work in progress), December 2016. 846 20.2. Informative References 848 [I-D.ietf-mmusic-trickle-ice-sip] 849 Ivov, E., Thomas, T., Marocco, E., and C. Holmberg, "A 850 Session Initiation Protocol (SIP) usage for Trickle ICE", 851 draft-ietf-mmusic-trickle-ice-sip-06 (work in progress), 852 October 2016. 854 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 855 and E. Lear, "Address Allocation for Private Internets", 856 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 857 . 859 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 860 A., Peterson, J., Sparks, R., Handley, M., and E. 861 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 862 June 2002. 864 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 865 with Session Description Protocol (SDP)", RFC 3264, June 866 2002. 868 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 869 Description Protocol", RFC 4566, July 2006. 871 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 872 Translation (NAT) Behavioral Requirements for Unicast 873 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 874 2007, . 876 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 877 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 878 DOI 10.17487/RFC5389, October 2008, 879 . 881 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 882 Relays around NAT (TURN): Relay Extensions to Session 883 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 885 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 886 Protocol (XMPP): Core", RFC 6120, March 2011. 888 [XEP-0030] 889 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 890 Andre, "XEP-0030: Service Discovery", XEP XEP-0030, June 891 2008. 893 [XEP-0176] 894 Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., 895 Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP 896 Transport Method", XEP XEP-0176, June 2009. 898 Appendix A. Interaction with Regular ICE 900 The ICE protocol was designed to be flexible enough to work in and 901 adapt to as many network environments as possible. Despite that 902 flexibility, ICE as specified in [rfc5245bis] does not by itself 903 support trickle ICE. This section describes how trickling of 904 candidates interacts with ICE. 906 [rfc5245bis] describes the conditions required to update check lists 907 and timer states while an ICE agent is in the Running state. These 908 conditions are verified upon transaction completion and one of them 909 stipulates that: 911 If there is not a pair in the valid list for each component of the 912 media stream, the state of the check list is set to Failed. 914 This could be a problem and cause ICE processing to fail prematurely 915 in a number of scenarios. Consider the following case: 917 1. Alice and Bob are both located in different networks with Network 918 Address Translation (NAT). Alice and Bob themselves have 919 different address but both networks use the same [RFC1918] block. 921 2. Alice sends Bob the candidate 2001:db8:a0b:12f0::10 which also 922 happens to correspond to an existing host on Bob's network. 924 3. Bob creates a check list consisting solely of 925 2001:db8:a0b:12f0::10 and starts checks. 927 4. These checks reach the host at 2001:db8:a0b:12f0::10 in Bob's 928 network, which responds with an ICMP "port unreachable" error and 929 per [rfc5245bis] Bob marks the transaction as Failed. 931 At this point the check list only contains Failed candidates and the 932 valid list is empty. This causes the media stream and potentially 933 all ICE processing to fail. 935 A similar race condition would occur if the initial ICE description 936 from Alice only contains candidates that can be determined as 937 unreachable from any of the candidates that Bob has gathered (e.g., 938 this would be the case if Bob's candidates only contain IPv4 939 addresses and the first candidate that he receives from Alice is an 940 IPv6 one). 942 Another potential problem could arise when a non-trickle ICE 943 implementation initiates an interaction with a Trickle ICE 944 implementation. Consider the following case: 946 1. Alice's client has a non-Trickle ICE implementation. 948 2. Bob's client has support for Trickle ICE. 950 3. Alice and Bob are behind NATs with address-dependent filtering 951 [RFC4787]. 953 4. Bob has two STUN servers but one of them is currently 954 unreachable. 956 After Bob's agent receives Alice's initial ICE description it would 957 immediately start connectivity checks. It would also start gathering 958 candidates, which would take a long time because of the unreachable 959 STUN server. By the time Bob's answer is ready and sent to Alice, 960 Bob's connectivity checks may well have failed: until Alice gets 961 Bob's answer, she won't be able to start connectivity checks and 962 punch holes in her NAT. The NAT would hence be filtering Bob's 963 checks as originating from an unknown endpoint. 965 Appendix B. Interaction with ICE Lite 967 The behavior of ICE lite agents that are capable of Trickle ICE does 968 not require any particular rules other than those already defined in 969 this specification and [rfc5245bis]. This section is hence provided 970 only for informational purposes. 972 An ICE lite agent would generate an ICE description as per 973 [rfc5245bis] and would indicate support for Trickle ICE. Given that 974 they will contain a complete generation of candidates, these ICE 975 descriptions would also be accompanied by an end-of-candidates 976 indication. 978 When performing full trickle, a full ICE implementation could send an 979 initial ICE description or response with no candidates. After 980 receiving a response that identifies the remote agent as an ICE lite 981 implementation, the initiator can choose to not send any additional 982 candidates. The same is also true in the case when the ICE lite 983 agent initiates the interaction and the full ICE agent is the 984 responder. In these cases the connectivity checks would be enough 985 for the ICE lite implementation to discover all potentially useful 986 candidates as peer reflexive. The following example illustrates one 987 such ICE session using SDP syntax: 989 ICE Lite Bob 990 Agent 991 | Offer (a=ice-lite a=ice-options:trickle) | 992 |---------------------------------------------->| 993 | |no cand 994 | Answer (a=ice-options:trickle) |trickling 995 |<----------------------------------------------| 996 | Connectivity Checks | 997 |<--------------------------------------------->| 998 peer rflx| | 999 cand disco| | 1000 | | 1001 |<=============== MEDIA FLOWS =================>| 1003 Figure 3: Example 1005 In addition to reducing signaling traffic this approach also removes 1006 the need to discover STUN bindings or make TURN allocations, which 1007 may considerably lighten ICE processing. 1009 Appendix C. Preserving Candidate Order while Trickling 1011 One important aspect of regular ICE is that connectivity checks for a 1012 specific foundation and component are attempted simultaneously by 1013 both agents, so that any firewalls or NATs fronting the agents would 1014 whitelist both endpoints and allow all except for the first 1015 ("suicide") packets to go through. This is also important to 1016 unfreezing candidates at the right time. While not crucial, 1017 preserving this behavior in Trickle ICE is likely to improve ICE 1018 performance. 1020 To achieve this, when trickling candidates agents MUST respect the 1021 order in which the components and streams as they have been 1022 negotiated appear (implicitly or explicitly) in the relevant ICE 1023 descriptions. Therefore a candidate for a specific component MUST 1024 NOT be sent prior to candidates for other components within the same 1025 foundation. 1027 For example, the following SDP description contains two components 1028 (RTP and RTCP) and two foundations (host and server reflexive): 1030 v=0 1031 o=jdoe 2890844526 2890842807 IN IP6 2001:db8:a0b:12f0::1 1032 s= 1033 c=IN IP4 2001:db8:a0b:12f0::1 1034 t=0 0 1035 a=ice-pwd:asd88fgpdd777uzjYhagZg 1036 a=ice-ufrag:8hhY 1037 m=audio 5000 RTP/AVP 0 1038 a=rtpmap:0 PCMU/8000 1039 a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host 1040 a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host 1041 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx 1042 raddr 2001:db8:a0b:12f0::1 rport 8998 1043 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx 1044 raddr 2001:db8:a0b:12f0::1 rport 8998 1046 For this description the RTCP host candidate MUST NOT be sent prior 1047 to the RTP host candidate. Similarly the RTP server reflexive 1048 candidate MUST be sent together with or prior to the RTCP server 1049 reflexive candidate. 1051 Similar considerations apply at the level of media streams in 1052 addition to foundations; this is covered by the requirement to always 1053 start unfreezing candidates starting from the first media stream as 1054 described under Section 5.2. 1056 Appendix D. Changes from Earlier Versions 1058 Note to the RFC-Editor: please remove this section prior to 1059 publication as an RFC. 1061 D.1. Changes from draft-ietf-ice-trickle-04 1063 o Removed dependency on SDP and offer/answer model. 1065 o Removed mentions of aggressive nomination, since it is deprecated 1066 in 5245bis. 1068 o Added section on requirements for signaling protocols. 1070 o Clarified terminology. 1072 o Addressed various WG feedback. 1074 D.2. Changes from draft-ietf-ice-trickle-03 1076 o Copy edit. 1078 D.3. Changes from draft-ietf-ice-trickle-03 1080 o Provided more detailed description of unfreezing behavior, 1081 specifically how to replace pre-existing peer-reflexive candidates 1082 with higher-priority ones received via trickling. 1084 D.4. Changes from draft-ietf-ice-trickle-02 1086 o Adjusted unfreezing behavior when there are disparate foundations. 1088 D.5. Changes from draft-ietf-ice-trickle-01 1090 o Changed examples to use IPv6. 1092 D.6. Changes from draft-ietf-ice-trickle-00 1094 o Removed dependency on SDP (which is to be provided in a separate 1095 specification). 1097 o Clarified text about the fact that a check list can be empty if no 1098 candidates have been sent or received yet. 1100 o Clarified wording about check list states so as not to define new 1101 states for "Active" and "Frozen" because those states are not 1102 defined for check lists (only for candidate pairs) in ICE core. 1104 o Removed open issues list because it was out of date. 1106 o Completed a thorough copy edit. 1108 D.7. Changes from draft-mmusic-trickle-ice-02 1110 o Addressed feedback from Rajmohan Banavi and Brandon Williams. 1112 o Clarified text about determining support and about how to proceed 1113 if it can be determined that the answering agent does not support 1114 Trickle ICE. 1116 o Clarified text about check list and timer updates. 1118 o Clarified when it is appropriate to use half trickle or to send no 1119 candidates in an offer or answer. 1121 o Updated the list of open issues. 1123 D.8. Changes from draft-ivov-01 and draft-mmusic-00 1125 o Added a requirement to trickle candidates by order of components 1126 to avoid deadlocks in the unfreezing algorithm. 1128 o Added an informative note on peer-reflexive candidates explaining 1129 that nothing changes for them semantically but they do become a 1130 more likely occurrence for Trickle ICE. 1132 o Limit the number of pairs to 100 to comply with 5245. 1134 o Added clarifications on the non-importance of how newly discovered 1135 candidates are trickled/sent to the remote party or if this is 1136 done at all. 1138 o Added transport expectations for trickled candidates as per Dale 1139 Worley's recommendation. 1141 D.9. Changes from draft-ivov-00 1143 o Specified that end-of-candidates is a media level attribute which 1144 can of course appear as session level, which is equivalent to 1145 having it appear in all m-lines. Also made end-of-candidates 1146 optional for cases such as aggressive nomination for controlled 1147 agents. 1149 o Added an example for ICE lite and Trickle ICE to illustrate how, 1150 when talking to an ICE lite agent doesn't need to send or even 1151 discover any candidates. 1153 o Added an example for ICE lite and Trickle ICE to illustrate how, 1154 when talking to an ICE lite agent doesn't need to send or even 1155 discover any candidates. 1157 o Added wording that explicitly states ICE lite agents have to be 1158 prepared to receive no candidates over signaling and that they 1159 should not freak out if this happens. (Closed the corresponding 1160 open issue). 1162 o It is now mandatory to use MID when trickling candidates and using 1163 m-line indexes is no longer allowed. 1165 o Replaced use of 0.0.0.0 to IP6 :: in order to avoid potential 1166 issues with RFC2543 SDP libraries that interpret 0.0.0.0 as an on- 1167 hold operation. Also changed the port number here from 1 to 9 1168 since it already has a more appropriate meaning. (Port change 1169 suggested by Jonathan Lennox). 1171 o Closed the Open Issue about use about what to do with cands 1172 received after end-of-cands. Solution: ignore, do an ICE restart 1173 if you want to add something. 1175 o Added more terminology, including trickling, trickled candidates, 1176 half trickle, full trickle, 1178 o Added a reference to the SIP usage for Trickle ICE as requested at 1179 the Boston interim. 1181 D.10. Changes from draft-rescorla-01 1183 o Brought back explicit use of Offer/Answer. There are no more 1184 attempts to try to do this in an O/A independent way. Also 1185 removed the use of ICE Descriptions. 1187 o Added SDP specification for trickled candidates, the trickle 1188 option and 0.0.0.0 addresses in m-lines, and end-of-candidates. 1190 o Support and Discovery. Changed that section to be less abstract. 1191 As discussed in IETF85, the draft now says implementations and 1192 usages need to either determine support in advance and directly 1193 use trickle, or do half trickle. Removed suggestion about use of 1194 discovery in SIP or about letting implementing protocols do what 1195 they want. 1197 o Defined Half Trickle. Added a section that says how it works. 1198 Mentioned that it only needs to happen in the first o/a (not 1199 necessary in updates), and added Jonathan's comment about how it 1200 could, in some cases, offer more than half the improvement if you 1201 can pre-gather part or all of your candidates before the user 1202 actually presses the call button. 1204 o Added a short section about subsequent offer/answer exchanges. 1206 o Added a short section about interactions with ICE Lite 1207 implementations. 1209 o Added two new entries to the open issues section. 1211 D.11. Changes from draft-rescorla-00 1213 o Relaxed requirements about verifying support following a 1214 discussion on MMUSIC. 1216 o Introduced ICE descriptions in order to remove ambiguous use of 1217 3264 language and inappropriate references to offers and answers. 1219 o Removed inappropriate assumption of adoption by RTCWEB pointed out 1220 by Martin Thomson. 1222 Authors' Addresses 1224 Emil Ivov 1225 Atlassian 1226 303 Colorado Street, #1600 1227 Austin 78701 1228 USA 1230 Phone: +1-512-640-3000 1231 Email: eivov@atlassian.com 1233 Eric Rescorla 1234 RTFM, Inc. 1235 2064 Edgewood Drive 1236 Palo Alto, CA 94303 1237 USA 1239 Phone: +1 650 678 2350 1240 Email: ekr@rtfm.com 1242 Justin Uberti 1243 Google 1244 747 6th St S 1245 Kirkland, WA 98033 1246 USA 1248 Phone: +1 857 288 8888 1249 Email: justin@uberti.name 1250 Peter Saint-Andre 1251 Filament 1252 P.O. Box 787 1253 Parker, CO 80134 1254 USA 1256 Phone: +1 720 256 6756 1257 Email: peter@filament.com 1258 URI: https://filament.com/