idnits 2.17.1 draft-ietf-mmusic-ice-08.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 4376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4366. ** 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 16 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 14 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 484: '... SHOULD send media with the symmetri...' RFC 2119 keyword, line 515: '... SHOULD have the same number of comp...' RFC 2119 keyword, line 517: '...s in a candidate MUST be of the same t...' RFC 2119 keyword, line 520: '..., each component MUST be obtained from...' RFC 2119 keyword, line 522: '...a streams, it is RECOMMENDED that ther...' (150 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 (March 29, 2006) is 6602 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: '12' is defined on line 4238, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 4252, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 4296, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 4321, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3548 (ref. '3') (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 4234 (ref. '9') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3266 (ref. '10') (Obsoleted by RFC 4566) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-03 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-00 -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '15') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '16') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 2733 (ref. '18') (Obsoleted by RFC 5109) == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-connectivity-precon-01 == 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 (-08) exists of draft-ietf-behave-nat-udp-00 Summary: 9 errors (**), 0 flaws (~~), 13 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: September 30, 2006 March 29, 2006 6 Interactive Connectivity Establishment (ICE): A Methodology for Network 7 Address Translator (NAT) Traversal for Offer/Answer Protocols 8 draft-ietf-mmusic-ice-08 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 September 30, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 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 the Simple Traversal of UDP 46 through NAT (STUN), applying its binding discovery, connectivity 47 check and relay usages. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . 8 54 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . 11 55 5. Receipt of the Offer and Generation of the Answer . . . . . 11 56 6. Processing the Answer . . . . . . . . . . . . . . . . . . . 12 57 7. Common Procedures . . . . . . . . . . . . . . . . . . . . . 12 58 7.1 Gathering Candidates . . . . . . . . . . . . . . . . . . . 12 59 7.2 Prioritizing the Candidates and Choosing an Active One . . 18 60 7.3 Encoding Candidates into SDP . . . . . . . . . . . . . . . 20 61 7.4 Forming Candidate Pairs . . . . . . . . . . . . . . . . . 23 62 7.5 Ordering the Candidate Pairs . . . . . . . . . . . . . . . 25 63 7.6 Performing the Connectivity Checks . . . . . . . . . . . . 28 64 7.7 Sending a Binding Request for Connectivity Checks . . . . 32 65 7.8 Receiving a Binding Request for Connectivity Checks . . . 33 66 7.9 Promoting a Candidate to Active . . . . . . . . . . . . . 35 67 7.10 Learning New Candidates from Connectivity Checks . . . . 36 68 7.10.1 On Receipt of a Binding Request . . . . . . . . . . 36 69 7.10.2 On Receipt of a Binding Response . . . . . . . . . . 40 70 7.11 Subsequent Offer/Answer Exchanges . . . . . . . . . . . 42 71 7.11.1 Sending of a Subsequent Offer . . . . . . . . . . . 42 72 7.11.2 Receiving the Offer and Sending an Answer . . . . . 45 73 7.11.3 Receiving the Answer . . . . . . . . . . . . . . . . 47 74 7.12 Binding Keepalives . . . . . . . . . . . . . . . . . . . 48 75 7.13 Sending Media . . . . . . . . . . . . . . . . . . . . . 49 76 7.14 Receiving Media . . . . . . . . . . . . . . . . . . . . 51 77 8. Guidelines for Usage with SIP . . . . . . . . . . . . . . . 52 78 9. Interactions with Forking . . . . . . . . . . . . . . . . . 54 79 10. Interactions with Preconditions . . . . . . . . . . . . . . 54 80 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 55 81 11.1 Basic Example . . . . . . . . . . . . . . . . . . . . . 56 82 11.2 Advanced Example . . . . . . . . . . . . . . . . . . . . 60 83 12. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 80 84 13. Security Considerations . . . . . . . . . . . . . . . . . . 82 85 13.1 Attacks on Connectivity Checks . . . . . . . . . . . . . 82 86 13.2 Attacks on Address Gathering . . . . . . . . . . . . . . 85 87 13.3 Attacks on the Offer/Answer Exchanges . . . . . . . . . 86 88 13.4 Insider Attacks . . . . . . . . . . . . . . . . . . . . 86 89 13.4.1 The Voice Hammer Attack . . . . . . . . . . . . . . 86 90 13.4.2 STUN Amplification Attack . . . . . . . . . . . . . 86 91 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 87 92 14.1 candidate Attribute . . . . . . . . . . . . . . . . . . 87 93 14.2 remote-candidate Attribute . . . . . . . . . . . . . . . 87 94 14.3 ice-pwd Attribute . . . . . . . . . . . . . . . . . . . 88 95 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 88 96 15.1 Problem Definition . . . . . . . . . . . . . . . . . . . 89 97 15.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . 89 98 15.3 Brittleness Introduced by ICE . . . . . . . . . . . . . 90 99 15.4 Requirements for a Long Term Solution . . . . . . . . . 91 100 15.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . 91 101 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91 102 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 103 17.1 Normative References . . . . . . . . . . . . . . . . . . 92 104 17.2 Informative References . . . . . . . . . . . . . . . . . 93 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . 94 106 Intellectual Property and Copyright Statements . . . . . . . 96 108 1. Introduction 110 RFC 3264 [4] defines a two-phase exchange of Session Descrption 111 Protocol (SDP) messages [5] for the purposes of establishment of 112 multimedia sessions. This offer/answer mechanism is used by 113 protocols such as the Session Initiation Protocol (SIP) [2]. 115 Protocols using offer/answer are difficult to operate through Network 116 Address Translators (NAT). Because their purpose is to establish a 117 flow of media packets, they tend to carry IP addresses within their 118 messages, which is known to be problematic through NAT [17]. The 119 protocols also seek to create a media flow directly between 120 participants, so that there is no application layer intermediary 121 between them. This is done to reduce media latency, decrease packet 122 loss, and reduce the operational costs of deploying the application. 123 However, this is difficult to accomplish through NAT. A full 124 treatment of the reasons for this is beyond the scope of this 125 specification. 127 Numerous solutions have been proposed for allowing these protocols to 128 operate through NAT. These include Application Layer Gateways 129 (ALGs), the Middlebox Control Protocol [19], Simple Traversal of UDP 130 through NAT (STUN) [16] and its revision [13], the STUN Relay Usage 131 [14], and Realm Specific IP [20] [21] along with session description 132 extensions needed to make them work, such as the Session Description 133 Protocol (SDP) [5] attribute for the Real Time Control Protocol 134 (RTCP) [1]. Unfortunately, these techniques all have pros and cons 135 which make each one optimal in some network topologies, but a poor 136 choice in others. The result is that administrators and implementors 137 are making assumptions about the topologies of the networks in which 138 their solutions will be deployed. This introduces complexity and 139 brittleness into the system. What is needed is a single solution 140 which is flexible enough to work well in all situations. 142 This specification provides that solution for media streams 143 established by signaling protocols based on the offer-answer model. 144 It is called Interactive Connectivity Establishment, or ICE. ICE 145 makes use of STUN and its relay extension, commonly called TURN, but 146 uses them in a specific methodology which avoids many of the pitfalls 147 of using any one alone. 149 2. Terminology 151 Several new terms are introduced in this specification: 153 Agent: As defined in RFC 3264, an agent is the protocol 154 implementation involved in the offer/answer exchange. There are 155 two agents involved in an offer/answer exchange. 157 Peer: From the perspective of one of the agents in a session, its 158 peer is the other agent. Specifically, from the perspective of 159 the offerer, the peer is the answerer. From the perspective of 160 the answerer, the peer is the offerer. 162 Transport Address: The combination of an IP address and port. 164 Local Transport Address: A local transport address is a transport 165 address that has been allocated from the operating system on the 166 host. This includes transport addresses obtained through Virtual 167 Private Networks (VPNs) and transport addresses obtained through 168 Realm Specific IP (RSIP) [20] (which lives at the operating system 169 level). Transport addresses are typically obtained by binding to 170 an interface. 172 m/c line: The media and connection lines in the SDP, which together 173 hold the transport address used for the receipt of media. 175 Derived Transport Address: A derived transport address is a transport 176 address which is derived from a local transport address. The 177 derived transport address is related to the associated local 178 transport address in that packets sent to the derived transport 179 address are received on the socket bound to its associated local 180 transport address. Derived addresses are obtained using protocols 181 like STUN, and more generally, any UNSAF protocol [22]. 183 Reflexive Transport Address: As defined in [13], a transport address 184 learned by a client which identifies that client as seen by 185 another host on an IP network, typically a STUN server. When 186 there is an intervening NAT between the client and the other host, 187 the reflexive transport address represents the binding allocated 188 to the client on the public side of the NAT. Reflexive transport 189 addresses are learned from the XOR-MAPPED-ADDRESS attribute in 190 STUN Binding Responses and Allocate Responses [14], and are a type 191 of derived transport address. 193 Server Reflexive Transport Address: A server reflexive transport 194 address is a reflexive address that is reflected off of a server, 195 distinct from the peer, whose address is configured or learned by 196 the client prior to an offer/answer exchange. 198 Peer Reflexive Transport Address: A peer reflexive transport address 199 is a reflexive address that is reflected off of the peer. Peer 200 reflexive transport addresses are learned by connectivity checks. 202 Relayed Transport Address: A transport address that terminates on a 203 server, and is forwarded towards the client. The STUN Allocate 204 Request can be used to obtain a relayed transport address, for 205 example. 207 Associated Local Transport Address: When a peer sends a packet to a 208 transport address, the associated local transport address is the 209 local transport address at which those packets will actually 210 arrive. For a local transport address, its associated local 211 transport address is the same as the local transport address 212 itself. For reflexive and relayed transport addresses, however, 213 they are not the same. The associated local transport address is 214 the one from which the reflexive or relayed transport was derived. 216 Candidate: A sequence of transport addresses that form an atomic set 217 for usage with a particular media session. Here, atomic means 218 that all of transport addresses in the candidate need to work 219 before the candidate will be used for actual media transport. In 220 the case of RTP, there can be one or more transport addresses per 221 candidate. In the most common case, there are two - one for RTP, 222 and another for RTCP. If the agent doesn't use RTCP, there would 223 be just one. If Generic Forward Error Correction (FEC) [18] is in 224 use, there may be more than two. The transport addresses that 225 compose a candidate are all of the same type - local, server 226 reflexive, peer reflexive or relayed. 228 Local Candidate: A candidate whose transport addresses are local 229 transport addresses. 231 Server Reflexive Candidate: A candidate whose transport addresses are 232 server reflexive transport addresses. 234 Peer Reflexive Candidate: A candidate whose transport addresses are 235 peer reflexive transport addresses. 237 Relayed Candidate: A candidate whose transport addresses are relayed 238 transport addresses. 240 Generating Candidate: The candidate from which a peer reflexive 241 candidate is derived. 243 Active Candidate: The candidate that is in use for exchange of media. 244 This is the one that an agent places in the m/c line of an offer 245 or answer. 247 Candidate ID: An identifier for a candidate. 249 Component: When a media stream, and as a consequence, its candidate, 250 require several IP addresses and ports to work atomically, each of 251 the constituent IP addresses and ports represents a component of 252 that media stream. For example, RTP-based media streams typically 253 have two components - one for RTP, and one for RTCP. 255 Component ID: An integer, starting with one within each candidate and 256 incrementing by one for each component, which identifies the 257 component. 259 Transport Address ID (tid): An identifier for a transport address, 260 formed by concatenating the candidate ID with the component ID, 261 separated by a "colon". 263 Candidate Pair: The combination of a candidate from one agent along 264 with a candidate from its peer. 266 Native Candidate: From the perspective of each agent, the candidate 267 in a candidate pair which represents a set of addresses obtained 268 by that agent. 270 Remote Candidate: From the perspective of each agent, the candidate 271 in a candidate pair which represents the set of addresses obtained 272 by that agents peer. 274 Transport Address Pair: The combination of the transport address for 275 one component of a candidate with the transport address of the 276 same component for the matching candidate in a candidate pair. 278 Transport Address Pair ID: An identifier for a transport address 279 pair. Formed by concatenating the native transport address ID 280 with the remote transport address ID, separated by a "colon". 282 Matching Transport Address Pair: When a STUN Binding Request is 283 received on a local transport address, the matching transport 284 address pair is the transport address pair whose connectivity is 285 being checked by that Binding Request. 287 Candidate Pair Priority Ordering: An ordering of candidate pairs 288 based on a combination of the qvalues of each candidate and the 289 candidate IDs of each candidate. 291 Candidate Pair Check Ordering: An ordering of candidate pairs that is 292 similar to the candidate pair priority ordering, except that the 293 active candidate appears at the top of the list, regardless of its 294 priority. 296 Transport Address Pair Check Ordering: An ordering of transport 297 address pairs that determines the sequence of connectivity checks 298 performed for the pairs. 300 Transport Address Pair Count: The number of transport address pairs 301 in a candidate pair. This is equal to the minimum of the number 302 of transport addresses in the native candidate and the number of 303 transport addresses in the remote candidate. 305 3. Overview of ICE 307 ICE makes the fundamental assumption that clients exist in a network 308 of segmented connectivity. This segmentation is the result of a 309 number of addressing realms in which a client can simultaneously be 310 connected. We use "realms" here in the broadest sense. A realm is 311 defined purely by connectivity. Two clients are in the same realm 312 if, when they exchange the addresses each has in that realm, they are 313 able to send packets to each other. This includes IPv6 and IPv4 314 realms, which actually use different address spaces, in addition to 315 private networks connected to the public Internet through NAT. 317 The key assumption in ICE is that a client cannot know, apriori, 318 which address realms it shares with any peer it may wish to 319 communicate with. Therefore, in order to communicate, it has to try 320 connecting to addresses in all of the realms. 322 Agent A STUN Servers Agent B 323 |(1) Gather Addresses | | 324 |-------------------->| | 325 |(2) Offer | | 326 |------------------------------------------>| 327 | |(3) Gather Addresses | 328 | |<--------------------| 329 |(4) Answer | | 330 |<------------------------------------------| 331 |(5) STUN Check | | 332 |<------------------------------------------| 333 |(6) STUN Check | | 334 |------------------------------------------>| 335 |(7) Media | | 336 |<------------------------------------------| 337 |(8) Media | | 338 |------------------------------------------>| 339 |(9) Offer | | 340 |------------------------------------------>| 341 |(10) Answer | | 342 |<------------------------------------------| 344 Figure 1 346 The basic flow of operation for ICE is shown in Figure 1. Before the 347 offerer establishes a session, it obtains local transport addresses 348 from its operating system on as many interfaces as it has access to. 349 These interfaces can include IPv4 and IPv6 interfaces, in addition to 350 Virtual Private Network (VPN) interfaces or ones associated with 351 RSIP. It then obtains transport addresses for the media from each 352 interface. Though ICE can support any type of transport protocol, 353 this specification only defines mechanisms for UDP. In addition, the 354 agent obtains server reflexive and relayed transport addresses. 355 These are usually obtained through a single STUN Allocate request, 356 which provides both. These requests are paced at a fixed rate in 357 order to limit network load and avoid NAT overload. The local, 358 server reflexive and relayed transport addresses are formed into 359 candidates, each of which represents a possible set of transport 360 addresses that might be viable for a media stream. 362 Each candidate is listed in a set of a=candidate attributes in the 363 offer. Each candidate is given a priority. Priority is a matter of 364 local policy, but typically, lowest priority would be given to 365 relayed transport addresses. Each candidate is also assigned a 366 distinct ID, called a candidate ID. 368 The agent will choose one of its candidates as its active candidate 369 for inclusion in the connection and media lines in the offer. Media 370 can be sent to this candidate immediately following its validation. 371 Media can also be sent to a candidate that is not active but has been 372 validated. Media is not sent without validation in order to avoid 373 denial-of-service attacks. In particular, without ICE, an offerer 374 can send an offer to another agent, and list the IP address and port 375 of a target in the offer. If the agent is an automata that answers a 376 call automatically, it will do so and then proceed to send media to 377 the target. This provides substantial packet amplifications. ICE 378 fixes this by requiring that an agent never send media packets unless 379 it has sent a STUN message towards the target of the RTP packets, and 380 received a reply from that target Section 7.13. 382 The offer is then sent to the answerer. This specification does not 383 address the issue of how the signaling messages themselves traverse 384 NAT. It is assumed that signaling protocol specific mechanisms are 385 used for that purpose. The answerer follows a similar process as the 386 offerer followed; it obtains addresses from local interfaces, obtains 387 derived transport addresses from those, and then groups them into 388 candidates for inclusion in a=candidate attributes in the answer. It 389 picks one candidate as its active candidate and places it into the 390 m/c line in the answer. 392 Once the offer/answer exchange has completed, both agents pair up the 393 candidates, and then determine an ordered set of transport address 394 pairs. This ordering is based primarily on the priority of the 395 candidates, with the exception of the active candidate, whose 396 addresses are at the top of the list. Both agents start at the top 397 of this list, beginning a connectivity check for that transport 398 address pair. At a fixed interval, checks for the next transport 399 address on the list begin. This results in a pacing of the 400 connectivity checks. These connectivity checks are performed through 401 peer-to-peer STUN requests, sent from one agent to the other. In 402 addition to pacing the checks out at regular intervals, the offerer 403 will generate a connectivity check for a transport address pair when 404 it receives one from its peer. As soon as the active candidate has 405 been verified by the STUN checks, media can begin to flow. Once a 406 higher priority candidate has been verified by the offerer, it ceases 407 additional connectivity checks, begins using that candidate for 408 media, and sends an updated offer which promotes this higher priority 409 candidate to the m/c-line. That candidate is also listed in 410 a=candidate attributes, resulting in periodic STUN keepalives through 411 the duration of the media session. 413 If an agent receives a STUN connectivity check with a new source IP 414 address and port, or a response to such a check with a new reflexive 415 transport address (obtained from the XOR-MAPPED-ADDRESS attribute), 416 this new address might be a viable candidate for the receipt of 417 media. This happens when there is a NAT with an address dependent or 418 address and port dependent mapping property [37] between the agents. 419 In such a case, the agents algorithmically construct a new candidate. 420 Like other candidates, connectivity checks begin for it, and if they 421 succeed, its transport addresses can be used for receipt of media by 422 promoting it to the m/c-line. 424 The gathering of addresses and connectivity checks take time. As a 425 consequence, in order to have minimal impact on the call setup time 426 or post-pickup delay for SIP, these offer/answer exchanges and checks 427 happen while the call is ringing. 429 4. Sending the Initial Offer 431 When an agent wishes to begin a session by sending an initial offer, 432 it starts by gathering transport addresses, as described in 433 Section 7.1. This will produce a set of candidates, including local 434 ones, server reflexive ones, and relayed ones. 436 This process of gathering candidates can actually happen at any time 437 before sending the initial offer. A agent can pre-gather transport 438 addresses, using a user interface cue (such as picking up the phone, 439 or entry into an address book) as a hint that communications is 440 imminent. Doing so eliminates any additional perceivable call setup 441 delays due to address gathering. 443 When it comes time to offer communications, the agent determines a 444 priority for each candidate and identifies the active candidate that 445 will be used for receipt of media, as described in Section 7.2. 447 The next step is to construct the offer message. For each media 448 stream, it places its candidates into a=candidate attributes in the 449 offer and puts its active candidate into the m/c line. The process 450 for doing this is described in Section 7.3. The offer is then sent. 452 5. Receipt of the Offer and Generation of the Answer 454 Upon receipt of the offer message, the agent checks if the offer 455 contains any a=candidate attributes. If the offer does, the offerer 456 supports ICE. In that case, it starts gathering candidates, as 457 described in Section 7.1, and prioritizes them as described in 458 Section 7.2. This processing is done immediately on receipt of the 459 offer, to prepare for the case where the user should accept the call, 460 or early media needs to be generated. By gathering candidates (and 461 performing connectivity checks) while the user is being alerted to 462 the request for communications, session establishment delays are 463 reduced. 465 The agent then constructs its answer, encoding its candidates into 466 a=candidate attributes and including the active one in the m/c-line, 467 as described in Section 7.3. The agent then forms candidate pairs as 468 described in Section 7.4. These are ordered as described in 469 Section 7.5. The agent then begins connectivity checks, as described 470 in Section 7.6. It follows the logic in Section 7.10 on receipt of 471 Binding Requests and responses to learn new candidates from the 472 checks themselves. 474 Transmission of media is performed according to the procedures in 475 Section 7.13. 477 6. Processing the Answer 479 There are two possible cases for processing of the answer. If the 480 answerer did not support ICE, the answer will not contain any 481 a=candidate attributes. As a result, the offerer knows that it 482 cannot perform its connectivity checks. In this case, it proceeds 483 with normal media processing as if ICE was not in use. However, it 484 SHOULD send media with the symmetric property described in 485 Section 7.13, and follow the keepalive procedures in Section 7.12. 487 If the answer contains candidates, it implies that the answerer 488 supports ICE. The offerer then forms candidate pairs as described in 489 Section 7.4. These are ordered as described in Section 7.5. The 490 agent then begins connectivity checks, as described in Section 7.6. 491 It follows the logic in Section 7.10 on receipt of Binding Requests 492 and responses to learn new candidates from the checks themselves. 494 Transmission of media is performed according to the procedures in 495 Section 7.13. 497 7. Common Procedures 499 This section discusses procedures that are common between offerer and 500 answerer. 502 7.1 Gathering Candidates 504 An agent gathers candidates when it believes that communications is 505 imminent. For offerers, this occurs before sending an offer 506 (Section 4). For answerers, it occurs before sending an answer 507 (Section 5). 509 Each candidate has one or more components, each of which is 510 associated with a sequence number, starting at 1 for the first 511 component of each candidate, and incrementing by 1 for each 512 additional component within that candidate. These components 513 represent a set of transport addresses for which connectivity must be 514 validated. For a particular media stream, all of the candidates 515 SHOULD have the same number of components. The number of components 516 that are needed are a function of the type of media stream. All of 517 the components in a candidate MUST be of the same type - server 518 reflexive, relayed, or local, and obtained from the same server in 519 the case of server reflexive or relayed candidates. For local 520 candidates, each component MUST be obtained from the same interface. 522 For traditional RTP-based media streams, it is RECOMMENDED that there 523 be two components per candidate - one for RTP and one for RTCP. The 524 component with the component ID of 1 MUST be RTP, and the one with 525 component ID of 2 MUST be RTCP. If an agent doesn't implement RTCP, 526 it SHOULD have a single component for the RTP stream (which will have 527 a component ID of 1 by definition). Each component of a candidate 528 has a single transport address. 530 The first step is to gather local candidates. Local candidates are 531 obtained by binding to ephemeral ports on an interface (physical or 532 virtual, including VPN interfaces) on the host. The process for 533 gathering local candidates depends on the transport protocol. 534 Procedures are specified here for UDP. Extensions to ICE that define 535 procedures for other transport protocols MUST specify how local 536 transport addresses are gathered. 538 For each UDP media stream the agent wishes to use, the agent SHOULD 539 obtain a set of candidates (one for each interface) by binding to N 540 ephemeral UDP ports on each interface, where N is the number of 541 components needed for the candidate. For RTP, N is typically two. 542 If a host has K local interfaces, this will result in K candidates 543 for each UDP stream, requiring K*N local transport addresses. 545 Once the agent has obtained local candidates, it obtains candidates 546 with derived transport addresses. The process for gathering derived 547 candidates depends on the transport protocol. Procedures are 548 specified here for UDP. Extensions to ICE that define procedures for 549 other transport protocols MUST specify how derived transport 550 addresses are gathered. 552 Agents which serve end users directly, such as softphones, 553 hardphones, terminal adapters and so on, MUST implement the STUN 554 Binding Discovery usage and SHOULD use it to obtain server reflexive 555 candidates. These devices SHOULD implement the STUN Relay usage, and 556 SHOULD use its Allocate request to obtain both server reflexive and 557 relayed candidates. They MAY implement and MAY use other protocols 558 that provide server reflexive or relayed transport addresses, such as 559 TEREDO [33]. 561 The requirement to use the relay Usage is at SHOULD strength to allow 562 for provider variation. If it is not to be used, it is RECOMMENDED 563 that it be implemented and just disabled through configuration, so 564 that it can re-enabled through configuration if conditions change in 565 the future. 567 Agents which represent network servers under the control of a service 568 provider, such as gateways to the telephone network, media servers, 569 or conferencing servers that are targeted at deployment only in 570 networks with public IP addresses MAY use the STUN Binding Discovery 571 usage and relay usage, or other similar protocols to obtain 572 candidates. 574 Why would these types of endpoints even bother to implement ICE? 575 The answer is that such an implementation greatly facilitates NAT 576 traversal for clients that connect to it. The ability to process 577 STUN connectivity checks allows for clients to obtain peer 578 reflexive transport addresses that can be used by the network 579 server to reach them without a relay, even through NATs with 580 restrictive mapping and filtering policies. Furthermore, 581 implementation of the STUN connectivity checks allows for NAT 582 bindings along the way to be kept open. ICE also provides 583 numerous security properties that are independent of NAT 584 traversal, and would benefit any multimedia endpoint. See 585 Section 13 for a discussion on these benefits. 587 Obtaining derived candidates requires transmission of packets which 588 have the effect of creating bindings on NAT devices between the 589 client and the STUN servers. Experience has shown that many NAT 590 devices have upper limits on the rate at which they will create new 591 bindings. Furthermore, transmission of these packets on the network 592 makes use of bandwidth and needs to be rate limited by the agent. As 593 a consequence, a client SHOULD pace its STUN transactions, such that 594 the start of each new transaction occurs at least Ta seconds after 595 the start of the previous transaction. The value of Ta SHOULD be 596 configurable, and SHOULD have a default of 50ms. Note that this 597 pacing applies only to the start of a new transaction; pacing of 598 retransmissions within a STUN transaction is governed by the 599 retransmission rules defined by STUN. 601 Derived candidates can be obtained from the STUN Binding Discovery 602 usage or the STUN Relay usage. The latter is preferred since it will 603 provide the client with both a server reflexive and a relayed 604 transport address with a single transaction. It is possible that 605 some STUN servers will only support the Relay usage or only the 606 Binding Discovery usage, in which case a client might be configured 607 with different servers depending on the usage. 609 To obtain both server reflexive and relayed candidates using the STUN 610 Relay Usage, the client takes a local UDP candidate, and for each 611 configured STUN server, produces both candidates. It is anticipated 612 that clients may have a multiplicity of STUN servers configured or 613 discovered in network environments where there are multiple layers of 614 NAT, and that layering is known to the provider of the client. To 615 obtain these candidates, for each configured STUN server, the client 616 initiates an Allocate Request transaction using the procedures of 617 Section 8.1.2 of [14] from each transport address of a particular 618 local candidate. The Allocate Response will provide the client with 619 its server reflexive transport address (obtained from the XOR-MAPPED- 620 ADDRESS attribute) and its relayed transport address in the RELAY- 621 ADDRESS attribute. Once the Allocate requests have given a client a 622 relayed transport address for all transport addresses in a relayed 623 candidate, there is no reason for a client to obtain further relayed 624 candidates through the same STUN server. Thus, if there are other 625 local candidates from which the client has not yet obtained relayed 626 transport address, the client SHOULD NOT bother to obtain them. 627 Instead, it SHOULD use the STUN Binding Discovery usage and obtain 628 just server reflexive addresses from that STUN server. The order in 629 which local candidates are tried against the STUN server to obtain 630 relayed candidates is a matter of local policy. 632 To obtain server reflexive candidates using the STUN Binding 633 Discovery usage, the client takes a local UDP candidate, and for each 634 configured STUN server, produces a server reflexive candidate. To 635 produce the server reflexive candidate from the local candidate, it 636 follows the procedures of Section 12.2 of [13] for each local 637 transport address in the local candidate. The Binding Response will 638 provide the client with its server reflexive transport address. If 639 the client had K local candidates, this will produce S*K server 640 reflexive candidates, where S is the number of STUN servers. 642 Since a client will pace its STUN transactions (both Binding and 643 Allocate requests) at a total rate of one new transaction every Ta 644 seconds, it will take a certain amount of time to complete the 645 address gathering phase. It is RECOMMENDED that implementations have 646 a configurable upper bound on the total amount of time allotted to 647 address gathering. Any transactions not completed at that point 648 SHOULD be abandoned, but MAY continue and be used in an updated offer 649 once they complete. A default value of 5s is RECOMMENDED. Since the 650 total number of allocations that could be done (based on the number 651 of STUN servers and local interfaces) might exceed this value, 652 clients SHOULD prioritize their local candidates and STUN servers, 653 performing transactions from the highest priority local candidates to 654 the highest priority STUN servers first. A STUN server would 655 typically be higher priority if it supports the STUN Relay Usage, 656 since such a server provides two transport addresses with one 657 transaction. 659 Once the allocations are complete, any redundant candidates are 660 discarded. Candidate A is redundant with candidate B if the 661 transport addresses for each component of each component match, and 662 each component of their associated local candidates match. For 663 example, consider a set of candidates with a single component. One 664 candidate is a local candidate, and its one component has a transport 665 address of 10.0.1.1:4458. A reflexive transport address is derived 666 from this local transport address, producing a 10.0.1.1:4458. These 667 two candidates are identical, and also have identical associated 668 local transport addresses, so they are redundant. 670 +----------+ 671 | STUN Srvr| 672 +----------+ 673 | 674 | 675 ----- 676 // \\ 677 | | 678 | B:net10 | 679 | | 680 \\ // 681 ----- 682 | 683 | 684 +----------+ 685 | NAT | 686 +----------+ 687 | 688 | 689 ----- 690 // \\ 691 | A | 692 |192.168/16 | 693 | | 694 \\ // 695 ----- 696 | 697 | 698 |192.168.1.1 ----- 699 +----------+ // \\ +----------+ 700 | | | | | | 701 | Offerer |---------| C:net10 |---------| Answerer | 702 | |10.0.1.1 | | 10.0.1.2 | | 703 +----------+ \\ // +----------+ 704 ----- 706 Figure 2 708 Consider the more complicated case of Figure 2. In this case, the 709 offerer is multi-homed. It has one interface, 10.0.1.1, on network 710 C, which is a net 10 private network. The Answerer is on this same 711 network. The offerer is also connected to network A, which is 712 192.168/16. The offerer has an interface of 192.168.1.1 on this 713 network. There is a NAT on this network, natting into network B, 714 which is another net10 private network, but not connected to network 715 C. There is a STUN server on network B. 717 The offerer obtains local transport address on its interface on 718 network C (10.0.1.1:2498) and a local transport address on its 719 interface on network A (192.168.1.1:3344). It performs a STUN query 720 to its configured STUN server from 192.168.1.1:3344. This query 721 passes through the NAT, which happens to assign the binding 10.0.1.1: 722 2498. The STUN server reflects this in the STUN Binding Response. 723 Now, the offerer has obtained a candidate with a transport address it 724 already has (10.0.1.1:2498), but from a new interface. It therefore 725 keeps it. When it performs its connectivity checks, the offerer will 726 end up sending packets from both interfaces, and those sent from its 727 interface on network C will succeed. 729 7.2 Prioritizing the Candidates and Choosing an Active One 731 The prioritization process takes the set of candidates and associates 732 each with a priority. This priority reflects the desire that the 733 agent has to receive media at that candidate, and is assigned as a 734 value from 0 to 1 (1 being most preferred). Priorities are ordinal, 735 so that their significance is only meaningful relative to other 736 candidates from that agent for a particular media stream. Candidates 737 MAY have the same priority. However, it is RECOMMENDED that each 738 candidate have a distinct priority. Doing so improves the efficiency 739 of ICE. 741 This specification makes no normative statements on how the 742 prioritization is done. However, some useful guidelines are 743 suggested on how such a prioritization can be determined. 745 One criteria for choosing one candidate over another is whether or 746 not that candidate involves the use of an intermediary. That is, if 747 media is sent to that candidate, will the media first transit an 748 intermediate server before being received. Relayed candidates are 749 clearly one type of candidates that involve an intermediary. Another 750 are local candidates associated with a VPN server. When media is 751 transited through an intermediary, it can increase the latency 752 between transmission and reception. It can increase the packet 753 losses, because of the additional router hops that may be taken. It 754 may increase the cost of providing service, since media will be 755 routed in and right back out of an intermediary run by the provider. 756 If these concerns are important, candidates with this property can be 757 listed with lower priority. 759 Another criteria for choosing one candidate over another is IP 760 address family. ICE works with both IPv4 and IPv6. It therefore 761 provides a transition mechanism that allows dual-stack hosts to 762 prefer connectivity over IPv6, but to fall back to IPv4 in case the 763 v6 networks are disconnected (due, for example, to a failure in a 764 6to4 relay) [25]. It can also help with hosts that have both a 765 native IPv6 address and a 6to4 address. In such a case, higher 766 priority could be afforded to the native v6 address, followed by the 767 6to4 address, followed by a native v4 address. This allows a site to 768 obtain and begin using native v6 addresses immediately, yet still 769 fallback to 6to4 addresses when communicating with agents in other 770 sites that do not yet have native v6 connectivity. 772 Another criteria for choosing one candidate over another is security. 773 If a user is a telecommuter, and therefore connected to their 774 corporate network and a local home network, they may prefer their 775 voice traffic to be routed over the VPN in order to keep it on the 776 corporate network when communicating within the enterprise, but use 777 the local network when communicating with users outside of the 778 enterprise. 780 Another criteria for choosing one address over another is topological 781 awareness. This is most useful for candidates that make use of 782 relays. In those cases, if an agent has preconfigured or dynamically 783 discovered knowledge of the topological proximity of the relays to 784 itself, it can use that to select closer relays with higher priority. 786 There may be transport-specific reasons for preferring one candidate 787 over another. In such a case, specifications defining usage of ICE 788 with other transport protocols SHOULD document such considerations. 790 Once the candidates have been prioritized, one may be selected as the 791 active one. This is the candidate that will be used for actual 792 exchange of media if and when its validated, until a higher priority 793 candidate is validated. The active candidate will also be used to 794 receive media from ICE-unaware peers. As such, it is RECOMMENDED 795 that one be chosen based on the likelihood of that candidate to work 796 with the peer that is being contacted. Unfortunately, it is 797 difficult to ascertain which candidate that might be. As an example, 798 consider a user within an enterprise. To reach non-ICE capable 799 agents within the enterprise, a local candidate has to be used, since 800 the enterprise policies may prevent communication between elements 801 using a relay on the public network. However, when communicating to 802 peers outside of the enterprise, a relayed candidate from a 803 publically accessible STUN server is needed. 805 Indeed, the difficulty in picking just one address that will work is 806 the whole problem that motivated the development of this 807 specification in the first place. As such, it is RECOMMENDED that 808 the active candidate be a relayed candidate from a STUN server 809 providing public IP addresses in response to an Allocate request. 810 Furthermore, ICE is only truly effective when it is supported on both 811 sides of the session. It is therefore most prudent to deploy it to 812 close-knit communities as a whole, rather than piecemeal. In the 813 example above, this would mean that ICE would ideally be deployed 814 completely within the enterprise, rather than just to parts of it. 816 An additional consideration for selection of the active candidate is 817 the switching of media stream destinations between the initial offer 818 and the subsequent offer. If the active candidate pair in the 819 initial offer is being validated, media will flow to that pair once 820 it is validated. When the ICE checks complete and yield a higher 821 priority candidate pair, media will begin to flow to it (there will 822 also be an updated offer/answer exchange that changes the active 823 candidate). This will result in a change in the destination of the 824 media packets. This may also cause a different path for the media 825 packets. That path might have different delay and jitter 826 characteristics. As a consequence, the jitter buffers may see a 827 glitch, causing possible media artifacts. If these issues are a 828 concern, the initial offer MAY omit an active candidate. In such a 829 case, an updated offer will need to be sent immediately when 830 communicating with an ICE-unaware agent, setting an active candidate. 832 There may be transport-specific reasons for selection of an active 833 candidate. In such a case, specifications defining usage of ICE with 834 other transport protocols SHOULD document such considerations. 836 7.3 Encoding Candidates into SDP 838 For each candidate for a media stream, the agent includes a series of 839 a=candidate attributes as media-level attributes, one for each 840 component in the candidate. Each candidate has a unique identifier, 841 called the candidate-id. The candidate-id MUST be chosen randomly 842 and contain at least 24 bits of randomness (this does not mean that 843 the candidate-id is 24 bits long; just that it has at least 24 bits 844 of randomness). It is chosen only when the candidate is placed into 845 the SDP for the first time; subsequent offers or answers within the 846 same session containing that same candidate MUST use the same 847 candidate-id used previously. 24 bits is sufficient because the 848 candidate-id is not providing security (the much more random password 849 is). It is needed only to prevent a possible simultaneous selection 850 by two agents within a private network for the useful lifetime of the 851 software or hardware. 853 Each component of the candidate has an identifier, called the 854 component-id. The component-id is a sequence number. For each 855 candidate, it starts at one, and increments by one for each 856 component. As discussed below, ICE will perform connectivity checks 857 such that, between a pair of candidates, checks only occur between 858 transport addresses with the same component-id. As a consequence, if 859 one candidate has three components, and it is paired with a candidate 860 that has two, there will only be two transport address pairs and two 861 connectivity checks. 863 ICE will work without a standardized mapping between the components 864 of a media stream and the numerical value of the component-id. This 865 allows ICE to be used with media streams with multiple components 866 without development of standards around such a mapping. However, a 867 specific mapping has been defined in this specification for RTP - 868 component-id 1 corresponds to RTP, and component-id of 2 corresponds 869 to RTCP. Like the candidate-id, the component-id is assigned at the 870 time the candidate is first placed into the SDP; subsequent offers or 871 answers within the same session containing that same candidate MUST 872 use the same component-id used previously. 874 The transport, addr and port of the a=candidate attribute (all 875 defined in Section 12) are set to the transport protocol, unicast 876 address and port of the tranport address. A Fully Qualified Domain 877 Name (FQDN) for a host MAY be used in place of a unicast address. In 878 that case, when receiving an offer or answer containing an FQDN in an 879 a=candidate attribute, the FQDN is looked up in the DNS using an A or 880 AAAA record, and the resulting IP address is used for the remainder 881 of ICE processing. The qvalue is set to the priority of the 882 candidate, and MUST be the same for all components of the candidate. 884 All of the candidates for a media stream share a password that is 885 used for securing the STUN connectivity checks. Furthermore, the 886 password for candidates for different media streams MAY be the same, 887 or MAY be different. This password MUST be chosen randomly with 128 888 bits of randomness (though it can be longer than 128 bits). This 889 password is contained in the a=ice-pwd attribute, present as a 890 session or media level attribute. New passwords MUST be selected for 891 each new session, even if the transport address from a previous 892 session was being recycled. 894 The combination of candidate-id and component-id uniquely identify 895 each transport address. As a consequence, each transport address has 896 a unique identifier, called the tid. The tid is formed by 897 concatenating the candidate-id with the component-id, separated by 898 the colon (":"). The tid is not explicitly encoded in the SDP; it is 899 derived from the candidate-id and component-id, which are present in 900 the SDP. The usage of the colon as a separator allows the 901 candidate-id and component-id to be extracted from the tid, since the 902 colon is not a valid character for the candidate-id. 904 The tid gets combined, through further concatenation, with the tid of 905 a transport address from the remote candidate (separated again by 906 another colon) to form the username that is placed in the STUN checks 907 between the peers. This allows the STUN message to uniquely identify 908 the pairing whose connectivity it is checking. The tid is needed as 909 a unique identifier because the IP address within the candidate fails 910 to provide that uniqueness as a consequence of NAT. 912 Consider agents A, B, and C. A and B are within private enterprise 1, 913 which is using 10.0.0.0/8. C is within private enterprise 2, which 914 is also using 10.0.0.0/8. As it turns out, B and C both have IP 915 address 10.0.1.1. A sends an offer to C. C, in its answer, provides 916 A with its transport addresses. In this case, thats 10.0.1.1:8866 917 and 8877. As it turns out, B is in a session at that same time, and 918 is also using 10.0.1.1:8866 and 8877. This means that B is prepared 919 to accept STUN messages on those ports, just as C is. A will send a 920 STUN request to 10.0.1.1:8866 and 8877. However, these do not go to 921 C as expected. Instead, they go to B. If B just replied to them, A 922 would believe it has connectivity to C, when in fact it has 923 connectivity to a completely different user, B. To fix this, tid 924 takes on the role of a unique identifier. C provides A with an 925 identifier for its transport address, and A provides one to C. A 926 concatenates these two identifiers (with a colon between) and uses 927 the result as the username in its STUN query to 10.0.1.1:8866. This 928 STUN query arrives at B. However, the username is unknown to B, and 929 so the request is rejected. A treats the rejected STUN request as if 930 there were no connectivity to C (which is actually true). Therefore, 931 the error is avoided. 933 An unfortunate consequence of the non-uniqueness of IP addresses is 934 that, in the above example, B might not even be an ICE agent. It 935 could be any host, and the port to which the STUN packet is directed 936 could be any ephemeral port on that host. If there is an application 937 listening on this socket for packets, and it is not prepared to 938 handle malformed packets for whatever protocol is in use, the 939 operation of that application could be affected. Fortunately, since 940 the ports exchanged in SDP are ephemeral and ususally drawn from the 941 dynamic or registered range, the odds are good that the port is not 942 used to run a server on host B, but rather is the agent side of some 943 protocol. This decreases the probability of hitting a port in-use, 944 due to the transient nature of port usage in this range. However, 945 the possibility of a problem does exist, and network deployers should 946 be prepared for it. Note that this is not a problem specific to ICE; 947 stray packets can arrive at a port at any time for any type of 948 protocol, especially ones on the public Internet. As such, this 949 requirement is just restating a general design guideline for Internet 950 applications - be prepared for unknown packets on any port. 952 The active candidate, if there is one, is placed into the m/c lines 953 of the SDP. For RTP streams, this is done by placing the RTP address 954 and port into the c and m lines in the SDP respectively. If the 955 agent is utilizing RTCP, it MUST encode its address and port using 956 the a=rtcp attribute as defined in RFC 3605 [1]. If RTCP is not in 957 use, the agent MUST signal that using b=RS:0 and b=RR:0 as defined in 958 RFC 3556 [6]. 960 If there is no active candidate, the agent MUST include an a=inactive 961 attribute. The RTP address and port in the m/c-line is 962 inconsequential, since it won't be used. 964 Encoding of candidates may involve transport protocol specific 965 considerations. There are none for UDP. However, extensions that 966 define usage of ICE with other transport protocols SHOULD specify any 967 special encoding considerations. 969 Once an offer or answer are sent, an agent MUST be prepared to 970 receive both STUN and media packets on each candidate. As discussed 971 in Section 7.13, media packets can be sent to a candidate prior to 972 its promotion to active. 974 7.4 Forming Candidate Pairs 976 Once the offer/answer exchange has completed, both agents will have a 977 set of candidates for each media stream. Each agent forms a set of 978 candidate pairs for each media stream by combining each of its 979 candidates with each of the candidates of its peer. Candidates can 980 be paired up only if their transport protocols are identical. If an 981 offer/answer exchange took place for a session comprised of an audio 982 and a video stream, and each agent had two candidates per media 983 stream, there would be 8 candidate pairs, 4 for audio and 4 for 984 video. One agent can offer two candidates for a media stream, and 985 the answer can contain three candidates for the same media stream. 986 In that case, there would be six candidate pairs. 988 Each candidate has a number of components, each of which has a 989 transport address. Within a candidate pair, the components 990 themselves are paired up such that transport addresses with the same 991 component ID are combined to form a transport address pair. 992 Returning to the previous example, for each of the 8 candidate pairs, 993 there would be two transport address pairs - one for RTP, and one for 994 RTCP. If one candidate has more components than the other, those 995 extra components will not be part of a transport address pair, won't 996 be validated, and will effectively be treated as if they weren't 997 included in the candidate pair in the first place. 999 The relationship between a candidate, candidate pair, transport 1000 address, transport address pair and component are shown in Figure 3. 1001 This figure shows the relationships as seen by the agent that owns 1002 the candidate with candidate ID "L". This candidate has two 1003 components with transport addresses A and B respectively. This 1004 candidate is called the native candidate, since it is the one owned 1005 by the agent in question. The candidate owned by its peer is called 1006 the remote candidate. As the figure shows, there is a single 1007 candidate pair, and two components in each candidate. The native 1008 candidate has a candidate-id of "L", and the remote candidate has a 1009 candidate-id of "R". Since the two component-ids are 1 and 2, 1010 candidate "L" has two transport addresses with transport address IDs 1011 of "L:1" and "L:2" respectively. Similarly, candidate "R" has two 1012 transport addresses with transport address IDs of "R:1" and "R:2" 1013 respectively. 1015 Furthermore, each transport address pair is associated with an ID, 1016 the transport address pair ID. This ID is equal to the concatenation 1017 of the tid of the native transport address with the tid of the remote 1018 transport address, separated by a colon. This means that the 1019 identifiers are seen differenly for each agent. For the agent that 1020 owns candidate "L", there are two transport address pairs. One 1021 contains transport address "L:1" and "R:1", with a transport address 1022 pair ID of "L:1:R:1". The other contains transport address "L:2" and 1023 "R:2", with a transport address pair ID of "L:2:R:2". For the agent 1024 that owns candidate "R", the identifiers for these two transport 1025 address pairs are reversed; it would be "R:1:L:1" for the first one 1026 and "R:2:L:2" for the second. 1028 ............................................... 1029 . . 1030 . . 1031 . ............. ............. . 1032 . . tid=L:1 . . tid=R:1 . . 1033 . . -- . . -- . . component 1034 component. . | A|------------------------| C| . . id=1 1035 id=1 . . -- . Transport . -- . . 1036 . . . Address . . . 1037 . . . Pair . . . 1038 . . . id=L:1:R:1 . . . 1039 . . . . . . 1040 . . . . . . 1041 . . tid=L:2 . . tid=R:2 . . 1042 component . . -- . . -- . . 1043 id=2 . . | B|------------------------| D| component 1044 . . -- . Transport . -- . . id=2 1045 . . . Address . . . 1046 . . . Pair . . . 1047 . . . id=L:2:R:2 . . . 1048 . . . . . . 1049 . ............. ............. . 1050 . Native Remote . 1051 . Candidate Candidate . 1052 . id=L id=R . 1053 . . 1054 . . 1055 ............................................... 1057 Candidate Pair 1059 Figure 3 1061 If a candidate pair was created as a consequence of an offer 1062 generated by an agent, then that agent is said to be the offerer of 1063 that candidate pair and all of its transport address pairs. 1064 Similarly, the other agent is said to be the answerer of that 1065 candidate pair and all of its transport address pairs. As a 1066 consequence, each agent has a particular role, either offerer or 1067 answerer, for each transport address pair. This role is important; 1068 when a candidate pair is to be promoted to active, the offerer is the 1069 one which performs the updated offer. 1071 7.5 Ordering the Candidate Pairs 1073 For the same reason that the STUN transactions during address 1074 gathering are paced at a rate of Ta transactions per second, so too 1075 are the connectivity checks paced, also at a rate of Ta transactions 1076 per second. However, in order to rapidly converge on a valid 1077 candidate pair that is mutually desirable, the candidate pairs are 1078 ordered, and the checks start with the candidate pair at the top of 1079 the list. Rapid convergence of ICE depends on both the offerer and 1080 answerer coming to the same conclusion on the ordering of candidate 1081 pairs. 1083 Recall that when each candidate is encoded into SDP, it contains a 1084 qvalue between 1 and 0, with 1 being the highest priority. Peer 1085 reflexive candidates, learned through the procedures described in 1086 Section 7.10 also have a priority between 0 and 1. For each media 1087 stream, the native candidates are ordered based on their qvalues, 1088 with higher q-values coming first. Amongst candidates with the same 1089 qvalue, they are ordered based on candidate ID, using reverse 1090 lexicographic order, where C1 is placed before C2, if C2 precedes C1 1091 lexicographically. Lexicographic order can be viewed as a numerical 1092 ordering where each "digit" is actually a number in numerical base 1093 256, with the mapping of characters to numerical value being defined 1094 by their ASCII encoding. For example, the candidate with candidate 1095 ID agD is greater than the candidate with ID ad7, and both of those 1096 are greater than the candidate with ID zz. Consequently, if these 1097 three candidates had equal q-values, they would be ordered as agD, 1098 ad7, zz - reverse of their lexicographic order. 1100 The usage of a reverse lexicographic order is important; as discussed 1101 in Section 13, it allows peer-derived candidates to be preferred over 1102 native ones. 1104 The result of these ordering rules will be an ordered list of 1105 candidates. The first candidate in this list is given a sequence 1106 number of 1, the next is given a sequence number of 2, and so on. 1107 This same procedure is done for the remote candidates. The result is 1108 that each candidate pair has two sequence numbers, one for the native 1109 candidate, and one for the remote candidate. 1111 First, all of the candidate pairs for whom the smaller of the two 1112 sequence numbers equals 1 are taken first. Then, all of those for 1113 whom the smaller of the two sequence numbers equals 2 are taken next, 1114 and so on. Amongst those pairs that share the same value for their 1115 smaller sequence number, they are ordered by the larger of their two 1116 sequence numbers (smallest first). Amongst those pairs that share 1117 the same value for their smaller sequence number and the same value 1118 for their larger sequence number, the larger of the two candidate IDs 1119 in each pair are selected, and the pairs are lexicographically 1120 ordered in reverse by that candidate ID, largest first. 1122 As an example, consider two agents, A and B. One offers two 1123 candidates for a media stream with candidate IDs of "g9" and "88", 1124 with q-values of 1.0 and 0.8 respectively. The other answers with 1125 three candidates with candidate IDs of "h8", "65" and "kl", with 1126 q-values of 0.3, 0.2 and 0.1 respectively. The following table shows 1127 the rank ordering of the six candidate pairs. The column labeled 1128 "Max SN" is the larger of the two sequence numbers in the candidate 1129 pair, and "Min SN" is the minimum. The column labeled "Max Cand. 1130 ID" is the value of the larger of the two candidate IDs in the 1131 candidate pair. 1133 Order A A A B B B Max 1134 Cand. Cand. Cand. Cand. Cand. Cand. Max Min Cand. 1135 ID q-value SN ID q-value SN SN SN ID 1136 --------------------------------------------------------------------- 1137 1 g9 1.0 1 h8 0.3 1 1 1 h8 1138 2 88 0.8 2 h8 0.3 1 2 1 h8 1139 3 g9 1.0 1 65 0.2 2 2 1 g9 1140 4 g9 1.0 1 k1 0.1 3 3 1 k1 1141 5 88 0.8 2 65 0.2 2 2 2 88 1142 6 88 0.8 2 k1 0.1 3 3 2 k1 1144 This ordering is then modified slightly by taking the candidate pair 1145 corresponding to the active candidate, if there is one, and promoting 1146 it to the top of the list. To find this candidate pair, the agent 1147 looks for candidate pairs whose native and remote transport addresses 1148 match the native and remote transport addresses in the m/c-line. It 1149 is possible that multiple candidates match; this happens in the case 1150 where an agent obtained the same derived transport address from 1151 different local transport addresses. In such a case, the agent 1152 should pick one of the matching candidates. 1154 Putting the active candidate at the top of the list allows it to be 1155 tested first. As discussed below, media is not sent until the 1156 corresponding candidate is verified, necessitating rapid verification 1157 of the active candidate. This modified ordering is called the 1158 candidate pair check ordering, since it reflects the order in which 1159 connectivity checks will be done. If there was no active candidate, 1160 the candidate pair check ordering and the candidate pair priority 1161 ordering will be identical. 1163 Within each candidate pair there will be a set of transport address 1164 pairs, one for each component ID. Those pairs are ordered by 1165 component ID. The result is an absolute ordering of all transport 1166 address pairs for a media stream, sorted first by the order of their 1167 candidate pairs (with the exception of the active candidate), 1168 followed by the order of their component IDs. This ordering is 1169 called the transport address pair check ordering. 1171 Ordering of candidates may involve transport protocol specific 1172 considerations. There are none for UDP. However, extensions that 1173 define usage of ICE with other transport protocols SHOULD specify any 1174 special ordering considerations. 1176 7.6 Performing the Connectivity Checks 1178 Connectivity checks are a STUN usage defined in [13]. They are 1179 performed by sending peer-to-peer STUN Binding Requests. These 1180 checks result in a candidate progressing through a state machine that 1181 captures the progress of connectivity checks. The specific state 1182 machine and the procedures for the connectivity checks are specific 1183 to the transport protocol. This specification defines rules for UDP. 1184 Extensions to ICE that describe other transport protocols SHOULD 1185 describe the state machine and the procedures for connectivity 1186 checks. 1188 The set of states visited by the offerer and answerer are depicted 1189 graphically in Figure 5 1191 | 1192 |Start 1193 | 1194 | 1195 V 1196 +------------+ 1197 | | 1198 | | 1199 | Waiting |----------------+ 1200 | | | 1201 | | | 1202 +------------+ | 1203 | | 1204 | Timer Ta | Get Req 1205 | --------. | ------- 1206 | Send Req Get Req | Send Res, 1207 V ------- | Send Req 1208 Get Res +------------+ Send Res, | 1209 ------- | | Re-Xmit | 1210 - | | Req | 1211 +---------------| Testing |-----------+ | 1212 | | | | | 1213 | | | | | 1214 | +------------+ | | 1215 | | | | 1216 | | Error | | 1217 | | ----- | | 1218 Timer Tr | | - | | 1219 -------- V V V V 1220 Send Req +------------+ +------------+ +------------+ 1221 +-----| | | | | | 1222 | | Recv- | | | | Send- | 1223 | | Valid |------->| Invalid |<-------| Valid | 1224 | | | | | | | 1225 +---->| | Error | | Error | | 1226 +------------+ ----- +------------+ ----- +------------+ 1227 | - ^ - | 1228 | | Error | 1229 | | ----- | 1230 | | - | 1231 | +------------+ | 1232 | | | | 1233 | | | | 1234 +-------------->| Valid |<-------------+ 1235 Get Req | | Get Res 1236 ------- | | ------- 1237 Send Res +------------+ - 1238 | ^ 1239 | | 1240 | | 1241 +-------+ 1242 Timer Tr 1243 -------- 1244 Send Req 1246 Figure 5 1248 The state machine has six states - waiting, testing, Recv-Valid, 1249 Send-Valid, Valid and Invalid. Initially, all transport address 1250 pairs start in the waiting state. In this state, the agent waits for 1251 one of two events - a chance to send a Binding Request, or receipt of 1252 a Binding Request. 1254 Since there is an instance of the state machine for each transport 1255 address pair, Binding Requests and responses need to be matched to 1256 the specific state machine for which they apply. This is done by 1257 computing the matching transport address pair for each Binding 1258 Request. This is done by examining the USERNAME of the incoming 1259 Binding Request. The USERNAME directly contains the transport 1260 address pair ID. Requests that are sent by an agent as part of the 1261 processing described here encode the transport address pair in the 1262 USERNAME. Binding Responses are matched to their requests using the 1263 STUN transaction ID, and then mapped to the transport address pair 1264 from that. 1266 Every Ta seconds, the agent starts a new connectivity check for a 1267 transport address pair. The check is started for the first transport 1268 address pair in the transport address pair check ordered list (which 1269 will be part of the active candidate) that is in the Waiting state. 1270 The state machine for this transport address pair is moved to the 1271 Testing state, and the agent sends a connectivity check using a STUN 1272 Binding Request, as outlined in Section 7.7. Once a STUN 1273 connectivity check begins, the processing of the check follows the 1274 rules for STUN. Specifically, retransmits of STUN requests are done 1275 as specified in [13], and furthermore, if a transaction fails and 1276 needs to be retried, that retry can happen rapidly, as described 1277 below. It doesn't "count" against the rate limit of 1/Ta checks per 1278 second. In addition, the keepalives that are generated for a valid 1279 pair do not count against the rate limit either. The rate limit 1280 applies strictly to the start of connectivity checks for a transport 1281 address pair that has been newly signaled through an offer/answer 1282 exchange. 1284 In addition, if, while in the Waiting state, an agent receives a 1285 Binding Request matching that transport address pair, and this 1286 Binding Request generates a successful response, the transport 1287 address pair moves into the Send-Valid state, and the agent sends a 1288 connectivity check of its own using a STUN Binding Request, as 1289 outlined in Section 7.7. If the Binding Request didn't generate a 1290 success response, there is no change in state or generation of a 1291 Binding Request. 1293 If, while in the Testing state, the agent receives a successful 1294 response to its STUN request, the transport address pair moves into 1295 the Recv-Valid state. In this state, the agent knows that packets 1296 can flow in both directions. However, its peer agent doesn't yet 1297 know that; all it knows is that it has been able to receive a packet. 1298 Thus, in this state, the agent awaits receipt of the Binding Request 1299 sent by its peer, as the response to that request is what informs its 1300 peer that packets can flow in both directions. 1302 If, while in the Testing state, the agent receives a Binding Request 1303 matching that transport address pair, and this Binding Request 1304 generates a successful response, the transport address pair moves 1305 into the Send-Valid state. In addition, the agent retransmits a 1306 Binding Request for the transaction in progress. This helps speed up 1307 bidirectional connectivity verification when one agent is behind a 1308 symmetric NAT. If the Binding Request didn't generate a success 1309 response, there is no change in state or generation of a Binding 1310 Request. 1312 If, while in the Send-Valid state, the agent receives a successful 1313 response to its STUN request, the transport address pair moves to the 1314 Valid state. In this state, the agent knows that packets can flow in 1315 each direction. It also knows that its peer has sent it the STUN 1316 Request whose response will demonstrate to the peer that packets can 1317 flow in each direction. 1319 If, while in the Recv-Valid state, the agent receives a STUN Binding 1320 Request from its peer that results in a successful response, the 1321 transport address pair moves into the Valid state. Receipt of a 1322 request whose response was not a successful one does not result in a 1323 change in state. 1325 In any state, if the STUN transaction results in an error, the state 1326 machine moves into the invalid state. A STUN transaction produces an 1327 "error" based on the processing in Section 7.7, which indicates which 1328 STUN response codes constitute an error as far as ICE processing is 1329 concerned. 1331 If a transport address pair is in the Recv-Valid or Valid state, an 1332 agent MUST generate a new STUN Binding Request transaction every Tr 1333 seconds. This transaction ensures that NAT bindings for the 1334 transport address pair remain open while the candidate is under 1335 consideration. The transaction is performed as outlined in 1336 Section 7.7. These transactions can also be used to keep the NAT 1337 bindings alive when the candidate is promoted to active, as described 1338 in Section 7.12. Tr SHOULD be configurable, and SHOULD default to 15 1339 seconds. If the transaction results in an error, the state machine 1340 moves to the invalid state. This happens in cases where the NAT 1341 bindings expire (e.g., due to binding timeouts or NAT failures). 1343 The candidate pair itself has a state, which is derived from the 1344 states of its transport address pairs. If at least one of the 1345 transport address pairs in a candidate pair is in the invalid state, 1346 the state of the candidate pair is considered to be invalid. If the 1347 candidate pair enters this state, an agent SHOULD move the state 1348 machines for all of the other transport address pairs in this 1349 candidate pair into the invalid state as well. This will ensure that 1350 connectivity checks never start for those transport address pairs. 1351 Furthermore, if checks are already in progress for one of those 1352 transport address pairs, the agent SHOULD cease them. 1354 If all of the transport address pairs making up the candidate pair 1355 are Valid, the candidate pair is considered valid. If all of the 1356 transport address pairs making up the candidate pair are either Valid 1357 or Recv-Valid, and at least one is Recv-Valid, the candidate pair is 1358 considered to be Recv-Valid. If all of the transport address pairs 1359 making up the candidate pair are either Valid or Send-Valid, and at 1360 least one is Send-Valid, the candidate pair is considered to be Send- 1361 Valid. If all of the transport address pairs in a candidate pair are 1362 in the Waiting state, the candidate pair is in the waiting state. If 1363 all of the transport address pairs in the candidate pair are either 1364 in the Waiting or Testing states, and at least one is in the Testing 1365 state, the state of the candidate pair is Testing. Otherwise, the 1366 state of the candidate pair is considered Indeterminate. 1368 A candidate itself also has a state. If a candidate is present in at 1369 least one valid candidate pair, that candidate is said to be valid. 1370 If all of the candidate pairs containing that candidate are invalid, 1371 the candidate itself is invalid. Otherwise, the candidate's state is 1372 Indeterminate. 1374 7.7 Sending a Binding Request for Connectivity Checks 1376 An agent performs a connectivity check on a transport address pair by 1377 sending a STUN Binding Request from its native transport address, and 1378 sending it to the remote transport address. The meaning of "sending 1379 from its native transport address" depends on the type of transport 1380 protocol and the type of transport address (local, reflexive, or 1381 relayed). This specification defines the meaning for UDP. 1382 Specifications defining other transport protocols must define what 1383 this means for them. 1385 For UDP-based local transport addresses, sending from the local 1386 transport address has the meaning one would expect - the request is 1387 sent such that the source IP address and port equal that of the local 1388 transport address. For reflexive ransport addresses, it is sent by 1389 sending from the associated local transport address used to derive 1390 that reflesive address. For relayed transport addresses, it is sent 1391 by using STUN mechanisms to send the request through the STUN relay 1392 (using the Send request). Sending the request through the STUN relay 1393 server neccesarily requires that the request be sent from the client, 1394 using the local transport address used to derive the relayed 1395 transport address. 1397 The Binding Request sent by the agent MUST contain the USERNAME 1398 attribute. This attribute MUST be set to the transport address pair 1399 ID of the corresponding transport address pair as seen by its peer. 1400 Thus, for the first transport address pair in Figure 3, if the agent 1401 on the left sends the STUN Binding Request, the USERNAME will have 1402 the value R:1:L:1. If the agent on the right sends the STUN Binding 1403 Request, the USERNAME will have the value L:1:R:1. To be clear, the 1404 USERNAME that is used is NOT the one seen locally, but rather the one 1405 as seen by its peer. The request SHOULD contain the MESSAGE- 1406 INTEGRITY attribute, computed according to [13]. The key used as 1407 input to the HMAC is the password provided by the peer for this 1408 remote transport address. This password will be identical for all 1409 remote transport addresses for the same media stream. 1411 Note that all ICE implementations are required to be compliant to 1412 [13], as opposed to the older [16]. Consequently, all connectivity 1413 checks will contain the magic cookie in the STUN header, and cause 1414 the STUN server embedded in each ICE implementation to include XOR- 1415 MAPPED-ADDRESS attributes in the response, rather than MAPPED- 1416 ADDRESS. 1418 The STUN transaction will generate either a timeout, or a response. 1419 If the response is a 420, 500, or 401, the agent should try again as 1420 described in [13] (as mentioned above, it need not wait Ta seconds to 1421 try again). Either initially, or after such a retry, the STUN 1422 transaction might produce a non-recoverable failure response (error 1423 codes 400, 430, 431, or 600) or a failure result inapplicable to this 1424 usage of STUN and thus unrecoverable (432, 433). If this happens, an 1425 error event is generated into the state machine, and the transport 1426 address pair enters the invalid state. 1428 If the STUN transaction times out, the client SHOULD NOT retry. The 1429 only reason a retry might succeed is if there was severe packet loss 1430 during the duration of the check, or the answer was significantly 1431 delayed, also due to packet loss. However, STUN Binding Request 1432 transactions run for 9.5 seconds, which is well beyond the typical 1433 tolerance for a session establishment. The retries come with a 1434 penalty of additional traffic, which can be used to launch DoS 1435 attacks Section 13.4.2. The only reason to not follow the SHOULD NOT 1436 is if the agent has adjusted the STUN transaction timers to be more 1437 aggressive. 1439 If the Binding Response is a 200, the agent SHOULD check for the 1440 MESSAGE-INTEGRITY attribute and verify it, as discussed in [13]. 1441 Indeed, this check SHOULD be done for all responses. This will 1442 result in the response being discarded (eventually leading to a 1443 timeout), if the integrity check fails. 1445 7.8 Receiving a Binding Request for Connectivity Checks 1447 As a result of providing a list of candidates in its offer or answer, 1448 an agent will receive STUN Binding Request messages. An agent MUST 1449 be prepared to receive STUN Binding Requests on each local transport 1450 address from the moment it sends an offer or answer that contains a 1451 candidate with that local transport address. Similarly, it MUST be 1452 prepared to receive STUN Binding Requests on a local transport 1453 address the moment it sends an offer or answer that contains a 1454 reflexive or relayed candidate derived from a local candidate with 1455 that local transport address. It can cease listening for STUN 1456 messages on that local transport address after sending an updated 1457 offer or answer which does not include any candidates with transport 1458 addresses that are equal to or derived from that local transport 1459 address. 1461 As discussed in [13], since the username and password for STUN 1462 requests are exchanged through another mechanism - here, ICE - the 1463 Shared Secret Request mechanism is not needed and need not be 1464 implemented by agents that provide the connectivity check usage. 1466 One of the candidates may be in use as the active candidate, or may 1467 become promoted to the active candidate in the next offer/answer 1468 exchange as a consequence of a successful validation. In either 1469 case, both media and STUN packets will be sent to the transport 1470 addresses comprising that candidate, causing both to receive on their 1471 associated local transport addresses. The agent MUST be able to 1472 disambiguate them. This is done trivially by looking for the STUN 1473 magic cookie as the value of the second 32-bit word in the packet. 1474 If present, it identifies a STUN packet. 1476 Processing of the Binding Request proceeds in two steps. The first 1477 is generation of the response, and the second ICE-specific 1478 processing. Generation of the response follows the general 1479 procedures of [13]. The USERNAME is considered valid if one of the 1480 candidate IDs sent in an offer or answer is a prefix of the USERNAME 1481 (this will always be the case, even for peer reflexive candidates). 1482 The password associated with that candidate ID is used to verify the 1483 MESSAGE-INTEGRITY attribute, if one was present in the request. If 1484 the USERNAME was not valid, the agent generates a 430. Otherwise, 1485 the success response will include the XOR-MAPPED-ADDRESS attribute, 1486 which is used for learning new candidates, as described in 1487 Section 7.10. The XOR-MAPPED-ADDRESS attribute is constructed using 1488 the source IP address and port of the Binding Request. For Binding 1489 Requests received over relayed transport addresses, this MUST be the 1490 source IP address and port of the Binding Request when it arrived at 1491 the relay, prior to forwarding towards the agent. That source 1492 transport address will be present in the REMOTE-ADDRESS attribute of 1493 a STUN Data Indication message, if the Binding Request was delivered 1494 through a Data Indication. If the Binding Request was not 1495 encapsulated in a Data Indication, that source address is equal to 1496 the current active destination for the STUN relay session. 1498 The ICE processing involves changes to the state machine for a 1499 transport address pair. This processing cannot be done until the 1500 initial offer/answer exchange has completed. As a consequence, if 1501 the oferrer received a Binding Request that generated a success 1502 response, but had not yet received the answer to its offer, it waits 1503 for the answer, and when it arrives, then performs the ICE 1504 processing. 1506 The agent takes the entire contents of the USERNAME, and compares 1507 them against the transport address pair identifiers as seen by that 1508 agent for each transport address pair. If there is no match, nothing 1509 is done - this should never happen for compliant implementations. If 1510 there is a match, the resulting transport address pair is called the 1511 matching transport address pair. The state machine for the matching 1512 transport address pair is then updated based on the receipt of a STUN 1513 Binding Request, and the resulting actions described in Section 7.6 1514 are undertaken. 1516 An agent will continue to receive periodic STUN connectivity checks 1517 on a local transport address as long as it had listed that transport 1518 address, or one derived from it, in an a=candidate attribute in its 1519 most recent offer or answer, the state machine for that transport 1520 address is in the Recv-Valid or Valid states, and the transport 1521 address is for UDP. Whether STUN keepalives are used for other 1522 transport protocols is defined by the specifications for that 1523 transport protocol. The agent processes any such transactions 1524 according to this section. It is possible that a transport address 1525 pair that was previously valid may become invalidated as a result of 1526 a subsequent failed STUN transaction. 1528 7.9 Promoting a Candidate to Active 1530 As a consequence of the connectivity checks, each agent will change 1531 the states for each transport address pair, and consequently, for the 1532 candidate pairs. When a candidate pair becomes valid, and the agent 1533 is in the role of offerer for that candidate pair, the agent follows 1534 the logic in this section. The rules only apply to the offerer of a 1535 candidate pair in order to eliminate the possibility of both agents 1536 simultaneously offering an update to promote a candidate to active. 1538 If this candidate pair is the first one in the candidate pair 1539 priority ordered list, the agent SHOULD send an updated offer as 1540 described in Section 7.11.1. If this candidate pair is not the first 1541 on that list, but it is the first on the candidate pair check ordered 1542 list, it means that this candidate pair is the active one, and its 1543 connectivity has been verified. This is good news; the currently 1544 active candidate is working. Media can now flow as described in 1545 Section 7.13 (media will never flow prior to validation). However, 1546 no updated offer is sent at this time. 1548 If this candidate pair is not the first on the candidate pair 1549 priority ordered list or the candidate pair check ordered list, and 1550 the wait-state timer has not yet been set, the agent sets this timer 1551 to Tws seconds. Tws SHOULD be configurable, and SHOULD have a 1552 default of 100ms. This timer allows for a higher priority 1553 connectivity check to complete, in the event its STUN Binding Request 1554 was lost or delayed in the network. If, prior to the wait-state 1555 timer firing, another connectivity check completes and a candidate 1556 pair is validated, there is no need to reset or cancel the timer. 1557 Once the timer fires, the agent SHOULD issue an updated offer as 1558 described in Section 7.11.1. 1560 In addition, in order to speed up ICE processing, once the agent has 1561 determined the candidate that is to be promoted, it will send and 1562 receive media using that candidate in expectation of an updated 1563 offer. This is discussed in Section 7.13. 1565 7.10 Learning New Candidates from Connectivity Checks 1567 ICE makes use of reflexive addresses, which are addresses that inform 1568 an agent of its transport address as seen by another host. An 1569 initial offer or answer generated by an agent includes server 1570 reflexive addresses, which are learned from a configured or 1571 discovered STUN server in the network. However, the connectivity 1572 checks themselves can inform an agent of reflexive addresses, and in 1573 particular, ones that are reflexive towards its peer. These are 1574 called peer reflexive candidates. A new peer reflexive candidate is 1575 typically observed when two agents are separated by a NAT with the 1576 address-dependent or address and port dependent mapping properties 1577 [37]. When the agent behind such a NAT sends a Binding Request to 1578 the other agent (assuming it is reachable), the NAT will create a new 1579 mapping for this Binding Request. Because STUN and the media packets 1580 are sent on the same port, regardless of the filtering properties of 1581 the NAT (whether endpoint independent, address dependent, or address 1582 and port dependent), this reflexive address can be used by the peer 1583 for sending STUN and media packets back towards the agent. 1585 To obtain and use these peer reflexive transport addresses, ICE 1586 agents perform additional processing on the receipt of STUN Binding 1587 Requests and responses, beyond the logic described in Section 7.7 and 1588 Section 7.8. This logic is described below. 1590 7.10.1 On Receipt of a Binding Request 1592 When a STUN Binding Request is received which generates a success 1593 response, that Binding Request would have been associated with a 1594 matching transport address pair and corresponding candidate pair. 1595 The source IP and port of this Binding Request are compared to the IP 1596 address and port of the remote transport address in the matching 1597 transport address pair. Note that, in this case, we are comparing 1598 actual IP addresses and ports - not tids. In addition, if the 1599 Binding Request arrived through a relayed transport address, the 1600 source IP and port of this binding request used for the comparison 1601 are those in the Binding Request when it arrived at the relay, prior 1602 to forwarding towards the agent. That source transport address will 1603 be present in the REMOTE-ADDRESS attribute of a STUN Data Indication 1604 message, if the Binding Request were delivered through a Data 1605 Indication. If the Binding Request was not encapsulated in a Data 1606 Indication, that source address is equal to the current active 1607 destination for the STUN relay session. 1609 The comparison of the source IP and port of the Binding Request and 1610 the IP address and port of the remote transport address in the 1611 matching transport address pair may indicate inequality. In that 1612 case, the source IP and port of the Binding Request (and again, for 1613 relayed transport address, this refers to the source IP address and 1614 port of the packet when it arrived at the relay) are compared to the 1615 IP address and ports across the transport address pairs in *all* 1616 remote candidates. If there is a match to another remote candidate 1617 (called the alternate remote candidate), this is not a new candidate; 1618 however, the Binding Request has effectively helped validate the 1619 alternate remote candidate. The agent SHOULD select the candidate 1620 pair corresponding to the combination of the alternate remote 1621 candidate and the native candidate from the original matching 1622 candidate pair. A "Get Req" event is passed to the state machine for 1623 that candidate pair. Consequently, if this candidate pair was in the 1624 Waiting state, a connectivity check will be generated for it. 1626 If, when the source IP and port of the STUN packet, when compared 1627 against all remote candidates, was not a match to any of them, it 1628 means that the source IP and port might represent another valid 1629 remote transport address - a peer derived one. 1631 To use it, that address needs to be associated with a candidate 1632 (called a peer-derived candidate). In this case, however, the 1633 candidate isn't signaled through an offer/answer exchange; it is 1634 constructed dynamically from information in the STUN request. Like 1635 all other candidates, the peer-derived candidate has a candidate ID. 1636 The candidate ID is derived from the candidate IDs of the matching 1637 candidate pair. In particular, the candidate ID is constructed by 1638 concatenating the remote candidate ID with the native candidate ID 1639 (without the colon). The password for the new candidate equals that 1640 of the remote candidate ID in the matching candidate pair (note that, 1641 this password would be the same for all remote candidates for the 1642 same media line). 1644 On receipt of a STUN Binding Request whose source IP and port don't 1645 match the transport address in any remote candidate, the agent 1646 constructs the candidate ID that represents the peer reflexive 1647 candidate, and checks to see if that candidate exists. It may 1648 already exist if it had been constructed as a consequence of a 1649 previous application of this logic on receipt of a Binding Request 1650 for a different transport address pair of the same candidate pair. 1651 If there is not yet a peer reflexive candidate with that candidate 1652 ID, the agent creates it, and assigns it the newly computed candidate 1653 ID. The priority of the peer-derived candidate MUST be set to the 1654 priority of its generating candidate - the remote candidate in the 1655 matching transport address pair. Note that, at this time, the peer 1656 derived candidate has no transport addresses in it. 1658 Newly created or not, the agent extracts the component ID from the 1659 matching transport address pair, and sees if a transport address with 1660 that same component ID exists in the peer reflexive candidate. If 1661 not (and it shouldn't), the agent adds a transport address to the 1662 peer reflexive candidate. This transport address is equal to the 1663 source IP address and port from the incoming STUN Binding Request 1664 (and in the case of a relayed transport address, the one seen by the 1665 relay). It is assigned the component ID equal to the component ID in 1666 the matching transport address pair. This transport address will 1667 have a tid, equal to the concatenation of the candidate ID for this 1668 new candidate, and the component ID, separated by a colon. 1670 The peer reflexive candidate becomes usable once the number of 1671 transport addresses in it equals the transport address pair count of 1672 the candidate pair from which it is derived. Initially, the peer 1673 reflexive candidate will start with a single transport address. More 1674 are added as the connectivity checks for the original candidate pair 1675 take place. Once the peer reflexive candidate becomes usable, it has 1676 to be paired up with native candidates. However, unlike the 1677 procedures of Section 7.5, which pair up each remote candidate with 1678 each native candidate, this peer reflexive candidate is only paired 1679 up with the native candidate from the candidate pair from which it 1680 was derived. This creates a new candidate pair, and a set of new 1681 transport address pairs. 1683 Recall that, for each candidate pair, one agent plays the role of 1684 offerer, and the other of answerer. For a peer-reflexive candidate, 1685 the role is identical to that of its generating candidate. 1687 Figure 6 provides a pictorial representation of the peer reflexive 1688 candidate (the one with id=RL) and its pairing with the native 1689 candidate with id L. The candidate with ID R is referred to as the 1690 generating candidate. The peer reflexive candidate is effectively an 1691 alternate for that generating candidate, but is only paired with a 1692 specific native candidate. Note that, for a particular generating 1693 candidate, there can be many peer derived candidates, up to one for 1694 each native candidate. 1696 ............. ............. 1697 . tid=L:1 . . tid=R:1 . 1698 component. -- . id=L:1:R:1 . -- .component 1699 id=1 . | A|-------------------------| C| . id=1 1700 . -- -------+ . -- . 1701 . . | . . Generating 1702 . . | . . Candidate 1703 . tid=L:2 . | . tid=R:2 . 1704 component. -- . | id=L:2:R:2 . -- .component 1705 id=2 . | B|-------C-----------------| D| . id=2 1706 . -- -----+ | . -- . 1707 .............| | ............. 1708 Native | | Remote 1709 Candidate | | Candidate 1710 id=L | | id=R 1711 | | 1712 | | ............. 1713 | | . tid=RL:1 . 1714 | | id=L:1:RL:1 . -- .component 1715 | +-----------------| C| . id=1 1716 | . -- . 1717 | . . Peer Derived 1718 | . . Candidate 1719 | . tid=RL:2 . 1720 | id=L:2:RL:2 . -- .component 1721 +-------------------| D| . id=2 1722 . -- . 1723 ............. 1724 Remote 1725 Candidate 1726 id=RL 1728 Figure 6 1730 The new transport address pairs have a state machine associated with 1731 them. The state that is entered, and actions to take as a 1732 consequence, are specific to the transport protocol. For UDP, the 1733 procedures are defined here. Extensions that define processing for 1734 other transport protocols SHOULD describe the behavior. 1736 For UDP, the state machine enters the Send-Valid state. Effectively, 1737 the Binding Request just received "counts" as a validation in this 1738 direction, even though it was formally done for a different candidate 1739 pair. In addition, the agent SHOULD generate a Binding Request for 1740 each transport address in this new candidate pair, as described in 1741 Section 7.7. The transport address pairs are inserted into the 1742 ordered list of pairs based on the ordering described in Section 7.5 1743 and processing follows the logic described in Section 7.6. 1745 7.10.2 On Receipt of a Binding Response 1747 The procedures on receipt of a Binding Response are nearly identical 1748 to those for receipt of a Binding Request as described above. 1750 When a successful STUN Binding Response is received, it will be 1751 associated with a matching transport address pair and corresponding 1752 candidate pair. This matching is done based on comparison of 1753 candidate IDs. The reflexive transport address from the Binding 1754 Response is compared to the IP address and port of the native 1755 transport address in the matching transport address pair. Note that, 1756 in this case, we are comparing actual IP addresses and ports - not 1757 tids. These may not match if there was a NAT between the two agents. 1758 If they do not match, the reflexive transport address is compared to 1759 the IP address and ports across the transport address pairs in *all* 1760 native candidates. If there is a match to another native candidate 1761 (called the alternate native candidate), this is not a new candidate; 1762 however, the Binding Response has effectively helped validate the 1763 alternate native candidate. The agent SHOULD select the candidate 1764 pair corresponding to the combination of the alternate native 1765 candidate and the remote candidate from the original matching 1766 candidate pair. If the candidate pair is in the Waiting state, it 1767 moves directly to the Recv Valid state. 1769 If, when the reflexive transport address, when compared against all 1770 native candidates, was not a match to any of them, it means that the 1771 reflexive transport address might represent another valid native 1772 transport address - a peer derived one. 1774 To use it, that address needs to be associated with a candidate. In 1775 this case, however, the candidate isn't signaled through an offer/ 1776 answer exchange; it is constructed dynamically from information in 1777 the STUN response. Such a candidate is called a peer reflexive 1778 candidate. Like all other candidates, the peer reflexive candidate 1779 has a candidate ID. The candidate ID is derived from the candidate 1780 IDs of the matching candidate pair. In particular, the candidate ID 1781 is constructed by concatenating the native candidate ID with the 1782 remote candidate ID (without the colon). The password for the new 1783 candidate equals that of the native candidate ID in the matching 1784 candidate pair. 1786 On receipt of a STUN Binding Response whose reflexive transport 1787 address didn't match the transport address in any native candidate, 1788 the agent constructs the candidate ID that represents the peer 1789 reflexive candidate, and checks to see if that candidate exists. It 1790 may already exist if it had been constructed as a consequence of a 1791 previous application of this logic on receipt of a Binding Response 1792 for a different transport address pair of the same candidate pair. 1793 If there is not yet a peer derived candidate with that candidate ID, 1794 the agent creates it, and assigns it the newly computed candidate ID. 1795 The priority of the new candidate MUST be set to the priority of the 1796 generating candidate - the native candidate in the matching transport 1797 address pair. Note that, at this time, the peer derived candidate 1798 has no transport addresses in it. 1800 Newly created or not, the agent extracts the component ID from the 1801 matching transport address pair, and sees if a transport address with 1802 that same component ID exists in the peer reflexive candidate. If 1803 not (and it shouldn't), the agent adds a transport address to the 1804 peer reflexive candidate. This transport address is equal to the 1805 reflexive transport address from the STUN Binding Response. It is 1806 assigned the component ID equal to the component ID in the matching 1807 transport address pair. This transport address will have a tid, 1808 equal to the concatenation of the candidate ID for this new 1809 candidate, and the component ID, separated by a colon. 1811 The peer-derived candidate becomes usable once the number of 1812 transport addresses in it equals the transport address pair count of 1813 candidate pair from which it is derived. Initially, the peer-derived 1814 candidate will start with a single transport address. More are added 1815 as the connectivity checks for the original candidate pair take 1816 place. Once the peer-derived candidate becomes usable, it has to be 1817 paired up with remote candidates. However, unlike the procedures of 1818 Section 7.5, which pair up each remote candidate with each native 1819 candidate, the peer-derived candidate is only paired up with the 1820 remote candidate from the matching candidate pair. This creates a 1821 new candidate pair, and a set of new transport address pairs. 1823 Recall that, for each candidate pair, one agent plays the role of 1824 offerer, and the other of answerer. For a peer-reflexive candidate, 1825 the role is identical to that of its generating candidate. 1827 The new transport address pairs have a state machine associated with 1828 them. The state that is entered, and actions to take as a 1829 consequence, are specific to the transport protocol. For UDP, the 1830 procedures are defined here. Extensions that define processing for 1831 other transport protocols SHOULD describe the behavior. 1833 For UDP, the state machine enters the Recv-Valid state. Effectively, 1834 the Binding Response just received "counts" as a validation in this 1835 direction, even though it was formally done for a different candidate 1836 pair. The transport address pairs are inserted into the ordered list 1837 of pairs based on the ordering described in Section 7.5, and 1838 processing follows the logic described in Section 7.6. 1840 7.11 Subsequent Offer/Answer Exchanges 1842 An agent MAY issue an updated offer at any time. This updated offer 1843 may be sent for reasons having nothing to do with ICE processing (for 1844 example, the addition of a video stream in a multimedia session), or 1845 it may be due to a change in ICE-related parameters. For example, if 1846 an agent acquires a new candidate after the initial offer/answer 1847 exchange, it may seek to add it. 1849 However, agents SHOULD follow the logic described in Section 7.9 to 1850 determine when to send an updated offer as a consequence of promoting 1851 a candidate to active. 1853 If there are any aspects of this processing that are specific to the 1854 transport protocol, those SHOULD be called out in ICE extensions that 1855 define operation with other transport protocols. There are no 1856 additional considerations for UDP. 1858 7.11.1 Sending of a Subsequent Offer 1860 The offer MAY contain a new active candidate in the m/c line. This 1861 candidate SHOULD be the native candidate from the highest candidate 1862 pair in the candidate pair priority ordered list whose state is 1863 Valid. If there are no candidate pairs in this state, the highest 1864 one whose state is Send-Valid or Recv-Valid SHOULD be used. If there 1865 are no candidate pairs in these states, the candidate pair that is 1866 most likely to work with this peer, as described in Section 7.2, 1867 SHOULD be used. The candidate is encoded into the m/c line in an 1868 updated offer as described in Section 7.3. Note that, while peer- 1869 derived candidates never appear in a=candidate attributes (only their 1870 generating candidates appear there), a peer-derived candidate can 1871 appear in the m/c line if it has been selected for usage for media. 1873 If the candidate pair whose native candidate was encoded into the 1874 m/c-line was Valid, Send-Valid or Recv-Valid, the agent MUST include 1875 an a=remote-candidate attribute into the offer. This attribute MUST 1876 contain the candidate ID of the remote candidate in the candidate 1877 pair. It is used by the recipient of the offer in selecting its 1878 candidate for the answer. 1880 The meaning of a=candidate attributes within a subsequent offer have 1881 the same meaning as they do in an initial offer. They are a request 1882 for the peer to attempt (or continue to attempt if the candidate was 1883 provided previously) a connectivity check using STUN from each of its 1884 own candidates. When an updated offer is sent, there are several 1885 dispositions regarding the candidates: 1887 retained: A candidate is retained if the candidate ID for the 1888 candidate is included in the new offer, and matches the candidate 1889 ID for a candidate in the previous offer or answer from the agent. 1890 In this case, all of the information about the candidate - its 1891 qvalue and components, and the IP addresses, ports, and transport 1892 protocols of its components, MUST be the same as the previous 1893 offer or answer from the agent. If the agent wants to change 1894 them, this is accomplished by changing the candidate ID as well. 1895 That will have the effect of removing the old candidate and adding 1896 a new one with the updated information. 1898 removed: A candidate is removed if its candidate ID appeared in a 1899 previous offer or answer, and that candidate ID is not present in 1900 the new offer. 1902 added: A candidate is added if its candidate ID appeared in the new 1903 offer, but was not present in a previous offer or answer from that 1904 agent. 1906 The following rules are used to determine the disposition of the each 1907 of the current native candidates in the new offer: 1909 o If a candidate is invalid, and all peer reflexive candidates 1910 generated from it are invalid as well, it SHOULD be removed. 1912 o If the candidate in the m/c-line is valid, all other candidates 1913 SHOULD be removed. This has the effect of stopping connectivity 1914 checks of other candidates. This SHOULD would not be followed if 1915 an agent wanted to keep a candidate ready for usage should, for 1916 some reason, the active candidate later become invalid. 1918 o If the candidate in the m/c-line is valid, and it is not peer 1919 reflexive, that candidate MUST be retained. If the candidate in 1920 the m/c-line is peer reflexive, its generating candidate MUST be 1921 retained, even if it is itself invalid. 1923 o If the candidate in the m/c-line has not been validated, all other 1924 candidates that are not invalid, or candidates for whom their 1925 derived candidates are not invalid, SHOULD be retained. 1927 o Peer reflexive candidates MUST NOT be added; they continue to be 1928 used as long as their generating candidate was retained. Peer 1929 derived candidates are learned exclusively through the STUN 1930 connectivity checks. 1932 A new candidate MAY be added. This can happen when the candidate is 1933 a new one, learned since the previous offer/answer exchange, and it 1934 has a higher priority than the currently active candidate. It can 1935 also occur when an agent wishes to restart checks for a transport 1936 address it had tried previously. Effectively, changing the candidate 1937 ID value in an updated offer will "restart" connectivity checks for 1938 that candidate. 1940 If a candidate is removed, the agent takes the following steps once 1941 the offer is sent: 1943 1. The agent eliminates any candidate pairs whose native candidate 1944 equalled the candidate that was removed. Equality is based on 1945 comparison of candidate IDs. 1947 2. The agent eliminates any candidate pairs that had a native 1948 candidate that is a peer reflexive candidate generated from the 1949 candidate that was removed. 1951 3. The candidate pairs that are eliminated are removed from the 1952 candidate pair priority ordered list and candidate pair check 1953 ordered list. As a consequence of this, if connectivity checks 1954 had not yet begun for the candidate pair, they won't. 1956 4. If connectivity checks were already in progress for transport 1957 addresses in a candidate pair that was removed, the agent SHOULD 1958 immediately terminate them. No further retransmissions take 1959 place, and no further transactions from that candidate will be 1960 made. 1962 5. If the removed candidate was a relayed candidate, the agent 1963 SHOULD de-allocate its transport addresses from the STUN relay if 1964 it is not using those resources elswhere. If a local candidate 1965 was removed, and all of its derived candidates were also removed 1966 (including any peer reflexive candidates), local operating system 1967 resources for each of the transport addresses in the local 1968 candidate SHOULD be de-allocated, as long as it is not using 1969 those resources elsewhere. The resources may be in use elsewhere 1970 if they were included in an initial offer which generated 1971 multiple answers (as can happen with SIP forking). In such a 1972 case, a subsequent offer which removes the candidate will not 1973 imply its removal with the other branches; each becomes a 1974 separate offer/answer relationship. 1976 Subsequent offers MUST contain a=ice-pwd attributes that specify the 1977 password for the candidates for each media stream. The password for 1978 the candidates for a particular media stream SHOULD have the same 1979 value as in previous offers. However, an agent MAY change it if, for 1980 some reason, the agent believes that the password may have been 1981 compromised. Note that it is permissible to use a session-level 1982 attribute in one offer, and in a subseqeunt offer, provide the same 1983 password as a media-level attribute. This is not a change in the 1984 password; merely a change in its representation. An agent MUST be 1985 prepared to receive connectivity checks that use either the new or 1986 old password until Tpw seconds after it receives the answer. Tpw 1987 SHOULD be configurable, and SHOULD default to 2 seconds. 1989 7.11.2 Receiving the Offer and Sending an Answer 1991 To generate the answer, the answerer has to decide which transport 1992 addresses to include in the m/c line, and which to include in 1993 candidate attributes. 1995 The first step in the process is to look for the a=remote-candidate 1996 attribute in the offer. The a=remote-candidate exists to eliminate a 1997 race condition between the updated offer and the response to the STUN 1998 Binding Request that moved a candidate into the Valid state. This 1999 race condition is shown in Figure 7. On receipt of message 5, agent 2000 A can move its transport address pair state machine into the Valid 2001 state. It sends a STUN response to the request (message 6), but this 2002 is lost. Agent A proceeds with an updated offer (message 7), which 2003 is received at agent B. As far as agent B is concerned, the transport 2004 address pair is still in the Send-Valid state. It will move into the 2005 Valid state only on receipt of the STUN response in message 10. 2006 Thus, upon receipt of the offer, agent B cannot determine which 2007 candidate to include in its answer. To eliminate this condition, the 2008 identity of the validated candidate is included in the offer itself. 2009 Note, however, that the answerer will not send media until it has 2010 received this STUN response. 2012 Agent A Network Agent B 2013 |(1) Offer | | 2014 |------------------------------------------>| 2015 |(2) Answer | | 2016 |<------------------------------------------| 2017 |(3) STUN Req. | | 2018 |------------------------------------------>| 2019 |(4) STUN Res. | | 2020 |<------------------------------------------| 2021 |(5) STUN Req. | | 2022 |<------------------------------------------| 2023 |(6) STUN Res. | | 2024 |-------------------->| | 2025 | |Lost | 2026 |(7) Offer | | 2027 |------------------------------------------>| 2028 |(8) Answer | | 2029 |<------------------------------------------| 2030 |(9) STUN Req. | | 2031 |<------------------------------------------| 2032 |(10) STUN Res. | | 2033 |------------------------------------------>| 2035 Figure 7 2037 If the a=remote-candidate attribute is present, the agent examines 2038 the transport addresses in the m/c-line of the offer. It compares 2039 these with the transport addresses in the remote candidates of all 2040 candidate pairs. If there is at least one match, the agent compares 2041 the native candidate ID of each matching pair with the value of the 2042 a=remote-candidate attribute. If there is a match, that candidate 2043 pair is selected. For each transport address pair in that candidate 2044 pair, if the state of the transport address pair is Send-Valid, the 2045 agent considers the state to be Valid just for the purpose of 2046 selecting the m/c-line as discussed in the paragraph below. The 2047 actual state MUST remain Send-Valid. This is necessary to prevent 2048 against DoS attacks. 2050 Rules for choosing transport addresses for the m/c-line are as 2051 follows. The agent examines the transport addresses in the m/c-line 2052 of the offer. It compares these with the transport addresses in the 2053 remote candidates of candidate pairs whose states are Valid. If 2054 there is a matching candidate pair in that state, the pair with the 2055 highest priority MUST be chosen, and the native candidate from that 2056 pair used as the active candidate. If there were no matching 2057 candidate pairs in the Valid state, the candidate that is most likely 2058 to work with this peer, as described in Section 7.2, SHOULD be used. 2060 Like the offerer, the answerer can decide, for each of its 2061 candidates, whether they are retained or removed. The same rules 2062 defined in Section 7.11.1 for determining their disposition apply to 2063 the answerer. Similarly, if a candidate is removed, the same rules 2064 in Section 7.11.1 regarding removal of canididate pairs and freeing 2065 of resources apply. 2067 Once the answer is sent, the answerer will have the set of native and 2068 remote candidates before this offer/answer exchange, and the set of 2069 native and remote candidates afterwards. A peer derived candidate 2070 continues to be used as long as its generating parent continues to be 2071 used. The agent then pairs up the native and remote candidates which 2072 were added or retained. This leads to a set of current candidate 2073 pairs. 2075 If a candidate pair existed previously, but as a consequence of the 2076 offer/answer exchange, it no longer exists, the agent takes the 2077 following steps: 2079 1. The candidate pair is removed from the candidate pair priority 2080 ordered list and candidate pair check ordered list. As a 2081 consequence of this, if connectivity checks had not yet begun for 2082 the candidate pair, they won't. 2084 2. If connectivity checks were already in progress for that 2085 candidate pair, the agent SHOULD immediately terminate any STUN 2086 transactions in progress from that candidate. No further 2087 retransmissions take place, and no further transactions from that 2088 candidate will be made. 2090 3. If the agent receives a STUN Binding Request for that candidate 2091 pair, the agent SHOULD generate a 430 response. 2093 If a candidate pair existed previously, and continues to exist, no 2094 changes are made; any STUN transactions in progress for that 2095 candidate pair continue, and it remains on the candidate pair 2096 priority ordered list and candidate pair check ordered list. 2098 If a candidate pair is new (because either its native candidate is 2099 new, or its remote candidate is new, or both), the agent takes the 2100 role of answerer for this candidate pair. The new candidate pair is 2101 inserted into the candidate pair priority ordered list and candidate 2102 pair check ordered list. STUN connectivity checks will start for 2103 them based on the logic described in Section 7.6. 2105 7.11.3 Receiving the Answer 2107 Once the answer is received, the answerer will have the set of native 2108 and remote candidates before this offer/answer exchange, and the set 2109 of native and remote candidates afterwards. It then follows the same 2110 logic described in Section 7.11.2, pairing up the candidate pairs, 2111 removing ones that are no longer in use, and beginning of processing 2112 for ones that are new. 2114 7.12 Binding Keepalives 2116 Once a candidate is promoted to active, and media begins flowing, it 2117 is still necessary to keep the bindings alive at intermediate NATs 2118 for the duration of the session. Normally, the media stream packets 2119 themselves (e.g., RTP) meet this objective. However, several cases 2120 merit further discussion. Firstly, in some RTP usages, such as SIP, 2121 the media streams can be "put on hold". This is accomplished by 2122 using the SDP "sendonly" or "inactive" attributes, as defined in RFC 2123 3264 [4]. RFC 3264 directs implementations to cease transmission of 2124 media in these cases. However, doing so may cause NAT bindings to 2125 timeout, and media won't be able to come off hold. 2127 Secondly, some RTP payload formats, such as the payload format for 2128 text conversation [36], may send packets so infrequently that the 2129 interval exceeds the NAT binding timeouts. 2131 Thirdly, if silence suppression is in use, long periods of silence 2132 may cause media transmission to cease sufficiently long for NAT 2133 bindings to time out. 2135 To prevent these problems, ICE implementations MUST continue to list 2136 their active candidate in a=candidate lines for UDP-based media 2137 streams. As a consequence of this, STUN packets will be transmitted 2138 periodically independently of the transmission (or lack thereof) of 2139 media packets. This provides a media independent, RTP independent, 2140 and codec independent solution for keeping the NAT bindings alive. 2142 If an ICE implementation is communciating with one that does not 2143 support ICE, keepalives MUST still be sent. Indeed, these keepalives 2144 are essential even if neither endpoint implements ICE. As such, this 2145 specification defines keepalive behavior generally, for endpoints 2146 that support ICE, and those that do not. 2148 All endpoints MUST send keepalives for each media session. These 2149 keepalives MUST be sent regardless of whether the media stream is 2150 currently inactive, sendonly, recvonly or sendrecv. The keepalive 2151 SHOULD be sent using a format which is supported by its peer. ICE 2152 endpoints allow for STUN-based keepalives for UDP streams, and as 2153 such, STUN keepalives MUST be used when an agent is communicating 2154 with a peer that supports ICE. An agent can determine that its peer 2155 supports ICE by the presence of the a=candidate attributes for each 2156 media session. If the peer does not support ICE, the choice of a 2157 packet format for keepalives is a matter of local implementation. A 2158 format which allows packets to easily be sent in the absence of 2159 actual media content is RECOMMENDED. Examples of formats which 2160 readily meet this goal are RTP No-Op [31] and RTP comfort noise [26]. 2162 STUN-based keepalives will be sent periodically every Tr seconds as a 2163 consequence of the rules in in Section 7.7. If STUN keepalives are 2164 not in use (because the peer does not support ICE), an agent SHOULD 2165 ensure that a media packet is sent every Tr seconds. If one is not 2166 sent as a consequence of normal media communications, a keepalive 2167 packet using one of the formats discussed above SHOULD be sent. 2169 7.13 Sending Media 2171 When an agent receives an offer and sends an answer, or when it 2172 receives an answer to an offer it sent, it begins connectivity 2173 checks. These checks will include validation of the active candidate 2174 pair, if there was one. An agent SHOULD NOT send media on the active 2175 candidate pair until that candidate pair has reached the Valid or 2176 Recv-Valid state. This is to help prevent a denial-of-service 2177 attack, described in Section 13. Once the active candidate pair 2178 reaches the Valid or Recv-Valid state, an agent MAY start sending 2179 media to that candidate pair. 2181 However, offer/answer exchanges are used with protocols, like SIP, 2182 which require media to be sent "early", from the answerer to the 2183 offer, prior to completion of the initial offer/answer exchange. It 2184 is highly desirable (and sometimes necessary) for this early media to 2185 use the candidate pair ultimately selected by ICE connectivity 2186 checks. For this reason, ICE provides an early media mechanism that 2187 allows for a candidate pair to be used in one direction prior to its 2188 promotion to active in a subsequent offer/answer exchange. Note 2189 that, with ICE, early media pertains to media sent to a candidate 2190 pair until its promotion to active in a subsequent offer/answer 2191 exchange. This is a broader definition than is used in [29], which 2192 defines early media as media sent prior to acceptance of a call. 2194 As a consequence of the connectivity checks, an agent will change the 2195 states for each transport address pair, and consequently, for the 2196 candidate pairs. When a candidate pair becomes Valid or Recv-Valid, 2197 and the candidate pair is not equal to the active candidate pair, and 2198 the agent is in the role of answerer for that candidate pair, the 2199 agent checks the position of that pair in the candidate pair priority 2200 ordered list. If it is the first, the agent selects this candidate 2201 pair for early media. If this candidate pair is not the first on the 2202 candidate pair priority ordered list, but is higher priority than the 2203 active candidate pair, and the early media wait-state timer has not 2204 yet been set, the agent sets this timer to Tws seconds. Tws SHOULD 2205 be configurable, and SHOULD have a default of 100ms. This timer 2206 allows for a higher priority connectivity check to complete, in the 2207 event its STUN Binding Request or Response was lost or delayed in the 2208 network. If, prior to the wait-state timer firing, another 2209 connectivity check completes and a candidate pair enters the Valid or 2210 Recv-Valid states, there is no need to reset or cancel the timer. 2211 Once the timer fires, the agent SHOULD select the highest priority 2212 candidate pair in the Valid or Recv-Valid state for which the agent 2213 has the role of answerer, and use that candidate pair for early 2214 media. 2216 ICE processing will ensure that, under almost all circumstances, the 2217 candidate pair selected by the answerer for early media will also be 2218 the one selected by the offerer for eventual promotion to active. 2219 The early media state implies that the answerer knows that this 2220 candidate pair is to be used, but the offerer doesn't know yet that 2221 it will eventually be validated. It is for this reason that the 2222 candidate pair can be used for early media. 2224 If a candidate pair is selected for early media, an agent MAY send 2225 media on that candidate pair, even if it is not the same as the 2226 active candidate pair. However, to deal with cases in which the 2227 offerer and answerer do not agree on the eventual selection of this 2228 candidate for promotion to active (a rare but possible case), the 2229 agent MUST discontinue using the candidate pair for sending media Tlo 2230 seconds after the answer has been reliably delivered. An answer is 2231 considered reliably delivered when the agent receives a confirmation 2232 that is has been delivered. In the case of an answer delivered in a 2233 200 OK to an offer in an INVITE (in the SIP case), the answer is 2234 considered reliably delivered upon receipt of the ACK. Tlo SHOULD be 2235 configurable and SHOULD have a default of 5 seconds. This time 2236 represents the amount of time it should take the offerer to perform 2237 its connectivity checks, arrive at the same conclusion about the 2238 viability of the early candidate, and then generate an updated offer 2239 promoting it to active. If, after Tlo seconds, no updated offer 2240 arrives, the answerer MUST cease using the early candidate. Media 2241 MAY be sent to the active candidate pair if it is in the Valid or 2242 Recv-Valid state. 2244 If an updated offer does arrive prior to the expiration of the timer, 2245 the agent MUST execute the procedures in Section 7.11.2, which will 2246 result in the selection of a candidate for the m/c-line in the 2247 answer. At that point, the procedures of this section SHOULD be 2248 restarted by the answerer. This implies that the active candidate 2249 pair, if Valid or Recv-Valid, will be used. If a higher priority 2250 candidate pair subsequently enters the Valid or Recv-Valid state, it 2251 may end up being used as an early candidate. 2253 To use a candidate pair, whether it is early or active, media is sent 2254 to the IP addresses and ports of the components in the remote 2255 candidate, and sends that media from the IP addresses and ports of 2256 the components in the native candidate. Transport addresses are 2257 paired up based on component ID. For example, if a remote candidate 2258 has two components R1 and R2, and the native candidate has two 2259 components L1 and L2, media packets are sent from L1 to R1 and from 2260 L2 to R2. This provides a property known as symmetry. This 2261 symmetric behavior MUST be followed by an agent even if its peer in 2262 the session doesn't support ICE. 2264 The definition of sending media "from" a particular transport address 2265 depends on the type of transport address. In the case of a server 2266 reflexive transport address, this means that the RTP packets are sent 2267 from the local transport address used to obtain the STUN address. In 2268 the case of a relayed transport address, this means that media 2269 packets are sent through the relay server (for STUN relays, this 2270 would be using the Send request). For local transport addresses, 2271 media is sent from that local transport address. For peer reflexive 2272 transport addresses, media is sent from the local transport address 2273 used to obtain the reflexive address. 2275 ICE has interactions with jitter buffer adaptation mechanisms. An 2276 RTP stream can begin using one candidate, and switch to another one. 2277 The newer candidate may result in RTP packets taking a different path 2278 through the network - one with different delay characteristics. As 2279 discussed below, agents are encouraged to re-adjust jitter buffers 2280 when there are changes in source or destination address. 2281 Furthermore, many audio codecs use the marker bit to signal the 2282 beginning of a talkspurt, for the purposes of jitter buffer 2283 adaptation. For such codecs, it is RECOMMENDED that the sender 2284 change the marker bit when an agent switches transmission of media 2285 from one candidate pair to another. 2287 7.14 Receiving Media 2289 ICE implementations MUST be prepared to receive media on a candidate 2290 pair if it is in the role of offerer for that candidate pair, even if 2291 that candidate pair is not currently active. This is a consequence 2292 of the early media mechanism described in the previous section. 2294 If an agent determines that its peer supports ICE (an offerer knows 2295 this when the answer contains a=candidate attributes), it SHOULD 2296 discard any media packets received on a candidate pair prior to the 2297 candidate pair entering the Send Valid state. This helps eliminate 2298 certain attacks, as discussed in Section 13. 2300 It is RECOMMENDED that, when an agent receives an RTP packet with a 2301 new source or destination IP address for a particular media stream, 2302 that the agent re-adjust its jitter buffers. 2304 RFC 3550 [23] describes an algorithm in Section 8.2 for detecting 2305 SSRC collisions and loops. These algorithms are based, in part, on 2306 seeing different source IP addresses and ports with the same SSRC. 2307 However, when ICE is used, such changes will naturally occur as the 2308 media streams switch between candidates. An agent will be able to 2309 determine that a media stream is from the same peer as a consequence 2310 of the STUN exchange that proceeds media transmission. Thus, if 2311 there is a change in source IP address and port, but the media 2312 packets come from the same peer agent, this SHOULD NOT be treated as 2313 an SSRC collision. 2315 8. Guidelines for Usage with SIP 2317 SIP [2] makes use of the offer/answer model, and is one of the 2318 primary targets for usage of ICE. SIP allows for offer/answer 2319 exchanges to occur in many different combinations of messages, 2320 including INVITE/200 OK and 200 OK/ACK. When support for reliable 2321 provisional responses (RFC 3262 [11]) and UPDATE (RFC 3311 [27]) are 2322 added, additional combinations of messages that can be used for 2323 offer/answer exchanges are added. As such, this section provides 2324 some guidance on good ways to make use of SIP with ICE. 2326 ICE requires a series of STUN-based connectivity checks to take place 2327 between endpoints. These checks start from the answerer on 2328 generation of its answer, and start from the offerer when it receives 2329 the answer. These checks can take time to complete, and as such, the 2330 selection of messages to use with offers and answers can effect 2331 perceived user latency. Two latency of figures are of particular 2332 interest. These are the post-pickup delay and the post-dial delay. 2333 The post-pickup delay refers to the time between when a user "answers 2334 the phone" and when any speech they utter can be delivered to the 2335 caller. The post-dial delay refers to the time between when a user 2336 enters the destination address for the user, and ringback begins as a 2337 consequence of having succesfully started ringing the phone of the 2338 called party. 2340 To reduce post-dial delays, it is RECOMMENDED that the caller begin 2341 gathering candidates prior to actually sending its initial INVITE. 2342 This can be started upon user interface cues that a call is pending, 2343 such as activity on a keypad or the phone going offhook. 2345 To reduce post-pickup delays, ICE allows for media to be sent from 2346 the answerer to the offerer on a candidate pair, prior to its 2347 promotion to active. However, this requires the answerer to have 2348 generated its answer and sent it. In most cases, it will require 2349 this answer to be received by the offerer. The reason is that 2350 connectivity checks or RTP packets from the answerer to the offerer 2351 will not be forwarded by NATs towards the offerer until the offerer 2352 has established a permission in the NAT by generating a packet 2353 towards the answerer. 2355 For this reason, if an offer is received in an INVITE request, the 2356 UAS SHOULD immediately gather its candidates and then generate an 2357 answer in a provisional response. When reliable provisional 2358 responses are not used, the SDP in the provisional response is not 2359 formally the answer; the value in the 200 OK is the actual answer. 2360 However, RFC 3261 allows for SDP to appear in an unreliable 2361 provisional response, in which case its value has to be identical to 2362 the value placed in the 200 OK. Thus, we refer to the SDP in the 2363 provisional response, even when unreliable, as the answer. To deal 2364 with possible losses of the provisional response, it SHOULD be 2365 retransmitted until some indication of receipt. This indication can 2366 either be through PRACK [11], or through the receipt of a STUN 2367 Binding Request with a correct username and password. Even if PRACK 2368 is not used, the provisional response SHOULD be retransmitted using 2369 the exponential backoff described in [11]. Furthermore, once the 2370 answer has been sent, the agent SHOULD begin its connectivity checks. 2371 Once a candidate reaches the Valid or Recv-Valid state, the UAS has a 2372 known-valid path for media packets towards the UAC. This point is 2373 called the connected point in ICE. 2375 Once the UAS reaches the connected point, media can be sent from the 2376 UAS towards the UAC without any additional delays. However, between 2377 the receipt of the INVITE and the connected point, any media that 2378 needs to be sent towards the caller (such as SIP early media [29] 2379 cannot be transmitted. For this reason, implementations MAY choose 2380 to delay alerting the called party until the connected point is 2381 reached. In the case of a PSTN gateway, this would mean that the 2382 setup message into the PSTN is delayed until the connected point. 2383 Doing this increases the post-dial delay, but has the effect of 2384 eliminating 'ghost rings'. Ghost rings are cases where the called 2385 party hears the phone ring, picks up, but hears nothing and cannot be 2386 heard. This technique works without requiring support for, or usage 2387 of, preconditions [7], since its a localized decision. It also has 2388 the benefit of guaranteeing that not a single packet of early media 2389 will get clipped. If an agent chooses to delay local alerting in 2390 this way, it SHOULD generate a 180 response once alerting begins. 2392 A slight variation of this approach is to wait for a connectivity 2393 check to succeed to a higher priority candidate pair than the active 2394 one. This allows for the agent to only ever send media, early or 2395 otherwise, to a single candidate, which will work better with jitter 2396 buffers, at the expense of even greater post-dial delays. 2398 Note that, prior to the promotion of a candidate pair to active, the 2399 offerer will not be able to send using the candidate pair. When used 2400 with SIP, if the initial offer is sent in the INVITE, and the answer 2401 is sent in both the provisional and final 200 OK response, the 2402 offerer will not be able to send media until it sends a re-INVITE and 2403 receives the 200 OK response to that re-INVITE. This can take 2404 several hundred milliseconds. If this latency is an issue (it is 2405 generally not considered an issue for voice systems), reliable 2406 provisional responses [11] MAY be used, in which case an UPDATE [27] 2407 can be used to send an updated offer prior to the call being 2408 answered. 2410 As discussed in Section 13, offer/answer exchanges SHOULD be secured 2411 against eavesdropping and man-in-the-middle attacks. To do that, the 2412 usage of SIPS [2] is RECOMMENDED when used in concert with ICE. 2414 9. Interactions with Forking 2416 SIP allows INVITE requests carrying offers to fork, which means that 2417 they are delivered to multiple user agents. Each of those user 2418 agents then provides an answer to the offer in the INVITE. The 2419 result is that a single offer generated by the UAC produces multiple 2420 answers. 2422 ICE interacts very well with forking. Indeed, ICE fixes some of the 2423 problems associated with forking. Once the offer/answer exchange has 2424 completed, the UAC will have an answer from each UAS that received 2425 the INVITE. The ICE connectivity checks that ensue will carry 2426 transport address pair IDs that correlate each of those checks (and 2427 thus their corresponding IP addresses and ports) with a specific 2428 remote user agent. As these checks happen before any media is 2429 transmitted, ICE allows a UAC to disambiguate subsequent media 2430 traffic by looking at the source IP address and port, and then 2431 correlate that traffic with a particular remote UA. When SIP is used 2432 without ICE, the incoming media traffic cannot be disambiguated 2433 without an additional offer/answer exchange. 2435 10. Interactions with Preconditions 2437 Because ICE involves multiple addresses and pre-session activities, 2438 its interactions with preconditions merits further discussion. 2440 Quality of Service (QoS) preconditions, which are defined in RFC 3312 2441 [7] and RFC 4032 [8], apply only to the IP addresses and ports listed 2442 in the m/c lines in an offer/answer. If ICE changes the address and 2443 port where media is received, this change is reflected in the m/c 2444 lines of a new offer/answer. As such, it appears like any other re- 2445 INVITE would, and is fully treated in RFC 3312 and 4032, which 2446 applies without regard to the fact that the m/c lines are changing 2447 due to ICE negotiations ocurring "in the background". 2449 However, usage of early candidates with QoS preconditions is NOT 2450 RECOMMENDED, since QoS will only be reserved for the candidate pair 2451 in the m/c-line. An agent SHOULD only send to the active candidate 2452 (once it enters the Valid or Recv-Valid states) if QoS preconditions 2453 are used for a media session. 2455 ICE also has (purposeful) interactions with connectivity 2456 preconditions [30]. Those interactions are described there. 2458 11. Examples 2460 This section provides two examples. One is a very basic example, and 2461 the other is more elaborate. A common configuration and setup is 2462 used in both cases. 2464 Two agents, L and R, are using ICE. Both agents have a single IPv4 2465 interface, and are configured with a single STUN server each (indeed, 2466 the same one for each). This STUN server supports both the Binding 2467 Discovery usage and the Relay usage. Agent L is behind a NAT, and 2468 agent R is on the public Internet. 2470 To facilitate understanding, transport addresses are listed in a 2471 mnemonic form. This form is entity-type-seqno, where entity refers 2472 to the entity whose interface the transport address is on, and is one 2473 of "L", "R", "STUN", or "NAT". The type is either "PUB" for 2474 transport addresses that are public, and "PRIV" for transport 2475 addresses that are private. Finally, seq-no is a sequence number 2476 that is different for each transport address of the same type on a 2477 particular entity. 2479 The STUN server has advertised transport address STUN-PUB-1 for both 2480 the binding discovery usage and the relay usage. 2482 In addition, candidate IDs are also listed in mnemonic form. Agent L 2483 uses candidate ID L1 for its local candidate, L2 for its server 2484 reflexive candidate, and L3 for its relayed candidate. Agent R uses 2485 R1 for its local candidate and R2 for its relayed candidate. The 2486 password is LPASS for each candidate from agent L, and RPASS for each 2487 candidate from agent R. 2489 In example SDP messages, $TADDR.IP is used to refer to the value of 2490 the IP address of the transport address with mnemonic name "taddr". 2491 Similarly, $TADDR.PORT is used to refer to the value of the port of 2492 the transport address with mnemonic name "TADDR". 2494 In the call flow itself, STUN messages are annotated with several 2495 attributes. The "S=" attribute indicates the source transport 2496 address of the message. The "D=" attribute indicates the destination 2497 transport address of the message. The "MA=" attribute is used in 2498 STUN Binding Response messages, STUN Binding Response messages 2499 carried in a STUN Send Request or Data Indication, and in a Allocate 2500 Response, and refers to the reflexive transport address derived from 2501 the XOR-MAPPED-ADDRESS attribute. The "RA=" attribute is used in 2502 STUN Data Indications, and refers to the value of the REMOTE-ADDRESS 2503 attribute. The "U=" attribute is used in STUN Requests, and 2504 corresponds to the STUN USERNAME. The "DA=" attribute is used in 2505 STUN Send requests, and refers to the value of the DESTINATION- 2506 ADDRESS attribute. The "R=" attribute is used in Allocate responses, 2507 and it indicates the value of the RELAY-ADDRESS attribute. 2509 The call flow examples omit STUN authentication operations. 2511 11.1 Basic Example 2513 In this example, the NAT has the address and port independent mapping 2514 property and the address dependent permission property. Neither 2515 agent is using the STUN relay usage, only the binding discovery 2516 usage. As a consequence, agent L will end up with two candidates - a 2517 local candidate and a server reflexive candidate. Agent R will have 2518 one - a local candidate (the reflexive candidate will be identical to 2519 the local one, and thus discarded). The agents are seeking to 2520 communicate using a single RTP-based voice stream. RTCP is not used. 2521 As a consequence, each candidate has one component. 2523 L NAT STUN R 2524 | | | | 2525 | | | | 2526 | | | | 2527 |RTP STUN alloc. | | 2528 | | | | 2529 | | | | 2530 | | | | 2531 |(1) STUN Req | | | 2532 |S=L-PRIV-1 | | | 2533 |D=STUN-PUB-1 | | | 2534 |------------->| | | 2535 | | | | 2536 | | | | 2537 | |(2) STUN Req | | 2538 | |S=NAT-PUB-1 | | 2539 | |D=STUN-PUB-1 | | 2540 | |------------->| | 2541 | | | | 2542 | |(3) STUN Res | | 2543 | |S=STUN-PUB-1 | | 2544 | |D=NAT-PUB-1 | | 2545 | |MA=NAT-PUB-1 | | 2546 | |<-------------| | 2547 | | | | 2548 |(4) STUN Res | | | 2549 |S=STUN-PUB-1 | | | 2550 |D=L-PRIV-1 | | | 2551 |MA=NAT-PUB-1 | | | 2552 |<-------------| | | 2553 | | | | 2554 | | | | 2555 | | | | 2556 | | | | 2557 |(5) Offer | | | 2558 |------------------------------------------->| 2559 | | | | 2560 | | | | 2561 | | | | 2562 | | | | 2563 | | | |RTP STUN alloc. 2564 | | | | 2565 | | | | 2566 | | | | 2567 | | |(6) STUN Req | 2568 | | |S=R-PUB-1 | 2569 | | |D=STUN-PUB-1 | 2570 | | |<-------------| 2571 | | | | 2572 | | |(7) STUN Res | 2573 | | |S=STUN-PUB-1 | 2574 | | |D=R-PUB-1 | 2575 | | |MA=R-PUB-1 | 2576 | | |------------->| 2577 | | | | 2578 | | | | 2579 | | | | 2580 | | | | 2581 |(8) answer | | | 2582 |<-------------------------------------------| 2583 | | | | 2584 | | | | 2585 |(9) Bind Req | | | 2586 |S=L-PRIV-1 | | | 2587 |D=R-PUB-1 | | | 2588 |------------->| | | 2589 | | | | 2590 | | | | 2591 | |(10) Bind Req | | 2592 | |S=NAT-PUB-1 | | 2593 | |D=R-PUB-1 | | 2594 | |---------------------------->| 2595 | | | | 2596 | |(11) Bind Res | | 2597 | |S=R-PUB-1 | | 2598 | |D=NAT-PUB-1 | | 2599 | |MA=NAT-PUB-1 | | 2600 | |<----------------------------| 2601 | | | | 2602 |(12) Bind Res | | | 2603 |S=R-PUB-1 | | | 2604 |D=L-PRIV-1 | | | 2605 |MA=NAT-PUB-1 | | | 2606 |<-------------| | | 2607 | | | | 2608 | | | | 2609 | | | | 2610 | | | | 2611 |RTP flows | | | 2612 | | | | 2613 | | | | 2614 | | | | 2615 | |(13) Bind Req | | 2616 | |S=R-PUB-1 | | 2617 | |D=NAT-PUB-1 | | 2618 | |<----------------------------| 2619 | | | | 2620 | | | | 2621 |(14) Bind Req | | | 2622 |S=R-PUB-1 | | | 2623 |D=L-PRIV-1 | | | 2624 |<-------------| | | 2625 | | | | 2626 |(15) Bind Res | | | 2627 |S=L-PRIV-1 | | | 2628 |D=R-PUB-1 | | | 2629 |MA=R-PUB-1 | | | 2630 |------------->| | | 2631 | | | | 2632 | |(16) Bind Res | | 2633 | |S=NAT-PUB-1 | | 2634 | |D=R-PUB-1 | | 2635 | |MA=R-PUB-1 | | 2636 | |---------------------------->| 2637 | | | | 2638 | | | | 2639 | | | | 2640 | | | | 2641 | | | |RTP flows 2642 | | | | 2643 | | | | 2644 | | | | 2645 | | | | 2646 | | | | 2647 | | | | 2648 | | | | 2650 Figure 8 2652 First, agent L obtains a server reflexive transport address for its 2653 RTP packets (messages 1-4). Recall that the NAT has the address and 2654 port independent mapping property. Here, it creates a binding of 2655 NAT-PUB-1 for this UDP request, and this becomes the server reflexive 2656 transport address for RTP, the sole component of its server reflexive 2657 candidate. 2659 With its two candidates, agent L prioritizes them, choosing the local 2660 candidate as highest priority, followed by the server reflexive 2661 candidate. It chooses its server reflexive candidate as the active 2662 candidate, and encodes it into the m/c-line. The resulting offer 2663 (message 5) looks like: 2665 v=0 2666 o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP 2667 s= 2668 c=IN IP4 $STUN-PUB-1.IP 2669 t=0 0 2670 a=ice-pwd:$LPASS 2671 m=audio $STUN-PUB-1.PORT RTP/AVP 0 2672 a=rtpmap:0 PCMU/8000 2673 a=candidate $L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT 2674 a=candidate $L2 1 UDP 0.7 $NAT-PUB-1.IP $NAT-PUB-1.PORT 2676 This offer is received at agent R. Agent R will gather its server 2677 reflexive transport address (messages 6-7). Since R is not behind a 2678 NAT, this address is identical to its local transport address, and 2679 thus does not represent a separate candidate. It therefore ends up 2680 with a single local candidate with a single component for RTP. Its 2681 resulting answer looks like: 2683 v=0 2684 o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP 2685 s= 2686 c=IN IP4 $R-PUB-1.IP 2687 t=0 0 2688 a=ice-pwd:$RPASS 2689 m=audio $R-PUB-1.PORT RTP/AVP 0 2690 a=rtpmap:0 PCMU/8000 2691 a=candidate $R1 1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT 2693 Next, agents L and R form candidate pairs and the transport address 2694 check ordered list. This list will start with the single component 2695 in the currently active candidate pair, L2:1:R1:1. Agent L begins 2696 its connectivity checks (messages 9-12), which succeed, placing the 2697 transport address pair and resulting candidate pair into the Recv- 2698 Valid state. Media can now flow. When agent R receives this request 2699 (message 10), the state of the candidate pair moves to Send-Valid. 2700 Agent R begins its connectivity checks (messages 13-16). When the 2701 check arrives at the NAT (message 13), it is permitted to pass since 2702 a permission was created towards $R-PUB-1 as a consequence of message 2703 10. This check arrives at agent L, which generates a success 2704 response (message 11), and updates the state of the candidate pair to 2705 Valid. This response arrives at agent R, which also updates the 2706 state of the candidate pair to valid. Now, media can flow from agent 2707 R to agent L as well. 2709 11.2 Advanced Example 2711 In this more advanced example, The NAT has address and port dependent 2712 mapping and filtering properties. Both agents use the STUN relay 2713 usage in addition to the binding discovery usage. As a consequence, 2714 agent L will end up with three candidates - a local candidate, a 2715 relayed candidate, and a server reflexive candidate. Agent R will 2716 have two - a local candidate and a relayed candidate (the server 2717 reflexive candidate will equal the local candidate and thus not be 2718 used). The agents are seeking to communicate using a single RTP- 2719 based voice stream, but are using RTCP. As a consequence, each 2720 candidate has two components - one for RTP and one for RTCP. 2722 L NAT STUN R 2723 | | | | 2724 | | | | 2725 | | | | 2726 |RTP Alloc. | | | 2727 | | | | 2728 | | | | 2729 | | | | 2730 |(1) Alloc Req | | | 2731 |S=L-PRIV-1 | | | 2732 |D=STUN-PUB-1 | | | 2733 |------------->| | | 2734 | | | | 2735 | | | | 2736 | |(2) Alloc Req | | 2737 | |S=NAT-PUB-1 | | 2738 | |D=STUN-PUB-1 | | 2739 | |------------->| | 2740 | |(3) Alloc Res | | 2741 | |S=STUN-PUB-1 | | 2742 | |D=NAT-PUB-1 | | 2743 | |R=STUN-PUB-2 | | 2744 | |MA=NAT-PUB-1 | | 2745 | |<-------------| | 2746 |(4) Alloc Res | | | 2747 |S=STUN-PUB-1 | | | 2748 |D=L-PRIV-1 | | | 2749 |R=STUN-PUB-2 | | | 2750 |MA=NAT-PUB-1 | | | 2751 |<-------------| | | 2752 | | | | 2753 | | | | 2754 | | | | 2755 |RTCP Alloc. | | | 2756 |Ta secs. later| | | 2757 | | | | 2758 | | | | 2759 | | | | 2760 |(5) Alloc Req | | | 2761 |S=L-PRIV-2 | | | 2762 |D=STUN-PUB-1 | | | 2763 |------------->| | | 2764 | | | | 2765 | | | | 2766 | |(6) Alloc Req | | 2767 | |S=NAT-PUB-2 | | 2768 | |D=STUN-PUB-1 | | 2769 | |------------->| | 2770 | |(7) Alloc Res | | 2771 | |S=STUN-PUB-1 | | 2772 | |D=NAT-PUB-2 | | 2773 | |R=STUN-PUB-3 | | 2774 | |MA=NAT-PUB-2 | | 2775 | |<-------------| | 2776 |(8) Alloc Res | | | 2777 |S=STUN-PUB-1 | | | 2778 |D=L-PRIV-2 | | | 2779 |R=STUN-PUB-3 | | | 2780 |MA=NAT-PUB-2 | | | 2781 |<-------------| | | 2782 | | | | 2783 | | | | 2784 | | | | 2785 | | | | 2786 |(9) Offer | | | 2787 |------------------------------------------->| 2788 | | | | 2789 | | | | 2790 | | | | 2791 | | | | 2792 | | | |RTP Alloc. 2793 | | | | 2794 | | | | 2795 | | | | 2796 | | |(10) Alloc Req| 2797 | | |S=R-PUB-1 | 2798 | | |D=STUN-PUB-1 | 2799 | | |<-------------| 2800 | | |(11) Alloc Res| 2801 | | |S=STUN-PUB-1 | 2802 | | |D=R-PUB-1 | 2803 | | |R=STUN-PUB-4 | 2804 | | |MA=R-PUB-1 | 2805 | | |------------->| 2806 | | | | 2807 | | | | 2808 | | | | 2809 | | | |RTCP Alloc. 2810 | | | |Ta secs. later 2811 | | | | 2812 | | | | 2813 | | | | 2814 | | |(12) Alloc Req| 2815 | | |S=R-PUB-2 | 2816 | | |D=STUN-PUB-1 | 2817 | | |<-------------| 2818 | | |(13) Alloc Res| 2819 | | |S=STUN-PUB-1 | 2820 | | |D=R-PUB-2 | 2821 | | |R=STUN-PUB-5 | 2822 | | |MA=R-PUB-2 | 2823 | | |------------->| 2824 | | | | 2825 | | | | 2826 | | | | 2827 | | | | 2828 |(14) answer | | | 2829 |<-------------------------------------------| 2830 | | | | 2831 | | | | 2832 | | | | 2833 | | | |Validate 2834 | | | |STUN-PUB-4 to STUN-PUB-2 2835 | | | | 2836 | | | | 2837 | | |(15) Send Ind | 2838 | | |S=R-PUB-1 | 2839 | | |D=STUN-PUB-1 | 2840 | | |DA=STUN-PUB-2 | 2841 | | |<-------------| 2842 | | | | 2843 | | |Bind Req. | 2844 | | |S=STUN-PUB-4 | 2845 | | |D=STUN-PUB-2 | 2846 | | |U=L3:1:R2:1 | 2847 | | | | 2848 | | | | 2849 | | | | 2850 | | | | 2851 | | | | 2852 | | |Discard | 2853 | | | | 2854 | | | | 2855 | | | | 2856 | | | | 2857 |Validate | | | 2858 |STUN-PUB-2 to STUN-PUB-4 | | 2859 | | | | 2860 | | | | 2861 |(16) Send Ind | | | 2862 |S=L-PRIV-1 | | | 2863 |D=STUN-PUB-1 | | | 2864 |DA=STUN-PUB-4 | | | 2865 |------------->| | | 2866 | | | | 2867 | |(17) Send Ind | | 2868 | |S=NAT-PUB-1 | | 2869 | |D=STUN-PUB-1 | | 2870 | |DA=STUN-PUB-4 | | 2871 | |------------->| | 2872 | | | | 2873 | | |Bind Req. | 2874 | | |S=STUN-PUB-2 | 2875 | | |D=STUN-PUB-4 | 2876 | | |U=R2:1:L3:1 | 2877 | | | | 2878 | | | | 2879 | | |(18) Data Ind | 2880 | | |S=STUN-PUB-1 | 2881 | | |D=R-PUB-1 | 2882 | | |RA=STUN-PUB-2 | 2883 | | |------------->| 2884 | | |(19) Send Ind | 2885 | | |S=R-PUB-1 | 2886 | | |D=STUN-PUB-1 | 2887 | | |DA=STUN-PUB-2 | 2888 | | |MA=STUN-PUB-2 | 2889 | | |<-------------| 2890 | | | | 2891 | | |Bind Res. | 2892 | | |S=STUN-PUB-4 | 2893 | | |D=STUN-PUB-2 | 2894 | | |MA=STUN-PUB-2 | 2895 | | | | 2896 | |(20) Data Ind | | 2897 | |S=STUN-PUB-1 | | 2898 | |D=NAT-PUB-1 | | 2899 | |RA=STUN-PUB-4 | | 2900 | |MA=STUN-PUB-2 | | 2901 | |<-------------| | 2902 |(21) Data Ind | | | 2903 |S=STUN-PUB-1 | | | 2904 |D=L-PRIV-1 | | | 2905 |RA=STUN-PUB-4 | | | 2906 |MA=STUN-PUB-2 | | | 2907 |<-------------| | | 2908 | | | | 2909 | | | | 2910 | | | | 2911 | | | |Validate 2912 | | | |STUN-PUB-4 to STUN-PUB-2 2913 | | | | 2914 | | | | 2915 | | |(22) Send Ind | 2916 | | |S=R-PUB-1 | 2917 | | |D=STUN-PUB-1 | 2918 | | |DA=STUN-PUB-2 | 2919 | | |<-------------| 2920 | | | | 2921 | | |Bind Req. | 2922 | | |S=STUN-PUB-4 | 2923 | | |D=STUN-PUB-2 | 2924 | | |U=L3:1:R2:1 | 2925 | | | | 2926 | | | | 2927 | |(23) Data Ind | | 2928 | |S=STUN-PUB-1 | | 2929 | |D=NAT-PUB-1 | | 2930 | |RA=STUN-PUB-4 | | 2931 | |<-------------| | 2932 | | | | 2933 |(24) Data Ind | | | 2934 |S=STUN-PUB-1 | | | 2935 |D=L-PRIV-1 | | | 2936 |RA=STUN-PUB-4 | | | 2937 |<-------------| | | 2938 |(25) Send Ind | | | 2939 |S=L-PRIV-1 | | | 2940 |D=STUN-PUB-1 | | | 2941 |DA=STUN-PUB-4 | | | 2942 |MA=STUN-PUB-4 | | | 2943 |------------->| | | 2944 | |(26) Send Ind | | 2945 | |S=NAT-PUB-1 | | 2946 | |D=STUN-PUB-1 | | 2947 | |DA=STUN-PUB-4 | | 2948 | |MA=STUN-PUB-4 | | 2949 | |------------->| | 2950 | | | | 2951 | | |Bind Res. | 2952 | | |S=STUN-PUB-2 | 2953 | | |D=STUN-PUB-4 | 2954 | | |MA=STUN-PUB-4 | 2955 | | | | 2956 | | |(27) Data Ind | 2957 | | |S=STUN-PUB-1 | 2958 | | |D=R-PUB-1 | 2959 | | |RA=STUN-PUB-2 | 2960 | | |MA=STUN-PUB-4 | 2961 | | |------------->| 2962 | | | | 2963 | | | | 2964 | | | | 2965 | | | |Validate 2966 | | | |STUN-PUB-5 to STUN-PUB-3 2967 | | | | 2968 | | | | 2969 | | |(28) Send Ind | 2970 | | |S=R-PUB-2 | 2971 | | |D=STUN-PUB-1 | 2972 | | |DA=STUN-PUB-3 | 2973 | | |<-------------| 2974 | | | | 2975 | | |Bind Req. | 2976 | | |S=STUN-PUB-5 | 2977 | | |D=STUN-PUB-3 | 2978 | | |U=L3:2:R2:2 | 2979 | | | | 2980 | | | | 2981 | | | | 2982 | | | | 2983 | | | | 2984 | | |Discard | 2985 | | | | 2986 | | | | 2987 | | | | 2988 | | | | 2989 |Validate | | | 2990 |STUN-PUB-3 to STUN-PUB-5 | | 2991 | | | | 2992 | | | | 2993 |(29) Send Ind | | | 2994 |S=L-PRIV-2 | | | 2995 |D=STUN-PUB-1 | | | 2996 |DA=STUN-PUB-5 | | | 2997 |------------->| | | 2998 | | | | 2999 | |(30) Send Ind | | 3000 | |S=NAT-PUB-2 | | 3001 | |D=STUN-PUB-1 | | 3002 | |DA=STUN-PUB-5 | | 3003 | |------------->| | 3004 | | | | 3005 | | |Bind Req. | 3006 | | |S=STUN-PUB-3 | 3007 | | |D=STUN-PUB-5 | 3008 | | |U=R2:2:L3:2 | 3009 | | | | 3010 | | | | 3011 | | |(31) Data Ind | 3012 | | |S=STUN-PUB-1 | 3013 | | |D=R-PUB-2 | 3014 | | |RA=STUN-PUB-3 | 3015 | | |------------->| 3016 | | |(32) Send Ind | 3017 | | |S=R-PUB-2 | 3018 | | |D=STUN-PUB-1 | 3019 | | |DA=STUN-PUB-3 | 3020 | | |MA=STUN-PUB-3 | 3021 | | |<-------------| 3022 | | | | 3023 | | |Bind Res. | 3024 | | |S=STUN-PUB-5 | 3025 | | |D=STUN-PUB-3 | 3026 | | |MA=STUN-PUB-3 | 3027 | | | | 3028 | |(33) Data Ind | | 3029 | |S=STUN-PUB-1 | | 3030 | |D=NAT-PUB-2 | | 3031 | |RA=STUN-PUB-5 | | 3032 | |MA=STUN-PUB-3 | | 3033 | |<-------------| | 3034 |(34) Data Ind | | | 3035 |S=STUN-PUB-1 | | | 3036 |D=L-PRIV-2 | | | 3037 |RA=STUN-PUB-5 | | | 3038 |MA=STUN-PUB-3 | | | 3039 |<-------------| | | 3040 | | | | 3041 | | | | 3042 | | | | 3043 | | | |Validate 3044 | | | |STUN-PUB-5 to STUN-PUB-3 3045 | | | | 3046 | | | | 3047 | | |(35) Send Ind | 3048 | | |S=R-PUB-2 | 3049 | | |D=STUN-PUB-1 | 3050 | | |DA=STUN-PUB-3 | 3051 | | |<-------------| 3052 | | | | 3053 | | |Bind Req. | 3054 | | |S=STUN-PUB-5 | 3055 | | |D=STUN-PUB-3 | 3056 | | |U=L3:2:R2:2 | 3057 | | | | 3058 | | | | 3059 | |(36) Data Ind | | 3060 | |S=STUN-PUB-1 | | 3061 | |D=NAT-PUB-2 | | 3062 | |RA=STUN-PUB-5 | | 3063 | |<-------------| | 3064 | | | | 3065 |(37) Data Ind | | | 3066 |S=STUN-PUB-1 | | | 3067 |D=L-PRIV-2 | | | 3068 |RA=STUN-PUB-5 | | | 3069 |<-------------| | | 3070 |(38) Send Ind | | | 3071 |S=L-PRIV-2 | | | 3072 |D=STUN-PUB-1 | | | 3073 |DA=STUN-PUB-5 | | | 3074 |MA=STUN-PUB-5 | | | 3075 |------------->| | | 3076 | |(39) Send Ind | | 3077 | |S=NAT-PUB-2 | | 3078 | |D=STUN-PUB-1 | | 3079 | |DA=STUN-PUB-5 | | 3080 | |MA=STUN-PUB-5 | | 3081 | |------------->| | 3082 | | | | 3083 | | |Bind Res. | 3084 | | |S=STUN-PUB-3 | 3085 | | |D=STUN-PUB-5 | 3086 | | |MA=STUN-PUB-5 | 3087 | | | | 3088 | | |(40) Data Ind | 3089 | | |S=STUN-PUB-1 | 3090 | | |D=R-PUB-2 | 3091 | | |RA=STUN-PUB-3 | 3092 | | |MA=STUN-PUB-5 | 3093 | | |------------->| 3094 | | | | 3095 | | | | 3096 | | | | 3097 | | | | 3098 |RTP flows | | | 3099 | | | | 3100 | | | | 3101 |(41) Send Ind | | | 3102 |S=L-PRIV-1 | | | 3103 |D=STUN-PUB-1 | | | 3104 |DA=STUN-PUB-4 | | | 3105 |------------->| | | 3106 | | | | 3107 | |(42) Send Ind | | 3108 | |S=NAT-PUB-1 | | 3109 | |D=STUN-PUB-1 | | 3110 | |DA=STUN-PUB-4 | | 3111 | |------------->| | 3112 | | | | 3113 | | | | 3114 | | |RTP | 3115 | | |S=STUN-PUB-2 | 3116 | | |D=STUN-PUB-4 | 3117 | | | | 3118 | | | | 3119 | | |(43) Data Ind | 3120 | | |S=STUN-PUB-1 | 3121 | | |D=R-PUB-1 | 3122 | | |RA=STUN-PUB-2 | 3123 | | |------------->| 3124 | | | | 3125 | | | | 3126 | | | | 3127 | | | | 3128 | | | |RTP flows 3129 | | | | 3130 | | | | 3131 | | |(44) Send Ind | 3132 | | |S=R-PUB-1 | 3133 | | |D=STUN-PUB-1 | 3134 | | |DA=STUN-PUB-2 | 3135 | | |<-------------| 3136 | | | | 3137 | | | | 3138 | | |RTP | 3139 | | |S=STUN-PUB-4 | 3140 | | |D=STUN-PUB-2 | 3141 | | | | 3142 | | | | 3143 | |(45) Data Ind | | 3144 | |S=STUN-PUB-1 | | 3145 | |D=NAT-PUB-1 | | 3146 | |RA=STUN-PUB-4 | | 3147 | |<-------------| | 3148 | | | | 3149 |(46) Data Ind | | | 3150 |S=STUN-PUB-1 | | | 3151 |D=L-PRIV-1 | | | 3152 |RA=STUN-PUB-4 | | | 3153 |<-------------| | | 3154 | | | | 3155 | | | | 3156 | | | | 3157 |Validate | | | 3158 |L-PRIV-1 to R-PUB-1 | | 3159 | | | | 3160 | | | | 3161 |(47) Bind Req.| | | 3162 |S=L-PRIV-1 | | | 3163 |D=R-PUB-1 | | | 3164 |U=R1:1:L1:1 | | | 3165 |------------->| | | 3166 | | | | 3167 | |(48) Bind Req.| | 3168 | |S=NAT-PUB-3 | | 3169 | |D=R-PUB-1 | | 3170 | |U=R1:1:L1:1 | | 3171 | |---------------------------->| 3172 | | | | 3173 | |(49) Bind Res.| | 3174 | |S=R-PUB-1 | | 3175 | |D=NAT-PUB-3 | | 3176 | |MA=NAT-PUB-3 | | 3177 | |<----------------------------| 3178 | | | | 3179 |(50) Bind Res.| | | 3180 |S=R-PUB-1 | | | 3181 |D=L-PRIV-1 | | | 3182 |MA-NAT-PUB-3 | | | 3183 |<-------------| | | 3184 | | | | 3185 | | | | 3186 | | | | 3187 | | | |Validate 3188 | | | |R-PUB-1 to L-PRIV-1 3189 | | | | 3190 | | | | 3191 | |(51) Bind Req.| | 3192 | |S=R-PUB-1 | | 3193 | |D=L-PRIV-1 | | 3194 | |U=L1:1:R1:1 | | 3195 | |<----------------------------| 3196 | | | | 3197 | | | | 3198 | | | | 3199 | | | | 3200 | |Discard | | 3201 | | | | 3202 | | | | 3203 | | | | 3204 | | | | 3205 | | | |Validate 3206 | | | |R-PUB-2 to L-PRIV-2 3207 | | | | 3208 | | | | 3209 | |(52) Bind Req.| | 3210 | |S=R-PUB-2 | | 3211 | |D=L-PRIV-2 | | 3212 | |U=L1:2:R1:2 | | 3213 | |<----------------------------| 3214 | | | | 3215 | | | | 3216 | | | | 3217 | | | | 3218 | |Discard | | 3219 | | | | 3220 | | | | 3221 | | | | 3222 | | | | 3223 |Validate | | | 3224 |L-PRIV-2 to R-PUB-2 | | 3225 | | | | 3226 | | | | 3227 |(53) Bind Req.| | | 3228 |S=L-PRIV-2 | | | 3229 |D=R-PUB-2 | | | 3230 |U=R1:2:L1:2 | | | 3231 |------------->| | | 3232 | | | | 3233 | |(54) Bind Req.| | 3234 | |S=NAT-PUB-4 | | 3235 | |D=R-PUB-2 | | 3236 | |U=R1:2:L1:2 | | 3237 | |---------------------------->| 3238 | | | | 3239 | |(55) Bind Res.| | 3240 | |S=R-PUB-2 | | 3241 | |D=NAT-PUB-4 | | 3242 | |MA=NAT-PUB-4 | | 3243 | |<----------------------------| 3244 | | | | 3245 |(56) Bind Res.| | | 3246 |S=R-PUB-2 | | | 3247 |D=L-PRIV-2 | | | 3248 |MA=NAT-PUB-4 | | | 3249 |<-------------| | | 3250 | | | | 3251 | | | | 3252 | | | | 3253 | | | |Validate 3254 | | | |R-PUB-1 to NAT-PUB-3 3255 | | | | 3256 | | | | 3257 | |(57) Bind Req.| | 3258 | |S=R-PUB-1 | | 3259 | |D=NAT-PUB-3 | | 3260 | |U=L1R1:1:R1:1 | | 3261 | |<----------------------------| 3262 | | | | 3263 |(58) Bind Req.| | | 3264 |S=R-PUB-1 | | | 3265 |D=L-PRIV-1 | | | 3266 |U=L1R1:1:R1:1 | | | 3267 |<-------------| | | 3268 | | | | 3269 |(59) Bind Res.| | | 3270 |S=L-PRIV-1 | | | 3271 |D=R-PUB-1 | | | 3272 |MA=R-PUB-1 | | | 3273 |------------->| | | 3274 | | | | 3275 | |(60) Bind Res.| | 3276 | |S=NAT-PUB-3 | | 3277 | |D=R-PUB-1 | | 3278 | |MA=R-PUB-1 | | 3279 | |---------------------------->| 3280 | | | | 3281 | | | | 3282 | | | | 3283 | | | |Validate 3284 | | | |R-PUB-2 to NAT-PUB-4 3285 | | | | 3286 | | | | 3287 | |(61) Bind Req.| | 3288 | |S=R-PUB-2 | | 3289 | |D=NAT-PUB-4 | | 3290 | |U=L1R1:2:R1:2 | | 3291 | |<----------------------------| 3292 | | | | 3293 |(62) Bind Req.| | | 3294 |S=R-PUB-2 | | | 3295 |D=L-PRIV-2 | | | 3296 |U=L1R1:2:R1:2 | | | 3297 |<-------------| | | 3298 | | | | 3299 |(63) Bind Res.| | | 3300 |S=L-PRIV-2 | | | 3301 |D=R-PUB-2 | | | 3302 |MA=R-PUB-2 | | | 3303 |------------->| | | 3304 | | | | 3305 | |(64) Bind Res.| | 3306 | |S=NAT-PUB-4 | | 3307 | |D=R-PUB-2 | | 3308 | |MA=R-PUB-2 | | 3309 | |---------------------------->| 3310 | | | | 3311 | | | | 3312 | | | | 3313 | | | | 3314 |(65) Offer | | | 3315 |------------------------------------------->| 3316 | | | | 3317 | | | | 3318 | | | | 3319 | | | | 3320 |(66) Answer | | | 3321 |<-------------------------------------------| 3322 | | | | 3323 | | | | 3324 | | | | 3325 | | | | 3326 | | | | 3327 | | | | 3329 Figure 11 3331 First, agent L obtains both server reflexive and relayed transport 3332 addresses for its RTP packets, using a STUN Allocate request, which 3333 will provide it with both types of addresses (messages 1-4). Recall 3334 that the NAT has the address and port dependent mapping property. 3335 Here, it creates a binding of NAT-PUB-1 for this UDP request, and 3336 this becomes the server reflexive transport address for RTP. The 3337 relayed transport address is STUN-PUB-2, allocated by the STUN 3338 server. Agent L repeats this process for RTCP (messages 5-8) Ta 3339 seconds later, and obtains NAT-PUB-2 as its server reflexive 3340 transport address for RTCP and STUN-PUB-3 for its relayed transport 3341 address. 3343 With its three candidates, agent L prioritizes them, choosing the 3344 local candidate as highest priority, followed by the server reflexive 3345 candidate, followed by the relayed candidate. It chooses its relayed 3346 candidate as the active candidate, and encodes it into the m/c-line. 3347 The resulting offer (message 17) looks like: 3349 v=0 3350 o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP 3351 s= 3352 c=IN IP4 $STUN-PUB-2.IP 3353 t=0 0 3354 a=ice-pwd:$LPASS 3355 m=audio $STUN-PUB-2.PORT RTP/AVP 0 3356 a=rtpmap:0 PCMU/8000 3357 a=rtcp:$STUN-PUB-3.PORT 3358 a=candidate $L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT 3359 a=candidate $L1 2 UDP 1.0 $L-PRIV-2.IP $L-PRIV-2.PORT 3360 a=candidate $L2 1 UDP 0.7 $NAT-PUB-1.IP $NAT-PUB-1.PORT 3361 a=candidate $L2 2 UDP 0.7 $NAT-PUB-2.IP $NAT-PUB-2.PORT 3362 a=candidate $L3 1 UDP 0.3 $STUN-PUB-2.IP $STUN-PUB-2.PORT 3363 a=candidate $L3 2 UDP 0.3 $STUN-PUB-3.IP $STUN-PUB-3.PORT 3365 This offer is received at agent R. Agent R will gather its server 3366 reflexive and relayed transport addresses for RTP from an Allocate 3367 request (messages 10-11). Since the server reflexive transport 3368 address matches its local transport address, no separate candidate is 3369 used for it. The agent then gathers its server reflexive and relayed 3370 transport addresses for RTCP (messages 12-13). It prioritizes the 3371 local candidate with higher priority than the relayed candidate, and 3372 selects the relayed candidate as the active candidate. Its resulting 3373 answer looks like: 3375 v=0 3376 o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP 3377 s= 3378 c=IN IP4 $STUN-PUB-4.IP 3379 t=0 0 3380 a=ice-pwd:$RPASS 3381 m=audio $STUN-PUB-4.PORT RTP/AVP 0 3382 a=rtpmap:0 PCMU/8000 3383 a=rtcp:$STUN-PUB-5.PORT 3384 a=candidate $R1 1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT 3385 a=candidate $R1 2 UDP 1.0 $R-PUB-2.IP $R-PUB-2.PORT 3386 a=candidate $R2 1 UDP 0.3 $STUN-PUB-4.IP $STUN-PUB-4.PORT 3387 a=candidate $R2 2 UDP 0.3 $STUN-PUB-5.IP $STUN-PUB-5.PORT 3389 Next, agents L and R form candidate pairs and the transport address 3390 check ordered list. This list will start with the two components in 3391 the currently active candidate pair - relayed candidates. Agent R 3392 begins its checks (message 15). It will check connectivity between 3393 the active candidate pair, starting with the first component, which 3394 is STUN-PUB-4 for agent R and STUN-PUB-2 for agent L. The state 3395 machine for that transport address pair moves to the Testing state. 3397 Since this is a relayed transport address for agent R, it utilizes 3398 the STUN Send Indication to deliver the Binding Request. The 3399 DESTINATION-ADDRESS is STUN-PUB-2. 3401 The STUN server will extract the content of the Send indication, 3402 which is a STUN Binding Request, and deliver it to the destination, 3403 STUN-PUB-4. This request will be sent from the relayed address 3404 allocated to R, which is STUN-PUB-4. As both interfaces are on the 3405 STUN server, this message is sent to itself (and thus the lack of a 3406 message number in the sequence diagram above). Note that the 3407 USERNAME in the Binding Request is L3:1:R2:1, which represents the 3408 transport address pair ID. This message gets discarded by the STUN 3409 server since, as of yet, there are no permissions established for the 3410 STUN-PUB-2 allocation. However, it did have the side effect of 3411 establishing a permission on the STUN-PUB-4 binding, allowing 3412 incoming packets from STUN-PUB-2. 3414 Once L gets the offer, it will attempt to validate the first 3415 transport address pair in the transport address pair check ordered 3416 list, which will be the active candidate. The state machine for this 3417 transport address pair moves into the Testing state. Like agent R 3418 did, it will use the STUN Send Indication to send a STUN Binding 3419 Request from its relayed transport address, STUN-PUB-2, to STUN-PUB-4 3420 (message 16). This packet traverses the NAT (message 17) and arrives 3421 at the STUN server. The STUN server will unwrap the contents of the 3422 packet and send them from STUN-PUB-2 to STUN-PUB-4. It will also, as 3423 a consequence, add a permission for STUN-PUB-4. The contents of the 3424 packet are a STUN Binding Request with USERNAME R2:1:L3:1 (note how 3425 this is the flip of the USERNAME in the Binding Request sent by agent 3426 R). This is also a packet from the STUN server to itself. However, 3427 now, the packet is not discarded, as a permission had been installed 3428 as a consequence of the "suicide packet" from agent R (a suicide 3429 packet is a packet that has no hope of traversing a far end NAT, but 3430 serves the purpose of enabling a permission in a near end NAT so that 3431 a packet from the peer can be returned). Thus, the STUN server will 3432 relay the received STUN request towards agent R (message 18). This 3433 is delivered as a STUN Data Indication. Notice how the REMOTE- 3434 ADDRESS is STUN-PUB-2; this is important as it will be used to 3435 construct the STUN Binding Response. 3437 Agent R will receive the Data Indication, and unwrap its contents to 3438 find the Binding Request. The state machine for this transport 3439 address pair is currently in the Testing state. It therefore moves 3440 into the Send-Valid state, and it generates a Binding Response. 3441 However, the XOR-MAPPED-ADDRESS in the Binding Response is 3442 constructed using the source IP address and port that were seen by 3443 the STUN server when the Binding Request arrived at STUN-PUB-4, which 3444 is the looped message between messages 17 and 18. This source 3445 address is STUN-PUB-2, which is the value of the REMOTE-ADDRESS 3446 attribute in message 18. Thus, the STUN Binding Response will 3447 contain STUN-PUB-2 in the XOR-MAPPED-ADDRESS, and is to be sent to 3448 STUN-PUB-2. To send the response, agent R takes the STUN Binding 3449 Response and encapsulates it in a STUN Send indication, setting the 3450 DESTINATION-ADDRESS to STUN-PUB-2. This is shown in message 19. 3452 The STUN server will receive this Send Indication, and unwrap its 3453 contents to find the STUN Binding Response. It sends it to the value 3454 of the DESTINATION-ADDRESS attribute, and sends it from the relayed 3455 address allocated to R, which is STUN-PUB-4. This, once again, 3456 results in a looped message to itself, and it arrives at STUN-PUB-2. 3457 Now, however, there is a permission installed for STUN-PUB-4. The 3458 STUN server will therefore forward the packet to agent L. To do so, 3459 it constructs a STUN Data Indication containing the contents of the 3460 packet. It sets the REMOTE-ADDRESS to the source transport address 3461 of the request it received (STUN-PUB-4), and forwards it to agent L 3462 (message 20). This traverses the NAT (message 21) and arrives at 3463 agent L. As a consequence of the receipt of a Binding Response, the 3464 state machine for this transport address pair moves to the Recv-Valid 3465 state. The agent also examines the XOR-MAPPED-ADDRESS of the STUN 3466 response. It indicates STUN-PUB-2. This is the same as the native 3467 transport address of this transport address pair, and thus doesn't 3468 represent a new transport address that might have been learned. 3470 Because of the receipt of message 18, the transport address pair 3471 moved from Testing to Send-Valid, causing R to attempt a 3472 retransmission of its STUN Binding Request that was lost (the 3473 contents of message 15 that were discarded by the STUN server due to 3474 lack of permission). This time, however, a permission has been 3475 installed and the retransmission will work. So, it sends the Binding 3476 Request again (message 22, identical to message 15). This is looped 3477 by the STUN server to itself again, but this time there is a 3478 permission in place when it arrives at STUN-PUB-2. As such, the 3479 request is forwarded towards agent L this time, in a STUN Data 3480 Indication (message 23). This traverses the NAT (message 24) and 3481 arrives at agent L. Agent L extracts the contents of the request, 3482 which are a STUN Binding Request. This causes the state machine to 3483 move from Recv-Valid to Valid. It generates a STUN Binding Response, 3484 and sets the XOR-MAPPED-ADDRESS based on the value of the REMOTE- 3485 ADDRESS in message 24 (STUN-PUB-4). This Binding Response is sent to 3486 STUN-PUB-4, which is accomplished through a STUN Send Indication 3487 (message 25). This Send Indication traverses the NAT (message 26) 3488 and is received by the STUN server. Its contents are decapsulated, 3489 and sent to STUN-PUB-4, which is again a loop on the same host. This 3490 packet is then sent towards agent R in a Data Indication (message 3491 27). The contents of the DATA Indication are extracted, and the 3492 agent sees a successful Binding Response. It therefore moves the 3493 state machine from the Send-Valid state to the Valid state. At this 3494 point, the transport address pair is in the Valid state for both 3495 agents. 3497 Approximately Ta seconds after agent R sent message 15, agent R will 3498 start checks for the next transport address pair in its transport 3499 address pair check ordered list. This is the second component of the 3500 same candidate pair, used for RTCP. This sequence, messages 28 3501 through 40, are identical to the ones for RTP, but differ only in the 3502 specific transport addresses. 3504 Once that validation happens, the second transport address pair has 3505 been validated. The candidate pair moves into the valid state, and 3506 both candidates are considered valid. The active candidate has now 3507 been validated, and media can begin to flow. It will do so through 3508 the STUN server; indeed, it is relayed "twice" through the STUN 3509 server. Even though there is a single STUN server, it is logically 3510 acting as two separate STUN servers. Indeed, had L and R used two 3511 separate STUN servers, media would be relayed through both STUN 3512 servers in a trapezoid configuration. 3514 The actual media flows are shown as well. It is important to note 3515 that, since the ICE checks have not yet concluded on the candidate 3516 that will ultimately be used, no STUN Set Active Destinations have 3517 been sent. As a consequence, media that is sent through the STUN 3518 servers has to be sent using STUN Send indications. This introduces 3519 some overhead, but is a transient condition. In message 41, agent L 3520 sends an RTP packet to agent R using a Send indication. It is sent 3521 to STUN-PUB-4. This traverses the NAT (message 42), and arrives at 3522 the STUN server. It is decapsulated, looped to itself, and arrives 3523 at STUN-PUB-4. From there, it is encapsulated in a Data Indication 3524 and sent to agent R (message 43). In the reverse direction, agent R 3525 will send an RTP packet using a STUN Send indication (message 42), 3526 and send it to STUN-PUB-2. This is received by the STUN server, 3527 decapsulated, and sent to STUN-PUB-2 from STUN-PUB-4. This is again 3528 a loop within the same host, arriving at STUN-PUB-4. The contents of 3529 the packet are sent to agent L through a STUN Data Indication 3530 (message 45), which traverses the NAT (message 46) to arrive at agent 3531 L. Since this call flow is already long enough, RTCP packet 3532 transmission is not shown. 3534 Approximately Ta seconds after it sends message 29, agent L goes to 3535 the next transport address pair in its transport address pair check 3536 ordered list that is in the Waiting state. This will be the RTP 3537 candidate for the top priority candidate pair, which is L-PRIV-1 on 3538 agent L and R-PUB-1 on agent R. This is a local candidate for each 3539 agent. To perform the check, agent L sends a STUN Binding Request 3540 from L-PRIV-1 to R-PUB-1 (message 47). Note the USERNAME of 3541 R1:1:L1:1, which identifies this transport address pair. This 3542 traverses the NAT (message 48). Since the NAT has the address and 3543 port dependent mapping property, and this is a new destination IP 3544 address, the NAT allocates a new transport address on its public 3545 side, NAT-PUB-3, and places this in the source IP address and port. 3546 This packet arrives at agent R. Agent R finds a matching transport 3547 address pair in the Waiting state. The state machine transitions to 3548 the Send-Valid state. It sends the Binding response, with a XOR- 3549 MAPPED-ADDRESS indicating NAT-PUB-3 (message 49), which traverses the 3550 NAT and arrives at agent L (message 50). Agent R, in addition to 3551 sending the response, will also send a Binding Request. It is 3552 important to remember that this Binding Request is sent to the remote 3553 address in the transport address pair (L-PRIV-1), and NOT to the 3554 source IP address and port of the Binding Request (NAT-PUB-3); that 3555 will happen later. This attempt is shown in message 51. However, 3556 since the L-PRIV-1 is private, the packet is discarded in the 3557 network. 3559 Now, as a consequence of receiving message 48, agent R will have 3560 constructed a peer-derived candidate. The candidate ID for this 3561 candidate is L1R1, and it initially contains a single transport 3562 address pair, NAT-PUB-3 and R-PUB-1. However, the candidate isn't 3563 yet usable until the other component gets added. Similarly, agent L 3564 will have constructed the same peer-derived candidate, with the same 3565 candidate ID and the same transport address pair. 3567 Some Ta seconds after sending message 28, agent R will move to the 3568 next transport address pair in the transport address pair check 3569 ordered list whose state is Waiting. This is the RTCP component of 3570 the highest priority candidate pair. It will attempt a connectivity 3571 check, from R-PUB-2 to L-PRIV-2 (message 52). Since L-PRIV-1 is 3572 private, this message is discarded. 3574 Some Ta seconds after sending message 47, agent L will move to the 3575 next transport address pair in the transport address pair check 3576 ordered list whose state is Waiting. This is the RTCP component of 3577 the highest priority candidate pair. It will attempt a connectivity 3578 check, from L-PRIV-2 to R-PUB-2 (message 53), which operates nearly 3579 identically to messages 47-50, with the exception of the specific 3580 addresses. Here, the NAT will create a new binding for the RTCP, 3581 NAT-PUB-4, and this transport address is new for both participants. 3582 On receipt of this Binding Request at agent R (message 54), agent R 3583 constructs the candidate ID for the peer-derived candidate, L1R1, and 3584 finds it already exists. As such, this new transport address is 3585 added, and the peer-derived candidate becomes complete and usable. 3586 Agent L does the same thing on receipt of message 56. This candidate 3587 will have the same priority as its generating candidate L1 (1.0), and 3588 is paired up with R1 (also at priority 1.0). Since L1R1 has the same 3589 priority as L1 itself, the ordering algorithm in Section 7.5 will use 3590 the reverse lexicographic order of the candidate ID iself to 3591 determine order. L1R1 is larger than L1, so that the peer-derived 3592 candidate will come before its generating candidate. As a 3593 consequence, the peer-derived candidate pair will have a higher 3594 priority than its generating candidate, and appear just before it in 3595 the candidate pair priority ordered list. 3597 As a consequence, after agent R sends message 55 and completes the 3598 peer-derived candidate, it will move the two transport addresses in 3599 the peer derived candidate into the Send-Valid state, and send a 3600 Binding Request for each in rapid succession (agent L will have moved 3601 both into the Recv-Valid state upon receipt of message 56). The 3602 first of these connectivity checks are for the RTP component, from 3603 R-PUB-1 to NAT-PUB-3 (message 57). Note the USERNAME in the STUN 3604 Binding Request, L1R1:1:R1:1, which identifies the peer-derived 3605 transport address pair. This will succesfully traverse the NAT and 3606 be delivered to agent L (message 58). The receipt of this request 3607 moves the state machine for this transport address pair from Recv- 3608 Valid to Valid, and a Binding Response is sent (message 59). This 3609 passes through the NAT and arrives at agent R (message 60). This 3610 causes its state machine to enter the Valid state as well. The 3611 reflexive transport address, R-PUB-1, is not new to agent R and thus 3612 does not result in the creation of a new peer-derived candidate. 3614 Messages 61 through 64 show the same basic flow for RTCP. Upon 3615 receipt of message 64, both transport address pairs are Valid at both 3616 agents, causing the peer derived candidate to become valid. Timer 3617 Tws is set at agent L, and fires without any higher priority 3618 candidate pairs becoming validated. At agent R, media can now be 3619 sent on this candidate pair from answerer (agent R) to offerer (agent 3620 L). Agent L sends an updated offer to promote the peer-derived 3621 candidate to active. This offer (message 65) looks like: 3623 v=0 3624 o=jdoe 2890844526 2890842808 IN IP4 $L-PRIV-1.IP 3625 s= 3626 c=IN IP4 $NAT-PUB-3.IP 3627 t=0 0 3628 a=ice-pwd:$LPASS 3629 m=audio $NAT-PUB-3.PORT RTP/AVP 0 3630 a=rtpmap:0 PCMU/8000 3631 a=rtcp:$NAT-PUB-4.PORT 3632 a=remote-candidate:R1 3633 a=candidate $L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT 3634 a=candidate $L1 2 UDP 1.0 $L-PRIV-2.IP $L-PRIV-2.PORT 3636 There are several important things to note in this offer. Firstly, 3637 note how the m/c-line now contains NAT-PUB-3 and NAT-PUB-4, the peer 3638 derived transport addresses it learned through the ICE processing. 3639 Secondly, note how there remains a candidate encoded into the 3640 a=candidate attributes. This is candidate L1, NOT candidate L1R1. 3641 Recall that the peer-derived candidates are never encoded into the 3642 SDP. Rather, their generating candidate is encoded. This will cause 3643 keepalives to take place for the generating candidate if valid 3644 (though its not) and any of its derived candidates, which is what we 3645 want. Finally, notice the inclusion of the a=remote-candidate 3646 attribute. Since agent L doesn't know whether agent R received 3647 messages 60 or 64, it doesnt know whether the state of the candidate 3648 is Send-Valid or Valid at agent R. So, it has to tell agent R that, 3649 in case its Send-Valid, to please use it anyway. 3651 The answer generated by agent R looks like: 3653 v=0 3654 o=bob 2808844564 2808844565 IN IP4 $R-PUB-1.IP 3655 s= 3656 c=IN IP4 $R-PUB-1.IP 3657 t=0 0 3658 a=ice-pwd:$RPASS 3659 m=audio $R-PUB-1.PORT RTP/AVP 0 3660 a=rtpmap:0 PCMU/8000 3661 a=rtcp:$R-PUB-2.PORT 3662 a=candidate $R1 1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT 3663 a=candidate $R1 2 UDP 1.0 $R-PUB-2.IP $R-PUB-2.PORT 3665 With this, media can now flow directly between endpoints. The 3666 removal of the relayed candidates from the offer/answer exchange will 3667 cause the STUN relay allocations to be removed. 3669 12. Grammar 3671 This specification defines three new SDP attributes - the 3672 "candidate", "remote-candidate" and "ice-pwd" attributes. 3674 The candidate attribute is a media-level attribute only. It contains 3675 a transport address for a candidate that can be used for connectivity 3676 checks. There may be multiple candidate attributes in a media block. 3678 The syntax of this attribute is defined using Augmented BNF as 3679 defined in RFC 4234 [9]: 3681 candidate-attribute = "candidate" ":" candidate-id SP component-id SP 3682 transport SP 3683 qvalue SP ;qvalue from RFC 3261 3684 addr SP ;addr from RFC 3266 3685 port ;port from RFC 2327 3686 *(SP extension-att-name SP 3687 extension-att-value) 3689 transport = "UDP" / transport-extension 3690 transport-extension = token 3691 candidate-id = 1*base64-char 3693 base64-char = ALPHANUM / DIGIT / "+" / "/" 3694 ;ALPHANUM from RFC 3261 3695 component-id = 1*DIGIT 3696 extension-att-name = byte-string ;from RFC 2327 3697 extension-att-value = byte-string 3699 The candidate-id is used to group together the transport addresses 3700 for a particular candidate. It MUST be constructed with at least 24 3701 bits of randomness. It MUST have the same value for all transport 3702 addresses within the same candidate. It MUST have a different value 3703 for transport addresses within different candidates for the same 3704 media stream. The candidate-id uses a syntax that is defined to be 3705 equal to the base64 alphabet [3], which allows the candidate-id to be 3706 generated by performing a base64 encoding of a randomly generated 3707 value (note, however, that this does not mean that the candidate-id 3708 or password is base64 decoded when use in STUN messages). In 3709 addition, if content is base64 encoded to generate the candidate-id, 3710 it MUST NOT be padded with '='. Section 2.2 of RFC 3548 indicates 3711 that some base64 usages do not require padding, and it requests that 3712 such usages call out that fact. ICE is one such usage. This is 3713 because the data is never decoded. The component-id is a positive 3714 integer, which identifies the specific component of the candidate. 3715 It MUST start at 1 and MUST increment by 1 for each component of a 3716 particular candidate. 3718 The addr production is taken from [10], allowing for IPv4 addresses, 3719 IPv6 addresses and FQDNs. The port production is taken from RFC 2327 3720 [5]. The token production is taken from RFC 3261 [2]. The transport 3721 production indicates the transport protocol for the candidate. This 3722 specification only defines UDP. However, extensibility is provided 3723 to allow for future transport protocols to be used with ICE, such as 3724 TCP or the Datagram Congestion Control Protocol (DCCP) [34]. 3726 The a=candidate attribute can itself be extended. The grammar allows 3727 for new name/value pairs to be added at the end of the attribute. An 3728 implementation MUST ignore any name/value pairs it doesn't 3729 understand. 3731 The syntax of the "remote-candidate" attribute is defined using 3732 Augmented BNF as defined in RFC 4234 [9]: 3734 remote-candidate-att = "remote-candidate" ":" candidate-id 3736 This attribute MUST be present in an offer when the candidate in the 3737 m/c-line is part of a candidate pair that is in the valid or 3738 partially valid state. 3740 The syntax of the "ice-pwd" attribute is defined as: 3742 ice-pwd-att = "ice-pwd" ":" password 3743 password = 1*base64-char 3745 The "ice-pwd" attribute can appear at either the session-level or 3746 media-level. When present in both, the value in the media-level 3747 takes precedence. Thus, the value at the session level is 3748 effectively a default that applies to all media streams, unless 3749 overriden by a media-level value. It MUST have at least 128 bits of 3750 randomness. Like the candidate-ID, its syntax is taken from the 3751 base64 alphabet, allowing the password to be generted from a base64 3752 encoding of a 128 bit value. In addition, if content is base64 3753 encoded to generate the candidate-id, it MUST NOT be padded with '='. 3755 13. Security Considerations 3757 There are several types of attacks possible in an ICE system. This 3758 section considers these attacks and their countermeasures. 3760 13.1 Attacks on Connectivity Checks 3762 An attacker might attempt to disrupt the STUN-based connectivity 3763 checks. Ultimately, all of these attacks fool an agent into thinking 3764 something incorrect about the results of the connectivity checks. 3765 The possible false conclusions an attacker can try and cause are: 3767 False Invalid: An attacker can fool a pair of agents into thinking a 3768 candidate pair is invalid, when it isn't. This can be used to 3769 cause an agent to prefer a different candidate (such as one 3770 injected by the attacker), or to disrupt a call by forcing all 3771 candidates to fail. 3773 False Valid: An attacker can fool a pair of agents into thinking a 3774 candidate pair is valid, when it isn't. This can cause an agent 3775 to proceed with a session, but then not be able to receive any 3776 media. 3778 False Peer-Derived Candidate: An attacker can cause an agent to 3779 discover a new peer-derived candidate, when it shouldn't have. 3780 This can be used to redirect media streams to a DoS target or to 3781 the attacker, for eavesdropping or other purposes. 3783 False Valid on False Candidate: An attacker has already convinced an 3784 agent that there is a candidate with an address that doesn't 3785 actually route to that agent (for example, by injecting a false 3786 peer-derived candidate or false STUN-derived candidate). It must 3787 then launch an attack that forces the agents to believe that this 3788 candidate is valid. 3790 Of the various techniques for creating faked STUN messages described 3791 in [13], many are not applicable for the connectivity checks. 3792 Compromises of STUN servers are not much of a concern, since the STUN 3793 servers are embedded in endpoints and distributed throughout the 3794 network. Thus, compromising the STUN server is equivalent to 3795 comprimising the endpoint, and if that happens, far more problematic 3796 attacks are possible than those against ICE. Similarly, DNS attacks 3797 are irrelevant since STUN servers are not discovered via DNS, they 3798 are signaled via SIP. Injection of fake responses and relaying 3799 modified requests all can be handled in ICE with the countermeasures 3800 discussed below. 3802 To force the false invalid result, the attacker has to wait for the 3803 connectivity check for one of the agents to be sent. When it is, the 3804 attacker needs to inject a fake response with an unrecoverable error 3805 response, such as a 600. This attack only needs to be launched 3806 against one of the agents in order to invalidate the candidate pair. 3807 However, since the candidate is, in fact, valid, the original request 3808 may reach the peer agent, and result in a success response. The 3809 attacker needs to force this packet or its response to be dropped, 3810 through a DoS attack, layer 2 network disruption, or other technique. 3811 If it doesn't do this, the success response will also reach the 3812 originator, alerting it to a possible attack. This will cause the 3813 agent to abandon the candidate, which is the desired result in any 3814 case. Fortunately, this attack is mitigated completely through the 3815 STUN message integrity mechanism. The attacker needs to inject a 3816 fake response, and in order for this response to be processed, the 3817 attacker needs the password. If the offer/answer signaling is 3818 secured, the attacker will not have the password. 3820 Forcing the fake valid result works in a similar way. The agent 3821 needs to wait for the Binding Request from each agent, and inject a 3822 fake success response. The attacker won't need to worry about 3823 disrupting the actual response since, if the candidate is not valid, 3824 it presumably wouldn't be received anyway. However, like the fake 3825 invalid attack, this attack is mitigated completely through the STUN 3826 message integrity and offer/answer security techniques. 3828 Forcing the false peer-derived candidate result can be done either 3829 with fake requests or responses, or with replays. We consider the 3830 fake requests and responses case first. It requires the attacker to 3831 send a Binding Request to one agent with a source IP address and port 3832 for the false transport address. In addition, the attacker must wait 3833 for a Binding Request from the other agent, and generate a fake 3834 response with a XOR-MAPPED-ADDRESS attribute. This attack is best 3835 launched against a candidate pair that is likely to be invalid, so 3836 the attacker doesnt need to contend with the actual responses to the 3837 real connectivity checks. Like the other attacks described here, 3838 this attack is mitigated by the STUN message integrity mechanisms and 3839 secure offer/answer exchanges. 3841 Forcing the false peer-derived candidate result with packet replays 3842 is different. The attacker waits until one of the agents sends a 3843 Binding Request for one of the transport address pairs. It then 3844 intercepts this request, and replays it towards the other agent with 3845 a faked source IP address. It must also prevent the original request 3846 from reaching the remote agent, either by launching a DoS attack to 3847 cause the packet to be dropped, or forcing it to be dropped using 3848 layer 2 mechanisms. The replayed packet is received at the other 3849 agent, and accepted, since the integrity check passes (the integrity 3850 check cannot and does not cover the source IP address and port). It 3851 is then responded to. This response will contain a XOR-MAPPED- 3852 ADDRESS with the false transport address. It is passed to the this 3853 false address. The attacker must then intercept it and relay it 3854 towards the originator. 3856 The other agent will then initiate a connectivity check towards that 3857 transport address. This validation needs to succeed. This requires 3858 the attacker to force a false valid on a false candidate. Injecting 3859 of fake requests or responses to achieve this goal is prevented using 3860 the integrity mechanisms of STUN and the offer/answer exchange. 3861 Thus, this attack can only be launched through replays. To do that, 3862 the attacker must intercept the Binding Request towards this false 3863 transport address, and replay it towards the other agent. Then, it 3864 must intercept the response and replay that back as well. 3866 This attack is very hard to launch unless the attacker themself is 3867 identified by the fake transport address. This is because it 3868 requires the attacker to intercept and replay packets sent by two 3869 different hosts. If both agents are on different networks (for 3870 example, across the public Internet), this attack can be hard to 3871 coordinate, since it needs to occur against two different endpoints 3872 on different parts of the network at the same time. 3874 If the attacker themself is identified by the fake transport address, 3875 the attack is easier to coordinate. However, if SRTP is used [24], 3876 the attacker will not be able to play the media packets, they will 3877 only be able to discard them, effectively disabling the media stream 3878 for the call. However, this attack requires the agent to disrupt 3879 packets in order to block the connectivity check from reaching the 3880 target. In that case, if the goal is to disrupt the media stream, 3881 its much easier to just disrupt it with the same mechanism, rather 3882 than attack ICE. 3884 13.2 Attacks on Address Gathering 3886 ICE endpoints make use of STUN for gathering addresses from a STUN 3887 server in the network. This is corresponds to the binding 3888 acquisition use case discussed in Section 10.1 of [13]. As a 3889 consequence, the attacks against STUN itself that are described in 3890 Section 12 [13] can still be used against the STUN address gathering 3891 operations that occur in ICE. 3893 However, the additional mechanisms provided by ICE actually 3894 counteract such attacks, making binding acquisition with STUN more 3895 secure when combined with ICE than without ICE. 3897 Consider an attacker which is able to provide an agent with a faked 3898 XOR-MAPPED-ADDRESS in a STUN Binding Request that is used for address 3899 gathering. This is the primary attack primitive described in Section 3900 12 of [13]. This address will be used as a STUN derived candidate in 3901 the ICE exchange. For this candidate to actually be used for media, 3902 the attacker must also attack the connectivity checks, and in 3903 particular, force a false valid on a false candidate. This attack is 3904 very hard to launch if the false address identifies a third party, 3905 and is prevented by SRTP if it identifies the attacker themself. 3907 If the attacker elects not to attack the connectivity checks, the 3908 worst it can do is prevent the STUN-derived address from being used. 3909 However, if the peer agent has at least one address that is reachable 3910 by the agent under attack, the STUN connectivity checks themselves 3911 will provide a STUN-derived address that can be used for the exchange 3912 of media. Peer derived candidates are preferred over the candidate 3913 they are generated from for this reason. As such, an attack solely 3914 on the STUN address gathering will normally have no impact on a call 3915 at all. 3917 13.3 Attacks on the Offer/Answer Exchanges 3919 An attacker that can modify or disrupt the offer/answer exchanges 3920 themselves can readily launch a variety of attacks with ICE. They 3921 could direct media to a target of a DoS attack, they could insert 3922 themselves into the media stream, and so on. These are similar to 3923 the general security considerations for offer/answer exchanges, and 3924 the security considerations in RFC 3264 [4] apply. These require 3925 techniques for message integrity and encryption for offers and 3926 answers, which are satisfied by the SIPS mechanism [2] when SIP is 3927 used. As such, the usage of SIPS with ICE is RECOMMENDED. 3929 13.4 Insider Attacks 3931 In addition to attacks where the attacker is a third party trying to 3932 insert fake offers, answers or stun messages, there are several 3933 attacks possible with ICE when the attacker is an authenticated and 3934 valid participant in the ICE exchange. 3936 13.4.1 The Voice Hammer Attack 3938 The voice hammer attack is an amplification attack, of the variety 3939 discussed in Section 3 of [32]. In this attack, the attacker 3940 initiates sessions to other agents, and includes the IP address and 3941 port of a DoS target in the m/c-line of their SDP. This causes 3942 substantial amplification; a single offer/answer exchange can create 3943 a continuing flood of media packets, possibly at high rates (consider 3944 video sources). This attack is not speific to ICE, but ICE can help 3945 provide remediation. 3947 Specifically, if ICE is used, the agent receiving the malicious SDP 3948 will first peform connectivity checks to the target of media before 3949 sending it there. If this target is a third party host, the checks 3950 will not succeed, and media is never sent. 3952 Unfortunately, ICE doesn't help if its not used, in which case an 3953 attacker could simply send the offer without the ICE parameters. 3954 However, in environments where the set of clients are known, and 3955 limited to ones that support ICE, the server can reject any offers or 3956 answers that don't indicate ICE support. 3958 13.4.2 STUN Amplification Attack 3960 The STUN amplification attack is similar to the voice hammer. 3961 However, instead of voice packets being directed to the target, STUN 3962 connectivity checks are directed to the target. This attack is 3963 accomplished by having the offerer send an offer with a large number 3964 of candidates, say 50. The answerer receives the offer, and starts 3965 its checks, which are directed at the target, and consequently, never 3966 generate a response. The answerer will start a new connectivity 3967 check every 50ms, and each check is a STUN transaction consisting of 3968 9 retransmits of a message 64 bytes in length. This produces a 3969 fairly substantial 92 kbps, just in STUN requests. 3971 It is impossible to eliminate the amplification, but the volume can 3972 be reduced through a variety of heuristics. For example, agents can 3973 limit the number of candidates they'll accept in an offer or answer, 3974 they can increase the value of Ta, or exponentially increase Ta as 3975 time goes on. All of these ultimately trade off the time for the ICE 3976 exchanges to complete, with the amount of traffic that gets sent. 3978 14. IANA Considerations 3980 This specification defines three new SDP attribute per the procedures 3981 of Appendix B of RFC 2327. The required information for the 3982 registrations are included here. 3984 14.1 candidate Attribute 3986 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 3988 Attribute Name: candidate 3990 Long Form: candidate 3992 Type of Attribute: media level 3994 Charset Considerations: The attribute is not subject to the charset 3995 attribute. 3997 Purpose: This attribute is used with Interactive Connectivity 3998 Establishment (ICE), and provides one of many possible candidate 3999 addresses for communication. These addresses are validated with 4000 an end-to-end connectivity check using Simple Traversal of UDP 4001 with NAT (STUN). 4003 Appropriate Values: See Section 12 of RFC XXXX [Note to RFC-ed: 4004 please replace XXXX with the RFC number of this specification]. 4006 14.2 remote-candidate Attribute 4008 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4010 Attribute Name: remote-candidate 4012 Long Form: remote-candidate 4014 Type of Attribute: media level 4016 Charset Considerations: The attribute is not subject to the charset 4017 attribute. 4019 Purpose: This attribute is used with Interactive Connectivity 4020 Establishment (ICE), and provides the identity of the remote 4021 candidate that the offerer wishes the answerer to use in its 4022 answer. 4024 Appropriate Values: See Section 12 of RFC XXXX [Note to RFC-ed: 4025 please replace XXXX with the RFC number of this specification]. 4027 14.3 ice-pwd Attribute 4029 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4031 Attribute Name: ice-pwd 4033 Long Form: ice-pwd 4035 Type of Attribute: session level 4037 Charset Considerations: The attribute is not subject to the charset 4038 attribute. 4040 Purpose: This attribute is used with Interactive Connectivity 4041 Establishment (ICE), and provides the password used to protect 4042 STUN connectivity checks. 4044 Appropriate Values: See Section 12 of RFC XXXX [Note to RFC-ed: 4045 please replace XXXX with the RFC number of this specification]. 4047 15. IAB Considerations 4049 The IAB has studied the problem of "Unilateral Self Address Fixing", 4050 which is the general process by which a agent attempts to determine 4051 its address in another realm on the other side of a NAT through a 4052 collaborative protocol reflection mechanism [22]. ICE is an example 4053 of a protocol that performs this type of function. Interestingly, 4054 the process for ICE is not unilateral, but bilateral, and the 4055 difference has a signficant impact on the issues raised by IAB. The 4056 IAB has mandated that any protocols developed for this purpose 4057 document a specific set of considerations. This section meets those 4058 requirements. 4060 15.1 Problem Definition 4062 From RFC 3424 any UNSAF proposal must provide: 4064 Precise definition of a specific, limited-scope problem that is to 4065 be solved with the UNSAF proposal. A short term fix should not be 4066 generalized to solve other problems; this is why "short term 4067 fixes usually aren't". 4069 The specific problems being solved by ICE are: 4071 Provide a means for two peers to determine the set of transport 4072 addresses which can be used for communication. 4074 Provide a means for resolving many of the limitations of other 4075 UNSAF mechanisms by wrapping them in an additional layer of 4076 processing (the ICE methodology). 4078 Provide a means for a agent to determine an address that is 4079 reachable by another peer with which it wishes to communicate. 4081 15.2 Exit Strategy 4083 From RFC 3424, any UNSAF proposal must provide: 4085 Description of an exit strategy/transition plan. The better short 4086 term fixes are the ones that will naturally see less and less use 4087 as the appropriate technology is deployed. 4089 ICE itself doesn't easily get phased out. However, it is useful even 4090 in a globally connected Internet, to serve as a means for detecting 4091 whether a router failure has temporarily disrupted connectivity, for 4092 example. ICE also helps prevent certain security attacks which have 4093 nothing to do with NAT. However, what ICE does is help phase out 4094 other UNSAF mechanisms. ICE effectively selects amongst those 4095 mechanisms, prioritizing ones that are better, and deprioritizing 4096 ones that are worse. Local IPv6 addresses can be preferred. As NATs 4097 begin to dissipate as IPv6 is introduced, derived transport addresses 4098 from other UNSAF mechanisms simply never get used, because higher 4099 priority connectivity exists. Therefore, the servers get used less 4100 and less, and can eventually be remove when their usage goes to zero. 4102 Indeed, ICE can assist in the transition from IPv4 to IPv6. It can 4103 be used to determine whether to use IPv6 or IPv4 when two dual-stack 4104 hosts communicate with SIP (IPv6 gets used). It can also allow a 4105 network with both 6to4 and native v6 connectivity to determine which 4106 address to use when communicating with a peer. 4108 15.3 Brittleness Introduced by ICE 4110 From RFC3424, any UNSAF proposal must provide: 4112 Discussion of specific issues that may render systems more 4113 "brittle". For example, approaches that involve using data at 4114 multiple network layers create more dependencies, increase 4115 debugging challenges, and make it harder to transition. 4117 ICE actually removes brittleness from existing UNSAF mechanisms. In 4118 particular, traditional STUN (as described in [16]) has several 4119 points of brittleness. One of them is the discovery process which 4120 requires a agent to try and classify the type of NAT it is behind. 4121 This process is error-prone. With ICE, that discovery process is 4122 simply not used. Rather than unilaterally assessing the validity of 4123 the address, its validity is dynamically determined by measuring 4124 connectivity to a peer. The process of determining connectivity is 4125 very robust. 4127 Another point of brittleness in STUN and any other unilateral 4128 mechanism is its absolute reliance on an additional server. ICE 4129 makes use of a server for allocating unilateral addresses, but allows 4130 agents to directly connect if possible. Therefore, in some cases, 4131 the failure of a STUN server would still allow for a call to progress 4132 when ICE is used. 4134 Another point of brittleness in traditional STUN is that it assumes 4135 that the STUN server is on the public Internet. Interestingly, with 4136 ICE, that is not necessary. There can be a multitude of STUN servers 4137 in a variety of address realms. ICE will discover the one that has 4138 provided a usable address. 4140 The most troubling point of brittleness in traditional STUN is that 4141 it doesn't work in all network topologies. In cases where there is a 4142 shared NAT between each agent and the STUN server, traditional STUN 4143 may not work. With ICE, that restriction can be lifted. 4145 Traditional STUN also introduces some security considerations. 4146 Fortunately, those security considerations are also mitigated by ICE. 4148 Consequently, ICE serves to repair the brittleness introduced in 4149 other UNSAF mechanisms, and does not introduce any additional 4150 brittleness into the system. 4152 15.4 Requirements for a Long Term Solution 4154 From RFC 3424, any UNSAF proposal must provide: 4156 Identify requirements for longer term, sound technical solutions 4157 -- contribute to the process of finding the right longer term 4158 solution. 4160 Our conclusions from STUN remain unchanged. However, we feel ICE 4161 actually helps because we believe it can be part of the long term 4162 solution. 4164 15.5 Issues with Existing NAPT Boxes 4166 From RFC 3424, any UNSAF proposal must provide: 4168 Discussion of the impact of the noted practical issues with 4169 existing, deployed NA[P]Ts and experience reports. 4171 A number of NAT boxes are now being deployed into the market which 4172 try and provide "generic" ALG functionality. These generic ALGs hunt 4173 for IP addresses, either in text or binary form within a packet, and 4174 rewrite them if they match a binding. This interferes with 4175 traditional STUN. However, the update to STUN [13] uses an encoding 4176 which hides these binary addresses from generic ALGs. Since [13] is 4177 required for all ICE implementations, this NAPT problem does not 4178 impact ICE. 4180 Existing NAPT boxes have non-deterministic and typically short 4181 expiration times for UDP-based bindings. This requires 4182 implementations to send periodic keepalives to maintain those 4183 bindings. ICE uses a default of 15s, which is a very conservative 4184 estimate. Eventually, over time, as NAT boxes become compliant to 4185 behave [37], this minimum keepalive will become deterministic and 4186 well-known, and the ICE timers can be adjusted. Having a way to 4187 discover the minimum keepalive interval would be far better still. 4189 16. Acknowledgements 4191 The authors would like to thank Flemming Andreasen, Rohan Mahy, Dean 4192 Willis, Dan Wing, Douglas Otis, Tim Moore, and Francois Audet for 4193 their comments and input. A special thanks goes to Magnus Westerlund 4194 for doing several detailed reviews on the various revisions of this 4195 specification. His input led to many substantive improvements in 4196 this document. 4198 17. References 4199 17.1 Normative References 4201 [1] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 4202 Session Description Protocol (SDP)", RFC 3605, October 2003. 4204 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 4205 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 4206 Session Initiation Protocol", RFC 3261, June 2002. 4208 [3] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 4209 RFC 3548, July 2003. 4211 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 4212 Session Description Protocol (SDP)", RFC 3264, June 2002. 4214 [5] Handley, M. and V. Jacobson, "SDP: Session Description 4215 Protocol", RFC 2327, April 1998. 4217 [6] Casner, S., "Session Description Protocol (SDP) Bandwidth 4218 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 4219 July 2003. 4221 [7] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 4222 Resource Management and Session Initiation Protocol (SIP)", 4223 RFC 3312, October 2002. 4225 [8] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation 4226 Protocol (SIP) Preconditions Framework", RFC 4032, March 2005. 4228 [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax 4229 Specifications: ABNF", RFC 4234, October 2005. 4231 [10] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in 4232 Session Description Protocol (SDP)", RFC 3266, June 2002. 4234 [11] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 4235 Responses in Session Initiation Protocol (SIP)", RFC 3262, 4236 June 2002. 4238 [12] Yon, D., "Connection-Oriented Media Transport in the Session 4239 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10 4240 (work in progress), November 2004. 4242 [13] Rosenberg, J., "Simple Traversal of UDP Through Network Address 4243 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-03 4244 (work in progress), March 2006. 4246 [14] Rosenberg, J., Mahy, R., and C. Huitema, "Obtaining Relay 4247 Addresses from Simple Traversal of UDP Through NAT (STUN)", 4248 Internet Draft draft-ietf-behave-turn-00.txt, February 2006. 4250 17.2 Informative References 4252 [15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 4253 Protocol (RTSP)", RFC 2326, April 1998. 4255 [16] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 4256 - Simple Traversal of User Datagram Protocol (UDP) Through 4257 Network Address Translators (NATs)", RFC 3489, March 2003. 4259 [17] Senie, D., "Network Address Translator (NAT)-Friendly 4260 Application Design Guidelines", RFC 3235, January 2002. 4262 [18] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for 4263 Generic Forward Error Correction", RFC 2733, December 1999. 4265 [19] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 4266 Rayhan, "Middlebox communication architecture and framework", 4267 RFC 3303, August 2002. 4269 [20] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm 4270 Specific IP: Framework", RFC 3102, October 2001. 4272 [21] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm 4273 Specific IP: Protocol Specification", RFC 3103, October 2001. 4275 [22] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 4276 Address Fixing (UNSAF) Across Network Address Translation", 4277 RFC 3424, November 2002. 4279 [23] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 4280 "RTP: A Transport Protocol for Real-Time Applications", 4281 RFC 3550, July 2003. 4283 [24] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 4284 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 4285 RFC 3711, March 2004. 4287 [25] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 4288 IPv4 Clouds", RFC 3056, February 2001. 4290 [26] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 4291 Comfort Noise (CN)", RFC 3389, September 2002. 4293 [27] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 4294 Method", RFC 3311, October 2002. 4296 [28] Bonica, R., Kompella, K., and D. Meyer, "Tracing Requirements 4297 for Generic Tunnels", RFC 3609, September 2003. 4299 [29] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone 4300 Generation in the Session Initiation Protocol (SIP)", RFC 3960, 4301 December 2004. 4303 [30] Andreasen, F., "Connectivity Preconditions for Session 4304 Description Protocol Media Streams", 4305 draft-ietf-mmusic-connectivity-precon-01 (work in progress), 4306 October 2005. 4308 [31] Andreasen, F., "A No-Op Payload Format for RTP", 4309 draft-ietf-avt-rtp-no-op-00 (work in progress), May 2005. 4311 [32] Rescorla, E. and M. Handley, "Internet Denial of Service 4312 Considerations", draft-iab-dos-03 (work in progress), 4313 September 2005. 4315 [33] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 4316 draft-huitema-v6ops-teredo-05 (work in progress), April 2005. 4318 [34] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 4319 draft-ietf-dccp-spec-13 (work in progress), December 2005. 4321 [35] Lazzaro, J., "Framing RTP and RTCP Packets over Connection- 4322 Oriented Transport", draft-ietf-avt-rtp-framing-contrans-06 4323 (work in progress), September 2005. 4325 [36] Hellstrom, G., "RTP Payload for Text Conversation", 4326 draft-ietf-avt-rfc2793bis-09 (work in progress), August 2004. 4328 [37] Audet, F. and C. Jennings, "NAT Behavioral Requirements for 4329 Unicast UDP", Internet Draft draft-ietf-behave-nat-udp-00.txt, 4330 February 2006. 4332 Author's Address 4334 Jonathan Rosenberg 4335 Cisco Systems 4336 600 Lanidex Plaza 4337 Parsippany, NJ 07054 4338 US 4340 Phone: +1 973 952-5000 4341 Email: jdrosen@cisco.com 4342 URI: http://www.jdrosen.net 4344 Intellectual Property Statement 4346 The IETF takes no position regarding the validity or scope of any 4347 Intellectual Property Rights or other rights that might be claimed to 4348 pertain to the implementation or use of the technology described in 4349 this document or the extent to which any license under such rights 4350 might or might not be available; nor does it represent that it has 4351 made any independent effort to identify any such rights. Information 4352 on the procedures with respect to rights in RFC documents can be 4353 found in BCP 78 and BCP 79. 4355 Copies of IPR disclosures made to the IETF Secretariat and any 4356 assurances of licenses to be made available, or the result of an 4357 attempt made to obtain a general license or permission for the use of 4358 such proprietary rights by implementers or users of this 4359 specification can be obtained from the IETF on-line IPR repository at 4360 http://www.ietf.org/ipr. 4362 The IETF invites any interested party to bring to its attention any 4363 copyrights, patents or patent applications, or other proprietary 4364 rights that may cover technology that may be required to implement 4365 this standard. Please address the information to the IETF at 4366 ietf-ipr@ietf.org. 4368 Disclaimer of Validity 4370 This document and the information contained herein are provided on an 4371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4373 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4374 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4375 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4378 Copyright Statement 4380 Copyright (C) The Internet Society (2006). This document is subject 4381 to the rights, licenses and restrictions contained in BCP 78, and 4382 except as set forth therein, the authors retain all their rights. 4384 Acknowledgment 4386 Funding for the RFC Editor function is currently provided by the 4387 Internet Society.