idnits 2.17.1 draft-ivov-mmusic-trickle-ice-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 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 (March 11, 2013) is 4069 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TODO' is mentioned on line 835, but not defined == Unused Reference: 'RFC3261' is defined on line 884, but no explicit reference was found in the text == Unused Reference: 'RFC3840' is defined on line 893, but no explicit reference was found in the text == Unused Reference: 'XEP-0115' is defined on line 914, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-02) exists of draft-ivov-mmusic-trickle-ice-sip-00 -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- 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: 3 errors (**), 0 flaws (~~), 8 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 Jitsi 4 Intended status: Standards Track E.K. Rescorla 5 Expires: September 12, 2013 RTFM, Inc. 6 J. Uberti 7 Google 8 March 11, 2013 10 Trickle ICE: Incremental Provisioning of Candidates for the Interactive 11 Connectivity Establishment (ICE) Protocol 12 draft-ivov-mmusic-trickle-ice-01 14 Abstract 16 This document describes an extension to the Interactive Connectivity 17 Establishment (ICE) protocol that allows ICE agents to send and 18 receive candidates incrementally rather than exchanging complete 19 lists. With such incremental provisioning, ICE agents can begin 20 connectivity checks while they are still gathering candidates and 21 considerably shorten the time necessary for ICE processing to 22 complete. 24 The above mechanism is also referred to as "trickle ICE". 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 September 12, 2013. 43 Copyright Notice 45 Copyright (c) 2013 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. Incompatibility with Standard ICE . . . . . . . . . . . . . . 5 63 4. Determining Support for Trickle ICE . . . . . . . . . . . . . 6 64 4.1. Unilateral Use of Trickle ICE (Half Trickle) . . . . . . 7 65 5. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 8 66 5.1. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 9 67 6. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 9 68 6.1. Sending the Initial Answer . . . . . . . . . . . . . . . 10 69 6.2. Forming check lists and beginning connectivity 70 checks . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 11 72 7. Receiving the Initial Answer . . . . . . . . . . . . . . . . 11 73 8. Performing Connectivity Checks . . . . . . . . . . . . . . . 11 74 8.1. Check List and Timer State Updates . . . . . . . . . . . 11 75 9. Discovering and Sending Additional Local Candidates . . . . . 12 76 9.1. Pairing newly learned candidates and updating 77 check lists . . . . . . . . . . . . . . . . . . . . . . . 12 78 9.2. Encoding the SDP for Additional Candidates . . . . . . . 14 79 9.3. Announcing End of Candidates . . . . . . . . . . . . . . 14 80 9.4. Receiving an End Of Candidates Notification . . . . . . . 16 81 10. Receiving Additional Remote Candidates . . . . . . . . . . . 16 82 11. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 16 83 12. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 17 84 13. Interaction with ICE Lite . . . . . . . . . . . . . . . . . . 17 85 14. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . 18 86 15. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 88 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 17.1. Normative References . . . . . . . . . . . . . . . . . . 19 90 17.2. Informative References . . . . . . . . . . . . . . . . . 19 91 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 21 92 A.1. MID/Stream Indices in SDP . . . . . . . . . . . . . . . . 21 93 A.2. Starting checks . . . . . . . . . . . . . . . . . . . . . 21 94 Appendix B. Changes From Earlier Versions . . . . . . . . . . . 21 95 B.1. Changes From draft-ivov-00 . . . . . . . . . . . . . . . 21 96 B.2. Changes From draft-rescorla-01 . . . . . . . . . . . . . 22 97 B.3. Changes From draft-rescorla-00 . . . . . . . . . . . . . 23 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 The Interactive Connectivity Establishment (ICE) protocol [RFC5245] 103 describes mechanisms for gathering, candidates, prioritizing them, 104 choosing default ones, exchanging them with the remote party, pairing 105 them and ordering them into check lists. Once all of the above have 106 been completed, and only then, the participating agents can begin a 107 phase of connectivity checks and eventually select the pair of 108 candidates that will be used in the following session. 110 While the above sequence has the advantage of being relatively 111 straightforward to implement and debug once deployed, it may also 112 prove to be rather lengthy. Gathering candidates or candidate 113 harvesting would often involve things like querying STUN [RFC5389] 114 servers, discovering UPnP devices, and allocating relayed candidates 115 at TURN [RFC5766] servers. All of these can be delayed for a 116 noticeable amount of time and while they can be run in parallel, they 117 still need to respect the pacing requirements from [RFC5245], which 118 is likely to delay them even further. Some or all of the above would 119 also have to be completed by the remote agent. Both agents would 120 next perform connectivity checks and only then would they be ready to 121 begin streaming media. 123 All of the above could lead to relatively lengthy session 124 establishment times and degraded user experience. 126 The purpose of this document is to define an alternative mode of 127 operation for ICE implementations, also known as "trickle ICE", where 128 candidates can be exchanged incrementally. This would allow ICE 129 agents to exchange host candidates as soon as a session has been 130 initiated. Connectivity checks for a media stream would also start 131 as soon as the first candidates for that stream have become 132 available. 134 Trickle ICE allows reducing session establishment times in cases 135 where connectivity is confirmed for the first exchanged candidates 136 (e.g. where the host candidates for one of the agents are directly 137 reachable from the second agent). Even when this is not the case, 138 running candidate harvesting for both agents and connectivity checks 139 all in parallel allows to considerably reduce ICE processing times. 141 It is worth pointing out that before being introduced to the IETF, 142 trickle ICE had already been included in specifications such as XMPP 143 Jingle [XEP-0176] and it has been in use in various implementations 144 and deployments. 146 In addition to the basics of trickle ICE, this document also 147 describes how support for trickle ICE needs to be discovered, how 148 regular ICE processing needs to be modified when building and 149 updating check lists, and how trickle ICE implementations should 150 interoperate with agents that only implement [RFC5245] processing. 152 This specification does not define usage of trickle ICE with any 153 specific signalling protocol, contrary to [RFC5245] which contains a 154 usage for ICE with SIP. Such usages would have to be specified in 155 separate documents such as for example 156 [I-D.ivov-mmusic-trickle-ice-sip]. 158 Trickle ICE does however reuse and build upon the SDP syntax defined 159 by vanilla ICE. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 This specification makes use of all terminology defined by the 168 protocol for Interactive Connectivity Establishment in [RFC5245]. 170 Vanilla ICE: The Interactive Connectivity Establishment protocol as 171 defined in [RFC5245]. 173 Candidate Harvester: A module used by an ICE agent to obtain local 174 candidates. Candidate harvesters use different mechanisms for 175 discovering local candidates. Some of them would typically make 176 use of protocols such as STUN or TURN. Others may also employ 177 techniques that are not referenced within [RFC5245]. UPnP based 178 port allocation and XMPP Jingle Relay Nodes [XEP-0278] are among 179 the possible examples. 181 Trickled Candidates: Candidates that a trickle ICE agent is sending 182 subsequently to but within the context defined by an offer or an 183 answer. Trickled candidates can be sent in parallel with 184 candidate harvesting and connectivity checks. 186 Trickling/Trickle (v.): The act of sending trickled candidates. 188 Half Trickle: A trickle ICE mode of operation where the offerer 189 gathers its first generation of candidates strictly before 190 creating and sending the offer. Once sent, that offer can be 191 processed by vanilla ICE agents and does not require support for 192 this specification. It also allows trickle ICE capable answerers 193 to still gather candidates and perform connectivity checks in a 194 non-blocking way, thus roughly offering "half" the advantages of 195 trickle ICE. The mechanism is mostly meant for use in cases where 196 support for trickle ICE cannot be confirmed prior to sending a 197 first offer. 199 Full Trickle: Regular mode of operation for trickle ICE agents, used 200 in opposition to the half trickle mode of operation. 202 3. Incompatibility with Standard ICE 204 The ICE protocol was designed to be fairly flexible so that it would 205 work in and adapt to as many network environments as possible. It is 206 hence important to point out at least some of the reasons why, 207 despite its flexibility, the specification in [RFC5245] would not 208 support trickle ICE. 210 [RFC5245] describes the conditions required to update check lists and 211 timer states while an ICE agent is in the Running state. These 212 conditions are verified upon transaction completion and one of them 213 stipulates that: 215 If there is not a pair in the valid list for each component of the 216 media stream, the state of the check list is set to Failed. 218 This could be a problem and cause ICE processing to fail prematurely 219 in a number of scenarios. Consider the following case: 221 o Alice and Bob are both located in different networks with Network 222 Address Translation (NAT). Alice and Bob themselves have 223 different address but both networks use the same [RFC1918] block. 225 o Alice sends Bob the candidate 10.0.0.10 which also happens to 226 correspond to an existing host on Bob's network. 228 o Bob creates a check list consisting solely of 10.0.0.10 and starts 229 checks. 231 o These checks reach the host at 10.0.0.10 in Bob's network, which 232 responds with an ICMP "port unreachable" error and per [RFC5245] 233 Bob marks the transaction as Failed. 235 At this point the check list only contains Failed candidates and the 236 valid list is empty. This causes the media stream and potentially 237 all ICE processing to Fail. 239 A similar race condition would occur if the initial offer from Alice 240 only contains candidates that can be determined as unreachable (per 241 [I-D.keranen-mmusic-ice-address-selection]) from any of the 242 candidates that Bob has gathered. This would be the case if Bob's 243 candidates only contain IPv4 addresses and the first candidate that 244 he receives from Alice is an IPv6 one. 246 Another potential problem could arise when a non-trickle ICE 247 implementation sends an offer to a trickle one. Consider the 248 following case: 250 o Alice's client has a non-trickle ICE implementation 252 o Bob's client has support for trickle ICE. 254 o Alice and Bob are behind NATs with address-dependent filtering 255 [RFC4787]. 257 o Bob has two STUN servers but one of them is currently unreachable 259 After Bob's agent receives Alice's offer it would immediately start 260 connectivity checks. It would also start gathering candidates, which 261 would take long because of the unreachable STUN server. By the time 262 Bob's answer is ready and sent to Alice, Bob's connectivity checks 263 may well have failed: until Alice gets Bob's answer, she won't be 264 able to start connectivity checks and punch holes in her NAT. The 265 NAT would hence be filtering Bob's checks as originating from an 266 unknown endpoint. 268 4. Determining Support for Trickle ICE 270 According to [RFC5245] every time an agent supporting trickle ICE 271 generates an offer or an answer, it MUST include the "trickle" token 272 in the ice-options attribute. Syntax for this token is defined in 273 Section 5.1. 275 Additionally, in order to avoid interoperability problems such as 276 those described in Section 3, it is important that trickle ICE 277 negotiation is only attempted in cases where the remote party 278 actually supports this specification. Agents that receive offers or 279 answers can verify support by examining them for the "trickle" ice- 280 options token. However, agents that are about to send a first offer, 281 have no immediate way of doing this. This means that usages of 282 trickle for specific protocols would need to either: 284 o Provide a way for agents to verify support of trickle ICE prior to 285 initiating a session. XMPP's Service discovery [XEP-0030] is an 286 example for one such mechanism; 288 o Make support for trickle ICE mandatory so that support could be 289 assumed the agents. 291 Alternately, for cases where a protocol provides neither of the 292 above, agents may either rely on provisioning/configuration, or use 293 the half trickle procedure described in Section 4.1. 295 Note that out-of-band discovery semantics and half trickle are only 296 necessary prior to session initiation, or in other words, when 297 sending the initial offer. Once a session is established and trickle 298 ICE support is confirmed for both parties, either agent can use full 299 trickle for subsequent offers. 301 4.1. Unilateral Use of Trickle ICE (Half Trickle) 303 The idea of using half trickle is about having the caller send a 304 regular, vanilla ICE offer, with a complete set of candidates. This 305 offer still indicates support for trickle ice, so the answerer is 306 able to respond with an incomplete set of candidates and continue 307 trickling the rest. Half trickle offers will typically contain an 308 end-of-candidates indication. 310 The mechanism can be used in cases where there is no way for an agent 311 to verify in advance whether a remote party supports trickle ice. 312 Because it contains a full set of candidates, its first offer can 313 thus be handled by a regular vanilla ICE agent, while still allowing 314 a trickle one to use the optimisation defined in this specification. 315 This prevents negotiation from failing in the former case while still 316 giving roughly half the trickle ICE benefits in the latter (hence the 317 name of the mechanism). 319 Use of half trickle is only necessary during an initial offer/answer 320 exchange. Once both parties have received a session description from 321 their peer, they can each reliably determine trickle ICE support and 322 use it for all subsequent offer/answer exchanges. 324 It is worth pointing out that using half trickle may actually bring 325 more than just half the improvement in terms of user experience. 326 This can happen in cases where an agent starts gathering candidates 327 upon user interface cues that a call is pending, such as activity on 328 a keypad or the phone going off hook. This would mean a part or all 329 candidate harvesting could have completed before the agent actually 330 needs to send the offer. Given that the answerer will be able to 331 trickle candidates, both agents will be able to start connectivity 332 checks and complete ICE processing earlier than with vanilla ICE and 333 potentially even as early as with full trickle. 335 However, such anticipation is not not always possible. For example, 336 a multipurpose user agent or a WebRTC web page where communication is 337 a non-central feature (e.g. calling a support line in case of a 338 problem with the main features) would not necessarily have a way of 339 distinguishing between call intentions and other user activity. 340 Still, even in these cases, using half trickle would be an 341 improvement over vanilla ICE as it would optimize performance for 342 answerers. 344 5. Sending the Initial Offer 346 An agent starts gathering candidates as soon as it has an indication 347 that communication is imminent (e.g. a user interface cue or an 348 explicit request to initiate a session). Contrary to vanilla ICE, 349 implementations of trickle ICE do not need to gather candidates in a 350 blocking manner. Therefore, unless half trickle is being used, 351 agents SHOULD generate and transmit their initial offer as early as 352 possible, in order to allow the remote party to start gathering and 353 trickling candidates. 355 Trickle ICE agents MAY include any set of candidates in an offer. 356 This includes the possibility of generating one with no candidates, 357 or one that contains all the candidates that the agent is planning on 358 using in the following session. 360 For optimal performance, it is RECOMMENDED that an initial offer 361 contains host candidates only. This would allow both agents to start 362 gathering server reflexive, relayed and other non-host candidates 363 simultaneously, and it would also enable them to begin connectivity 364 checks. 366 If the privacy implications of revealing host addresses are a 367 concern, agents MAY generate an offer that contains no candidates and 368 then only trickle candidates that do not reveal host addresses (e.g. 369 relayed candidates). 371 Prior to actually sending an initial offer, agents MAY verify if the 372 remote party supports trickle ICE, where such mechanisms actually 373 exist. If absence of such support is confirmed agents MUST fall back 374 to using vanilla ICE or abandon the entire session. 376 All trickle ICE offers and answers MUST indicate support of this 377 specification, as explained in Section 5.1. 379 Calculating priorities and foundations, as well as determining 380 redundancy of candidates work the same way they do with vanilla ICE. 382 5.1. Encoding the SDP 384 The process of encoding the SDP [RFC4566] is mostly the same as the 385 one used by vanilla ICE. Still, trickle ICE does require a few 386 differences described here. 388 Agents MUST indicate support for Trickle ICE by including the 389 "trickle" token for the "a=ice-options" attribute: 391 a=ice-options:trickle 393 As mentioned earlier in this section, Offers and Answers can contain 394 any set of candidates, which means that a trickle ICE session 395 description MAY contain no candidates at all. In such cases the 396 agent would still need to place an address in the "c=" line(s). If 397 the use of a host address there is undesirable (e.g. for privacy 398 reasons), the agent MAY set the connection address to IP6 ::. In this 399 case it MUST also set the port number to 9 (Discard). There is no 400 need to include a fictitious candidate for the IP6 :: address when 401 doing so. 403 It is worth noting that the use of IP6 :: has been selected over IP4 404 0.0.0.0, even though [RFC3264] already gives the latter semantics 405 appropriate for such use. The reason for this choice is the historic 406 use of 0.0.0.0 as a means of putting a stream on hold [RFC2543] and 407 the ambiguity that this may cause with legacy libraries and 408 applications. 410 It is also worth mentioning that use of IP6 :: here does not 411 constitute any kind of indication as to the actual use of IPv6 412 candidates in a session and it can very well appear in a negotiation 413 that only involves IPv4 candidates. 415 6. Receiving the Initial Offer 417 When an agent receives an initial offer, it will first check if it 418 indicates support for trickle ICE as explained in Section 4. If this 419 is not the case, the agent MUST process the offer according to the 420 [RFC5245] procedures or standard [RFC3264] processing in case no ICE 421 support is detected at all. 423 It is worth pointing out that in case support for trickle ICE is 424 confirmed, an agent will automatically assume support for vanilla ICE 425 as well even if the support verification procedure in [RFC5245] 426 indicates otherwise. Specifically, such verification would indicate 427 lack of support when the offer contains no candidates. The IP6 :: 428 address present in the c= line in that case would not "appear in a 429 candidate attribute". Obviously, a fallback to [RFC3264] is not 430 required when this happens. 432 If, the offer does indicate support for trickle ICE, the agent will 433 determine its role, start gathering and prioritizing candidates and, 434 while doing so it will also respond by sending its own answer, so 435 that both agents can start forming check lists and begin connectivity 436 checks. 438 6.1. Sending the Initial Answer 440 An agent can respond to an initial offer at any point while gathering 441 candidates. The answer can again contain any set of candidates 442 including none or all of them. Unless it is protecting host 443 addresses for privacy reasons, the agent would typically construct 444 this initial answer including only them, thus allowing the remote 445 party to also start forming checklists and performing connectivity 446 checks. 448 The answer MUST indicate support for trickle ICE as described by 449 Section 4. 451 6.2. Forming check lists and beginning connectivity checks 453 After exchanging offer and answer, and as soon as they have obtained 454 local and remote candidates, agents will begin forming candidate 455 pairs, computing their priorities and creating check lists according 456 to the vanilla ICE procedures described in [RFC5245]. Obviously in 457 order for candidate pairing to be possible, it would be necessary 458 that both the offer and the answer contained candidates. If this was 459 not the case agents will still create the check lists (so that their 460 Active/Frozen state could be monitored and updated) but they will 461 only populate them once they actually have the candidates. 463 Initially, all check lists will have their Active/Frozen state set to 464 Frozen. 466 Trickle ICE agents will then also attempt to unfreeze the check list 467 for the first media stream (i.e. the first media stream that was 468 reported to the ICE implementation from the using application). If 469 this checklist is still empty however, agents will continue examining 470 media streams in the order they were reported and will unfreeze the 471 first non-empty checklist. 473 Respecting the order in which lists have been reported to an ICE 474 implementation, or in other words, the order in which they appear in 475 SDP, is helpful so that checks for the same media stream is more 476 likely to be performed simultaneously by both agents. 478 6.3. Encoding the SDP 480 The process for encoding the SDP at the answerer is identical to the 481 process followed by the offerer for both full and lite 482 implementations, as described in Section 5.1. 484 7. Receiving the Initial Answer 486 When receiving an answer, agents will follow vanilla ICE procedures 487 to determine their role and they would then form check lists (as 488 described in Section 6.2) and begin connectivity checks . 490 8. Performing Connectivity Checks 492 For the most part, trickle ICE agents perform connectivity checks 493 following vanilla ICE procedures. Of course, the asynchronous nature 494 of candidate harvesting in trickle ICE would impose a number of 495 changes described here. 497 8.1. Check List and Timer State Updates 499 The vanilla ICE specification requires that agents update check lists 500 and timer states upon completing a connectivity check transaction. 501 During such an update vanilla ICE agents would set the state of a 502 check list to Failed if the following two conditions are satisfied: 504 o all of the pairs in the check list are either in the Failed or 505 Succeeded state; 507 o if at least one of the components of the media stream has no pairs 508 in its valid list. 510 With trickle ICE, the above situation would often occur when 511 candidate harvesting and trickling are still in progress and it is 512 perfectly possible that future checks will succeed. For this reason 513 trickle ICE agents add the following conditions to the above list: 515 o all candidate harvesters have completed and the agent is not 516 expecting to learn any new candidates; 518 o the remote agent has sent an end-of-candidates indication for that 519 check list as described in Section 9.3. 521 Vanilla ICE requires that agents then update all other check lists, 522 placing one pair in each of them into the Waiting state, effectively 523 unfreezing the check list. Given that with trickle ICE, other check 524 lists may still be empty at that point, a trickle ICE agent SHOULD 525 also maintain an explicit Active/Frozen state for every check list, 526 rather than deducing it from the state of the pairs it contains. 527 This state should be set to Active when unfreezing the first pair in 528 a list or when that couldn't happen because a list was empty. 530 9. Discovering and Sending Additional Local Candidates 532 After an offer or an answer have been sent, agents will most likely 533 continue discovering new local candidates as STUN, TURN and other 534 non-host candidate harvesting mechanisms begin to yield results. 535 Whenever an agent discovers such a new candidate it will compute its 536 priority, type, foundation and component id according to normal 537 vanilla ICE procedures. 539 The new candidate is then checked for redundancy against the existing 540 list of local candidates. If its transport address and base match 541 those of an existing candidate, it will be considered redundant and 542 will be ignored. This would often happen for server reflexive 543 candidates that match the host addresses they were obtained from 544 (e.g. when the latter are public IPv4 addresses). Contrary to 545 vanilla ICE, trickle ICE agents will consider the new candidate 546 redundant regardless of its priority. [TODO: is this OK? if not we 547 need to check if the existing candidate was already used in conn 548 checks, cancel them, and then restart them with the new candidate ... 549 and in this specific case there's probably no point to do that]. 551 Then, if no remote candidates are currently known for this same 552 stream, the new candidate will simply be added to the list of local 553 candidates. 555 Otherwise, if the agent has already learned of one or more remote 556 candidates for this stream and component, it will begin pairing the 557 new local candidates with them and adding the pairs to the existing 558 check lists according to their priority. 560 9.1. Pairing newly learned candidates and updating check lists 561 Forming candidate pairs will work the way it is described by the 562 vanilla ICE specification. Actually adding the new pair to a check 563 list however, will happen according to the rules described below. 565 If the new pair's local candidate is server reflexive, the server 566 reflexive candidate MUST be replaced by its base before adding the 567 pair to the list. Once this is done, the agent examines the check 568 list looking for another pair that would be redundant with the new 569 one. If such a pair exists and its state is: 571 Succeeded: the newly formed pair is ignored. 573 Frozen or Waiting: the agent chooses the pair with the higher 574 priority local candidate, places it in the state that the old pair 575 was in (i.e. Frozen or Waiting) and removes the other one as 576 redundant. 578 Failed: the agent chooses the pair with the higher priority local 579 candidate, places it in the Waiting state and removes the other 580 one as redundant. 582 In-Progress: The agent cancels the in-progress transaction (where 583 cancellation happens as explained in Section 7.2.1.4 of 584 [RFC5245]), then it chooses the pair with the higher priority 585 local candidate, places it in the Waiting state and removes the 586 other one as redundant. 588 For all other pairs, including those with a server reflexive local 589 candidate that were not found to be redundant: 591 o if all check lists are empty and in the Frozen state, or in other 592 words, if this is the first pair the agent is adding to any check 593 list, both the pair and its containing check list will be placed 594 in an Active state. 596 o if this check list is Frozen then the new pair will also be 597 assigned a Frozen state. 599 o else if the check list is Active and it is either empty or 600 contains only candidates in the Succeeded and Failed states, then 601 the new pair's state is set to Waiting. 603 o else if the check list is non-empty and Active, then the new pair 604 state will be set to 606 Frozen: if there is at least one pair in the list whose 607 foundation matches the one in the new pair and whose state 608 is neither Succeeded nor Failed (eventually the new pair 609 will get unfrozen after the the on-going check for the 610 existing pair concludes); 612 Waiting: if the list contains no pairs with the same foundation 613 as the new one, or, in case such pairs exist but they are 614 all in either the Succeeded or Failed states. 616 9.2. Encoding the SDP for Additional Candidates 618 To facilitate interoperability an ICE agent will encode additional 619 candidates using the vanilla ICE SDP syntax. For example: 621 a=candidate:2 1 UDP 1658497328 198.51.100.33 5000 typ host 623 Given that such lines do not provide a relationship between the 624 candidate and the m line that it relates to, signalling protocols 625 using trickle ICE MUST establish that relation themselves using an 626 MID [RFC3388]. Such MIDs use "media stream identification", as 627 defined in [RFC3388], to identify a corresponding m-line. When 628 creating candidate lines usages of trickle ICE MUST use the MID if 629 possible, or the m-line index if not. Obviously, agents MUST NOT 630 send individual candidates prior to generating the corresponding SDP 631 session description. 633 The exact means of transporting additional candidates to a remote 634 agent is left to the protocols using trickle ICE. It is important to 635 note, however, that these candidate exchanges are not part of the 636 offer/answer model. 638 9.3. Announcing End of Candidates 640 Once all candidate harvesters for a specific media stream complete, 641 or expire, the agents will generate an "end-of-candidates" indication 642 for that stream and send it to the remote agent via the signalling 643 channel. Such indications are sent in the form of a media-level 644 attribute that has the following form: end-of-candidates. 646 a=end-of-candidates 648 The end-of-candidates indications can be sent as part of an offer, 649 which would typically be the case with half trickle initial offers, 650 they can accompany the last candidate an agent can send for a stream, 651 and they can also be sent alone (e.g. after STUN Binding requests or 652 TURN Allocate requests to a server timeout and the agent has no other 653 active harvesters). 655 Controlled trickle ICE agents SHOULD always send end-of-candidates 656 indications once harvesting for a media stream has completed unless 657 ICE processing terminates before they've had a chance to do so. 658 Sending the indication is necessary in order to avoid ambiguities and 659 speed up ICE conclusion. This is necessary in order to avoid 660 ambiguities and speed up ICE conclusion. Controlling agents on the 661 other hand MAY sometimes conclude ICE processing prior to sending 662 end-of-candidates notifications for all streams. This would 663 typically be the case with aggressive nomination. Yet it is 664 RECOMMENDED that controlling agents do send such indications whenever 665 possible for the sake of consistency and keeping middle boxes and 666 controlled agents up-to-date on the state of ICE processing. 668 When sending end-of-candidates during trickling, rather than as a 669 part of an offer or an answer, it is the responsibility of the using 670 protocol to define means that can be used to relate the indication to 671 one or more specific m-lines. 673 Receiving an end-of-candidates notification allows an agent to update 674 check list states and, in case valid pairs do not exist for every 675 component in every media stream, determine that ICE processing has 676 failed. It also allows agents to speed ICE conclusion in cases where 677 a candidate pair has been validates but it involves the use of lower- 678 preference transports such as TURN. In such situations some 679 implementations may choose to wait in case higher-priority candidates 680 are received and end-of-candidates provides an indication that this 681 is not going to happen. 683 An agent MAY also choose to generate an end-of-candidates event 684 before candidate harvesting has actually completed, if the agent 685 determines that harvesting has continued for more than an acceptable 686 period of time. However, an agent MUST NOT send any more candidates 687 after it has send an end-of-candidates notification. 689 When performing half trickle agents SHOULD send end-of-candidates 690 together with their initial offer unless they are planning on 691 potentially sending additional candidates in case the remote party 692 turns out to actually support trickle ICE. 694 When end-of-candidates is sent as part of an offer or an answer it 695 can appear as a session-level attribute, which would be equivalent to 696 having it appear in all m-lines. 698 Once an agent sends the end-of-candidates event, it will update the 699 state of the corresponding check list as explained in section 700 Section 8.1. Past that point agents MUST NOT send any new 701 candidates. Once an agent has received an end-of-candidates 702 indication, it MUST also ignore any newly received candidates for 703 that media stream. Adding new candidates to the negotiation is hence 704 only possible through an ICE restart. 706 It is important to note that This specification does not override 707 vanilla ICE semantics for concluding ICE processing. This means that 708 even if end-of-candidates indications are sent agents will still have 709 to go through pair nomination. Also, if pairs have been nominated 710 for components and media streams, ICE processing will still conclude 711 even if end-of-candidate indications have not been received for all 712 streams. 714 9.4. Receiving an End Of Candidates Notification 716 When an agent receives an end-of-candidates notification for a 717 specific check list, they will update its state as per Section 8.1. 718 In case the list is still in the Active state after the update, the 719 agent will persist the the fact that an end-of-candidates 720 notification has been received for and take it into account in future 721 list updates. 723 [TODO would we like to say anything about nomination? in general 724 this would be up to implementers but is there a need for some basic 725 guidelines?] 727 10. Receiving Additional Remote Candidates 729 At any point of ICE processing, a trickle ICE agent may receive new 730 candidates from the remote agent. When this happens and no local 731 candidates are currently known for this same stream, the new remote 732 candidates are simply added to the list of remote candidates. 734 Otherwise, the new candidates are used for forming candidate pairs 735 with the pool of local candidates and they are added to the local 736 check lists as described in Section 9.1. 738 Once the remote agent has completed candidate harvesting, it will 739 send an end-of-candidates event. Upon receiving such an event, the 740 local agent MUST update check list states as per Section 8.1. This 741 may lead to some check lists being marked as Failed. 743 11. Concluding ICE Processing 744 This specification does not directly modify the procedures ending ICE 745 processing described in Section 8 of [RFC5245], and trickle ICE 746 implementations will follow the same rules. 748 12. Subsequent Offer/Answer Exchanges 750 Either agent MAY generate a subsequent offer at any time allowed by 751 [RFC3264]. When this happens agents will use [RFC5245] semantics to 752 determine whether or not the new offer requires an ICE restart. If 753 this is the case then agents would perform trickle ICE as they would 754 in an initial offer/answer exchange. 756 The only differences between an ICE restart and a brand new media 757 session are that: 759 o during the restart, media can continue to be sent to the 760 previously validated pair. 762 o both agents are already aware whether or not their peer supports 763 trickle ICE, and there is no longer need for performing half 764 trickle or confirming support with other mechanisms. 766 13. Interaction with ICE Lite 768 Behaviour of Trickle ICE capable ICE lite agents does not require any 769 particular rules other than those already defined in this 770 specification and [RFC5245]. This section is hence added with an 771 informational purpose only. 773 A Trickle ICE capable ICE Lite agent would generate offers or answers 774 as per [RFC5245]. Both will indicate support for trickle ICE 775 (Section 5.1) and given that they will contain a complete set of 776 candidates (the agent's host candidates) these offers and answers 777 would also be accompanied with an end-of-candidates notification. 779 When performing full trickle, a full ICE implementation could send an 780 offer or an answer with no candidates and an IP6 :: connection line 781 address. After receiving an answer that identifies the remote agent 782 as an ICE lite implementation, the offerer may very well choose to 783 not send any additional candidates. The same is also true in the 784 case when the ICE lite agent is making the offer and the full ICE one 785 is answering. In these cases the connectivity checks would be enough 786 for the ICE lite implementation to discover all potentially useful 787 candidates as peer reflexive. The following example illustrates one 788 such ICE session: 790 ICE Lite Bob 791 Agent 792 | Offer (a=ice-lite a=ice-options:trickle) | 793 |---------------------------------------------->| 794 | |no cand 795 | Answer (a=ice-options:trickle) |trickling 796 |<----------------------------------------------| 797 | Connectivity Checks | 798 |<--------------------------------------------->| 799 peer rflx| | 800 cand disco| | 801 | | 802 |<=============== MEDIA FLOWS =================>| 804 Figure 1: Example 806 In addition to reducing signaling traffic this approach also removes 807 the need to discover STUN bindings, or to make TURN or UPnP 808 allocations which may considerably lighten ICE processing. 810 14. Example Flow 812 A typical successful trickle ICE exchange with an Offer/Answer 813 protocol would look this way: 815 Alice Bob 816 | Offer | 817 |---------------------------------------------->| 818 | Additional Candidates | 819 |---------------------------------------------->| 820 | | 821 | Answer | 822 |<----------------------------------------------| 823 | Additional Candidates | 824 |<----------------------------------------------| 825 | | 826 | Additional Candidates and Connectivity Checks | 827 |<--------------------------------------------->| 828 | | 829 |<=============== MEDIA FLOWS =================>| 831 Figure 2: Example 833 15. Security Considerations 835 [TODO] 837 16. Acknowledgements 839 The authors would like to thank Bernard Adoba, Christer Holmberg, 840 Enrico Marocco, Flemming Andreasen, Jonathan Lennox and Martin 841 Thomson for their reviews and suggestions on improving this document. 843 17. References 845 17.1. Normative References 847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 848 Requirement Levels", BCP 14, RFC 2119, March 1997. 850 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 851 with Session Description Protocol (SDP)", RFC 3264, June 852 2002. 854 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 855 Description Protocol", RFC 4566, July 2006. 857 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 858 (ICE): A Protocol for Network Address Translator (NAT) 859 Traversal for Offer/Answer Protocols", RFC 5245, April 860 2010. 862 17.2. Informative References 864 [I-D.ivov-mmusic-trickle-ice-sip] 865 Ivov, E., Marocco, E., and C. Holmberg, "A Session 866 Initiation Protocol (SIP) usage for Trickle ICE", draft- 867 ivov-mmusic-trickle-ice-sip-00 (work in progress), January 868 2013. 870 [I-D.keranen-mmusic-ice-address-selection] 871 Keraenen, A. and J. Arkko, "Update on Candidate Address 872 Selection for Interactive Connectivity Establishment 873 (ICE)", draft-keranen-mmusic-ice-address-selection-01 874 (work in progress), July 2012. 876 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 877 E. Lear, "Address Allocation for Private Internets", BCP 878 5, RFC 1918, February 1996. 880 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 881 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 882 March 1999. 884 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 885 A., Peterson, J., Sparks, R., Handley, M., and E. 886 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 887 June 2002. 889 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 890 Schulzrinne, "Grouping of Media Lines in the Session 891 Description Protocol (SDP)", RFC 3388, December 2002. 893 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 894 "Indicating User Agent Capabilities in the Session 895 Initiation Protocol (SIP)", RFC 3840, August 2004. 897 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 898 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 899 RFC 4787, January 2007. 901 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 902 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 903 October 2008. 905 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 906 Relays around NAT (TURN): Relay Extensions to Session 907 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 909 [XEP-0030] 910 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 911 Andre, "XEP-0030: Service Discovery", XEP XEP-0030, June 912 2008. 914 [XEP-0115] 915 Hildebrand, J., Saint-Andre, P., Troncon, R., and J. 916 Konieczny, "XEP-0115: Entity Capabilities", XEP XEP-0115, 917 February 2008. 919 [XEP-0176] 920 Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., 921 Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP 922 Transport Method", XEP XEP-0176, June 2009. 924 [XEP-0278] 925 Camargo, T., "XEP-0278: Jingle Relay Nodes", XEP XEP-0278, 926 June 2011. 928 Appendix A. Open issues 930 At the time of writing of this document the authors have no clear 931 view on how and if the following list of issues should be addressed. 933 A.1. MID/Stream Indices in SDP 935 This specification does not currently define syntax for candidate-to- 936 stream bindings although it says that they should be implemented with 937 MID or a stream index. Yet, it is reasonable to assume that most 938 usages would need to do this within the SDP and it may make sense to 939 agree on the format. Here's one possible way to do this: 941 a=mid:1 942 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 943 a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx 944 a=mid:2 945 a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx 946 a=end-of-candidates 948 A.2. Starting checks 950 Normally Vanilla ICE implementations would first activate a check 951 list, validate at least one pair in every component and only then 952 unfreeze all other checklists. With trickle ICE this would be 953 suboptimal since, candidates can arrive randomly and we would be 954 wasting time waiting for a checklist to fill (almost as if we were 955 doing vanilla ICE). We need to decide if unfreezing everything 956 solely based on foundation is good enough. 958 Appendix B. Changes From Earlier Versions 960 Note to the RFC-Editor: please remove this section prior to 961 publication as an RFC. 963 B.1. Changes From draft-ivov-00 965 o Specified that end-of-candidates is a media level attribute which 966 can of course appear as session level, which is equivalent to 967 having it appear in all m-lines. Also made end-of-candidates 968 optional for cases such as aggressive nomination for controlled 969 agents. 971 o Added an example for ICE lite and trickle ICE to illustrate how, 972 when talking to an ICE lite agent doesn't need to send or even 973 discover any candidates. 975 o Added an example for ICE lite and trickle ICE to illustrate how, 976 when talking to an ICE lite agent doesn't need to send or even 977 discover any candidates. 979 o Added wording that explicitly states ICE lite agents have to be 980 prepared to receive no candidates over signalling and that they 981 should not freak out if this happens. (Closed the corresponding 982 open issue). 984 o It is now mandatory to use MID when trickling candidates and using 985 m-line indexes is no longer allowed. 987 o Replaced use of 0.0.0.0 to IP6 :: in order to avoid potential 988 issues with RFC2543 SDP libraries that interpret 0.0.0.0 as an on- 989 hold operation. Also changed the port number here from 1 to 9 990 since it already has a more appropriate meaning. (Port change 991 suggested by Jonathan Lennox). 993 o Closed the Open Issue about use about what to do with cands 994 received after end-of-cands. Solution: ignore, do an ice restart 995 if you want to add something. 997 o Added more terminology, including trickling, trickled candidates, 998 half trickle, full trickle, 1000 o Added a reference to the SIP usage for trickle ICE as requested at 1001 the Boston interim. 1003 B.2. Changes From draft-rescorla-01 1005 o Brought back explicit use of Offer/Answer. There are no more 1006 attempts to try to do this in an O/A independent way. Also 1007 removed the use of ICE Descriptions. 1009 o Added SDP specification for trickled candidates, the trickle 1010 option and 0.0.0.0 addresses in m-lines, and end-of-candidates. 1012 o Support and Discovery. Changed that section to be less abstract. 1013 As discussed in IETF85, the draft now says implementations and 1014 usages need to either determine support in advance and directly 1015 use trickle, or do half trickle. Removed suggestion about use of 1016 discovery in SIP or about letting implementing protocols do what 1017 they want. 1019 o Defined Half Trickle. Added a section that says how it works. 1020 Mentioned that it only needs to happen in the first o/a (not 1021 necessary in updates), and added Jonathan's comment about how it 1022 could, in some cases, offer more than half the improvement if you 1023 can pre-gather part or all of your candidates before the user 1024 actually presses the call button. 1026 o Added a short section about subsequent offer/answer exchanges. 1028 o Added a short section about interactions with ICE Lite 1029 implementations. 1031 o Added two new entries to the open issues section. 1033 B.3. Changes From draft-rescorla-00 1035 o Relaxed requirements about verifying support following a 1036 discussion on MMUSIC. 1038 o Introduced ICE descriptions in order to remove ambiguous use of 1039 3264 language and inappropriate references to offers and answers. 1041 o Removed inappropriate assumption of adoption by RTCWEB pointed out 1042 by Martin Thomson. 1044 Authors' Addresses 1046 Emil Ivov 1047 Jitsi 1048 Strasbourg 67000 1049 France 1051 Phone: +33 6 72 81 15 55 1052 Email: emcho@jitsi.org 1054 Eric Rescorla 1055 RTFM, Inc. 1056 2064 Edgewood Drive 1057 Palo Alto, CA 94303 1058 USA 1060 Phone: +1 650 678 2350 1061 Email: ekr@rtfm.com 1062 Justin Uberti 1063 Google 1064 747 6th St S 1065 Kirkland, WA 98033 1066 USA 1068 Phone: +1 857 288 8888 1069 Email: justin@uberti.name