idnits 2.17.1 draft-ietf-mmusic-ice-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3810. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 25 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 7 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 469: '...ia, described in Section 7.13, MUST be...' RFC 2119 keyword, line 500: '... SHOULD have the same number of comp...' RFC 2119 keyword, line 503: '...a streams, it is RECOMMENDED that ther...' RFC 2119 keyword, line 505: '...omponent ID of 1 MUST be RTP, and the ...' RFC 2119 keyword, line 506: '...omponent ID of 2 MUST be RTCP. If an ...' (123 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 19, 2005) is 6762 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) == Unused Reference: '6' is defined on line 3674, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 3706, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 3739, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 3769, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3489 (ref. '1') (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 3548 (ref. '4') (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 2327 (ref. '7') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2234 (ref. '11') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3266 (ref. '12') (Obsoleted by RFC 4566) == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-connectivity-precon-00 -- Possible downref: Normative reference to a draft: ref. '16' -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '17') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2733 (ref. '19') (Obsoleted by RFC 5109) == Outdated reference: A later version (-04) exists of draft-ietf-avt-rtp-no-op-00 == Outdated reference: A later version (-05) exists of draft-iab-dos-03 == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-11 Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: April 22, 2006 October 19, 2005 6 Interactive Connectivity Establishment (ICE): A Methodology for Network 7 Address Translator (NAT) Traversal for Offer/Answer Protocols 8 draft-ietf-mmusic-ice-06 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 22, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes a protocol for Network Address Translator 42 (NAT) traversal for multimedia session signaling protocols based on 43 the offer/answer model, such as the Session Initiation Protocol 44 (SIP). This protocol is called Interactive Connectivity 45 Establishment (ICE). ICE makes use of existing protocols, such as 46 Simple Traversal of UDP Through NAT (STUN) and Traversal Using Relay 47 NAT (TURN). ICE makes use of STUN in peer-to-peer cooperative 48 fashion, allowing participants to discover, create and verify mutual 49 connectivity. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . 8 56 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . 10 57 5. Receipt of the Offer and Generation of the Answer . . . . . 11 58 6. Processing the Answer . . . . . . . . . . . . . . . . . . . 11 59 7. Common Procedures . . . . . . . . . . . . . . . . . . . . . 11 60 7.1 Gathering Candidates . . . . . . . . . . . . . . . . . . . 12 61 7.2 Prioritizing the Candidates and Choosing an Active One . . 15 62 7.3 Encoding Candidates into SDP . . . . . . . . . . . . . . . 17 63 7.4 Forming Candidate Pairs . . . . . . . . . . . . . . . . . 19 64 7.5 Ordering the Candidate Pairs . . . . . . . . . . . . . . . 22 65 7.6 Performing the Connectivity Checks . . . . . . . . . . . . 23 66 7.7 Sending a Binding Request for Connectivity Checks . . . . 27 67 7.8 Receiving a Binding Request for Connectivity Checks . . . 29 68 7.9 Promoting a Candidate to Active . . . . . . . . . . . . . 31 69 7.10 Learning New Candidates from Connectivity Checks . . . . 31 70 7.10.1 On Receipt of a Binding Request . . . . . . . . . . 32 71 7.10.2 On Receipt of a Binding Response . . . . . . . . . . 35 72 7.11 Subsequent Offer/Answer Exchanges . . . . . . . . . . . 37 73 7.11.1 Sending of a Subsequent Offer . . . . . . . . . . . 37 74 7.11.2 Receiving the Offer and Sending an Answer . . . . . 39 75 7.11.3 Receiving the Answer . . . . . . . . . . . . . . . . 41 76 7.12 Binding Keepalives . . . . . . . . . . . . . . . . . . . 41 77 7.13 Sending Media . . . . . . . . . . . . . . . . . . . . . 42 78 8. Guidelines for Usage with SIP . . . . . . . . . . . . . . . 43 79 9. Interactions with Forking . . . . . . . . . . . . . . . . . 44 80 10. Interactions with Preconditions . . . . . . . . . . . . . . 45 81 11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 45 82 12. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 68 83 13. Security Considerations . . . . . . . . . . . . . . . . . . 69 84 13.1 Attacks on Connectivity Checks . . . . . . . . . . . . . 69 85 13.2 Attacks on Address Gathering . . . . . . . . . . . . . . 72 86 13.3 Attacks on the Offer/Answer Exchanges . . . . . . . . . 73 87 13.4 Insider Attacks . . . . . . . . . . . . . . . . . . . . 73 88 13.4.1 The Voice Hammer Attack . . . . . . . . . . . . . . 73 89 13.4.2 STUN Amplification Attack . . . . . . . . . . . . . 74 90 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 74 91 14.1 candidate Attribute . . . . . . . . . . . . . . . . . . 74 92 14.2 remote-candidate Attribute . . . . . . . . . . . . . . . 75 93 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 75 94 15.1 Problem Definition . . . . . . . . . . . . . . . . . . . 75 95 15.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . 76 96 15.3 Brittleness Introduced by ICE . . . . . . . . . . . . . 76 97 15.4 Requirements for a Long Term Solution . . . . . . . . . 77 98 15.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . 78 99 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 100 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 101 17.1 Normative References . . . . . . . . . . . . . . . . . . 78 102 17.2 Informative References . . . . . . . . . . . . . . . . . 79 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . 81 104 Intellectual Property and Copyright Statements . . . . . . . 82 106 1. Introduction 108 A multimedia session signaling protocol is a protocol that exchanges 109 control messages between a pair of agents for the purposes of 110 establishing the flow of media traffic between them. This media flow 111 is distinct from the flow of control messages, and may take a 112 different path through the network. Examples of such protocols are 113 the Session Initiation Protocol (SIP) [3], the Real Time Streaming 114 Protocol (RTSP) [17] and the International Telecommunications Union 115 (ITU) H.323. 117 These protocols, by nature of their design, are difficult to operate 118 through Network Address Translators (NAT). Because their purpose is 119 to establish a flow of media packets, they tend to carry IP addresses 120 within their messages, which is known to be problematic through NAT 121 [18]. The protocols also seek to create a media flow directly 122 between participants, so that there is no application layer 123 intermediary between them. This is done to reduce media latency, 124 decrease packet loss, and reduce the operational costs of deploying 125 the application. However, this is difficult to accomplish through 126 NAT. A full treatment of the reasons for this is beyond the scope of 127 this specification. 129 Numerous solutions have been proposed for allowing these protocols to 130 operate through NAT. These include Application Layer Gateways 131 (ALGs), the Middlebox Control Protocol [20], Simple Traversal of UDP 132 through NAT (STUN) [1], Traversal Using Relay NAT [16], and Realm 133 Specific IP [21] [22] along with session description extensions 134 needed to make them work, such as the Session Description Protocol 135 (SDP) [7] attribute for the Real Time Control Protocol (RTCP) [2]. 136 Unfortunately, these techniques all have pros and cons which make 137 each one optimal in some network topologies, but a poor choice in 138 others. The result is that administrators and implementors are 139 making assumptions about the topologies of the networks in which 140 their solutions will be deployed. This introduces complexity and 141 brittleness into the system. What is needed is a single solution 142 which is flexible enough to work well in all situations. 144 This specification provides that solution for media streams 145 established by signaling protocols based on the offer-answer model, 146 RFC 3264 [5]. It is called Interactive Connectivity Establishment, 147 or ICE. ICE makes use of STUN and TURN, but uses them in a specific 148 methodology which avoids many of the pitfalls of using any one alone. 150 2. Terminology 152 Several new terms are introduced in this specification: 154 Agent: As defined in RFC 3264, an agent is the protocol 155 implementation involved in the offer/answer exchange. There are 156 two agents involved in an offer/answer exchange. 158 Peer: From the perspective of one of the agents in a session, its 159 peer is the other agent. Specifically, from the perspective of 160 the offerer, the peer is the answerer. From the perspective of 161 the answerer, the peer is the offerer. 163 Transport Address: The combination of an IP address and port. 165 Local Transport Address: A local transport address is a transport 166 address that has been allocated from the operating system on the 167 host. This includes transport addresses obtained through Virtual 168 Private Networks (VPNs) and transport addresses obtained through 169 Realm Specific IP (RSIP) [21] (which lives at the operating system 170 level). Transport addresses are typically obtained by binding to 171 an interface. 173 m/c line: The media and connection lines in the SDP, which together 174 hold the transport address used for the receipt of media. 176 Derived Transport Address: A derived transport address is a transport 177 address which is derived from a local transport address. The 178 derived transport address is related to the associated local 179 transport address in that packets sent to the derived transport 180 address are received on the socket bound to its associated local 181 transport address. Derived addresses are obtained using protocols 182 like STUN and TURN, and more generally, any UNSAF protocol [23]. 184 Associated Local Transport Address: When a peer sends a packet to a 185 transport address, the associated local transport address is the 186 local transport address at which those packets will actually 187 arrive. For a local transport address, its associated local 188 transport address is the same as the local transport address 189 itself. For STUN derived and TURN derived transport addresses, 190 however, they are not the same. The associated local transport 191 address is the one from which the STUN or TURN transport was 192 derived. 194 Peer Derived Transport Address: A peer derived transport address is a 195 derived transport address learned from a STUN server running 196 within a peer in a media session. 198 TURN Derived Transport Address: A derived transport address obtained 199 from a TURN server. 201 STUN Derived Transport Address: A derived transport address obtained 202 from a STUN server whose address has been provisioned or 203 discovered by the UA. This, by definition, excludes Peer Derived 204 Transport Addresses. 206 Candidate: A sequence of transport addresses that form an atomic set 207 for usage with a particular media session. Here, atomic means 208 that all of transport addresses in the candidate need to work 209 before the candidate will be used for actual media transport. In 210 the case of RTP, there can be one or more transport addresses per 211 candidate. In the most common case, there are two - one for RTP, 212 and another for RTCP. If the agent doesn't use RTCP, there would 213 be just one. If Generic Forward Error Correction (FEC) [19] is in 214 use, there may be more than two. The transport addresses that 215 compose a candidate are all of the same type - local, STUN 216 derived, TURN derived or peer derived. 218 Local Candidate: A candidate whose transport addresses are local 219 transport addresses. 221 STUN Candidate: A candidate whose transport addresses are STUN 222 derived transport addresses. 224 TURN Candidate: A candidate whose transport addresses are TURN 225 derived transport addresses. 227 Peer Derived Candidate: A candidate whose transport addresses are 228 peer derived transport addresses. 230 Generating Candidate: The candidate from which a peer derived 231 candidate is derived. 233 Active Candidate: The candidate that is in use for exchange of media. 234 This is the one that an agent places in the m/c line of an offer 235 or answer. 237 Candidate ID: An identifier for a candidate. 239 Component: When a media stream, and as a consequence, its candidate, 240 require several IP addresses and ports to work atomically, each of 241 the constituent IP addresses and ports represents a component of 242 that media stream. For example, RTP-based media streams typically 243 have two components - one for RTP, and one for RTCP. 245 Component ID: An integer, starting with one within each candidate and 246 incrementing by one for each component, which identifies the 247 component. 249 Transport Address ID (tid): An identifier for a transport address, 250 formed by concatenating the candidate ID with the component ID, 251 separated by a "colon". 253 Candidate Pair: The combination of a candidate from one agent along 254 with a candidate from its peer. 256 Native Candidate: From the perspective of each agent, the candidate 257 in a candidate pair which represents a set of addresses obtained 258 by that agent. 260 Remote Candidate: From the perspective of each agent, the candidate 261 in a candidate pair which represents the set of addresses obtained 262 by that agents peer. 264 Transport Address Pair: The combination of the transport address for 265 one component of a candidate with the transport address of the 266 same component for the matching candidate in a candidate pair. 268 Transport Address Pair ID: An identifier for a transport address 269 pair. Formed by concatenating the native transport address ID 270 with the remote transport address ID, separated by a "colon". 272 Matching Transport Address Pair: When a STUN Binding Request is 273 received on a local transport address, the matching transport 274 address pair is the transport address pair whose connectivity is 275 being checked by that Binding Request. 277 Candidate Pair Priority Ordering: An ordering of candidate pairs 278 based on a combination of the qvalues of each candidate and the 279 candidate IDs of each candidate. 281 Candidate Pair Check Ordering: An ordering of candidate pairs that is 282 similar to the candidate pair priority ordering, except that the 283 active candidate appears at the top of the list, regardless of its 284 priority. 286 Transport Address Pair Check Ordering: An ordering of transport 287 address pairs that determines the sequence of connectivity checks 288 performed for the pairs. 290 Transport Address Pair Count: The number of transport address pairs 291 in a candidate pair. This is equal to the minimum of the number 292 of transport addresses in the native candidate and the number of 293 transport addresses in the remote candidate. 295 3. Overview of ICE 297 ICE makes the fundamental assumption that clients exist in a network 298 of segmented connectivity. This segmentation is the result of a 299 number of addressing realms in which a client can simultaneously be 300 connected. We use "realms" here in the broadest sense. A realm is 301 defined purely by connectivity. Two clients are in the same realm 302 if, when they exchange the addresses each has in that realm, they are 303 able to send packets to each other. This includes IPv6 and IPv4 304 realms, which actually use different address spaces, in addition to 305 private networks connected to the public Internet through NAT. 307 The key assumption in ICE is that a client cannot know, apriori, 308 which address realms it shares with any peer it may wish to 309 communicate with. Therefore, in order to communicate, it has to try 310 connecting to addresses in all of the realms. 312 Agent A TURN,STUN Servers Agent B 313 |(1) Gather Addresses | | 314 |-------------------->| | 315 |(2) Offer | | 316 |------------------------------------------>| 317 | |(3) Gather Addresses | 318 | |<--------------------| 319 |(4) Answer | | 320 |<------------------------------------------| 321 |(5) STUN Check | | 322 |<------------------------------------------| 323 |(6) STUN Check | | 324 |------------------------------------------>| 325 |(7) Offer | | 326 |------------------------------------------>| 327 |(8) Answer | | 328 |<------------------------------------------| 329 |(9) Media | | 330 |<------------------------------------------| 331 |(10) Media | | 332 |------------------------------------------>| 334 Figure 1 336 The basic flow of operation for ICE is shown in Figure 1. Before the 337 offerer establishes a session, it obtains local transport addresses 338 from its operating system on as many interfaces as it has access to. 339 These interfaces can include IPv4 and IPv6 interfaces, in addition to 340 Virtual Private Network (VPN) interfaces or ones associated with 341 RSIP. It then obtains transport addresses for the media from each 342 interface. Though the ICE framework can support any type of 343 transport protocol, this specification only defines mechanisms for 344 UDP. In addition, the agent obtains derived transport addresses from 345 each local transport address using protocols such as STUN and TURN. 346 These are paced at a fixed rate in order to limit network load and 347 avoid NAT overload. The local and derived transport addresses are 348 formed into candidates, each of which represents a possible set of 349 transport addresses that might be viable for a media stream. 351 Each candidate is listed in a set of a=candidate attributes in the 352 offer. Each candidate is given a priority. Priority is a matter of 353 local policy, but typically, lowest priority would be given to 354 transport addresses learned from a TURN server (i.e., TURN derived 355 transport addresses). Each candidate is also assigned a distinct ID, 356 called a candidate ID. 358 The agent will choose one of its candidates as its active candidate 359 for inclusion in the connection and media lines in the offer. Media 360 can be sent to this candidate immediately following its validation. 361 Media is not sent without validation in order to avoid denial-of- 362 service attacks. In particular, without ICE, an offerer can send an 363 offer to another agent, and list the IP address and port of a target 364 in the offer. If the agent is an automata that answers a call 365 automatically, it will do so and then proceed to send media to the 366 target. This provides substantial packet amplifications. ICE fixes 367 this by using STUN-based validation of addresses. 369 The offer is then sent to the answerer. This specification does not 370 address the issue of how the signaling messages themselves traverse 371 NAT. It is assumed that signaling protocol specific mechanisms are 372 used for that purpose. The answerer follows a similar process as the 373 offerer followed; it obtains addresses from local interfaces, obtains 374 derived transport addresses from those, and then groups them into 375 candidates for inclusion in a=candidate attributes in the answer. It 376 picks one candidate as its active candidate and places it into the 377 m/c line in the answer. 379 Once the offer/answer exchange has completed, both agents pair up the 380 candidates, and then determine an ordered set of transport address 381 pairs. This ordering is based primarily on the priority of the 382 candidates, with the exception of the active candidate, whose 383 addresses are at the top of the list. Both agents start at the top 384 of this list, beginning a connectivity check for that transport 385 address pair. At a fixed interval, checks for the next transport 386 address on the list begin. This results in a pacing of the 387 connectivity checks. These connectivity checks are performed through 388 peer-to-peer STUN requests, sent from one agent to the other. In 389 addition to pacing the checks out at regular intervals, the offerer 390 will generate a connectivity check for a transport address pair when 391 it receives one from its peer. As soon as the active candidate has 392 been verified by the STUN checks, media can begin to flow. Once a 393 higher priority candidate has been verified by the offerer, it ceases 394 additional connectivity checks, and sends an updated offer which 395 promotes this higher priority candidate to the m/c-line. That 396 candidate is also listed in a=candidate attributes, resulting in 397 periodic STUN keepalives through the duration of the media session. 399 If an agent receives a STUN connectivity check with a new source IP 400 address and port, or a response to such a check with a new IP address 401 and port indicated in the MAPPED-ADDRESS attribute, this new address 402 might be a viable candidate for the receipt of media. This happens 403 when there is a symmetric NAT between the agents. In such a case, 404 the agents algorithmically construct a new candidate. Like other 405 candidates, connectivity checks begin for it, and if they succeed, 406 its transport addresses can be used for receipt of media by promoting 407 it to the m/c-line. 409 The gathering of addresses and connectivity checks take time. As a 410 consequence, in order to have no impact on the call setup time or 411 post-pickup delay for SIP, these offer/answer exchanges and checks 412 happen while the call is ringing. 414 4. Sending the Initial Offer 416 When an agent wishes to begin a session by sending an initial offer, 417 it starts by gathering transport addresses, as described in 418 Section 7.1. This will produce a set of candidates, including local 419 ones, STUN-derived ones, and TURN-derived ones. 421 This process of gathering candidates can actually happen at any time 422 before sending the initial offer. A agent can pre-gather transport 423 addresses, using a user interface cue (such as picking up the phone, 424 or entry into an address book) as a hint that communications is 425 imminent. Doing so eliminates any additional perceivable call setup 426 delays due to address gathering. 428 When it comes time to offer communications, the agent determines a 429 priority for each candidate and identifies the active candidate that 430 will be used for receipt of media, as described in Section 7.2. 432 The next step is to construct the offer message. For each media 433 stream, it places its candidates into a=candidate attributes in the 434 offer and puts its active candidate into the m/c line. The process 435 for doing this is described in Section 7.3. The offer is then sent. 437 5. Receipt of the Offer and Generation of the Answer 439 Upon receipt of the offer message, the agent checks if the offer 440 contains any a=candidate attributes. If it does, the offerer 441 supports ICE. In that case, it starts gathering candidates, as 442 described in Section 7.1, and prioritizes them as described in 443 Section 7.2. This processing is done immediately on receipt of the 444 offer, to prepare for the case where the user should accept the call, 445 or early media needs to be generated. By gathering candidates (and 446 performing connectivity checks) while the user is being alerted to 447 the request for communications, session establishment delays due to 448 that gathering can be eliminated. 450 The agent then constructs its answer, encoding its candidates into 451 a=candidate attributes and including the active one in the m/c-line, 452 as described in Section 7.3. The agent then forms candidate pairs as 453 described in Section 7.4. These are ordered as described in 454 Section 7.5. The agent then begins connectivity checks, as described 455 in Section 7.6. It follows the logic in Section 7.10 on receipt of 456 Binding Requests and responses to learn new candidates from the 457 checks themselves. 459 Transmission of media is performed according to the procedures in 460 Section 7.13. 462 6. Processing the Answer 464 There are two possible cases for processing of the answer. If the 465 answerer did not support ICE, the answer will not contain any 466 a=candidate attributes. As a result, the offerer knows that it 467 cannot perform its connectivity checks. In this case, it proceeds 468 with normal media processing as if ICE was not in use. The 469 procedures for sending media, described in Section 7.13, MUST be 470 followed however. 472 If the answer contains candidates, it implies that the answerer 473 supports ICE. The agent then forms candidate pairs as described in 474 Section 7.4. These are ordered as described in Section 7.5. The 475 agent then begins connectivity checks, as described in Section 7.6. 476 It follows the logic in Section 7.10 on receipt of Binding Requests 477 and responses to learn new candidates from the checks themselves. 479 Transmission of media is performed according to the procedures in 480 Section 7.13. 482 7. Common Procedures 484 This section discusses procedures that are common between offerer and 485 answerer. 487 7.1 Gathering Candidates 489 An agent gathers candidates when it believes that communications is 490 imminent. For offerers, this occurs before sending an offer 491 (Section 4). For answerers, it occurs before sending an answer 492 (Section 5). 494 Each candidate has one or more components, each of which is 495 associated with a sequence number, starting at 1 for the first 496 component of each candidate, and incrementing by 1 for each 497 additional component within that candidate. These components 498 represent a set of transport addresses for which connectivity must be 499 validated. For a particular media stream, all of the candidates 500 SHOULD have the same number of components. The number of components 501 that are needed are a function of the type of media stream. 503 For traditional RTP-based media streams, it is RECOMMENDED that there 504 be two components per candidate - one for RTP and one for RTCP. The 505 component with the component ID of 1 MUST be RTP, and the one with 506 component ID of 2 MUST be RTCP. If an agent doesn't implement RTCP, 507 it SHOULD have a single component for the RTP stream (which will have 508 a component ID of 1 by definition). Each component of a candidate 509 has a single transport address. 511 The first step is to gather local candidates. Local candidates are 512 obtained by binding to ephemeral ports on an interface (physical or 513 virtual, including VPN interfaces) on the host. The process for 514 gathering local candidates depends on the transport protocol. 515 Procedures are specified here for UDP. Extensions to ICE that define 516 procedures for other transport protocols MUST specify how local 517 transport addresses are gathered. 519 For each UDP media stream the agent wishes to use, the agent SHOULD 520 obtain a set of candidates (one for each interface) by binding to N 521 ephemeral UDP ports on each interface, where N is the number of 522 components needed for the candidate. For RTP, N is typically two. 523 If a host has K local interfaces, this will result in K candidates 524 for each UDP stream , requiring K*N local transport addresses. 526 Once the agent has obtained local candidates, it obtains candidates 527 with derived transport addresses. The process for gathering derived 528 candidates depends on the transport protocol. Procedures are 529 specified here for UDP. Extensions to ICE that define procedures for 530 other transport protocols MUST specify how derived transport 531 addresses are gathered. 533 Agents which serve end users directly, such as softphones, 534 hardphones, terminal adapters and so on, MUST implement STUN and 535 SHOULD use it to obtain STUN candidates. These devices SHOULD 536 implement and SHOULD use TURN to obtain TURN candidates. They MAY 537 implement and MAY use other protocols that provide derived transport 538 addresses, such as TEREDO [31]. Usage of STUN and TURN is at SHOULD 539 strength to allow for provider variation. If it is not to be used, 540 it is RECOMMENDED that it be implemented and just disabled through 541 configuration, so that it can re-enabled through configuration if 542 conditions change in the future. 544 Agents which represent network servers under the control of a service 545 provider, such as gateways to the telephone network, media servers, 546 or conferencing servers that are targeted at deployment only in 547 networks with public IP addresses MAY use STUN, TURN or other similar 548 protocols to obtain candidates. 550 Why would these types of endpoints even bother to implement ICE? 551 The answer is that such an implementation greatly facilitates NAT 552 traversal for clients that connect to it. The ability to process 553 STUN connectivity checks allows for clients to obtain peer-derived 554 transport addresses that can be used by the network server to 555 reach them without a relay, even through symmetric NAT. 556 Furthermore, implementation of the STUN connectivity checks allows 557 for NAT bindings along the way to be kept open. ICE also provides 558 numerous security properties that are independent of NAT 559 traversal, and would benefit any multimedia endpoint. See 560 Section 13 for a discussion on these benefits. 562 Obtaining STUN, TURN and other derived candidates requires 563 transmission of packets which have the effect of creating bindings on 564 NAT devices between the client and the STUN or TURN servers. 565 Experience has shown that many NAT devices have upper limits on the 566 rate at which they will create new bindings. Furthermore, 567 transmission of these packets on the network makes use of bandwidth 568 and needs to be rate limited by the agent. As a consequence, a 569 client SHOULD pace its STUN and TURN transactions, such that the 570 start of each new transaction occurs at least Ta seconds after the 571 start of the previous transaction. The value of Ta SHOULD be 572 configurable, and SHOULD have a default of 50ms. Note that this 573 pacing applies only to the start of a new transaction; pacing of 574 retransmissions within a STUN or TURN transaction is governed by the 575 retransmission rules defined in those protocols. 577 To obtain STUN candidates, the client takes a local UDP candidate, 578 and for each configured STUN server, produces a STUN candidate. It 579 is anticipated that clients may have a multiplicity of STUN servers 580 that it discovers or is configured with in network environments where 581 there are multiple layers of NAT. To produce the STUN candidate from 582 the local candidate, it follows the procedures of Section 9 of RFC 583 3489 for each local transport address in the local candidate. It 584 obtains a shared secret from the STUN server and then initiates a 585 Binding Request transaction from each local transport address to that 586 server. The Binding Response will provide the client with its STUN 587 derived transport address in the MAPPED-ADDRESS attribute. If the 588 client had K local candidates, this will produce S*K STUN candidates, 589 where S is the number of STUN servers. 591 It is anticipated that clients may have a multiplicity of TURN 592 servers configured or discovered in network environments where there 593 are multiple layers of NAT, and that layering is known to the 594 provider of the client. To obtain TURN candidates, for each 595 configured TURN server, the client initiates an Allocate Request 596 transaction using the procedures of Section 8 of [16] from each 597 transport address of a particular local candidate. The Allocate 598 Response will provide the client with its TURN derived transport 599 address in the MAPPED-ADDRESS attribute. Once the TURN allocations 600 against a particular TURN server succeed from all of the transport 601 addresses in a particular local candidate, the client SHOULD NOT 602 attempt any further TURN allocations to that particular server from 603 the transport addresses in any other local candidates. This is to 604 reduce the number of bindings allocated from the NATs. Only a single 605 TURN candidate is needed from a particular TURN server. The order in 606 which local candidates are tried against the TURN server is a matter 607 of local policy. 609 Since a client will pace its STUN and TURN allocations at a rate of 610 one new transaction every Ta seconds, it will take a certain amount 611 of time for these allocations to occur. It is RECOMMENDED that 612 implementations have a configurable upper bound on the total number 613 of such allocations they will perform before generation of their 614 offer or answer. Any allocations not completed at that point SHOULD 615 be abandoned, but MAY continue and be used in an updated offer once 616 they complete. A default value of 10 is RECOMMENDED. Since the 617 total number of allocations that could be done (based on the number 618 of STUN servers, TURN servers and local interfaces) might exceed this 619 value, clients SHOULD prioritize their allocations and perform higher 620 priority ones first. It is RECOMMENDED that STUN allocations be 621 prioritized over TURN allocations. 623 Once the allocations are complete, any redundant candidates are 624 discarded. A candidate is redundant if its transport addresses for 625 each component match the transport addresses for each component of 626 another candidate. 628 7.2 Prioritizing the Candidates and Choosing an Active One 630 The prioritization process takes the set of candidates and associates 631 each with a priority. This priority reflects the desire that the 632 agent has to receive media on that address, and is assigned as a 633 value from 0 to 1 (1 being most preferred). Priorities are ordinal, 634 so that their significance is only meaningful relative to other 635 candidates from that agent for a particular media stream. Candidates 636 MAY have the same priority. However, it is RECOMMENDED that each 637 candidate have a distinct priority. Doing so improves the efficiency 638 of ICE. 640 This specification makes no normative recommendations on how the 641 prioritization is done. However, some useful guidelines are 642 suggested on how such a prioritization can be determined. 644 One criteria for choosing one candidate over another is whether or 645 not that candidate involves the use of a relay. That is, if media is 646 sent to that candidate, will the media first transit a relay before 647 being received. TURN candidates make use of relays (the TURN 648 server), as do any local candidates associated with a VPN server. 649 When media is transited through a relay, it can increase the latency 650 between transmission and reception. It can increase the packet 651 losses, because of the additional router hops that may be taken. It 652 may increase the cost of providing service, since media will be 653 routed in and right back out of a relay run by the provider. If 654 these concerns are important, candidates with this property can be 655 listed with lower priority. 657 Another criteria for choosing one candidate over another is IP 658 address family. ICE works with both IPv4 and IPv6. It therefore 659 provides a transition mechanism that allows dual-stack hosts to 660 prefer connectivity over IPv6, but to fall back to IPv4 in case the 661 v6 networks are disconnected (due, for example, to a failure in a 662 6to4 relay) [26]. It can also help with hosts that have both a 663 native IPv6 address and a 6to4 address. In such a case, higher 664 priority could be afforded to the native v6 address, followed by the 665 6to4 address, followed by a native v4 address. This allows a site to 666 obtain and begin using native v6 addresss immediately, yet still 667 fallback to 6to4 addresses when communicating with agents in other 668 sites that do not yet have native v6 connectivity. 670 Another criteria for choosing one candidate over another is security. 671 If a user is a telecommuter, and therefore connected to their 672 corporate network and a local home network, they may prefer their 673 voice traffic to be routed over the VPN in order to keep it on the 674 corporate network when communicating within the enterprise, but use 675 the local network when communicating with users outside of the 676 enterprise. 678 Another criteria for choosing one address over another is topological 679 awareness. This is most useful for candidates which make use of 680 relays (including TURN and VPN). In those cases, if an agent has 681 preconfigured or dynamically discovered knowledge of the topological 682 proximity of the relays to itself, it can use that to select closer 683 relays with higher priority. 685 There may be transport-specific reasons for preferring one candidate 686 over another. In such a case, specifications defining usage of ICE 687 with other transport protocols SHOULD document such considerations. 689 Once the candidates have been prioritized, one may be selected as the 690 active one. This is the candidate that will be used for actual 691 exchange of media if and when its validated, until replaced by an 692 updated offer or answer. The active candidate will also be used to 693 receive media from ICE-unaware peers. As such, it is RECOMMENDED 694 that one be chosen based on the likelihood of that candidate to work 695 with the peer that is being contacted. Unfortunately, it is 696 difficult to ascertain which candidate that might be. As an example, 697 consider a user within an enterprise. To reach non-ICE capable 698 agents within the enterprise, a local candidate has to be used, since 699 the enterprise policies may prevent communication between elements 700 using a relay on the public network. However, when communicating to 701 peers outside of the enterprise, a TURN-based candidate from a 702 publically accessible TURN server is needed. 704 Indeed, the difficulty in picking just one address that will work is 705 the whole problem that motivated the development of this 706 specification in the first place. As such, it is RECOMMENDED that 707 the active candidate be a TURN derived candidate from a TURN server 708 providing public IP addresses. Furthermore, ICE is only truly 709 effective when it is supported on both sides of the session. It is 710 therefore most prudent to deploy it to close-knit communities as a 711 whole, rather than piecemeal. In the example above, this would mean 712 that ICE would ideally be deployed completely within the enterprise, 713 rather than just to parts of it. 715 An additional consideration for selection of the active candidate is 716 the switching of media stream destinations between the initial offer 717 and the subsequent offer. If the active candidate pair in the 718 initial offer is be validated, media will flow once that pair is 719 validated. When the ICE checks complete and yield a higher priority 720 candidate pair, there will be an updated offer/answer exchange that 721 will change the active candidate. This will result in a change in 722 the destination of the media packets. This may also cause a 723 different path for the media packets. That path might have different 724 delay and jitter characteristics. As a consequence, the jitter 725 buffers may see a glitch, causing possible media artifacts. If these 726 issues are a concern, the initial offer MAY omit an active candidate. 727 In such a case, an updated offer will need to be sent immediately 728 when communicating with an ICE-unaware agent, setting an active 729 candidate. 731 There may be transport-specific reasons for selection of an active 732 candidate. In such a case, specifications defining usage of ICE with 733 other transport protocols SHOULD document such considerations. 735 7.3 Encoding Candidates into SDP 737 For each candidate for a media stream, the agent includes a series of 738 a=candidate attributes as media-level attributes, one for each 739 component in the candidate. Each candidate has a unique identifier, 740 called the candidate-id. The candidate-id MUST be chosen randomly 741 and contain at least 128 bits of randomness (this does not mean that 742 the candidate-id is 128 bits long; just that it has at least 128 bits 743 of randomness). It is chosen only when the candidate is placed into 744 the SDP for the first time; subsequent offers or answers within the 745 same session containing that same candidate MUST use the same 746 candidate-id used previously. 748 Each component of the candidate has an identifier, called the 749 component-id. The component-id is a sequence number. For each 750 candidate, it starts at one, and increments by one for each 751 component. As discussed below, ICE will perform connectivity checks 752 such that, between a pair of candidates, checks only occur between 753 transport addresses with the same component-id. As a consequence, if 754 one candidate has three components, and it is paired with a candidate 755 that has two, there will only be two transport address pairs and two 756 connectivity checks. 758 ICE will work without a standardized mapping between the components 759 of a media stream and the numerical value of the component-id. This 760 allows ICE to be used with media streams with multiple components 761 without development of standards around such a mapping. However, a 762 specific mapping has been defined in this specification for RTP - 763 component-id 1 corresponds to RTP, and component-id of 2 corresponds 764 to RTCP. Like the candidate-id, the component-id is assigned at the 765 time the candidate is first placed into the SDP; subsequent offers or 766 answers within the same session containing that same candidate MUST 767 use the same component-id used previously. 769 The transport, addr and port of the a=candidate attribute (all 770 defined in Section 12) are set to the transport protocol, unicast 771 address and port of the tranport address. A Fully Qualified Domain 772 Name (FQDN) for a host MAY be used in place of a unicast address. In 773 that case, when receiving an offer or answer containing an FQDN in an 774 a=candidate attribute, the FQDN is looked up in the DNS using an A or 775 AAAA record, and the resulting IP address is used for the remainder 776 of ICE processing. The qvalue is set to the priority of the 777 candidate, and MUST be the same for all components of the candidate. 778 Each transport address also includes a password that will be used for 779 securing the STUN connectivity checks. This password MUST be chosen 780 randomly with 128 bits of randomness (though it can be longer than 781 128 bits). Like the candidate-id, it is chosen when the candidate is 782 placed into an SDP for the first time for a particular session; 783 subsequent offers and answers within the same session conveying the 784 same candidate MUST use the same password. The converse is true; if 785 a new offer is generated as part of a new multimedia session, a new 786 password (and candidate-id) would be used even if the transport 787 address from a previous session was being recycled. 789 The combination of candidate-id and component-id uniquely identify 790 each transport address. As a consequence, each transport address has 791 a unique identifier, called the tid. The tid is formed by 792 concatenating the candidate-id with the component-id, separated by 793 the colon (":"). The tid is not explicitly encoded in the SDP; it is 794 derived from the candidate-id and component-id, which are present in 795 the SDP. The usage of the colon as a separator allows the 796 candidate-id and component-id to be extracted from the tid, since the 797 colon is not a valid character for the candidate-id. 799 The tid gets combined, through further concatenation, with the tid of 800 a transport address from the remote candidate (separated again by 801 another colon) to form the username that is placed in the STUN checks 802 between the peers. This allows the STUN message to uniquely identify 803 the pairing whose connectivity it is checking. The tid is needed as 804 a unique identifier because the IP address within the candidate fails 805 to provide that uniqueness as a consequence of NAT. 807 Consider agents A, B, and C. A and B are within private enterprise 1, 808 which is using 10.0.0.0/8. C is within private enterprise 2, which 809 is also using 10.0.0.0/8. As it turns out, B and C both have IP 810 address 10.0.1.1. A sends an offer to C. C, in its answer, provides 811 A with its transport addresses. In this case, thats 10.0.1.1:8866 812 and 8877. As it turns out, B is in a session at that same time, and 813 is also using 10.0.1.1:8866 and 8877. This means that B is prepared 814 to accept STUN messages on those ports, just as C is. A will send a 815 STUN request to 10.0.1.1:8866 and 8877. However, these do not go to 816 C as expected. Instead, they go to B. If B just replied to them, A 817 would believe it has connectivity to C, when in fact it has 818 connectivity to a completely different user, B. To fix this, tid 819 takes on the role of a unique identifier. C provides A with an 820 identifier for its transport address, and A provides one to C. A 821 concatenates these two identifiers (with a colon between) and uses 822 the result as the username in its STUN query to 10.0.1.1:8866. This 823 STUN query arrives at B. However, the username is unknown to B, and 824 so the request is rejected. A treats the rejected STUN request as if 825 there were no connectivity to C (which is actually true). Therefore, 826 the error is avoided. 828 An unfortunate consequence of the non-uniqueness of IP addresses is 829 that, in the above example, B might not even be an ICE agent. It 830 could be any host, and the port to which the STUN packet is directed 831 could be any ephemeral port on that host. If there is an application 832 listening on this socket for packets, and it is not prepared to 833 handle malformed packets for whatever protocol is in use, the 834 operation of that application could be affected. Fortunately, since 835 the ports exchanged in SDP are ephemeral and ususally drawn from the 836 dynamic or registered range, the odds are good that the port is not 837 used to run a server on host B, but rather is the agent side of some 838 protocol. This decreases the probability of hitting a port in-use, 839 due to the transient nature of port usage in this range. However, 840 the possibility of a problem does exist, and network deployers should 841 be prepared for it. Note that this is not a problem specific to ICE; 842 stray packets can arrive at a port at any time for any type of 843 protocol, especially ones on the public Internet. As such, this 844 requirement is just restating a general design guideline for Internet 845 applications - be prepared for unknown packets on any port. 847 The active candidate, if there is one, is placed into the m/c lines 848 of the SDP. For RTP streams, this is done by placing the RTP address 849 and port into the c and m lines in the SDP respectively. If the 850 agent is utilizing RTCP, it MUST encode its address and port using 851 the a=rtcp attribute as defined in RFC 3605 [2]. If RTCP is not in 852 use, the agent MUST signal that using b=RS:0 and b=RR:0 as defined in 853 RFC 3556 [8]. 855 If there is no active candidate, the agent MUST include an a=inactive 856 attribute. The RTP address and port in the m/c-line is 857 inconsequential, since it won't be used. 859 Encoding of candidates may involve transport protocol specific 860 considerations. There are none for UDP. However, extensions that 861 define usage of ICE with other transport protocols SHOULD specify any 862 special encoding considerations. 864 7.4 Forming Candidate Pairs 866 Once the offer/answer exchange has completed, both agents will have a 867 set of candidates for each media stream. Each agent forms a set of 868 candidate pairs for each media stream by combining each of its 869 candidates with each of the candidates of its peer. Candidates can 870 be paired up only if their transport protocols are identical. If an 871 offer/answer exchange took place for a session comprised of an audio 872 and a video stream, and each agent had two candidates per media 873 stream, there would be 8 candidate pairs, 4 for audio and 4 for 874 video. One agent can offer two candidates for a media stream, and 875 the answer can contain three candidates for the same media stream. 876 In that case, there would be six candidate pairs. 878 Each candidate has a number of components, each of which has a 879 transport address. Within a candidate pair, the components 880 themselves are paired up such that transport addresses with the same 881 component ID are combined to form a transport address pair. 882 Returning to the previous example, for each of the 8 candidate pairs, 883 there would be two transport address pairs - one for RTP, and one for 884 RTCP. If one candidate has more components than the other, those 885 extra components will not be part of a transport address pair, won't 886 be validated, and will effectively be treated as if they weren't 887 included in the candidate pair in the first place. 889 The relationship between a candidate, candidate pair, transport 890 address, transport address pair and component are shown in Figure 2. 891 This figure shows the relationships as seen by the agent that owns 892 the candidate with candidate ID "L". This candidate has two 893 components with transport addresses A and B respectively. This 894 candidate is called the native candidate, since it is the one owned 895 by the agent in question. The candidate owned by its peer is called 896 the remote candidate. As the figure shows, there is a single 897 candidate pair, and two components in each candidate. The native 898 candidate has a candidate-id of "L", and the remote candidate has a 899 candidate-id of "R". Since the two component-ids are 1 and 2, 900 candidate "L" has two transport addresses with transport address IDs 901 of "L:1" and "L:2" respectively. Similarly, candidate "R" has two 902 transport addresses with transport address IDs of "R:1" and "R:2" 903 respectively. 905 Furthermore, each transport address pair is associated with an ID, 906 the transport address pair ID. This ID is equal to the concatenation 907 of the tid of the native transport address with the tid of the remote 908 transport address, separated by a colon. This means that the 909 identifiers are seen differenly for each agent. For the agent that 910 owns candidate "L", there are two transport address pairs. One 911 contains transport address "L:1" and "R:1", with a transport address 912 pair ID of "L:1:R:1". The other contains transport address "L:2" and 913 "R:2", with a transport address pair ID of "L:2:R:2". For the agent 914 that owns candidate "R", the identifiers for these two transport 915 address pairs are reversed; it would be "R:1:L:1" for the first one 916 and "R:2:L:2" for the second. 918 ............................................... 919 . . 920 . . 921 . ............. ............. . 922 . . tid=L:1 . . tid=R:1 . . 923 . . -- . . -- . . component 924 component. . | A|------------------------| C| . . id=1 925 id=1 . . -- . Transport . -- . . 926 . . . Address . . . 927 . . . Pair . . . 928 . . . id=L:1:R:1 . . . 929 . . . . . . 930 . . . . . . 931 . . tid=L:2 . . tid=R:2 . . 932 component . . -- . . -- . . 933 id=2 . . | B|------------------------| D| component 934 . . -- . Transport . -- . . id=2 935 . . . Address . . . 936 . . . Pair . . . 937 . . . id=L:2:R:2 . . . 938 . . . . . . 939 . ............. ............. . 940 . Native Remote . 941 . Candidate Candidate . 942 . id=L id=R . 943 . . 944 . . 945 ............................................... 947 Candidate Pair 949 Figure 2 951 If a candidate pair was created as a consequence of an offer 952 generated by an agent, then that agent is said to be the offerer of 953 that candidate pair and all of its transport address pairs. 954 Similarly, the other agent is said to be the answerer of that 955 candidate pair and all of its transport address pairs. As a 956 consequence, each agent has a particular role, either offerer or 957 answerer, for each transport address pair. This role is important; 958 when a candidate pair is to be promoted to active, the offerer is the 959 one which performs the updated offer. 961 7.5 Ordering the Candidate Pairs 963 For the same reason that the STUN and TURN allocations are paced at a 964 rate of Ta transactions per second, so too are the connectivity 965 checks paced, also at a rate of Ta transactions per second. However, 966 in order to rapidly converge on a valid candidate pair that is 967 mutually desirable, the candidate pairs are ordered, and the checks 968 start with the candidate pair at the top of the list. Rapid 969 convergence of ICE depends on both the offerer and answerer coming to 970 the same conclusion on the ordering of candidate pairs. 972 Recall that when each candidate is encoded into SDP, it contains a 973 qvalue between 1 and 0, with 1 being the highest priority. Peer- 974 derived candidates, learned through the procedures described in 975 Section 7.10 also have a priority between 0 and 1. For each media 976 stream, the native candidates are ordered based on their qvalues, 977 with higher q-values coming first. Amongst candidates with the same 978 qvalue, they are ordered based on candidate ID, using lexicographic 979 order where C1 is placed before C2, if C2 precedes C1. In other 980 words, if the qvalues are the same, the candidates are sorted in 981 reverse order. This is actually important; as discussed in 982 Section 13, it allows peer-derived candidates to be preferred over 983 native ones. The result of these two ordering rules will be an 984 ordered list of candidates. The first candidate in this list is 985 given a sequence number of 1, the next is given a sequence number of 986 2, and so on. This same procedure is done for the remote candidates. 987 The result is that each candidate pair has two sequence numbers, one 988 for the native candidate, and one for the remote candidate. 990 First, all of the candidate pairs for whom the smaller of the two 991 sequence numbers equals 1 are taken first. Then, all of those for 992 whom the smaller of the two sequence numbers equals 2 are taken next, 993 and so on. Amongst those pairs that share the same value for their 994 smaller sequence number, they are ordered by the larger of their two 995 sequence numbers (smallest first). Amongst those pairs that share 996 the same value for their smaller sequence number and the same value 997 for their larger sequence number, the larger of the two candidate IDs 998 in each pair are selected, and the pairs are lexicographically 999 ordered in reverse by that candidate ID, largest first. 1001 As an example, consider two agents, A and B. One offers two 1002 candidates for a media stream with candidate IDs of "g9" and "88", 1003 with q-values of 1.0 and 0.8 respectively. The other answers with 1004 three candidates with candidate IDs of "h8", "65" and "kl", with 1005 q-values of 0.3, 0.2 and 0.1 respectively. The following table shows 1006 the rank ordering of the six candidate pairs. The column labeled 1007 "Max SN" is the larger of the two sequence numbers in the candidate 1008 pair, and "Min SN" is the minimum. The column labeled "Max Cand. 1010 ID" is the value of the larger of the two candidate IDs in the 1011 candidate pair. 1013 Order A A A B B B Max 1014 Cand. Cand. Cand. Cand. Cand. Cand. Max Min Cand. 1015 ID q-value SN ID q-value SN SN SN ID 1016 --------------------------------------------------------------------- 1017 1 g9 1.0 1 h8 0.3 1 1 1 h8 1018 2 88 0.8 2 h8 0.3 1 2 1 h8 1019 3 g9 1.0 1 65 0.2 2 2 1 g9 1020 4 g9 1.0 1 k1 0.1 3 3 1 k1 1021 5 88 0.8 2 65 0.2 2 2 2 88 1022 6 88 0.8 2 k1 0.1 3 3 2 k1 1024 This ordering is then modified slightly by taking the candidate pair 1025 corresponding to the active candidate, if there is one, and promoting 1026 it to the top of the list. This allows the current active candidate 1027 to be tested first. As discussed below, media is not sent until the 1028 corresponding candidate is verified, necessitating rapid verification 1029 of the active candidate. This modified ordering is called the 1030 candidate pair check ordering, since it reflects the order in which 1031 connectivity checks will be done. If there was no active candidate, 1032 the candidate pair check ordering and the candidate pair priority 1033 ordering will be identical. 1035 Within each candidate pair there will be a set of transport address 1036 pairs, one for each component ID. Those pairs are ordered by 1037 component ID. The result is an absolute ordering of all transport 1038 address pairs for a media stream, sorted first by the order of their 1039 candidate pairs (with the exception of the active candidate), 1040 followed by the order of their component IDs. This ordering is 1041 called the transport address pair check ordering. 1043 Ordering of candidates may involve transport protocol specific 1044 considerations. There are none for UDP. However, extensions that 1045 define usage of ICE with other transport protocols SHOULD specify any 1046 special ordering considerations. 1048 7.6 Performing the Connectivity Checks 1050 Connectivity checks are performed by sending peer-to-peer STUN 1051 Binding Requests. These checks result in a candidate progressing 1052 through a state machine that captures the progress of connectivity 1053 checks. The specific state machine and the procedures for the 1054 connectivity checks are specific to the transport protocol. This 1055 specification defines rules for UDP. Extensions to ICE that describe 1056 other transport protocols SHOULD describe the state machine and the 1057 procedures for connectivity checks. 1059 The set of states visited by the offerer and answerer are depicted 1060 graphically in Figure 4 1062 | 1063 |Start 1064 | 1065 | 1066 V 1067 +------------+ 1068 | | 1069 | | 1070 | Waiting |----------------+ 1071 | | | 1072 | | | 1073 +------------+ | 1074 | | 1075 | Timer Ta | Get Req 1076 | --------. | ------- 1077 | Send Req | Send Res, 1078 V | Send Req 1079 Get Res +------------+ Get Req | 1080 ------- | | ------- | 1081 - | | Send Res | 1082 +---------------| Testing |-----------+ | 1083 | | | | | 1084 | | | | | 1085 | +------------+ | | 1086 | | | | 1087 | | Error | | 1088 | | ----- | | 1089 Timer Tr | | - | | 1090 -------- V V V V 1091 Send Req +------------+ +------------+ +------------+ 1092 +-----| | | | | | 1093 | | Recv- | | | | Send- | 1094 | | Valid |------->| Invalid |<-------| Valid | 1095 | | | | | | | 1096 +---->| | Error | | Error | | 1097 +------------+ ----- +------------+ ----- +------------+ 1098 | - ^ - | 1099 | | Error | 1100 | | ----- | 1101 | | - | 1102 | +------------+ | 1103 | | | | 1104 | | | | 1105 +-------------->| Valid |<-------------+ 1106 Get Req | | Get Res 1107 ------- | | ------- 1108 Send Res +------------+ - 1109 | ^ 1110 | | 1111 | | 1112 +-------+ 1113 Timer Tr 1114 -------- 1115 Send Req 1117 Figure 4 1119 The state machine has six states - waiting, testing, Recv-Valid, 1120 Send-Valid, Valid and Invalid. Initially, all transport address 1121 pairs start in the waiting state. In this state, the agent waits for 1122 one of two events - a chance to send a Binding Request, or receipt of 1123 a Binding Request. 1125 Since there is an instance of the state machine for each transport 1126 address pair, Binding Requests and responses need to be matched to 1127 the specific state machine for which they apply. This is done by 1128 computing the matching transport address pair for each Binding 1129 Request. This is done by examining the USERNAME of the incoming 1130 Binding Request. The USERNAME directly contains the transport 1131 address pair ID. Requests that are sent by an agent as part of the 1132 processing described here encode the transport address pair in the 1133 USERNAME. Binding Responses are matched to their requests using the 1134 STUN transaction ID, and then mapped to the transport address pair 1135 from that. 1137 Every Ta seconds, the agent starts a new connectivity check for a 1138 transport address pair. The check is started for the first transport 1139 address pair in the transport address pair check ordered list (which 1140 will be the active candidate) that is in the Waiting state. The 1141 state machine for this transport address pair is moved to the Testing 1142 state, and the agent sends a connectivity check using a STUN Binding 1143 Request, as outlined in Section 7.7. Once a STUN connectivity check 1144 begins, the processing of the check follows the rules for STUN. 1145 Specifically, retransmits of STUN requests are done as specified in 1146 RFC 3489, and furthermore, if a transaction fails and needs to be 1147 retried, that retry can happen rapidly, as described below. It 1148 doesn't "count" against the rate limit of 1/Ta checks per second. In 1149 addition, the keepalives that are generated for a valid pair do not 1150 count against the rate limit either. The rate limit applies strictly 1151 to the start of connectivity checks by the answerer for a transport 1152 address pair that has been newly signaled through an offer/answer 1153 exchange. 1155 In addition, if, while in the Waiting state, an agent receives a 1156 Binding Request matching that transport address pair, and this 1157 Binding Request generates a successful response, the agent moves into 1158 the Send-Valid state, and sends a connectivity check of its own using 1159 a STUN Binding Request, as outlined in Section 7.7. If the Binding 1160 Request didn't generate a success response, there is no change in 1161 state or generation of a Binding Request. 1163 If, while in the Testing state, the agent receives a successful 1164 response to its STUN request, it moves into the Recv-Valid state. In 1165 this state, the agent knows that packets can flow in both directions. 1166 However, its peer agent doesn't yet know that; all it knows is that 1167 it has been able to receive a packet. Thus, in this state, the agent 1168 awaits receipt of the Binding Request sent by its peer, as the 1169 response to that request is what informs its peer that packets can 1170 flow in both directions. 1172 If, while in the Send-Valid state, the agent receives a successful 1173 response to its STUN request, it moves to the Valid state. In this 1174 state, the agent knows that packets can flow in each direction. It 1175 also knows that its peer has sent it the STUN Request whose response 1176 will demonstrate to the peer that packets can flow in each direction. 1178 If, while in the Recv-Valid state, the agent receives a STUN Binding 1179 Request from its peer that results in a successful response, the 1180 agent moves into the Valid state. Receipt of a request whose 1181 response was not a successful one does not result in a change in 1182 state. 1184 In any state, if the STUN transaction results in an error, the state 1185 machine moves into the invalid state. 1187 If a transport address pair is in the Recv-Valid or Valid state, an 1188 agent MUST generate a new STUN Binding Request transaction every Tr 1189 seconds. This transaction ensures that NAT bindings for the 1190 transport address pair remain open while the candidate is under 1191 consideration. The transaction is performed as outlined in 1192 Section 7.7. These transactions can also be used to keep the 1193 bindings alive when the candidate is promoted to active, as described 1194 in Section 7.12. Tr SHOULD be configurable, and SHOULD default to 15 1195 seconds. If the transaction results in an error, the state machine 1196 moves to the invalid state. This happens in cases where the NAT 1197 bindings expire (e.g., due to binding timeouts or NAT failures). 1199 The candidate pair itself has a state, which is derived from the 1200 states of its transport address pairs. If at least one of the 1201 transport address pairs in a candidate pair is in the invalid state, 1202 the state of the candidate pair is considered to be invalid. If the 1203 candidate pair enters this state, an agent SHOULD move the state 1204 machines for all of the other transport address pairs in this 1205 candidate pair into the invalid state as well. This will ensure that 1206 connectivity checks never start for those transport address pairs. 1207 Furthermore, if checks are already in progress for one of those 1208 transport address pairs, the agent SHOULD cease them. 1210 If all of the transport address pairs making up the candidate pair 1211 are Valid, the candidate pair is considered valid. If all of the 1212 transport address pairs making up the candidate pair are either Valid 1213 or Recv-Valid, and at least one is Recv-Valid, the candidate pair is 1214 considered to be Recv-Valid. If all of the transport address pairs 1215 making up the candidate pair are either Valid or Send-Valid, and at 1216 least one is Send-Valid, the candidate pair is considered to be Send- 1217 Valid. If all of the transport address pairs in a candidate pair are 1218 in the Waiting state, the candidate pair is in the waiting state. If 1219 all of the transport address pairs in the candidate pair are either 1220 in the Waiting or Testing states, and at least one is in the Testing 1221 state, the state of the candidate pair is Testing. Otherwise, the 1222 state of the candidate pair is considered Indeterminate. 1224 A candidate itself also has a state. If a candidate is present in at 1225 least one valid candidate pair, that candidate is said to be valid. 1226 If all of the candidate pairs containing that candidate are invalid, 1227 the candidate itself is invalid. Otherwise, the candidate's state is 1228 Indeterminate. 1230 If a native candidate becomes valid, and is more preferred than the 1231 active one, the offerer sends an updated offer with this newly 1232 validated candidate promoted to the m/c-line. This process is 1233 discussed in more detail in Section 7.9. 1235 7.7 Sending a Binding Request for Connectivity Checks 1237 An agent performs a Binding Request transaction by sending a STUN 1238 Binding Request from its native transport address, and sending it to 1239 the remote transport address. The meaning of "sending from its 1240 native transport address" depends on the type of transport protocol 1241 and the type of transport address (local, STUN-derived, TURN-derived, 1242 or peer-derived). This specification defines the meaning for UDP. 1243 Specifications defining other transport protocols must define what 1244 this means for them. 1246 For UDP-based local transport addresses, sending from the local 1247 transport address has the meaning one would expect - the request is 1248 sent such that the source IP address and port For STUN derived UDP 1249 transport addresses, it is sent by sending from the local transport 1250 address used to derive that STUN address. For TURN derived UDP 1251 transport addresses, it is sent by using TURN mechanisms to send the 1252 request through the TURN server (using the SEND primitive). Sending 1253 the request through the TURN server neccesarily requires that the 1254 request be sent from the client, using the local transport address 1255 used to derive the TURN transport address. 1257 The Binding Request sent by the agent MUST contain the USERNAME 1258 attribute. This attribute MUST be set to the transport address pair 1259 ID of the corresponding transport address pair as seen by its peer. 1260 Thus, for the first transport address pair in Figure 2, if the agent 1261 on the left sends the STUN Binding Request, the USERNAME will have 1262 the value R:1:L:1. If the agent on the right sends the STUN Binding 1263 Request, the USERNAME will have the value L:1:R:1. To be clear, the 1264 USERNAME that is used is NOT the one seen locally, but rather the one 1265 as seen by its peer. The request SHOULD contain the MESSAGE- 1266 INTEGRITY attribute, computed according to RFC 3489 procedures. The 1267 key used as input to the HMAC is the password provided by the peer 1268 for this remote transport address. The Binding Request MUST NOT 1269 contain the CHANGE-REQUEST or RESPONSE-ADDRESS attribute. 1271 The STUN transaction will generate either a timeout, or a response. 1272 If the response is a 420, 500, or 401, the agent should try again as 1273 described in RFC 3489 (as mentioned above, it need not wait Ta 1274 seconds to try again). Either initially, or after such a retry, the 1275 STUN transaction might produce a non-recoverable failure response 1276 (error codes 400, 430, 431, or 600) or a failure result inapplicable 1277 to this usage of STUN and thus unrecoverable (432, 433). If this 1278 happens, an error event is generated into the state machine, and the 1279 transport address pair enters the invalid state. 1281 If the STUN transaction times out, the client SHOULD NOT retry. The 1282 only reason a retry might succeed is if there was severe packet loss 1283 during the duration of the check, or the answer was significantly 1284 delayed, also due to packet loss. However, STUN Binding Request 1285 transactions run for 9.5 seconds, which is well beyond the typical 1286 tolerance for a session establishment. The retries come with a 1287 penalty of additional traffic, which can be used to launch DoS 1288 attacks Section 13.4.2. The only reason to not follow the SHOULD NOT 1289 is if the agent has adjusted the STUN transaction timers to be more 1290 aggressive. 1292 If the Binding Response is a 200, the agent SHOULD check for the 1293 MESSAGE-INTEGRITY attribute and verify it, as discussed in RFC 3489. 1294 Indeed, this check SHOULD be done for all responses. This will 1295 result in the response being discarded (eventually leading to a 1296 timeout), if the integrity check fails. 1298 7.8 Receiving a Binding Request for Connectivity Checks 1300 As a result of providing a list of candidates in its offer or answer, 1301 an agent will receive STUN Binding Request messages. An agent MUST 1302 be prepared to receive STUN Binding Requests on each local transport 1303 address from the moment it sends an offer or answer that contains a 1304 candidate with that local transport address. Similarly, it MUST be 1305 prepared to receive STUN Binding Requests on a local transport 1306 address the moment it sends an offer or answer that contains a STUN 1307 or TURN candidate derived from a local candidate containing that 1308 local transport address. It can cease listening for STUN messages on 1309 that local transport address after sending an updated offer or answer 1310 which does not include any candidates with transport addresses that 1311 are equal to or derived from that local transport address. 1313 The agent does not need to provide STUN service on any other IP 1314 addresses or ports, unlike the STUN usage described in [1]. The need 1315 to run the service on multiple ports is to support receipt of Binding 1316 Requests with the CHANGE-REQUEST attribute. However, that attribute 1317 is not used when STUN is used for connectivity checks. A server 1318 SHOULD reject, with a 400 answer, any STUN requests with a CHANGE- 1319 REQUEST attribute whose value is non-zero. The CHANGED-ADDRESS 1320 attribute in a BindingAnswer is set to the transport address on which 1321 the server is running. 1323 Furthermore, there is no need to support TLS or to be prepared to 1324 receive SharedSecret request messages. Those messages are used to 1325 obtain shared secrets to be used with BindingRequests. However, with 1326 ICE, these shared secrets are exchanged through the offer/answer 1327 exchange itself. 1329 One of the candidates may be in use as the active candidate. For the 1330 transport addresses comprising that candidate, the agent will receive 1331 both STUN requests and media packets on its associated local 1332 transport addresses. The agent MUST be able to disambiguate them. 1333 In the case of RTP/RTCP, this disambiguation is easy. RTP and RTCP 1334 packets start with the bits 0b10 (v=2). The first two bits in STUN 1335 are always 0b00. This disambiguation also works for packets sent 1336 using Secure RTP [25], since the RTP header is in the clear. 1337 Disambiguating STUN with other media stream protocols may be more 1338 complicated. However, it can always be possible with arbitrarily 1339 high probabilities by selecting an appropriately random username (see 1340 below). 1342 Processing of the Binding Request proceeds in two steps. The first 1343 is generation of the response, and the second is side-effect 1344 processing. Generation of the response follows the general 1345 procedures of RFC 3489. The USERNAME is considered valid if its 1346 topmost portion (the part up to, but not including the second colon) 1347 corresponds to a transport address ID known to the agent. The 1348 password associated with that transport address ID is used to verify 1349 the MESSAGE-INTEGRITY attribute, if one was present in the request. 1350 If the USERNAME was not valid, the agent generates a 430. Otherwise, 1351 the success response will include the MAPPED-ADDRESS attribute, which 1352 is used for learning new candidates, as described in Section 7.10. 1353 The MAPPED-ADDRESS attribute is populated with the source IP address 1354 and port of the Binding Request. For Binding Requests received over 1355 TURN-derived transport addresses, this MUST be the source IP address 1356 and port of the Binding Request when it arrived at the TURN relay, 1357 prior to forwarding towards the agent. That source transport address 1358 will be present in the REMOTE-ADDRESS attribute of a TURN Data 1359 Indication message, if the Binding Request were delivered through a 1360 Data Indication. If the Binding Request was not encapsulated in a 1361 Data Indication, that source address is equal to the current active 1362 destination for the TURN session. 1364 The side effect processing involves changes to the state machine for 1365 a transport address pair. This processing cannot be done until the 1366 initial offer/answer exchange has completed. As a consequence, if 1367 the answerer received a Binding Request that generated a success 1368 response, but had not yet received the answer to its offer, it waits 1369 for the answer, and when it arrives, then performs the side effect 1370 processing. 1372 The agent takes the entire contents of the USERNAME, and compares 1373 them against the transport address pair identifiers as seen by that 1374 agent for each transport address pair. If there is no match, nothing 1375 is done - this should never happen for compliant implementations. If 1376 there is a match, the resulting transport address pair is called the 1377 matching transport address pair. The state machine for the matching 1378 transport address pair is then updated based on the receipt of a STUN 1379 Binding Request, and the resulting actions described in Section 7.6 1380 are undertaken. 1382 An agent will continue to receive periodic STUN transactions on a 1383 local transport address as long as it had listed that transport 1384 address, or one derived from it, in an a=candidate attribute in its 1385 most recent offer or answer, and the state machine indicates that 1386 Binding Requests are periodically sent (as is the case for UDP). It 1387 MUST process any such transactions according to this section. It is 1388 possible that a transport address pair that was previously valid may 1389 become invalidated as a result of a subsequent failed STUN 1390 transaction. 1392 7.9 Promoting a Candidate to Active 1394 As a consequence of the connectivity checks, each agent will change 1395 the states for each transport address pair, and consequently, for the 1396 candidate pairs. When a candidate pair becomes valid, and the agent 1397 is in the role of offerer for that candidate pair, the agent follows 1398 the logic in this section. The rules only apply to the offerer of a 1399 candidate pair in order to eliminate the possibility of both agents 1400 simultaneously offering an update to promote a candidate to active. 1402 If this candidate pair is the first one in the candidate pair 1403 priority ordered list, the agent SHOULD send an updated offer as 1404 described in Section 7.11.1. If this candidate pair is not the first 1405 on that list, but it is the first on the candidate pair check ordered 1406 list, it means that this candidate pair is the active one, and its 1407 connectivity has been verified. This is good news; the currently 1408 active candidate is working. Media can now flow as described in 1409 Section 7.13 (media will never flow prior to validation). However, 1410 no updated offer is sent at this time. 1412 If this candidate pair is not the first on the candidate pair 1413 priority ordered list or the candidate pair check ordered list, and 1414 the wait-state timer has not yet been set, the agent sets this timer 1415 to Tws seconds. Tws SHOULD be configurable, and SHOULD have a 1416 default of 100ms. This timer allows for a higher priority 1417 connectivity check to complete, in the event its STUN Binding Request 1418 was lost or delayed in the network. If, prior to the wait-state 1419 timer firing, another connectivity check completes and a candidate 1420 pair is validated, there is no need to reset or cancel the timer. 1421 Once the timer fires, the agent SHOULD issue an updated offer as 1422 described in Section 7.11.1. 1424 7.10 Learning New Candidates from Connectivity Checks 1426 ICE makes use of candidate addresses learned through protocols like 1427 STUN, as described in Section 7.1. These addresses are learned when 1428 STUN requests are sent to configured STUN servers. However, the 1429 peer-to-peer STUN connectivity checks can themselves provide 1430 additional candidates that ICE can make use of. This happens, for 1431 example, when two agents are separated by a symmetric NAT. When the 1432 agent behind the symmetric NAT sends a Binding Request to the other 1433 agent (which can have a public address or be behind any type of NAT 1434 except for symmetric), the symmetric NAT will create a new NAT 1435 binding for this Binding Request. Because of the properties of 1436 symmetric NAT, that binding can be used be the agent on the public 1437 side of the symmetric NAT to send packets back to the agent behind 1438 the symmetric NAT. 1440 To do this, ICE agents perform additional processing on the receipt 1441 of STUN Binding Requests and responses, beyond the logic described in 1442 Section 7.7 and Section 7.8. This logic is described below. 1444 7.10.1 On Receipt of a Binding Request 1446 When a STUN Binding Request is received which generates a success 1447 response, that Binding Request would have been associated with a 1448 matching transport address pair and corresponding candidate pair. 1449 The source IP and port of this Binding Request are compared to the IP 1450 address and port of the remote transport address in the matching 1451 transport address pair. Note that, in this case, we are comparing 1452 actual IP addresses and ports - not tids. In addition, if the 1453 Binding Request arrived through a TURN derived transport address, the 1454 source IP and port of this binding request used for the comparison 1455 are those in the Binding Request when it arrived at the TURN relay, 1456 prior to forwarding towards the agent. That source transport address 1457 will be present in the REMOTE-ADDRESS attribute of a TURN Data 1458 Indication message, if the Binding Request were delivered through a 1459 Data Indication. If the Binding Request was not encapsulated in a 1460 Data Indication, that source address is equal to the current active 1461 destination for the TURN session. 1463 The comparison of the source IP and port of the Binding Request and 1464 the IP address and port of the remote transport address in the 1465 matching transport address pair may not match. One reason this could 1466 happen is if there was a NAT between the two agents. If they do not 1467 match, the source IP and port of the Binding Request (and again, for 1468 TURN derived transport address, this refers to the source IP address 1469 and port of the packet when it arrived at the relay) are compared to 1470 the IP address and ports across the transport address pairs in *all* 1471 remote candidates. If there is still no match, it means that the 1472 source IP and port might represent another valid remote transport 1473 address. Such a transport address is called a peer-derived transport 1474 address. 1476 To use it, that address needs to be associated with a candidate 1477 (called a peer-derived candidate). In this case, however, the 1478 candidate isn't signaled through an offer/answer exchange; it is 1479 constructed dynamically from information in the STUN request. Like 1480 all other candidates, the peer-derived candidate has a candidate ID. 1481 The candidate ID is derived from the candidate IDs of the matching 1482 candidate pair. In particular, the candidate ID is constructed by 1483 concatenating the remote candidate ID with the native candidate ID 1484 (without the colon). 1486 On receipt of a STUN Binding Request whose source IP and port don't 1487 match the transport address in any remote candidate, the agent 1488 constructs the candidate ID that represents the peer-derived 1489 candidate, and checks to see if that candidate exists. It may 1490 already exist if it had been constructed as a consequence of a 1491 previous application of this logic on receipt of a Binding Request 1492 for a different transport address pair of the same candidate pair. 1493 If there is not yet a peer derived candidate with that candidate ID, 1494 the agent creates it, and assigns it the newly computed candidate ID. 1495 The priority of the peer-derived candidate MUST be set to the 1496 priority of its generating candidate - the remote candidate in the 1497 matching transport address pair. Note that, at this time, the peer 1498 derived candidate has no transport addresses in it. 1500 Newly created or not, the agent extracts the component ID from the 1501 matching transport address pair, and sees if a transport address with 1502 that same component ID exists in the peer derived candidate. If not 1503 (and it shouldn't), the agent adds a transport address to the peer- 1504 derived candidate. This transport address is equal to the source IP 1505 address and port from the incoming STUN Binding Request. It is 1506 assigned the component ID equal to the component ID in the matching 1507 transport address pair. This transport address will have a tid, 1508 equal to the concatenation of the candidate ID for this new 1509 candidate, and the component ID, separated by a colon. 1511 The peer-derived candidate becomes usable once the number of 1512 transport addresses in it equals the transport address pair count of 1513 the candidate pair from which it is derived. Initially, the peer- 1514 derived candidate will start with a single transport address. More 1515 are added as the connectivity checks for the original candidate pair 1516 take place. Once the peer-derived candidate becomes usable, it has 1517 to be paired up with native candidates. However, unlike the 1518 procedures of Section 7.5, which pair up each remote candidate with 1519 each native candidate, this peer-derived candidate is only paired up 1520 with the native candidate from the candidate pair from which it was 1521 derived. This creates a new candidate pair, and a set of new 1522 transport address pairs. 1524 Recall that, for each candidate pair, one agent plays the role of 1525 offerer, and the other of answerer. For peer-derived candidates, the 1526 agent that receives the STUN request and follows the processing in 1527 this section acts as the answerer. 1529 Figure 5 provides a pictorial representation of the peer derived 1530 candidate (the one with id=RL) and its pairing with the native 1531 candidate with id L. The candidate with ID R is referred to as the 1532 generating candidate. The peer-derived candidate is effectively an 1533 alternate for that generating candidate, but is only paired with a 1534 specific native candidate. Note that, for a particular generating 1535 candidate, there can be many peer derived candidates, up to one for 1536 each native candidate. 1538 ............. ............. 1539 . tid=L:1 . . tid=R:1 . 1540 component. -- . id=L:1:R:1 . -- .component 1541 id=1 . | A|------------------------| C| . id=1 1542 . -- -------+ . -- . 1543 . . | . . 1544 . . | . . Generating 1545 . . | . . Candidate 1546 . . | . . 1547 . . | . . 1548 . tid=L:2 . | . tid=R:2 . 1549 component. -- . | id=L:2:R:2 . -- .component 1550 id=2 . | B|-------C----------------| D| . id=2 1551 . -- -----+ | . -- . 1552 . .| | . . 1553 . .| | . . 1554 . .| | . . 1555 . .| | . . 1556 .............| | ............. 1557 Native | | Remote 1558 Candidate | | Candidate 1559 id=L | | id=R 1560 | | 1561 | | 1562 .| | 1563 | | 1564 | | 1565 | | 1566 | | ............. 1567 | | . tid=RL:1 . 1568 | | id=L:1:RL:1 . -- .component 1569 | +-----------------| C| . id=1 1570 | . -- . 1571 | . . 1572 | . . Peer Derived 1573 | . . Candidate 1574 | . . 1575 | . . 1576 | . tid=RL:2 . 1577 | id=L:2:RL:2 . -- .component 1578 +-------------------| D| . id=2 1579 . -- . 1580 . . 1581 . . 1582 . . 1584 . . 1585 ............. 1586 Remote 1587 Candidate 1588 id=RL 1590 Figure 5 1592 The new transport address pairs have a state machine associated with 1593 them. The state that is entered, and actions to take as a 1594 consequence, are specific to the transport protocol. For UDP, the 1595 procedures are defined here. Extensions that define processing for 1596 other transport protocols SHOULD describe the behavior. 1598 For UDP, the state machine enters the Send-Valid state. Effectively, 1599 the Binding Request just received "counts" as a validation in this 1600 direction, even though it was formally done for a different candidate 1601 pair. In addition, the agent SHOULD generate a Binding Request for 1602 each transport address in this new candidate pair, as described in 1603 Section 7.7. The transport address pairs are inserted into the 1604 ordered list of pairs based on the ordering described in Section 7.5 1605 and processing follows the logic described in Section 7.6. 1607 7.10.2 On Receipt of a Binding Response 1609 The procedures on receipt of a Binding Response are nearly identical 1610 to those for receipt of a Binding Request as described above. 1612 When a successful STUN Binding Response is received, it will be 1613 associated with a matching transport address pair and corresponding 1614 candidate pair. This matching is done based on comparison of 1615 candidate IDs. The value of the MAPPED-ADDRESS attribute of the 1616 Binding Response are compared to the IP address and port of the 1617 native transport address in the matching transport address pair. 1618 Note that, in this case, we are comparing actual IP addresses and 1619 ports - not tids. These may not match if there was a NAT between the 1620 two agents. If they do not match, the value of the MAPPED-ADDRESS 1621 attribute of the Binding Response are compared to the IP address and 1622 ports across the transport address pairs in *all* native candidates. 1623 If there is still no match, it means that the MAPPED-ADDRESS might 1624 represent another valid remote transport address. 1626 To use it, that address needs to be associated with a candidate. In 1627 this case, however, the candidate isn't signaled through an offer/ 1628 answer exchange; it is constructed dynamically from information in 1629 the STUN response. Such a candidate is called a peer-derived 1630 candidate. Like all other candidates, the peer-derived candidate has 1631 a candidate ID. The candidate ID is derived from the candidate IDs 1632 of the matching candidate pair. In particular, the candidate ID is 1633 constructed by concatenating the native candidate ID with the remote 1634 candidate ID (without the colon). 1636 On receipt of a STUN Binding Response whose MAPPED-ADDRESS didn't 1637 match the transport address in any native candidate, the agent 1638 constructs the candidate ID that represents the peer-derived 1639 candidate, and checks to see if that candidate exists. It may 1640 already exist if it had been constructed as a consequence of a 1641 previous application of this logic on receipt of a Binding Response 1642 for a different transport address pair of the same candidate pair. 1643 If there is not yet a peer derived candidate with that candidate ID, 1644 the agent creates it, and assigns it the newly computed candidate ID. 1645 The priority of the new candidate MUST be set to the priority of the 1646 generating candidate - the native candidate in the matching transport 1647 address pair. Note that, at this time, the peer derived candidate 1648 has no transport addresses in it. 1650 Newly created or not, the agent extracts the component ID from the 1651 matching transport address pair, and sees if a transport address with 1652 that same component ID exists in the peer derived candidate. If not 1653 (and it shouldn't), the agent adds a transport address to the peer- 1654 derived candidate. This transport address is equal to the MAPPED- 1655 ADDRESS from the STUN Binding Response. It is assigned the component 1656 ID equal to the component ID in the matching transport address pair. 1657 This transport address will have a tid, equal to the concatenation of 1658 the candidate ID for this new candidate, and the component ID, 1659 separated by a colon. 1661 The peer-derived candidate becomes usable once the number of 1662 transport addresses in it equals the transport address pair count of 1663 candidate pair from which it is derived. Initially, the peer-derived 1664 candidate will start with a single transport address. More are added 1665 as the connectivity checks for the original candidate pair take 1666 place. Once the peer-derived candidate becomes usable, it has to be 1667 paired up with remote candidates. However, unlike the procedures of 1668 Section 7.5, which pair up each remote candidate with each native 1669 candidate, the peer-derived candidate is only paired up with the 1670 remote candidate from the matching candidate pair . This creates a 1671 new candidate pair, and a set of new transport address pairs. 1673 Recall that, for each candidate pair, one agent plays the role of 1674 offerer, and the other of answerer. For peer-derived candidates, the 1675 agent that receives the STUN request and follows the processing in 1676 this section acts as the answerer. 1678 The new transport address pairs have a state machine associated with 1679 them. The state that is entered, and actions to take as a 1680 consequence, are specific to the transport protocol. For UDP, the 1681 procedures are defined here. Extensions that define processing for 1682 other transport protocols SHOULD describe the behavior. 1684 For UDP, the state machine enters the Recv-Valid state. Effectively, 1685 the Binding Response just received "counts" as a validation in this 1686 direction, even though it was formally done for a different candidate 1687 pair. The transport address pairs are inserted into the ordered list 1688 of pairs based on the ordering described in Section 7.5, and 1689 processing follows the logic described in Section 7.6. 1691 7.11 Subsequent Offer/Answer Exchanges 1693 An agent MAY issue an updated offer at any time. This updated offer 1694 may be sent for reasons having nothing to do with ICE processing (for 1695 example, the addition of a video stream in a multimedia session), or 1696 it may be due to a change in ICE-related parameters. For example, if 1697 an agent acquires a new candidate after the initial offer/answer 1698 exchange, it may seek to add it. 1700 However, agents SHOULD follow the logic described in Section 7.9 to 1701 determine when to send an updated offer as a consequence of promoting 1702 a candidate to active. 1704 If there are any aspects of this processing that are specific to the 1705 transport protocol, those SHOULD be called out in ICE extensions that 1706 define operation with other transport protocols. There are no 1707 additional considerations for UDP. 1709 7.11.1 Sending of a Subsequent Offer 1711 The offer MAY contain a new active candidate in the m/c line. This 1712 candidate SHOULD be the native candidate from the highest candidate 1713 pair in the candidate pair priority ordered list whose state is 1714 valid. If there are no candidate pairs in this state, the highest 1715 one whose state is partially valid SHOULD be used. If there are no 1716 candidate pairs in this state, the candidate pair that is most likely 1717 to work with this peer, as described in Section 7.2, SHOULD be used. 1718 The candidate is encoded into the m/c line in an updated offer as 1719 described in Section 7.3. 1721 If the candidate pair whose native candidate was encoded into the 1722 m/c-line was valid or partially valid, the agent MUST include an 1723 a=remote-candidate attribute into the offer. This attribute MUST 1724 contain the candidate ID of the remote candidate in the candidate 1725 pair. It is used by the recipient of the offer in selecting its 1726 candidate for the answer. 1728 The meaning of a=candidate attributes within a subsequent offer have 1729 the same meaning as they do in an initial offer. They are a request 1730 for the peer to attempt (or continue to attempt if the candidate was 1731 provided previously) a connectivity check using STUN from each of its 1732 own candidates. When an updated offer is sent, there are several 1733 dispositions regarding the candidates: 1735 retained: A candidate is retained if the candidate ID for the 1736 candidate is included in the new offer, and matches the candidate 1737 ID for a candidate in the previous offer or answer. In this case, 1738 all of the information about the candidate - its qvalue and 1739 components, and the IP addresses, ports, STUN passwords and 1740 transport protocols of its components, MUST be the same as the 1741 previous offer or answer from the agent. If the agent wants to 1742 change them, this is accomplished by changing the candidate ID as 1743 well. That will have the effect of removing the old candidate and 1744 adding a new one with the updated information. 1746 removed: A candidate is removed if its candidate ID appeared in a 1747 previous offer or answer, and that candidate ID is not present in 1748 the new offer. 1750 added: A candidate is added if its candidate ID appeared in the new 1751 offer, but was not present in a previous offer or answer from that 1752 agent. 1754 The following rules are used to determine the disposition of the each 1755 of the current native candidates in the new offer: 1757 o If a candidate is invalid, and all peer-derived candidates 1758 generated from it are invalid as well, it SHOULD be removed. 1760 o If the candidate in the m/c-line is valid, all other candidates 1761 SHOULD be removed. This has the effect of stopping connectivity 1762 checks of other candidates. This SHOULD would not be followed if 1763 an agent wanted to keep a candidate ready for usage should, for 1764 some reason, the active candidate later become invalid. 1766 o If the candidate in the m/c-line is valid, and it is not peer- 1767 derived, that candidate MUST be retained. If the candidate in the 1768 m/c-line is peer-derived, its generating candidate MUST be 1769 retained, even if it is itself invalid. 1771 o If the candidate in the m/c-line has not been validated, all other 1772 candidates that are not invalid, or candidates for whom their 1773 derived candidates are not invalid, SHOULD be retained. 1775 o Peer derived candidates MUST NOT be added; they continue to be 1776 used as long as their generating candidate was retained. Peer 1777 derived candidates are learned exclusively through the STUN 1778 connectivity checks. 1780 A new candidate MAY be added. This can happen when the candidate is 1781 a new one, learned since the previous offer/answer exchange, and it 1782 has a higher priority than the currently active candidate. It can 1783 also occur when an agent wishes to restart checks for a transport 1784 address it had tried previously. Effectively, changing the candidate 1785 ID value in an updated offer will "restart" connectivity checks for 1786 that candidate. 1788 If a candidate is removed, the agent takes the following steps: 1790 1. The agent eliminates any candidate pairs whose native candidate 1791 equalled the candidate that was removed. Equality is based on 1792 comparison of candidate IDs. 1794 2. The agent eliminates any candidate pairs that had a native 1795 candidate that is a peer derived candidate generated from the 1796 candidate that was removed. 1798 3. The candidate pairs that are eliminated are removed from the 1799 candidate pair priority ordered list and candidate pair check 1800 ordered list. As a consequence of this, if connectivity checks 1801 had not yet begun for the candidate pair, they won't. 1803 4. If connectivity checks were already in progress for transport 1804 addresses in that candidate pair, the agent SHOULD immediately 1805 terminate them. No further retransmissions take place, and no 1806 further transactions from that candidate will be made. 1808 5. If the removed candidate was a TURN-derived candidate, the agent 1809 SHOULD de-allocate its transport addresses from the TURN server. 1810 If a local candidate was removed, and all of its derived 1811 candidates were also removed (including any peer-derived 1812 candidates), local operating system resources for each of the 1813 transport addresses in the local candidate SHOULD be de- 1814 allocated. 1816 7.11.2 Receiving the Offer and Sending an Answer 1818 To generate the answer, the answerer has to decide which transport 1819 addresses to include in the m/c line, and which to include in 1820 candidate attributes. 1822 Rules for choosing transport addresses for the m/c-line are as 1823 follows. The agent examines the transport addresses in the m/c-line 1824 of the offer. It compares these with the transport addresses in the 1825 remote candidates of candidate pairs whose states are Valid. If 1826 there is matching candidate pair in that state, the agent MUST pick 1827 the native candidate from one of those pairs, and use that candidate 1828 as the active one. If none of the matching pairs are in the Valid 1829 state, the agent checks if there are any matching pairs in the Send- 1830 Valid state. If there are, the agent looks for the a=remote- 1831 candidate attribute in the offer. If present, and the candidate ID 1832 listed there is one of the native candidate IDs amongst the matching 1833 pairs, that candidate ID MUST be used as the active one. If the 1834 a=remote-candidate attribute was not present in the offer, or there 1835 were no matching candidate pairs in the Send-Valid state, the 1836 candidate that is most likely to work with this peer, as described in 1837 Section 7.2, SHOULD be used. 1839 The a=remote-candidate exists to eliminate a race condition between 1840 the updated offer and the response to the STUN Binding Request that 1841 moved a candidate into the valid state. If the answer arrives at the 1842 agent prior to the Binding Response, the candidate pair that was 1843 validated by the offer will still be in the Send-Valid state. To 1844 eliminate this condition, the identity of the validated candidate is 1845 included in the offer itself. 1847 Like the offerer, the answer can decide, for each of its candidates, 1848 whether they are retained or removed. The same rules defined in 1849 Section 7.11.1 for determining their disposition apply to the 1850 answerer. Similarly, if a candidate is removed, the same rules in 1851 Section 7.11.1 regarding removal of canididate pairs and freeing of 1852 resources apply. 1854 Once the answer is sent, the answerer will have the set of native and 1855 remote candidates before this offer/answer exchange, and the set of 1856 native and remote candidates afterwards. The agent then pairs up the 1857 native and remote candidates which were added or retained. 1858 Furthermore, for candidate pairs containing a peer derived transport 1859 address, those pairs continue as long as both candidates are 1860 retained. A peer derived candidate continues to be used as long as 1861 its generating parent continues to be used. This leads to a set of 1862 current candidate pairs. 1864 If a candidate pair existed previously, but as a consequence of the 1865 offer/answer exchange, either its native or remote candidate has been 1866 removed, the agent takes the following steps: 1868 1. The candidate pair is removed from the candidate pair priority 1869 ordered list and candidate pair check ordered list. As a 1870 consequence of this, if connectivity checks had not yet begun for 1871 the candidate pair, they won't. 1873 2. If connectivity checks were already in progress for that 1874 candidate pair, the agent SHOULD immediately terminate any STUN 1875 transactions in progress from that candidate. No further 1876 retransmissions take place, and no further transactions from that 1877 candidate will be made. 1879 3. If the agent receives a STUN Binding Request for that candidate 1880 pair, the agent SHOULD generate a 430 response. 1882 If a candidate pair existed previously, and continues to exist, no 1883 changes are made; any STUN transactions in progress for that 1884 candidate pair continue, and it remains on the candidate pair 1885 priority ordered list and candidate pair check ordered list. 1887 If a candidate pair is new (because either its native candidate is 1888 new, or its remote candidate is new, or both), the agent takes the 1889 role of answerer for this candidate pair. The new candidate pair is 1890 inserted into the candidate pair priority ordered list and candidate 1891 pair check ordered list. STUN connectivity checks will start for 1892 them based on the logic described in Section 7.6. 1894 7.11.3 Receiving the Answer 1896 Once the answer is received, the answerer will have the set of native 1897 and remote candidates before this offer/answer exchange, and the set 1898 of native and remote candidates afterwards. It then follows the same 1899 logic described in Section 7.11.2, pairing up the candidate pairs, 1900 removing ones that are no longer in use, and beginning of processing 1901 for ones that are new. 1903 7.12 Binding Keepalives 1905 Once a candidate is promoted to active, and media begins flowing, it 1906 is still necessary to keep the bindings alive at intermediate NATs 1907 for the duration of the session. Normally, the media stream packets 1908 themselves (e.g., RTP) meet this objective. However, several cases 1909 merit further discussion. Firstly, in some RTP usages, such as SIP, 1910 the media streams can be "put on hold". This is accomplished by 1911 using the SDP "sendonly" or "inactive" attributes, as defined in RFC 1912 3264 [5]. RFC 3264 directs implementations to cease transmission of 1913 media in these cases. However, doing so may cause NAT bindings to 1914 timeout, and media won't be able to come off hold. 1916 Secondly, some RTP payload formats, such as the payload format for 1917 text conversation [34], may send packets so infrequently that the 1918 interval exceeds the NAT binding timeouts. 1920 Thirdly, if silence suppression is in use, long periods of silence 1921 may cause media transmission to cease sufficiently long for NAT 1922 bindings to time out. 1924 To prevent these problems, ICE implementations MUST continue to list 1925 their active transport addresses in a=candidate lines for UDP-based 1926 media streams. As a consequence of this, STUN packets will be 1927 transmitted periodically independently of the transmission (or lack 1928 thereof) of media packets. This provides a media independent, RTP 1929 independent, and codec independent solution for keeping the NAT 1930 bindings alive. STUN Binding Requests cannot be used for TCP-based 1931 transports because the media protocol may not provide framing 1932 services to support this. As such, application layer keepalives MUST 1933 be used in this case. 1935 If an ICE implementation is communciating with one that does not 1936 support ICE, keepalives MUST still be sent. Indeed, these keepalives 1937 are essential even if neither endpoint implements ICE. As such, this 1938 specification defines keepalive behavior generally, for endpoints 1939 that support ICE, and those that do not. 1941 All endpoints MUST send keepalives for each media session. These 1942 keepalives MUST be sent regardless of whether the media stream is 1943 currently inactive, sendonly, recvonly or sendrecv. The keepalive 1944 SHOULD be sent using a format which is supported by its peer. ICE 1945 endpoints allow for STUN-based keepalives for UDP streams, and as 1946 such, STUN keepalives MUST be used when an agent is communicating 1947 with a peer that supports ICE. An agent can determine that its peer 1948 supports ICE by the presence of the a=candidate attributes for each 1949 media session. If the peer does not support ICE, the choice of a 1950 packet format for keepalives is a matter of local implementation. A 1951 format which allows packets to easily be sent in the absence of 1952 actual media content is RECOMMENDED. Examples of formats which 1953 readily meet this goal are RTP No-Op [29] and RTP comfort noise [27]. 1955 STUN-based keepalives will be sent periodically every Tr seconds as a 1956 consequence of the rules in in Section 7.7. If STUN keepalives are 1957 not in use (because the peer does not support ICE or because of TCP), 1958 an agent SHOULD ensure that a media packet is sent every Tr seconds. 1959 If one is not sent as a consequence of normal media communications, a 1960 keepalive packet using one of the formats discussed above SHOULD be 1961 sent. 1963 7.13 Sending Media 1965 An agent MUST NOT send media packets until the active candidate has 1966 entered either the Valid or Recv-Valid state. This is to prevent a 1967 particularly destructive denial-of-service attack described in 1968 Section 13.4.1. 1970 It is important to note that an agent always sends media to the 1971 address in the m/c-line, not to a validated candidate. To use a 1972 candidate, it must be promoted to the m/c-line through an updated 1973 offer/answer exchange. 1975 When an agent sends media packets, it MUST send them from the same IP 1976 address and port it has advertised in the m/c-line. This provides a 1977 property known as symmetry, which is an essential facet of NAT 1978 traversal. 1980 In the case of a STUN-derived transport address, this means that the 1981 RTP packets are sent from the local transport address used to obtain 1982 the STUN address. In the case of a TURN-derived transport address, 1983 this means that media packets are sent through the TURN server (using 1984 the TURN SEND primitive). For local transport addresses, media is 1985 sent from that local transport address. 1987 This symmetric behavior MUST be followed by an agent even if its peer 1988 in the session doesn't support ICE. 1990 8. Guidelines for Usage with SIP 1992 SIP [3] makes use of the offer/answer model, and is one of the 1993 primary targets for usage of ICE. SIP allows for offer/answer 1994 exchanges to occur in many different combinations of messages, 1995 including INVITE/200 OK and 200 OK/ACK. When support for reliable 1996 provisional responses (RFC 3262 [13]) and UPDATE (RFC 3311 [28]) are 1997 added, additional combinations of messages that can be used for 1998 offer/answer exchanges are added. As such, this section provides 1999 some guidance on good ways to make use of SIP with ICE. 2001 ICE requires a series of STUN-based connectivity checks to take place 2002 between endpoints, along with an updated offer/answer exchange to use 2003 a validated candidate. These exchanges require time to complete. If 2004 the initial offer/answer exchange were to take place in the INVITE 2005 and 200 OK response respectively, the connectivity checks and updated 2006 offer would all occur after the called party answered. This will 2007 result in a potential increase in the post-pickup delay. This delay 2008 refers to the time between when a user "answers the phone" and when 2009 any speech they utter can be delivered to the caller. 2011 To eliminate any increase in post-pickup delay due to ICE, it is 2012 RECOMMENDED that the initial offer/answer exchange take place in an 2013 INVITE and a 18x provisional response. As a consequence, support for 2014 RFC 3262 is RECOMMENDED with ICE. The STUN connectivity checks will 2015 then take place while the called party is being "rung". To deliver 2016 the updated offer prior to the user answering the call, it is 2017 RECOMMENDED that it be delivered with an UPDATE request. This will 2018 allow ICE to have completed prior to the called party even answering 2019 the session invitation. 2021 If RFC 3262 and RFC 3311 are not supported by both agents, tuning can 2022 still take place to reduce post-pickup delays. In particular, the 2023 answerer SHOULD include its answer in an unreliable 18x response. 2024 RFC 3261 requires that the same answer also be placed in a 200 OK, 2025 which is delivered reliably. However, placing it in a 18x gives the 2026 offerer an early preview of the answer, and allows the connectivity 2027 checks to all occur prior to the user answering the call. However, 2028 the updated offer with the highest priority valid candidate promoted 2029 to the m/c-line cannot occur until after the 200 OK, in which case it 2030 SHOULD be done with a re-INVITE. Fortunately, if the active 2031 candidates in the initial offer/answer exchange end up being valid 2032 anyway, media can flow as soon as the user answers the call (or even 2033 before hand, if early media is needed). The additional offer/answer 2034 exchange in the re-INVITE would merely improve the situation by using 2035 a higher priority candidate pair. 2037 One of the difficulties in including the answer in the 18x, and then 2038 using it for connectivity checks, is that the 18x might be lost. In 2039 such a case, the STUN connectivity check from the answerer to the 2040 offerer (UAS to UAC) will pend indefinitely. To prevent this, it is 2041 RECOMMENDED that a SIP UA retransmit its 18x periodically, using the 2042 same exponential backoff defined in RFC 3262, until such time as a 2043 Binding Response is received for any of the Binding Requests it sent. 2045 As discussed in Section 13, offer/answer exchanges SHOULD be secured 2046 against eavesdropping and man-in-the-middle attacks. To do that, the 2047 usage of SIPS is RECOMMENDED when used in concert with ICE. 2049 9. Interactions with Forking 2051 SIP allows INVITE requests carrying offers to fork, which means that 2052 they are delivered to multiple user agents. Each of those user 2053 agents then provides an answer to the offer in the INVITE. The 2054 result is that a single offer generated by the UAC produces multiple 2055 answers. 2057 ICE interacts very well with forking. Indeed, ICE fixes some of the 2058 problems associated with forking. Once the offer/answer exchange has 2059 completed, the UAC will have an answer from each UAS that received 2060 the INVITE. The ICE connectivity checks that ensue will carry 2061 transport address pair IDs that correlate each of those checks (and 2062 thus their corresponding IP addresses and ports) with a specific 2063 remote user agent. As these checks happen before any media is 2064 transmitted, ICE allows a UAC to disambiguate subsequent media 2065 traffic by looking at the source IP address and port, and then 2066 correlate that traffic with a particular remote UA. When SIP is used 2067 without ICE, the incoming media traffic cannot be disambiguated 2068 without an additional offer/answer exchange. 2070 10. Interactions with Preconditions 2072 Because ICE involves multiple addresses and pre-session activities, 2073 its interactions with preconditions merits further discussion. 2075 Quality of Service (QoS) preconditions, which are defined in RFC 3312 2076 [9] and RFC 4032 [10], apply only to the IP addresses and ports 2077 listed in the m/c lines in an offer/answer. If ICE changes the 2078 address and port where media is received, this change is reflected in 2079 the m/c lines of a new offer/answer. As such, it appears like any 2080 other re-INVITE would, and is fully treated in RFC 3312 and 4032, 2081 which applies without regard to the fact that the m/c lines are 2082 changing due to ICE negotiations ocurring "in the background". 2084 ICE also has (purposeful) interactions with connectivity 2085 preconditions [14]. Those interactions are described there. 2087 11. Example 2089 This section provides an example ICE call flow. Two agents, L and R, 2090 are using ICE. Both agents have a single IPv4 interface, and are 2091 configured with a single TURN and single STUN server each (indeed, 2092 the same one for each). As a consequence, each agent will end up 2093 with three candidates - a local candidate, a TURN-derived candidate, 2094 and a STUN-derived candidate. The agents are seeking to communicate 2095 using a single RTP-based voice stream. As a consequence, each 2096 candidate has two components - one for RTP and one for RTCP. Agent L 2097 is behind a symmetric NAT, and agent R is on the public Internet. 2099 To facilitate understanding, transport addresses are listed in a 2100 mnemonic form. This form is