idnits 2.17.1 draft-ivov-mmusic-trickle-ice-00.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 (January 28, 2013) is 4099 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 702, but not defined == Unused Reference: 'RFC3261' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'RFC3840' is defined on line 751, but no explicit reference was found in the text == Unused Reference: 'XEP-0115' is defined on line 772, 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) -- 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 (~~), 7 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 Jitsi 4 Intended status: Standards Track E. Rescorla 5 Expires: August 1, 2013 RTFM, Inc. 6 J. Uberti 7 Google 8 January 28, 2013 10 Trickle ICE: Incremental Provisioning of Candidates for the Interactive 11 Connectivity Establishment (ICE) Protocol 12 draft-ivov-mmusic-trickle-ice-00 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 August 1, 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 . . . . . . . . . . . . . . 4 63 4. Determining Support for Trickle ICE . . . . . . . . . . . . . 6 64 4.1. Unilateral Use of Trickle ICE (Half Trickle) . . . . . . . 6 65 5. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 7 66 5.1. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 8 67 6. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 8 68 6.1. Sending the Initial Answer . . . . . . . . . . . . . . . . 9 69 6.2. Forming check lists and beginning connectivity checks . . 9 70 6.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 10 71 7. Receiving the Initial Answer . . . . . . . . . . . . . . . . . 10 72 8. Performing Connectivity Checks . . . . . . . . . . . . . . . . 10 73 8.1. Check List and Timer State Updates . . . . . . . . . . . . 10 74 9. Learning and Sending Additional Local Candidates . . . . . . . 11 75 9.1. Encoding the SDP for Additional Candidates . . . . . . . . 12 76 9.2. Announcing End of Candidates . . . . . . . . . . . . . . . 13 77 9.3. Receiving an End Of Candidates Notification . . . . . . . 14 78 10. Receiving Additional Remote Candidates . . . . . . . . . . . . 14 79 11. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 14 80 12. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 14 81 13. Interaction with ICE Lite . . . . . . . . . . . . . . . . . . 15 82 14. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 15. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 85 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 17.1. Normative References . . . . . . . . . . . . . . . . . . . 16 87 17.2. Informative References . . . . . . . . . . . . . . . . . . 16 88 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . . 17 89 A.1. MID/Stream Indices in SDP . . . . . . . . . . . . . . . . 18 90 A.2. ICE Lite and Candidate Signalling . . . . . . . . . . . . 18 91 A.3. Handling new candidates after check completion . . . . . . 18 92 Appendix B. Changes From Earlier Versions . . . . . . . . . . . . 18 93 B.1. Changes From draft-rescorla-01 . . . . . . . . . . . . . . 18 94 B.2. Changes From draft-rescorla-00 . . . . . . . . . . . . . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 The Interactive Connectivity Establishment (ICE) protocol [RFC5245] 100 describes mechanisms for gathering, candidates, prioritizing them, 101 choosing default ones, exchanging them with the remote party, pairing 102 them and ordering them into check lists. Once all of the above have 103 been completed, and only then, the participating agents can begin a 104 phase of connectivity checks and eventually select the pair of 105 candidates that will be used in the following session. 107 While the above sequence has the advantage of being relatively 108 straightforward to implement and debug once deployed, it may also 109 prove to be rather lengthy. Gathering candidates or candidate 110 harvesting would often involve things like querying STUN [RFC5389] 111 servers, discovering UPnP devices, and allocating relayed candidates 112 at TURN [RFC5766] servers. All of these can be delayed for a 113 noticeable amount of time and while they can be run in parallel, they 114 still need to respect the pacing requirements from [RFC5245], which 115 is likely to delay them even further. Some or all of the above would 116 also have to be completed by the remote agent. Both agents would 117 next perform connectivity checks and only then would they be ready to 118 begin streaming media. 120 All of the above could lead to relatively lengthy session 121 establishment times and degraded user experience. 123 The purpose of this document is to define an alternative mode of 124 operation for ICE implementations, also known as "trickle ICE", where 125 candidates can be exchanged incrementally. This would allow ICE 126 agents to exchange host candidates as soon as a session has been 127 initiated. Connectivity checks for a media stream would also start 128 as soon as the first candidates for that stream have become 129 available. 131 Trickle ICE allows reducing session establishment times in cases 132 where connectivity is confirmed for the first exchanged candidates 133 (e.g. where the host candidates for one of the agents are directly 134 reachable from the second agent). Even when this is not the case, 135 running candidate harvesting for both agents and connectivity checks 136 all in parallel allows to considerably reduce ICE processing times. 138 It is worth pointing out that before being introduced to the IETF, 139 trickle ICE had already been included in specifications such as XMPP 140 Jingle [XEP-0176] and it has been in use in various implementations 141 and deployments. 143 In addition to the basics of trickle ICE, this document also 144 describes how support for trickle ICE needs to be discovered, how 145 regular ICE processing needs to be modified when building and 146 updating check lists, and how trickle ICE implementations should 147 interoperate with agents that only implement [RFC5245] processing. 149 This specification does not define usage of trickle ICE with any 150 specific signalling protocol, contrary to [RFC5245] which contains a 151 usage for ICE wht SIP. Such usages would have to be specified in 152 separate documents. 154 Trickle ICE does however reuse and build upon the SDP syntax defined 155 by vanilla ICE. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 This specification makes use of all terminology defined by the 164 protocol for Interactive Connectivity Establishment in [RFC5245]. 166 Vanilla ICE: The Interactive Connectivity Establishment protocol as 167 defined in [RFC5245]. 168 Candidate Harvester: A module used by an ICE agent to obtain local 169 candidates. Candidate harvesters use different mechanisms for 170 discovering local candidates. Some of them would typically make 171 use of protocols such as STUN or TURN. Others may also employ 172 techniques that are not referenced within [RFC5245]. UPnP based 173 port allocation and XMPP Jingle Relay Nodes [XEP-0278] are among 174 the possible examples. 176 3. Incompatibility with Standard ICE 178 The ICE protocol was designed to be fairly flexible so that it would 179 work in and adapt to as many network environments as possible. It is 180 hence important to point out at least some of the reasons why, 181 despite its flexibility, the specification in [RFC5245] would not 182 support trickle ICE. 184 [RFC5245] describes the conditions required to update check lists and 185 timer states while an ICE agent is in the Running state. These 186 conditions are verified upon transaction completion and one of them 187 stipulates that: 189 If there is not a pair in the valid list for each component of the 190 media stream, the state of the check list is set to Failed. 192 This could be a problem and cause ICE processing to fail prematurely 193 in a number of scenarios. Consider the following case: 195 o Alice and Bob are both located in different networks with Network 196 Address Translation (NAT). Alice and Bob themselves have 197 different address but both networks use the same [RFC1918] block. 198 o Alice sends Bob the candidate 10.0.0.10 which also happens to 199 correspond to an existing host on Bob's network. 200 o Bob creates a check list consisting solely of 10.0.0.10 and starts 201 checks. 202 o These checks reach the host at 10.0.0.10 in Bob's network, which 203 responds with an ICMP "port unreachable" error and per [RFC5245] 204 Bob marks the transaction as Failed. 205 At this point the check list only contains Failed candidates and the 206 valid list is empty. This causes the media stream and potentially 207 all ICE processing to Fail. 209 A similar race condition would occur if the initial offer from Alice 210 only contains candidates that can be determined as unreachable (per 211 [I-D.keranen-mmusic-ice-address-selection]) from any of the 212 candidates that Bob has gathered. This would be the case if Bob's 213 candidates only contain IPv4 addresses and the first candidate that 214 he receives from Alice is an IPv6 one. 216 Another potential problem could arise when a non-trickle ICE 217 implementation sends an offer to a trickle one. Consider the 218 following case: 219 o Alice's client has a non-trickle ICE implementation 220 o Bob's client has support for trickle ICE. 221 o Alice and Bob are behind NATs with address-dependent filtering 222 [RFC4787]. 223 o Bob has two STUN servers but one of them is currently unreachable 225 After Bob's agent receives Alice's offer it would immediately start 226 connectivity checks. It would also start gathering candidates, which 227 would take long because of the unreachable STUN server. By the time 228 Bob's answer is ready and sent to Alice, Bob's connectivity checks 229 may well have failed: until Alice gets Bob's answer, she won't be 230 able to start connectivity checks and punch holes in her NAT. The 231 NAT would hence be filtering Bob's checks as originating from an 232 unknown endpoint. 234 4. Determining Support for Trickle ICE 236 According to [RFC5245] every time an agent supporting trickle ICE 237 generates an offer or an answer, it MUST include the "trickle" token 238 in the ice-options attribute. Syntax for this token is defined in 239 Section 5.1. 241 Additionally, in order to avoid interoperability problems such as 242 those described in Section 3, it is important that trickle ICE 243 negotiation is only attempted in cases where the remote party 244 actually supports this specification. Agents that receive offers or 245 answers can verify support by examining them for the "trickle" ice- 246 options token. However, agents that are about to send a first offer, 247 have no immediate way of doing this. This means that usages of 248 trickle for specific protocols would need to either: 250 o Provide a way for agents to verify support of trickle ICE prior to 251 initiating a session. XMPP's Service discovery [XEP-0030] is an 252 example for one such mechanism; 253 o Make support for trickle ICE mandatory so that support could be 254 assumed the agents. 256 Alternately, for cases where a protocol provides neither of the 257 above, agents may either rely on provisioning/configuration, or use 258 the half trickle procedure described in Section 4.1. 260 Note that out-of-band discovery semantics and half trickle are only 261 necessary prior to session initiation, or in other words, when 262 sending the initial offer. Once a session is established and trickle 263 ICE support is confirmed for both parties, either agent can use full 264 trickle for subsequent offers. 266 4.1. Unilateral Use of Trickle ICE (Half Trickle) 268 The idea of using half trickle is about having the caller send a 269 regular, vanilla ICE offer, with a complete set of candidates. This 270 offer still indicates support for trickle ice, so the answerer is 271 able to respond with an incomplete set of candidates and continue 272 trickling the rest. Half trickle offers will typically contain an 273 end-of-candidates indication. 275 The mechanism can be used in cases where there is no way for an agent 276 to verify in advance whether a remote party supports trickle ice. 277 Because it contains a full set of candidates, its first offer can 278 thus be handled by a regular vanilla ICE agent, while still allowing 279 a trickle one to use the optimisation defined in this specification. 280 This prevents negotiation from failing in the former case while still 281 giving roughly half the trickle ICE benefits in the latter (hence the 282 name of the mechanism). 284 Use of half trickle is only necessary during an initial offer/answer 285 exchange. Once both parties have received a session description from 286 their peer, they can each reliably determine trickle ICE support and 287 use it for all subsequent offer/answer exchanges. 289 It is worth pointing out that using half trickle may actually bring 290 more than just half the improvement in terms of user experience. 291 This can happen in cases where an agent starts gathering candidates 292 upon user interface cues that a call is pending, such as activity on 293 a keypad or the phone going off hook. This would mean a part or all 294 candidate harvesting could have completed before the agent actually 295 needs to send the offer. Given that the answerer will be able to 296 trickle candidates, both agents will be able to start connectivity 297 checks and complete ICE processing earlier than with vanilla ICE and 298 potentially even as early as with full trickle. 300 However, such anticipation is not not always possible. For example, 301 a multipurpose user agent or a WebRTC web page where communication is 302 a non-central feature (e.g. calling a support line in case of a 303 problem with the main features) would not necessarily have a way of 304 distinguishing between call intentions and other user activity. 305 Still, even in these cases, using half trickle would be an 306 improvement over vanilla ICE as it would optimize performance for 307 answerers. 309 5. Sending the Initial Offer 311 An agent starts gathering candidates as soon as it has an indication 312 that communication is imminent (e.g. a user interface cue or an 313 explicit request to initiate a session). Contrary to vanilla ICE, 314 implementations of trickle ICE do not need to gather candidates in a 315 blocking manner. Therefore, unless half trickle is being used, 316 agents SHOULD generate and transmit their initial offer as early as 317 possible, in order to allow the remote party to start gathering and 318 trickling candidates. 320 Trickle ICE agents MAY include any set of candidates in an offer. 321 This includes the possibility of generating one with no candidates, 322 or one that contains all the candidates that the agent is planning on 323 using in the following session. 325 For optimal performance, it is RECOMMENDED that an initial offer 326 contains host candidates only. This would allow both agents to start 327 gathering server reflexive, relayed and other non-host candidates 328 simultaneously, and it would also enable them to begin connectivity 329 checks. 331 If the privacy implications of revealing host addresses are a 332 concern, agents MAY generate an offer that contains no candidates and 333 then only trickle candidates that do not reveal host addresses (e.g. 334 relayed candidates). 336 Prior to actually sending an initial offer, agents MAY verify if the 337 remote party supports trickle ICE, where such mechanisms actually 338 exist. If absence of such support is confirmed agents MUST fall back 339 to using vanilla ICE or abandon the entire session. 341 All trickle ICE offers and answers MUST indicate support of this 342 specification, as explained in Section 5.1. 344 Calculating priorities and foundations, as well as determining 345 redundancy of candidates work the same way they do with vanilla ICE. 347 5.1. Encoding the SDP 349 The process of encoding the SDP [RFC4566] is mostly the same as the 350 one used by vanilla ICE. Still, trickle ICE does require a few 351 differences described here. 353 Agents MUST indicate support for Trickle ICE by including the 354 "trickle" token for the "a=ice-options" attribute: 356 a=ice-options:trickle 358 As mentioned earlier in this section, Offers and Answers can contain 359 any set of candidates, which means that a trickle ICE session 360 description MAY contain no candidates at all. In such cases the 361 agent would still need to place an address in the "c=" line(s). If 362 the use of a host address there is undesirable (e.g. for privacy 363 reasons), the agent MAY set the connection address to 0.0.0.0. In 364 this case it MUST also set the port number to 1. There is no need to 365 include a fictitious 0.0.0.0 candidate when doing so. 367 6. Receiving the Initial Offer 369 When an agent receives an initial offer, it will first check if it 370 indicates support for trickle ICE as explained in Section 4. If this 371 is not the case, the agent MUST process the offer according to the 372 [RFC5245] procedures or standard [RFC3264] processing in case no ICE 373 support is detected at all. 375 It is worth pointing out that in case support for trickle ICE is 376 confirmed, an agent will automatically assume support for vanilla ICE 377 as well even if the support verification procedure in [RFC5245] 378 indicates otherwise. Specifically, such verification would indicate 379 lack of support when the offer contains no candidates. The 0.0.0.0 380 address present in the c= line in that case would not "appear in a 381 candidate attribute". Obviously, a fallback to [RFC3264] is not 382 required when this happens. 384 If, the offer does indicate support for trickle ICE, the agent will 385 determine its role, start gathering and prioritizing candidates and, 386 while doing so it will also respond by sending its own answer, so 387 that both agents can start forming check lists and begin connectivity 388 checks. 390 6.1. Sending the Initial Answer 392 An agent can respond to an initial offer at any point while gathering 393 candidates. The answer can again contain any set of candidates 394 including none or all of them. Unless it is protecting host 395 addresses for privacy reasons, the agent would typically construct 396 this initial answer including only them, thus allowing the remote 397 party to also start forming checklists and performing connectivity 398 checks. 400 The answer MUST indicate support for trickle ICE as described by 401 Section 4. 403 6.2. Forming check lists and beginning connectivity checks 405 After exchanging offer and answer, and as soon as they have obtained 406 local and remote candidates, agents will begin forming candidate 407 pairs, computing their priorities and creating check lists according 408 to the vanilla ICE procedures described in [RFC5245]. Obviously in 409 order for candidate pairing to be possible, it would be necessary 410 that both the offer and the answer contained candidates. If this was 411 not the case agents will still create the check lists (so that their 412 Active/Frozen state could be monitored and updated) but they will 413 only populate them once they actually have the candidates. 415 Initially, all check lists will have their Active/Frozen state set to 416 Frozen. 418 Trickle ICE agents will then also attempt to unfreeze the check list 419 for the first media stream (i.e. the first media stream that was 420 reported to the ICE implementation from the using application). If 421 this checklist is still empty however, agents will continue examining 422 media streams in the order they were reported and will unfreeze the 423 first non-empty checklist. 425 Respecting the order in which lists have been reported to an ICE 426 implementation, or in other words, the order in which they appear in 427 SDP, is helpful so that checks for the same media stream is more 428 likely to be performed simultaneously by both agents. 430 6.3. Encoding the SDP 432 The process for encoding the SDP at the answerer is identical to the 433 process followed by the offerer for both full and lite 434 implementations, as described in Section 5.1. 436 7. Receiving the Initial Answer 438 When receiving an answer, agents will follow vanilla ICE procedures 439 to determine their role and they would then form check lists (as 440 described in Section 6.2) and begin connectivity checks . 442 8. Performing Connectivity Checks 444 For the most part, trickle ICE agents perform connectivity checks 445 following vanilla ICE procedures. Of course, the asynchronous nature 446 of candidate harvesting in trickle ICE would impose a number of 447 changes described here. 449 8.1. Check List and Timer State Updates 451 The vanilla ICE specification requires that agents update check lists 452 and timer states upon completing a connectivity check transaction. 453 During such an update vanilla ICE agents would set the state of a 454 check list to Failed if the following two conditions are satisfied: 456 o all of the pairs in the check list are either in the Failed or 457 Succeeded state; 458 o if at least one of the components of the media stream has no pairs 459 in its valid list. 461 With trickle ICE, the above situation would often occur when 462 candidate harvesting and trickling are still in progress and it is 463 perfectly possible that future checks will succeed. For this reason 464 trickle ICE agents add the following conditions to the above list: 466 o all candidate harvesters have completed and the agent is not 467 expecting to learn any new candidates; 469 o the remote agent has sent an end-of-candidates indication for that 470 check list as described in Section 9.2. 472 Vanilla ICE requires that agents then update all other check lists, 473 placing one pair in each of them into the Waiting state, effectively 474 unfreezing the check list. Given that with trickle ICE, other check 475 lists may still be empty at that point, a trickle ICE agent SHOULD 476 also maintain an explicit Active/Frozen state for every check list, 477 rather than deducing it from the state of the pairs it contains. 478 This state should be set to Active when unfreezing the first pair in 479 a list or when that couldn't happen because a list was empty. 481 9. Learning and Sending Additional Local Candidates 483 After an offer or an answer have been sent, agents will most likely 484 continue discovering new local candidates as STUN, TURN and other 485 non-host candidate harvesting mechanisms begin to yield results. 486 Whenever such a new candidate is learned agents will compute its 487 priority, type, foundation and component id according to normal 488 vanilla ICE procedures. 490 The new candidate is then checked for redundancy against the existing 491 list of local candidates. If its transport address and base match 492 those of an existing candidate, it will be considered redundant and 493 will be ignored. This would often happen for server reflexive 494 candidates that match the host addresses they were obtained from 495 (e.g. when the latter are public IPv4 addresses). Contrary to 496 vanilla ICE, trickle ICE agents will consider the new candidate 497 redundant regardless of its priority. [TODO: is this OK? if not we 498 need to check if the existing candidate was already used in conn 499 checks, cancel them, and then restart them with the new candidate ... 500 and in this specific case there's probably no point to do that]. 502 Then, if no remote candidates are currently known for this same 503 stream, the new candidate will simply be added to the list of local 504 candidates. 506 Otherwise, if the agent has already learned of one or more remote 507 candidates for this stream and component, it will begin pairing the 508 new local candidates with them and adding the pairs to the existing 509 check lists according to their priority. Forming candidate pairs 510 will work the way it is described by the vanilla ICE specification. 511 Actually adding the new pair to a check list however, will happen 512 according to the rules described below. 514 If the new pair's local candidate is server reflexive, the server 515 reflexive candidate MUST be replaced by its base before adding the 516 pair to the list. Once this is done, the agent examines the check 517 list looking for another pair that would be redundant with the new 518 one. If such a pair exists and its state is: 520 Succeeded: the newly formed pair is ignored. 521 Frozen or Waiting: the agent chooses the pair with the higher 522 priority local candidate, places it in the state that the old pair 523 was in (i.e. Frozen or Waiting) and removes the other one as 524 redundant. 525 Failed: the agent chooses the pair with the higher priority local 526 candidate, places it in the Waiting state and removes the other 527 one as redundant. 528 In-Progress: The agent cancels the in-progress transaction (where 529 cancellation happens as explained in Section 7.2.1.4 of 530 [RFC5245]), then it chooses the pair with the higher priority 531 local candidate, places it in the Waiting state and removes the 532 other one as redundant. 534 For all other pairs, including those with a server reflexive local 535 candidate that were not found to be redundant: 536 o if this check list is Frozen then the new pair will also be 537 assigned a Frozen state. 538 o else if the check list is Active and it is either empty or 539 contains only candidates in the Succeeded and Failed states, then 540 the new pair's state is set to Waiting. 541 o else if the check list is non-empty and Active, then the new pair 542 state will be set to 543 Frozen: if there is at least one pair in the list whose 544 foundation matches the one in the new pair and whose state is 545 neither Succeeded nor Failed (eventually the new pair will get 546 unfrozen after the the on-going check for the existing pair 547 concludes); 548 Waiting: if the list contains no pairs with the same foundation 549 as the new one, or, in case such pairs exist but they are all 550 in either the Succeeded or Failed states. 552 9.1. Encoding the SDP for Additional Candidates 554 To facilitate interoperability an ICE agent will encode additional 555 candidates using the vanilla ICE SDP syntax. For example: 557 a=candidate:2 1 UDP 1658497328 198.51.100.33 5000 typ host 559 Given that such lines do not provide a relationship between the 560 candidate and the m line that it relates to, signalling protocols 561 using trickle ICE MUST establish that relation themselves. This can 562 be done in one of two ways: using the m-line index, or an MID 563 [RFC3388]. The m-line index is a zero-based index, referring to the 564 Nth m-line in the SDP. The MID uses "media stream identification", 565 as defined in [RFC3388], to identify the m-line. When creating 566 candidate lines usages of trickle ICE SHOULD use the MID if possible, 567 or the m-line index if not. Agents MUST NOT send individual 568 candidates any prior to generating the corresponding SDP session 569 description. 571 The exact means of transporting additional candidates to a remote 572 agent is left to the protocols using trickle ICE. It is important to 573 note, however, that these candidate exchanges are not part of the 574 offer/answer model. [TODO: or should we pick one of the two? Is 575 there any reason not to mandate MID?] 577 9.2. Announcing End of Candidates 579 Once all candidate harvesters for a specific media stream complete, 580 or expire, the agent MUST generate an "end-of-candidates" indication 581 for that stream and send it to the remote agent via the signalling 582 channel. The SDP representation for end-of-candidates following 583 form: 585 a=end-of-candidates 587 The end-of-candidates notifications can be sent as part of an offer, 588 which would typically be the case with half trickle initial offers, 589 they can accompany the last candidate an agent can send for a stream, 590 and they can also be sent alone (e.g. after STUN Binding requests or 591 TURN Allocate requests to a server timeout and the agent has no other 592 active harvesters). 594 Receiving an end-of-candidates notification allows an agent to update 595 check list states and, in case valid pairs do not exist for every 596 component in every media stream, determine that ICE processing has 597 failed. 599 An agent MAY also choose to generate an end-of-candidates event 600 before candidate harvesting has actually completed, if the agent 601 determines that harvesting has continued for more than an acceptable 602 period of time. However, an agent MUST NOT send any more candidates 603 after it has send an end-of-candidates notification. 605 Half trickle agents SHOULD send end-of-candidates together with their 606 initial offer unless they are planning on potentially sending 607 additional candidates in case the remote party turns out to actually 608 support trickle ICE. (TODO: can this be useful?) 610 Once the agent sends the end-of-candidates event, it will update the 611 state of the corresponding check list as explained in section 612 Section 8.1 614 9.3. Receiving an End Of Candidates Notification 616 When an agent receives an end-of-candidates notification for a 617 specific check list, they will update its state as per Section 8.1. 618 In case the list is still in the Active state after the update, the 619 agent will persist the the fact that an end-of-candidates 620 notification has been received for and take it into account in future 621 list updates. 623 [TODO would we like to say anything about nomination? in general this 624 would be up to implementers but is there a need for some basic 625 guidelines?] 627 10. Receiving Additional Remote Candidates 629 At any point of ICE processing, a trickle ICE agent may receive new 630 candidates from the remote agent. When this happens and no local 631 candidates are currently known for this same stream, the new remote 632 candidates are simply added to the list of remote candidates. 634 Otherwise, the new candidates are used for forming candidate pairs 635 with the pool of local candidates. 637 Once the remote agent has completed candidate harvesting, it will 638 send an end-of-candidates event. Upon receiving such an event, the 639 local agent MUST update check list states as per Section 8.1. This 640 may lead to some check lists being marked as Failed. 642 11. Concluding ICE Processing 644 This specification does not directly modify the procedures ending ICE 645 processing described in Section 8 of [RFC5245], and trickle ICE 646 implementations will follow the same rules. 648 12. Subsequent Offer/Answer Exchanges 650 Either agent MAY generate a subsequent offer at any time allowed by 651 [RFC3264]. When this happens agents will use [RFC5245] semantics to 652 determine whether or not the new offer requires an ICE restart. If 653 this is the case then agents would perform trickle ICE as they would 654 in an initial offer/answer exchange. 656 The only differences between an ICE restart and a brand new media 657 session are that: 659 o during the restart, media can continue to be sent to the 660 previously validated pair. 661 o both agents are already aware whether or not their peer supports 662 trickle ICE, and there is no longer need for performing half 663 trickle or confirming support with other mechanisms. 665 13. Interaction with ICE Lite 667 Behaviour of Trickle ICE capable ICE lite agents does not require any 668 particular rules other than those already defined in this 669 specification and [RFC5245]. This section is hence added with an 670 informational purpose only. 672 A Trickle ICE capable ICE Lite agent would generate offers or answers 673 as per [RFC5245]. Both will indicate support for trickle ICE 674 (Section 5.1) and given that they will contain a complete set of 675 candidates (the agent's host candidates) these offers and answers 676 would also be accompanied with an end-of-candidates notification. 678 14. Example Flow 680 A typical successful trickle ICE exchange with an Offer/Answer 681 protocol would look this way: 683 Alice Bob 684 | Offer | 685 |---------------------------------------------->| 686 | Additional Candidates | 687 |---------------------------------------------->| 688 | | 689 | Answer | 690 |<----------------------------------------------| 691 | Additional Candidates | 692 |<----------------------------------------------| 693 | | 694 | Additional Candidates and Connectivity Checks | 695 |<--------------------------------------------->| 696 | | 697 |<=============== MEDIA FLOWS =================>| 698 Figure 1: Example 700 15. Security Considerations 702 [TODO] 704 16. Acknowledgements 706 The authors would like to thank Bernard Adoba, Christer Holmberg, 707 Enrico Marocco, Jonathan Lennox and Martin Thomson for their reviews 708 and suggestions on improving this document. 710 17. References 712 17.1. Normative References 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, March 1997. 717 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 718 with Session Description Protocol (SDP)", RFC 3264, 719 June 2002. 721 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 722 Description Protocol", RFC 4566, July 2006. 724 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 725 (ICE): A Protocol for Network Address Translator (NAT) 726 Traversal for Offer/Answer Protocols", RFC 5245, 727 April 2010. 729 17.2. Informative References 731 [I-D.keranen-mmusic-ice-address-selection] 732 Keraenen, A. and J. Arkko, "Update on Candidate Address 733 Selection for Interactive Connectivity Establishment 734 (ICE)", draft-keranen-mmusic-ice-address-selection-01 735 (work in progress), July 2012. 737 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 738 E. Lear, "Address Allocation for Private Internets", 739 BCP 5, RFC 1918, February 1996. 741 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 742 A., Peterson, J., Sparks, R., Handley, M., and E. 744 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 745 June 2002. 747 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 748 Schulzrinne, "Grouping of Media Lines in the Session 749 Description Protocol (SDP)", RFC 3388, December 2002. 751 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 752 "Indicating User Agent Capabilities in the Session 753 Initiation Protocol (SIP)", RFC 3840, August 2004. 755 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 756 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 757 RFC 4787, January 2007. 759 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 760 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 761 October 2008. 763 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 764 Relays around NAT (TURN): Relay Extensions to Session 765 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 767 [XEP-0030] 768 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 769 Andre, "XEP-0030: Service Discovery", XEP XEP-0030, 770 June 2008. 772 [XEP-0115] 773 Hildebrand, J., Saint-Andre, P., Troncon, R., and J. 774 Konieczny, "XEP-0115: Entity Capabilities", XEP XEP-0115, 775 February 2008. 777 [XEP-0176] 778 Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., 779 Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP 780 Transport Method", XEP XEP-0176, June 2009. 782 [XEP-0278] 783 Camargo, T., "XEP-0278: Jingle Relay Nodes", XEP XEP-0278, 784 June 2011. 786 Appendix A. Open issues 788 At the time of writing of this document the authors have no clear 789 view on how and if the following list of issues should be addressed. 791 A.1. MID/Stream Indices in SDP 793 This specification does not currently define syntax for candidate-to- 794 stream bindings although it says that they should be implemented with 795 MID or a stream index. Yet, it is reasonable to assume that most 796 usages would need to do this within the SDP and it may make sense to 797 agree on the format. Here's one possible way to do this: 799 a=mid:1 800 a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host 801 a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx 802 a=mid:2 803 a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx 804 a=end-of-candidates 806 A.2. ICE Lite and Candidate Signalling 808 ICE Lite implementations of Trickle ICE do not necessarily need to 809 receive candidates from their peers: it would be enough for them to 810 start getting checks and discover all candidates as peer reflexive. 811 This would allow to reduce signalling traffic but could introduce 812 other issues. 814 A.3. Handling new candidates after check completion 816 Basically, do any new candidates discovered after ICE completes (e.g. 817 from a new interface that comes up) need an ICE restart, or not? 819 Appendix B. Changes From Earlier Versions 821 Note to the RFC-Editor: please remove this section prior to 822 publication as an RFC. 824 B.1. Changes From draft-rescorla-01 826 o Brought back explicit use of Offer/Answer. There are no more 827 attempts to try to do this in an O/A independent way. Also 828 removed the use of ICE Descriptions. 829 o Added SDP specification for trickled candidates, the trickle 830 option and 0.0.0.0 addresses in m-lines, and end-of-candidates. 831 o Support and Discovery. Changed that section to be less abstract. 832 As discussed in IETF85, the draft now says implementations and 833 usages need to either determine support in advance and directly 834 use trickle, or do half trickle. Removed suggestion about use of 835 discovery in SIP or about letting implementing protocols do what 836 they want. 837 o Defined Half Trickle. Added a section that says how it works. 838 Mentioned that it only needs to happen in the first o/a (not 839 necessary in updates), and added Jonathan's comment about how it 840 could, in some cases, offer more than half the improvement if you 841 can pre-gather part or all of your candidates before the user 842 actually presses the call button. 843 o Added a short section about subsequent offer/answer exchanges. 844 o Added a short section about interactions with ICE Lite 845 implementations. 846 o Added two new entries to the open issues section. 848 B.2. Changes From draft-rescorla-00 850 o Relaxed requirements about verifying support following a 851 discussion on MMUSIC. 852 o Introduced ICE descriptions in order to remove ambiguous use of 853 3264 language and inappropriate references to offers and answers. 854 o Removed inappropriate assumption of adoption by RTCWEB pointed out 855 by Martin Thomson. 857 Authors' Addresses 859 Emil Ivov 860 Jitsi 861 Strasbourg 67000 862 France 864 Phone: +33 6 72 81 15 55 865 Email: emcho@jitsi.org 867 Eric Rescorla 868 RTFM, Inc. 869 2064 Edgewood Drive 870 Palo Alto, CA 94303 871 USA 873 Phone: +1 650 678 2350 874 Email: ekr@rtfm.com 875 Justin Uberti 876 Google 877 747 6th St S 878 Kirkland, WA 98033 879 USA 881 Phone: +1 857 288 8888 882 Email: justin@uberti.name