idnits 2.17.1 draft-ietf-mmusic-ice-05.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 2180. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2157. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2164. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2170. ** 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 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 376: '...dia, described in Section 7.8, MUST be...' RFC 2119 keyword, line 406: '... agent wishes to use, the agent SHOULD...' RFC 2119 keyword, line 411: '... use, the agent SHOULD obtain a set o...' RFC 2119 keyword, line 414: '...r TCP, the agent SHOULD obtain a set o...' RFC 2119 keyword, line 426: '... [22] can run over TCP [27]. As such, it is RECOMMENDED that both UDP...' (87 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 (July 17, 2005) is 6852 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: '5' is defined on line 2048, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2051, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 2069, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3489 (ref. '1') (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 2327 (ref. '7') (Obsoleted by RFC 4566) == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-connectivity-precon-00 == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-07 -- Possible downref: Normative reference to a draft: ref. '14' == Outdated reference: A later version (-04) exists of draft-ietf-avt-rtp-no-op-00 -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '16') (Obsoleted by RFC 7826) == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-11 == Outdated reference: A later version (-06) exists of draft-ietf-avt-rtp-framing-contrans-05 Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 9 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: January 18, 2006 July 17, 2005 6 Interactive Connectivity Establishment (ICE): A Methodology for Network 7 Address Translator (NAT) Traversal for Offer/Answer Protocols 8 draft-ietf-mmusic-ice-05 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 January 18, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes a methodology for Network Address Translator 42 (NAT) traversal for multimedia session signaling protocols, such as 43 the Session Initiation Protocol (SIP). This methodology is called 44 Interactive Connectivity Establishment (ICE). ICE makes use of 45 existing protocols, such as Simple Traversal of UDP Through NAT 46 (STUN) and Traversal Using Relay NAT (TURN). ICE makes use of STUN 47 in peer-to-peer cooperative fashion, allowing participants to 48 discover, create and verify mutual connectivity. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 6 55 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 8 56 5. Receipt of the Offer and Generation of the Answer . . . . . . 9 57 6. Processing the Answer . . . . . . . . . . . . . . . . . . . . 9 58 7. Common Procedures . . . . . . . . . . . . . . . . . . . . . . 10 59 7.1 Gathering Candidates . . . . . . . . . . . . . . . . . . . 10 60 7.2 Encoding Candidates into SDP . . . . . . . . . . . . . . . 13 61 7.3 Prioritizing the Transport Addresses and Choosing an 62 Active One . . . . . . . . . . . . . . . . . . . . . . . . 15 63 7.4 Connectivity Checks . . . . . . . . . . . . . . . . . . . 17 64 7.4.1 UDP Connectivity Checks . . . . . . . . . . . . . . . 19 65 7.4.1.1 Send Validation . . . . . . . . . . . . . . . . . 19 66 7.4.1.2 Receive Validation . . . . . . . . . . . . . . . . 20 67 7.4.1.3 Learning New Candidates from Connectivity 68 Checks . . . . . . . . . . . . . . . . . . . . . . 22 69 7.4.1.3.1 On Receipt of a Binding Request . . . . . . . 23 70 7.4.1.3.2 On Receipt of a Binding Response . . . . . . . 26 71 7.4.2 TCP Connectivity Checks . . . . . . . . . . . . . . . 26 72 7.4.2.1 Connection Establishment . . . . . . . . . . . . . 26 73 7.4.2.2 Sending STUN Binding Requests . . . . . . . . . . 27 74 7.4.2.3 Receiving STUN Requests . . . . . . . . . . . . . 29 75 7.5 Promoting a Valid Candidate to Active . . . . . . . . . . 30 76 7.5.1 Minimum Requirements . . . . . . . . . . . . . . . . . 30 77 7.5.2 Suggested Algorithm . . . . . . . . . . . . . . . . . 31 78 7.6 Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 33 79 7.6.1 Sending of an Offer . . . . . . . . . . . . . . . . . 33 80 7.6.2 Receiving the Offer and Sending an Answer . . . . . . 34 81 7.6.3 Receiving the Answer . . . . . . . . . . . . . . . . . 36 82 7.7 Binding Keepalives . . . . . . . . . . . . . . . . . . . . 37 83 7.8 Sending Media . . . . . . . . . . . . . . . . . . . . . . 38 84 8. Interactions with Forking . . . . . . . . . . . . . . . . . . 38 85 9. Interactions with Preconditions . . . . . . . . . . . . . . . 38 86 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 39 87 11. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 39 88 12. Security Considerations . . . . . . . . . . . . . . . . . . 40 89 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42 90 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 42 91 14.1 Problem Definition . . . . . . . . . . . . . . . . . . . . 42 92 14.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 43 93 14.3 Brittleness Introduced by ICE . . . . . . . . . . . . . . 43 94 14.4 Requirements for a Long Term Solution . . . . . . . . . . 44 95 14.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . 45 96 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 97 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 98 16.1 Normative References . . . . . . . . . . . . . . . . . . . 45 99 16.2 Informative References . . . . . . . . . . . . . . . . . . 46 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 47 101 Intellectual Property and Copyright Statements . . . . . . . . 48 103 1. Introduction 105 A multimedia session signaling protocol is a protocol that exchanges 106 control messages between a pair of agents for the purposes of 107 establishing the flow of media traffic between them. This media flow 108 is distinct from the flow of control messages, and may take a 109 different path through the network. Examples of such protocols are 110 the Session Initiation Protocol (SIP) [3], the Real Time Streaming 111 Protocol (RTSP) [16] and the International Telecommunications Union 112 (ITU) H.323. 114 These protocols, by nature of their design, are difficult to operate 115 through Network Address Translators (NAT). Because their purpose in 116 life is to establish a flow of packets, they tend to carry IP 117 addresses within their messages, which is known to be problematic 118 through NAT [17]. The protocols also seek to create a media flow 119 directly between participants, so that there is no application layer 120 intermediary between them. This is done to reduce media latency, 121 decrease packet loss, and reduce the operational costs of deploying 122 the application. However, this is difficult to accomplish through 123 NAT. A full treatment of the reasons for this is beyond the scope of 124 this specification. 126 Numerous solutions have been proposed for allowing these protocols to 127 operate through NAT. These include Application Layer Gateways 128 (ALGs), the Middlebox Control Protocol [18], Simple Traversal of UDP 129 through NAT (STUN) [1], Traversal Using Relay NAT [14], and Realm 130 Specific IP [19] [20] along with session description extensions 131 needed to make them work, such as the Session Description Protocol 132 (SDP) [7] attribute for the Real Time Control Protocol (RTCP) [2]. 133 Unfortunately, these techniques all have pros and cons which make 134 each one optimal in some network topologies, but a poor choice in 135 others. The result is that administrators and implementors are 136 making assumptions about the topologies of the networks in which 137 their solutions will be deployed. This introduces complexity and 138 brittleness into the system. What is needed is a single solution 139 which is flexible enough to work well in all situations. 141 This specification provides that solution for protocols based on the 142 offer-answer model, RFC 3264 [4]. It is called Interactive 143 Connectivity Establishment, or ICE. ICE makes use of STUN and TURN, 144 but uses them in a specific methodology which avoids many of the 145 pitfalls of using any one alone. 147 2. Terminology 149 Several new terms are introduced in this specification: 151 Peer: From the perspective of one of the agents in a session, its 152 peer is the other agent. Specifically, from the perspective of 153 the offerer, the peer is the answerer. From the perspective of 154 the answerer, the peer is the offeror. 156 Transport Address: The combination of an IP address and port. 158 Local Transport Address: A local transport address a transport 159 address that has been allocated from the operating system on the 160 host. This includes transport addresses obtained through Virtual 161 Private Networks (VPNs) and transport addresses obtained through 162 Realm Specific IP (RSIP) [19] (which lives at the operating system 163 level). Transport addresses are typically obtained by binding to 164 an interface. 166 m/c line: The media and connection lines in the SDP, which together 167 hold the transport address used for the receipt of media. 169 Derived Transport Address: A derived transport address is a transport 170 address which is derived from a local transport address. The 171 derived transport address is related to the associated local 172 transport address in that packets sent to the derived transport 173 address are received on the socket bound to its associated local 174 transport address. Derived addresses are obtained using protocols 175 like STUN and TURN, and more generally, any UNSAF protocol [21]. 177 Candidate Transport Address: A transport address advertised by a 178 agent in an offer or answer. A candidate transport address can 179 either by a local transport address or a derived transport 180 address. 182 Peer Derived Transport Address: A peer derived transport address is a 183 derived transport address learned from a STUN server running 184 within a peer in a media session. 186 TURN Derived Transport Address: A derived transport address obtained 187 from a TURN server. 189 STUN Derived Transport Address: A derived transport address obtained 190 from a STUN server whose address has been provisioned into the UA. 191 This, by definition, excludes Peer Derived Transport Addresses. 193 Candidate: A sequence of candidate transport addresses that form an 194 atomic set for usage with a particular media stream. In the case 195 of RTP, there are two candidate transport addresses per candidate: 196 one for RTP, and another for RTCP. Connectivity is verified to 197 all of the candidate transport addresses within a candidate before 198 that candidate is used. The transport addresses that compose a 199 candidate are all of the same type - local, STUN derived, TURN 200 derived or peer derived. 202 Local Candidate: A candidate whose transport addresses are local 203 transport addresses. 205 STUN Candidate: A candidate whose transport addresses are STUN 206 derived transport addresses. 208 TURN Candidate: A candidate whose transport addresses are TURN 209 derived transport addresses. 211 Peer Candidate: A candidate whose transport addresses are peer 212 derived transport addresses. 214 Active Candidate: The candidate that is in use for exchange of media. 215 This is the one that an agent places in the m/c line of an offer 216 or answer. 218 3. Overview of ICE 220 ICE makes the fundamental assumption that clients exist in a network 221 of segmented connectivity. This segmentation is the result of a 222 number of addressing realms in which a client can simultaneously be 223 connected. We use "realms" here in the broadest sense. A realm is 224 defined purely by connectivity. Two clients are in the same realm 225 if, when they exchange the addresses each has in that realm, they are 226 able to send packets to each other. This includes IPv6 and IPv4 227 realms, which actually use different address spaces, in addition to 228 private networks connected to the public Internet through NAT. 230 The key assumption in ICE is that a client cannot know, apriori, 231 which address realms it shares with any peer it may wish to 232 communicate with. Therefore, in order to communicate, it has to try 233 connecting to addresses in all of the realms. 235 Agent A TURN,STUN Servers Agent B 236 |(1) Gather Addresses | | 237 |-------------------->| | 238 |(2) Offer | | 239 |------------------------------------------>| 240 | |(3) Gather Addresses | 241 | |<--------------------| 242 |(4) Answer | | 243 |<------------------------------------------| 244 |(5) Media | | 245 |<------------------------------------------| 246 |(6) Media | | 247 |------------------------------------------>| 248 |(7) STUN Checks | | 249 |<------------------------------------------| 250 |(8) STUN Checks | | 251 |------------------------------------------>| 252 |(9) Offer | | 253 |------------------------------------------>| 254 |(10) Answer | | 255 |<------------------------------------------| 256 |(11) Media | | 257 |<------------------------------------------| 258 |(12) Media | | 259 |------------------------------------------>| 261 Figure 1 263 The basic flow of operation for ICE is shown in Figure 1. Before the 264 offeror establishes a session, it obtains local transport addresses 265 from its operating system on as many interfaces as it has access to. 266 These interfaces can include IPv4 and IPv6 interfaces, in addition to 267 Virtual Private Network (VPN) interfaces or ones associated with 268 RSIP. For media protocols that support both UDP and TCP (such as the 269 Real Time Transport Protocol (RTP) [22], which can run over either), 270 it obtains both TCP and UDP transport addresses. In addition, the 271 agent obtains derived transport addresses from each local transport 272 address using protocols such as STUN and TURN. Each local and 273 derived transport address becomes a candidate for receipt of media 274 traffic. 276 The agent will choose one of its candidate transport addresses as its 277 initial media transport address for inclusion in the connection and 278 media lines in the offer. This transport address will be utilized 279 for media traffic while connectivity is verified to all of the 280 candidates. Since these checks may take time to execute, media 281 clipping will occur if the media transport address is not reachable 282 by the peer. To minimize the probability of clipping, the transport 283 address that is most likely to work is chosen. This is normally a 284 TURN-derived tranport address, but others can be utilized based on 285 local policy. 287 Each candidate transport address (including the one being used as the 288 media transport address) is listed in an a=candidate attribute in the 289 offer. Each candidate is given a preference. Preference is a matter 290 of local policy, but typically, lowest preference would be given to 291 transport addresses learned from a TURN server (i.e., TURN derived 292 transport addresses). Each candidate is also assigned a distinct ID, 293 called a transport ID (tid). 295 The offer is then sent to the answerer. This specification does not 296 address the issue of how the signaling messages themselves traverse 297 NAT. It is assumed that signaling protocol specific mechanisms are 298 used for that purpose. The answerer follows a similar process as the 299 offeror followed; it obtains addresses from local interfaces, obtains 300 derived transport addresses from those, and the combination becomes 301 its set of candidate transport addresses. It picks one as its 302 initial media transport address and places it into the m/c line in 303 the answer, and then lists all of them in the a=candidate attributes 304 in the answer, along with a preference and tid. 306 Once the offer/answer exchange has completed, each agent sends media 307 from its media transport address to the media transport address of 308 its peer. This media stream may or may not work, depending on 309 whether or not the media transport address is reachable. In parallel 310 with the transmission of media, a connectivity check begins. This 311 check makes use of STUN messages sent from each candidate to each 312 other candidate. These checks will allow each agent to determine 313 whether it can send packets from a particular candidate to a 314 candidate from its peer, and whether packets can be sent back. If, 315 after a certain period of time, an agent determines that a pair of 316 candidates works, and has a higher priority than the transport 317 addresses currently in use for media (perhaps because the ones in use 318 don't work), it sends a new offer that "promotes" its candidate into 319 the m/c line. This causes the media traffic to switch to this new 320 transport address. 322 4. Sending the Initial Offer 324 When an agent wishes to begin a session by sending an initial offer, 325 it starts by gathering transport addresses, as described in 326 Section 7.1. This will produce a set of candidates, including local 327 ones, STUN-derived ones, and TURN-derived ones. 329 This process of gathering candidates can actually happen at any time 330 before sending the initial offer. A agent can pre-gather transport 331 addresses, using a user interface cue (such as picking up the phone, 332 or entry into an address book) as a hint that communications is 333 imminent. Doing so eliminates any additional perceivable call setup 334 delays due to address gathering. 336 When it comes time to offer communications, it determines a priority 337 for each candidate and identifies the active candidate that will be 338 used for receipt of media, as described in Section 7.3. 340 The next step is to construct the offer message. For each media 341 stream, it places its candidates into a=candidate attributes in the 342 offer and puts its active candidate into the m/c line. The process 343 for doing this is described in Section 7.2. The offer is then sent. 345 5. Receipt of the Offer and Generation of the Answer 347 Upon receipt of the offer message, the agent checks if the offer 348 contains any a=candidate attributes. If it does, the offeror 349 supports ICE. In that case, it starts gathering candidates, as 350 described in Section 7.1, and prioritizes them Section 7.3. This 351 processing is done immediately on receipt of the offer, to prepare 352 for the case where the user should accept the call, or early media 353 needs to be generated. By gathering candidates while the user is 354 being alerted to the request for communications, session 355 establishment delays due to that gathering can be eliminated. 357 At some point, the answerer will decide to accept or reject the 358 communications. A rejection terminates ICE processing. In the case 359 of acceptance, the answer is constructed, and if the offeror 360 supported ICE, the candidates are encoded into the SDP as described 361 in Section 7.2. The answer is then sent. If the offeror supported 362 ICE, the answerer begins its connectivity checks as described in 363 Section 7.4. 365 In addition, and regardless if the offeror supported ICE, the 366 answerer can begin sending media packets as it normally would. It 367 sends media according to the procedures in Section 7.8. 369 6. Processing the Answer 371 There are two possible cases for processing of the answer. If the 372 answerer did not support ICE, the answer will not contain any 373 a=candidate attributes. As a result, the offeror knows that it 374 cannot perform its connectivity checks. In this case, it proceeds 375 with normal media processing as if ICE was not in use. The 376 procedures for sending media, described in Section 7.8, MUST be 377 followed however. 379 If the answer contains candidates, it implies that the answerer 380 supported ICE. In that case, the offeror begins connectivity checks 381 as described in Section 7.4. It also starts sending media, using the 382 candidate in the m/c line, based on the procedures described in 383 Section 7.8. 385 7. Common Procedures 387 This section discusses procedures that are common between offeror and 388 answerer. 390 7.1 Gathering Candidates 392 An agent gathers candidates when it believes that communications is 393 imminent. For offerors, this occurs before sending an offer 394 (Section 4). For answerers, it occurs before sending an answer 395 (Section 5). 397 Each candidate is composed of a series of transport addresses of the 398 same type. In the case of RTP, the candidate is composed of either 399 one or two transport addresses. Normally there are two - one for 400 RTP, and one for RTCP. However, if RTCP is not in use, a candidate 401 will only contain a single transport address. 403 The first step is to gather local candidates. Local candidates are 404 obtained by binding to ephemeral ports on an interface (physical or 405 virtual, including VPN interfaces) on the host. Specifically, for 406 each UDP-only media stream the agent wishes to use, the agent SHOULD 407 obtain a set of candidates (one for each interface) by binding to N 408 ephemeral UDP ports on each interface, where N is the number of 409 transport addresses needed for the candidate. For RTP, N is 410 typically two. For each TCP-only media stream the agent wishes to 411 use, the agent SHOULD obtain a set of candidates by binding to N 412 ephemeral TCP ports on each interface, where N is the number of 413 transport addresses needed for the candidate. For media streams that 414 can support either UDP or TCP, the agent SHOULD obtain a set of 415 candidates by binding to N ephemeral UDP and N ephemeral TCP ports on 416 each interface, where N is the number of transport addresses needed 417 for the candidate. 419 If a host has K local interfaces, this will result in K candidates 420 for each UDP stream (requiring K*N transport addresses), K candidates 421 for each TCP stream (requiring K*N transport addresses), and 2K 422 candidates for streams that support UDP and TCP (requiring 2*K*N 423 transport addresses). 425 Media streams carried using the Real Time Transport Protocol (RTP) 426 [22] can run over TCP [27]. As such, it is RECOMMENDED that both UDP 427 and TCP candidates be obtained. Transmission of real time media over 428 UDP is generally preferred to TCP. However, many network 429 environments, for better or for worse, permit only TCP traffic. 430 Obtaining a TCP candidate, and then using it in conjunction with a 431 TURN relay as described below, allows for ICE to make use of the TCP 432 media only when UDP connectivity is non-existent, as it may be in 433 these restricted environments. However, providers of real-time 434 communications services may decide that it is preferable to have no 435 media at all than it is to have media over TCP. To allow for choice, 436 it is RECOMMENDED that agents be configurable with whether they 437 obtain TCP candidates for real time media. 439 Having it be configurable, and then configuring it to be off, is 440 far better than not having the capability at all. An important 441 goal of this specification is to provide a single mechanism that 442 can be used across all types of endpoints. As such, it is 443 preferable to account for provider and network variation through 444 configuration, instead of hard-coded limitations in an 445 implementation. Furthermore, network characteristics and 446 connectivity assumptions can, and will change over time. Just 447 because a agent is communicating with a server on the public 448 network today, doesn't mean that it won't need to communicate with 449 one behind a NAT tomorrow. Just because a agent is behind a full 450 cone NAT today, doesn't mean that tomorrow they won't pick up 451 their agent and take it to a public network access point where 452 there is a symmetric NAT or one that only allows outbound TCP. 453 The way to handle these cases and build a reliable system is for 454 agents to implement a diverse set of techniques for allocating 455 addresses, so that at least one of them is almost certainly going 456 to work in any situation. Implementors should consider very 457 carefully any assumptions that they make about deployments before 458 electing not to implement one of the mechanisms for address 459 allocation. In particular, implementors should consider whether 460 the elements in the system may be mobile, and connect through 461 different networks with different connectivity. They should also 462 consider whether endpoints which are under their control, in terms 463 of location and network connectivity, would always be under their 464 control. Only in cases where there isn't now, and never will be, 465 endpoint mobility or nomadicity of any sort, should a technique be 466 omitted. 468 Once the agent has obtained local candidates, it obtains candidates 469 with derived transport addresses. Agents which serve end users 470 directly, such as softphones, hardphones, terminal adaptors and so 471 on, MUST implement STUN and SHOULD use it to obtain STUN candidates. 472 These devices SHOULD implement and SHOULD use TURN to obtain TURN 473 candidates. They MAY implement and MAY use other protocols that 474 provide derived transport addresses, such as TEREDO [25]. As with 475 TCP, usage of STUN and TURN is at SHOULD strength to allow for 476 provider variation. If it is not to be used, it is also RECOMMENDED 477 that it be implemented and just disabled through configuration, so 478 that it can re-enabled through configuration if conditions change in 479 the future. 481 Agents which represent network servers under the control of a service 482 provider, such as gateways to the telephone network, media servers, 483 or conferencing servers that are targeted at deployment only in 484 networks with public IP addresses MAY use STUN, TURN or other similar 485 protocols to obtain candidates. 487 Why would these types of endpoints even bother to implement ICE? 488 The answer is that such an implementation greatly facilitates NAT 489 traversal for endpoints that connect to it. The ability to 490 process STUN connectivity checks allows for the network server to 491 obtain peer-derived transport addresses that can be used to 492 provide relay-free traversal of symmetric NAT for endpoints that 493 connect to it. Furthermore, implementation of the STUN 494 connectivity checks allows for NAT bindings along the way to be 495 kept open. ICE also provides numerous security properties that 496 are independent of NAT traversal, and would benefit any multimedia 497 endpoint. See Section 12 for a discussion on these benefits. 499 To obtain STUN candidates (which are always UDP), the client takes a 500 local UDP candidate, and for each configured STUN server, produces a 501 STUN candidate. It is anticipated that clients may have a 502 multiplicity of STUN servers configured in network environments where 503 there are multiple layers of NAT, and that layering is known to the 504 provider of the client. To produce the STUN candidate from the local 505 candidate, it follows the procedures of Section 9 of RFC 3489 for 506 each local transport address in the local candidate. It obtains a 507 shared secret from the STUN server and then initiates a Binding 508 Request transaction from the local transport address to that server. 509 The Binding Response will provide the client with its STUN derived 510 transport address in the MAPPED-ADDRESS attribute. If the client had 511 K local candidates, this will produce S*K STUN candidates, where S is 512 the number of configured STUN servers. 514 To obtain UDP TURN candidates, the client takes a local UDP 515 candidate, and for each configured TURN server, produces a TURN 516 candidate. It is anticipated that clients may have a multiplicity of 517 TURN servers configured in network environments where there are 518 multiple layers of NAT, and that layering is known to the provider of 519 the client. To produce the TURN candidate from the local candidate, 520 it follows the procedures of Section 8 of [14] for each local 521 transport address in the local candidate. It initiates an Allocate 522 Request transaction from the local transport address to that server. 524 The Allocate Response will provide the client with its TURN derived 525 transport address in the MAPPED-ADDRESS attribute. If the client had 526 K local candidates, this will produce S*K UDP TURN candidates, where 527 S is the number of configured TURN servers. 529 To obtain a TURN-derived TCP candidates, the client takes a local TCP 530 candidate, and for each configured TURN server, produces a TCP TURN 531 candidate. It is anticipated that clients may have a multiplicity of 532 TURN servers configured in network environments where there are 533 multiple layers of NAT, and that layering is known to the provider of 534 the client. To produce the TURN candidate from the local candidate, 535 it iterates through the local transport addresses in the local 536 candidate, and for for each one, initiates a TCP connection from the 537 same interface the local transport address to the TURN server. It is 538 not neccesary to initiate the connection from the actual port in the 539 local transport address. Following the procedures of Section 8 of 540 [14], it initiates an Allocate Request transaction over the 541 connection. The Allocate Response will provide the client with its 542 TCP TURN derived transport address in the MAPPED-ADDRESS attribute. 543 If the client had K local TCP candidates, this will produce S*K TCP 544 TURN candidates, where S is the number of configured TURN servers. 546 7.2 Encoding Candidates into SDP 548 For each candidate to be placed into the SDP, the agent includes a 549 series of a=candidate attributes as media-level attributes, one for 550 each transport address in the candidate. Each of the transport 551 addresses for the same candidate MUST have the same value of the 552 candidate-id attribute. The a=candidate attributes for different 553 candidates MUST be unique within that media stream. Using a simple 554 sequence number, incrementing by one for each candidate for a media 555 stream, meets these requirements. The transport, unicast-address and 556 port of the attribute are set to those for the candidate. The qvalue 557 is set to the priority of this candidate (note that, for RTP, the RTP 558 and RTCP transport addresses MUST have equal priority values). The 559 tid MUST be chosen randomly with 128 bits of randomness. The tid is 560 chosen only when the transport address is placed into the SDP for the 561 first time; subsequent offers or answers within the same session 562 containing that same transport address would use the same tid used 563 previously. 565 The tid serves as a unique identifier for each transport address. It 566 also gets combined, through concatenation, with the tid of a peer 567 candidate to form the username and password that is placed in the 568 STUN checks between the peers. This allows the STUN message to 569 uniquely identify the pairing whose connectivity it is checking. The 570 tid is needed as a unique identifier because the IP address within 571 the candidate fails to provide that uniqueness as a consequence of 572 NAT. 574 Consider agents A, B, and C. A and B are within private enterprise 1, 575 which is using 10.0.0.0/8. C is within private enterprise 2, which 576 is also using 10.0.0.0/8. As it turns out, B and C both have IP 577 address 10.0.1.1. A sends an offer to C. C, in its answer, provides 578 A with its transport addresses. In this case, thats 10.0.1.1:8866 579 and 8877. As it turns out, B is in a session at that same time, and 580 is also using 10.0.1.1:8866 and 8877. This means that B is prepared 581 to accept STUN messages on those ports, just as C is. A will send a 582 STUN request to 10.0.1.1:8866 and 8877. However, these do not go to 583 C as expected. Instead, they go to B. If B just replied to them, A 584 would believe it has connectivity to C, when in fact it has 585 connectivity to a completely different user, B. To fix this, tid 586 takes on the role of a unique identifier. C provides A with an 587 identifier for its transport address, and A provides one to C. A 588 concatenates these two identifiers and uses the result as the 589 username and password in its STUN query to 10.0.1.1:8866. This STUN 590 query arrives at B. However, the username is unknown to B, and so the 591 request is rejected. A treats the rejected STUN request as if there 592 were no connectivity to C (which is actually true). Therefore, the 593 error is avoided. 595 An unfortunate consequence of the non-uniqueness of IP addresses is 596 that, in the above example, B might not even be an ICE agent. It 597 could be any host, and the port to which the STUN packet is directed 598 could be any ephemeral port on that host. If there is an application 599 listening on this socket for packets, and it is not prepared to 600 handle malformed packets for whatever protocol is in use, the 601 operation of that application could be effected. Fortunately, since 602 the ports exchanged in SDP are ephemeral and ususally drawn from the 603 dynamic or registered range, the odds are good that the port is not 604 used to run a server on host B, but rather is the agent side of some 605 protocol. This decreases the probability of hitting a port in-use, 606 due to the transient nature of port usage in this range. However, 607 the possibility of a problem does exist, and network deployers should 608 be prepared for it. 610 Note that, because there are separate transport addresses for RTP and 611 RTCP, each will have a distinct tid. 613 The active candidate is placed into the m/c lines of the SDP. For 614 RTP streams, this is done by placing the RTP address and port into 615 the c and m lines in the SDP respectively. If the agent it utilizing 616 RTCP, it MUST encode its address and port using the a=rtcp attribute 617 as defined in RFC 3605 [2]. If RTCP is not in use, the agent MUST 618 signal that using b=RS:0 and b=RR:0 as defined in RFC 3556 [8]. 620 For media streams that are inherently TCP-based (as opposed to ones 621 where TCP is a fallback and would be listed as a candidate but not 622 the initial active address), the connections MUST be signaled using 623 comedia [13], and those connections MUST be in "holdconn" mode. This 624 has the effect of suspending connection attempts via the comedia 625 mechanisms, allowing ICE to open the connections instead. These 626 connections then get removed from holdconn mode when the ICE 627 procedures complete and an updated offer/answer exchange takes place 628 that promotes one of the existing ICE-established connections to 629 active. Note that this has the result of increasing the post-dial- 630 delay for TCP-oriented media, but brings with it substantial security 631 and NAT traversal properties. 633 7.3 Prioritizing the Transport Addresses and Choosing an Active One 635 The prioritization process takes the set of candidates and associates 636 each with a priority. This priority reflects the desire that the 637 agent has to receive media on that address, and is assigned as a 638 value from 0 to 1 (1 being most preferred). Priorities are ordinal, 639 so that their significance is only meaningful relative to other 640 candidates for a particular media stream. 642 This specification makes no normative recommendations on how the 643 prioritization is done. However, some useful guidelines are 644 suggested on how such a prioritization can be determined. 646 One criteria for choosing one candidate over another is whether or 647 not that candidate involves the use of a relay. That is, if media is 648 sent to that candidate, will the media first transit a relay before 649 being received. TURN candidates make use of relays (the TURN 650 server), as do any local candidates associated with a VPN server. 651 When media is transited through a relay, it can increase the latency 652 between transmission and reception. It can increase the packet 653 losses, because of the additional router hops that may be taken. It 654 may increase the cost of providing service, since media will be 655 routed in and right back out of a relay run by the provider. If 656 these concerns are important, candidates with this property can be 657 listed with lower priority. 659 Another criteria for choosing one candidate over another is IP 660 address family. ICE works with both IPv4 and IPv6. It therefore 661 provides a transition mechanism that allows dual-stack hosts to 662 prefer connectivity over IPv6, but to fall back to IPv4 in case the 663 v6 networks are disconnected (due, for example, to a failure in a 664 6to4 relay) [24]. It can also help with hosts that have both a 665 native IPv6 address and a 6to4 address. In such a case, higher 666 priority could be afforded to the native v6 address, followed by the 667 6to4 address, followed by a native v4 address. This allows a site to 668 obtain and begin using native v6 addresss immediately, yet still 669 fallback to 6to4 addresses when communicating with agents in other 670 sites that do not yet have native v6 connectivity. 672 Another criteria for choosing one candidate over another is security. 673 If a user is a telecommuter, and therefore connected to their 674 corporate network and a local home network, they may prefer their 675 voice traffic to be routed over the VPN in order to keep it on the 676 corporate network when communicating within the enterprise, but use 677 the local network when communicating with users outside of the 678 enterprise. 680 Another criteria for choosing one address over another is topological 681 awareness. This is most useful for candidates which make use of 682 relays (including TURN and VPN). In those cases, if a agent has 683 preconfigured or dynamically discovered knowledge of the topological 684 proximity of the relays to itself, it can use that to select closer 685 relays with higher priority. 687 Finally, the transport protocol itself is a criteria for choosing one 688 candidate over another. If a particular media stream can run over 689 UDP or TCP, the UDP candidates might be preferred over the TCP 690 candidates. This allows ICE to use the lower latency UDP 691 connectivity if it exists, but fallback to TCP if UDP doesn't work. 693 Once the candidates have been prioritized, one is selected as the 694 active one. This is the candidate that will be used for actual 695 exchange of media, until replaced by an updated offer or answer. 696 Since the ICE connectivity checks can take a few seconds to execute, 697 media clipping can occur is this candidate doesn't work. The active 698 candidate will also be used to receive media from ICE-unaware peers. 699 As such, it is RECOMMENDED that one be chosen based on the likelihood 700 of that candidate to work with the peer that is being contacted. 701 Unfortunately, it is difficult to ascertain which candidate that 702 might be. As an example, consider a user within an enterprise. To 703 reach non-ICE capable agents within the enterprise, a local candidate 704 has to be used, since the enterprise policies may prevent 705 communication between elements using a relay on the public network. 706 However, when communicating to peers outside of the enterprise, a 707 TURN-based candidate from a publically accessible TURN server is 708 needed. 710 Indeed, the difficulty in picking just one address that will work is 711 the whole problem that motivated the development of this 712 specification in the first place. As such, it is RECOMMENDED that 713 the default address be a TURN candidate from a TURN server providing 714 public IP addresses. Furthermore, ICE is only truly effective when 715 it is supported on both sides of the session. It is therefore most 716 prudent to deploy it to close-knit communities as a whole, rather 717 than piecemeal. In the example above, this would mean that ICE would 718 ideally be deployed completely within the enterprise, rather than 719 just to parts of it. 721 7.4 Connectivity Checks 723 Once the offer/answer exchange has completed, both agents will have a 724 set of candidates for each media stream. Each agent forms a set of 725 pairings for each media stream by combining each of its UDP 726 candidates with each of the UDP candidates of its peer, and by 727 combining each of its TCP candidates with each of the TCP candidates 728 of its peer. If candidates for other transport protocols were 729 signaled through the offer/answer exchange, a pairing is performed 730 between each of those as well. If an offer/answer exchange took 731 place for a session comprised of an audio and a video stream, and 732 each stream had two UDP and two TCP candidates from each agent, there 733 would be 16 pairings, 8 for audio and 8 for video. Each of those 734 eight would be comprised of four UDP and four TCP. Note that there 735 is no requirement that the number of candidates from each peer be the 736 same. One agent can offer two UDP candidates for a media stream, and 737 the answer can contain three UDP candidates for the same media 738 stream. In that case, there would be six UDP pairings. 740 Each candidate has a number of transport addresses. In the case of 741 RTP, there are either one or two. Within the pairing, the transport 742 addresses of each candidate are linked together one-to-one to form a 743 transport address pair. In the case of RTP, the result will either 744 be one or two transport address pairs - one for RTP, and possibly 745 another for RTCP. The relationship between a candidate, transport 746 address, pairing and transport address pair are shown in Figure 2. 747 This figure shows the pairing as seen by the agent that owns the 748 candidate {A,B}. The candidate owned by that agent is called the 749 native candidate, and the one owned by its peer is the remote 750 candidate. As the figure shows, there is one pairing between two 751 candidates, and two transport address pairs ({A,C} and {B,D}). If 752 one of the candidates only had one transport address (in the case 753 where RTCP was not being used by one agent), there would only be one 754 transport address pair, {A,C}. Each transport address is associated 755 with a tid. Furthermore, each transport address pair is associated 756 with an ID, the transport address pair ID. This ID is equal to the 757 concatenation of the tid of the native transport address with the tid 758 of the remote transport address. This means that the identifiers are 759 different for each agent. For the agent that owns {A,B}, the 760 transport address pair ID is WY for the first transport address pair, 761 and XZ for the second. For the agent that owns {C,D}, it would be 762 reversed - YW for the first transport address pair, and ZX for the 763 second. 765 ........................................... 766 . . 767 .......... . . .......... 768 . . . ............. ............. . . . 769 . . . . . . . . . . 770 . -- . . . -- . . -- . . . -- . 771 . | A|<<<<<<<<<<| A|--------------------| C|>>>>>>>>>>>>| K| . 772 . -- . . . -- . Transport . -- . . . -- . 773 . . . . Transport . Address . Transport . . . . 774 . . . . Address . Pair . Address . . . . 775 . . . . tid=W . ID=WY . tid=Y . . . . 776 . . . . . . . . . . 777 . . . . . . . . . . 778 . . . . . . . . . . 779 . -- . . . -- . . -- . . . -- . 780 . | J|<<<<<<<<<<| B|--------------------| D|>>>>>>>>>>>>| D| . 781 . -- . . . -- . Transport . -- . . . -- . 782 .......... . . Transport . Address . Transport . . .......... 783 Associated . . Address . Pair . Address . . Associated 784 Local . . tid=X . ID=XZ . tid=Z . . Local 785 Transport . . . . . . Transport 786 Addresses . ............. ............. . Addresses 787 . Native Remote . 788 . Candidate Candidate . 789 . and and . 790 . Transport Addresses Transport Addresses . 791 . . 792 ........................................... 794 Pairing 796 Figure 2 798 The figure also shows that each transport address has an associated 799 local transport address. The associated local transport address is 800 the local transport address at which the agent will receive packets 801 sent to the transport address. For a local transport address, its 802 associated local transport address is the same. That is the case of 803 transport address A and D in the diagram. For STUN derived and TURN 804 derived transport addresses, however, they are not the same. The 805 associated local transport address is the one from which the STUN or 806 TURN transport was derived. 808 Next, each agent begins sending connectivity checks for each 809 transport address pair. The procedure differs for UDP and TCP. 811 7.4.1 UDP Connectivity Checks 813 An agent considers a UDP pairing validated when all of its transport 814 address pairs have been validated. Each transport address pair is 815 validated if an agent successfully completed a STUN Binding Request 816 transaction from its native transport address to the corresponding 817 remote transport address, and when it has received a STUN Binding 818 Request transaction on its native transport address, sent from the 819 remote transport address. This ensures that packets can flow in each 820 direction. 822 Because validation of a transport address pair involves a STUN 823 transaction in each direction, a pair can be in one of five states - 824 unknown, invalid, send-valid, receive-valid and valid. Each 825 transport address pair starts in the unknown state. 827 7.4.1.1 Send Validation 829 To validate a transport address pair in the send direction, an agent 830 needs to complete a successful STUN Binding Request transaction. 831 This means it needs to send a Binding Request from its native 832 transport address to the remote transport address, and receive a 833 successful Binding Response back. 835 For UDP-based transport addresses, an agent initiates a STUN Binding 836 Request transaction by sending from its native transport address, and 837 sends it to the remote transport address. The meaning of "sending 838 from its native transport address" is clear in the case of a local 839 transport address - the request is sent such that the source IP 840 address and port of the packet is equal to that local transport 841 address. However, the meaning is different for STUN and TURN derived 842 transport addresses. For STUN derived transport address, it is sent 843 by sending from the local transport address used to derive that STUN 844 address. For TURN derived transport addresses, it is sent by using 845 TURN mechanisms to send the request through the TURN server (using 846 the SEND primitive). Sending the request through the TURN server 847 neccesarily requires that the request be sent from the client, using 848 the local transport address used to derive the TURN transport 849 address. 851 The Binding Request sent by the agent MUST contain the USERNAME 852 attribute. This attribute MUST be set to the transport address pair 853 ID of the corresponding transport address pair as seen by its peer. 854 Thus, for the first transport address pair in the example above, if 855 the agent on the left sends the STUN Binding Request, the USERNAME 856 will have the value YW. The request MAY contain the MESSAGE- 857 INTEGRITY attribute, computed according to RFC 3489 procedures. The 858 MESSAGE-INTEGRITY The Binding Request MUST NOT contain the CHANGE- 859 REQUEST or ANSWER-ADDRESS attribute. 861 Each of these STUN transactions will generate either a timeout, or a 862 response. If the response is a 420, 500, or 401, the agent should 863 try again as described in RFC 3489. Either initially, or after such 864 a retry, the STUN transaction might produce a non-recoverable failure 865 response (error codes 400, 431, or 600) or a failure result 866 inapplicable to this usage of STUN and thus unrecoverable (432, 433). 867 If this happens the transport address pair and its corresponding 868 candidate is considered invalid. If the STUN transaction produces a 869 430 error or times out, the client SHOULD retry with a new STUN 870 Binding Request transaction. The 430 response code, as described 871 below, is generated when the server doesn't recognize the STUN 872 username because the BindingRequest was sent received prior to the 873 receipt of the answer. Its ocurrence is a result of a failed race 874 between the BindingRequest and the answer. This is remedied by 875 retrying, which allows the "slower" answer to be received. These 876 retry transactions carry the same USERNAME value as the original 877 Binding Request, and differ only in their STUN transaction ID. If 878 these retries have not produced a success response after Tg seconds, 879 the transport address pair is considered invalid. Tg SHOULD be 880 configurable. It is RECOMMENDED that it default to 50 seconds. This 881 is a reasonable approximation of the maximum SIP transaction 882 duration. 884 If the STUN transaction succeeds for a UDP transport address pair 885 (producing a success response), and the pair was previously in the 886 receive-valid state, it is considered valid. If the pair was 887 previously in the unknown state, it is considered send-valid. 889 If a transport address pair is send-valid or valid, an agent MUST 890 generate a new STUN Binding Request transaction every Tr seconds. 891 This transaction ensures that NAT bindings for the transport address 892 pair remain open while the candidate is under consideration. They 893 can also be used to keep the bindings alive when the candidate is 894 promoted to active, as described in Section 7.7. Tr SHOULD be 895 configurable, and SHOULD default to 15 seconds. Each new Binding 896 Request transaction is processed according to the procedures in this 897 Section. It is possible for a previously valid candidate to later be 898 invalidated by a subsequent STUN transaction. This happens in cases 899 where the NAT bindings expire. 901 7.4.1.2 Receive Validation 903 As a result of providing a list of candidates in its offer or answer, 904 an ICE implementation will receive STUN Binding Request messages. An 905 agent MUST be prepared to receive STUN Binding Requests on each local 906 transport address from the moment it sends an offer or answer that 907 contains a candidate with that local transport address. Similarly, 908 it MUST be prepared to receive STUN Binding Requests on a local 909 transport address the moment it sends an offer or answer that 910 contains a STUN or TURN candidate derived from a local candidate 911 containing that local transport address. It can cease listening for 912 STUN messages on that local transport address after reliably sending 913 an updated offer or answer which does not include any candidates 914 equal to or derived from that local transport address. Here, 915 "reliably" means that the agent knows that the offer or answer was 916 received by its peer. This knowledge is based on the protocol 917 carrying the offer/answer exchanges. In the case of SIP, if the 918 offer is in an INVITE, the agent knows this was received by its peer 919 when a 200 OK or reliable provisional response [9] is received with 920 the answer. If the offer is in a reliable provisional response, the 921 agent knows it was reliably received when the PRACK arrives. If an 922 answer is in a 200 OK response, the agent knows this was received 923 when the ACK is received. 925 The agent does not need to provide STUN service on any other IP 926 address or port, unlike the STUN usage described in [1]. The need to 927 run the service on multiple ports is to support the change flags. 928 However, those flags are not needed with ICE, and the server SHOULD 929 reject, with a 400 answer, any STUN requests with these flags set. 930 The CHANGED-ADDRESS attribute in a BindingAnswer is set to the 931 transport address on which the server is running. 933 Furthermore, there is no need to support TLS or to be prepared to 934 receive SharedSecret request messages. Those messages are used to 935 obtain shared secrets to be used with BindingRequests. However, with 936 ICE, a shared secret is not needed. The tid's that are exchanged and 937 used to form the STUN USERNAME attribute do not actually require the 938 security properties associated with a shared secret in order for ICE 939 to operate securely; this is because ICE security is bootstrapped off 940 of the protocol carrying the offer/answer exchanges. 942 One of the candidates will be in use as the active candidate. For 943 the transport addresses comprising that candidate, the agent will 944 receive both STUN requests and media packets on its associated local 945 transport addresses. The agent MUST be able to disambiguate them. 946 In the case of RTP/RTCP, this disambiguation is easy. RTP and RTCP 947 packets start with the bits 0b10 (v=2). The first two bits in STUN 948 are always 0b00. This disambiguation also works for packets sent 949 using Secure RTP [23], since the RTP header is in the clear. 950 Disambiguating STUN with other media stream protocols may be more 951 complicated. However, it can always be possible with arbitrarily 952 high probabilities by selecting an appropriately random username (see 953 below). 955 The STUN Binding Request can only be usefully processed once an 956 offer/answer exchange has completed. As a result, if an offeror 957 receives a STUN Binding Request message prior to the receipt of an 958 answer to its offer, it MUST reject the request with a 430 response. 959 This will cause the answerer to retry, and give time for the answer 960 (which is in transit) to arrive at the offerer. 962 If the offer/answer exchange has completed, the agent MUST follow the 963 procedures defined in RFC 3489 and verify that the USERNAME attribute 964 is known to the server. Here, this is done by taking the USERNAME 965 attribute, and comparing it against the transport address pair 966 identifiers for each transport address pair as seen by that agent. 967 If there is no match, the STUN Binding Request generates a 400. If 968 there is a match, the resulting transport address pair is called the 969 matching transport address pair. The user agent proceeds with the 970 processing of the request and generation of a response as per RFC 971 3489. In addition, the if the state of that transport address pair 972 was previously unknown, it changes to receive-valid. If the state 973 was previously send-valid, it moves to valid. 975 An agent will continue to receive periodic STUN transactions as long 976 as it had listed its transport address in an a=candidate attribute. 977 It MUST process those transactions according to this section. It is 978 possible that a transport address pair that was previously valid may 979 become invalidated as a result of a subsequent failed STUN 980 transaction. 982 7.4.1.3 Learning New Candidates from Connectivity Checks 984 ICE makes use of candidate addresses learned through protocols like 985 STUN, as described in Section 7.1. These addresses are learned when 986 STUN requests are sent to configured STUN servers. However, the 987 peer-to-peer STUN connectivity checks can themselves provide 988 additional candidates that ICE can make use of. This happens when 989 two agents are separated by a symmetric NAT. When the agent behind 990 the symmetric NAT sends a Binding Request to the other agent (which 991 can have a public address or be behind any type of NAT except for 992 symmetric), the symmetric NAT will create a new NAT binding for this 993 Binding Request. Because of the properties of symmetric NAT, that 994 binding can be used be the agent on the public side of the symmetric 995 NAT to send packets back to the agent behind the symmetric NAT. 997 To do this, ICE agents dynamically learn new candidates by examining 998 the source IP addresses and MAPPED-ADDRESS attributes in STUN Binding 999 Requests and Responses respectively. If they don't match any 1000 existing candidates, a new candidate is added. This candidate 1001 corresponds to the new IP address and port created by the symmetric 1002 NAT, and is a new point of contact for the agent behind the symmetric 1003 NAT. Since that candidate is only reachable from the very specific 1004 IP address and port where the STUN request was sent to, the new 1005 candidate is paired up with that transport address on the other 1006 agent. Since all candidates need to have properties, such as tids, 1007 priorities and candidate IDs, these are all computed algorithmically, 1008 so that they can be determined by both agents just from the STUN 1009 message. 1011 The specific procedures on receipt of a Binding Request and Response 1012 for accomplishing this are described here. 1014 7.4.1.3.1 On Receipt of a Binding Request 1016 When a STUN Binding Request is received which generates a success 1017 response, the source IP address and port of that request is compared 1018 all existing remote transport addresses. If there is no match, the 1019 agent creates a new remote candidate, and adds a transport address to 1020 it. It sets the IP address and port of this new remote transport 1021 address to the IP address and port that was present in the incoming 1022 Binding Request. Since this is a new candidate transport address, it 1023 requires a new tid. The agent creates one algorithmically, by 1024 concatenating the tid of the remote transport address in the matching 1025 transport address pair (recall that the matching transport address 1026 pair is the one whose transport address pair ID matched the username 1027 of the incoming Binding Request) with the string representation of 1028 the source IP address and port from the incoming Binding Request. 1029 This string representation is defined using the grammar for 1030 "hostport" from RFC 3261 [3], which defines the familiar notation of 1031 the IP address and port separated by a colon. 1033 The priority of the new candidate MUST be set to the priority of the 1034 remote candidate in the matching transport address pair. There is no 1035 need to compute the candidate ID for this new candidate. 1037 Though this is a valid transport address, the agent does not pair it 1038 up with each of its own transport addresses. Rather, it pairs it up 1039 only with the native transport address from the matching transport 1040 address pair. This creates a new transport address pair. Since 1041 connectivity has been verified in the receive direction, the agent 1042 sets its state to receive-valid. As with all other transport address 1043 pairs, the agent will attempt to validate send capabilities by 1044 sending a STUN Binding Request according to the procedures in 1045 Section 7.4.1.1. 1047 It is important to note that this process creates a new remote 1048 transport address, not a whole new remote candidate. For a whole 1049 remote candidate to come into existence, all of its component 1050 transport addresses must come into existence, and all must have been 1051 obtained as a result of a STUN Binding Requests between transport 1052 address pairs in the same pairing. As an example, consider the 1053 pairing in Figure 2. If the peer is behind a symmetric NAT, the 1054 Binding Request sent from C to A might produce a new remote transport 1055 address for RTP. To create a full candidate, a STUN Binding Request 1056 from D to B has to also create a new remote transport address, to be 1057 used for RTCP. If this were to happen, the resulting set of 1058 relationships is shown in Figure 3. To simplify the diagram, 1059 associated local transport address relationships have been omitted. 1060 Notice how the tids of the new remote candidate have been constructed 1061 by concatenating the tids of the original remote candidate with the 1062 newly discovered transport addresses, here, {R,S}. 1064 ............. ............. 1065 . . . . 1066 . -- . . -- . 1067 . | A|---------------------------------------| C| . 1068 . -- -----------+ Transport . -- . 1069 . Transport . | Address . Transport . 1070 . Address . | Pair . Address . 1071 . tid=W . | ID=WY . tid=Y . 1072 . . | . . 1073 . . | . . 1074 . . | . . 1075 . -- . | . -- . 1076 . | B|-----------C---------------------------| D| . 1077 . -- ---------+ | Transport . -- . 1078 . Transport . | | Address . Transport . 1079 . Address . | | Pair . Address . 1080 . tid=X . | | ID=XZ . tid=Z . 1081 . . | | . . 1082 ............. | | ............. 1083 | | remote 1084 native | | candidate 1085 candidate | | 1086 | | ............. 1087 | | . . 1088 | | . -- . 1089 | +---------------------------| R| . 1090 | Transport . -- . 1091 | Address . Transport . 1092 | Pair . Address . 1093 | ID=WYR . tid=YR . 1094 | . . 1095 | . . 1096 | . . 1097 | . -- . 1098 +-----------------------------| S| . 1099 Transport . -- . 1100 Address . Transport . 1101 Pair . Address . 1102 ID=XZS . tid=ZS . 1103 . . 1104 ............. 1105 peer-derived 1106 remote candidate 1108 Figure 3 1110 7.4.1.3.2 On Receipt of a Binding Response 1112 When an agent receives a successful Binding Response, it examines the 1113 MAPPED-ADDRESS attribute in that response. If the MAPPED-ADDRESS 1114 does match any of the existing candidate transport addresses, this 1115 represents a new peer-derived transport address. 1117 The agent creates a new local candidate, and adds a transport address 1118 to it. It sets the IP address and port of this new native transport 1119 address to the IP address and port that was present in the MAPPED- 1120 ADDRESS attribute of the Binding Response. Since this is a new 1121 candidate transport address, it requires a new tid. The agent 1122 creates one algorithmically, by concatenating the tid of the native 1123 transport address in the transport address pair that was being 1124 validated by the Binding Request with the string representation of 1125 the source IP address and port from the MAPPED-ADDRESS attribute. 1126 This string representation is defined using the grammar for 1127 "hostport" from RFC 3261 [3], which defines the familiar notation of 1128 the IP address and port separated by a colon. 1130 The priority of the new candidate MUST be set to the priority of the 1131 native candidate that was being validated by the Binding Request. 1132 The agent SHOULD assign a new candidate ID to this candidate. 1134 Though this is a valid transport address, the agent does not pair it 1135 up with each of the remote transport addresses. Rather, it pairs it 1136 up only with the remote transport address from the transport address 1137 pair that was being validated. This creates a new transport address 1138 pair. Since connectivity has been verified in the send direction, 1139 the agent sets its state to send-valid. As with all other transport 1140 address pairs, the agent will attempt to validate receive 1141 capabilities by waiting for a a STUN Binding Request according to the 1142 procedures in Section 7.4.1.2. 1144 It is important to note that this process creates a new native 1145 transport address, not a whole new candidate. For a whole native 1146 candidate to come into existence, all of its component transport 1147 addresses must come into existence, and all must have been obtained 1148 as a result of a STUN Binding Requests between transport address 1149 pairs in the same pairing. 1151 7.4.2 TCP Connectivity Checks 1153 7.4.2.1 Connection Establishment 1155 Because of the connection-oriented nature of TCP, the connectivity 1156 checks work differently. After the offer/answer exchange completes, 1157 each agent will have a set of TCP candidates at which it is waiting 1158 to receive a connection on, and it will have a similar set from its 1159 peer. Thus, a pairing of TCP candidates allows for the possibility 1160 of TCP connections in each direction. Unlike the UDP checks, where 1161 the STUN packets are sent from the native transport addresses to the 1162 remote ones, the TCP connections are not opened from the native TCP 1163 transport addresses to the remote ones. This would represent a 1164 simultaneous open, and represent an unusual condition that would 1165 either fail, or at best result in a single TCP connection. Rather, 1166 ICE desires to attempt two connections, one in each direction, and 1167 use one of them if both happen to succeed. 1169 To accomplish this, each agent will attempt to open a connection to 1170 each remote transport address in the transport address pair, and do 1171 so "from" its native transport address. Here, however, "from" means 1172 something different than the UDP case. If the native transport 1173 address is a local transport address, the agent opens the TCP 1174 connection from the same IP interface used to obtain the local 1175 transport address, but from a different and ephemeral port. Indeed, 1176 that port MUST NOT be the same as the port in the local transport 1177 address. If the native transport address is a TURN-derived TCP 1178 transport address, no attempt is made to open a connection at all. 1179 TURN-derived TCP transport addresses can only be used in passive 1180 mode. 1182 As such, for each TCP transport address pair, there will be either 1183 zero, one, or two connection attempts. If the transport address 1184 pairs are both TURN-derived, there will be zero (both sides passive). 1185 If one of the transport addresses is local, and the other TURN 1186 derived, there will be one connection attempt. The agent owning the 1187 local transport address will be in active mode, and the agent owning 1188 the TURN-derived one will be in passive mode. If both are local 1189 transport address, there will be two attempts, and each agent will 1190 act in active mode. 1192 Because a transport address pair can produce multiple connections, 1193 validity becomes a property of the TCP connection itself. A 1194 transport address pair is considered valid if at least one valid 1195 connection has been established within it. An entire pairing is 1196 valid if all transport address pairs are valid. 1198 7.4.2.2 Sending STUN Binding Requests 1200 Once the connection is established, the agent which opened the 1201 connection (that is, acted in active mode) sends a STUN Binding 1202 Request over that connection. STUN Binding Requests as described in 1203 RFC 3489 are not normally sent over UDP, but when used in conjunction 1204 with ICE for connectivity checks, they are sent over TCP. 1206 This unusual operation requires some explanation. At first glance, a 1207 successful TCP connection ought to be sufficient. Clearly, 1208 connectivity is established, as TCP packets were exchanged in both 1209 directions via the TCP handshake. While that is true, the STUN 1210 Binding Requests serve many purposes, only one of which is to 1211 literally test connectivity. The STUN requests also serve as a 1212 correlation vehicle, allowing the agent to match the source of a 1213 connection attempt with the offer/answer signaling driving the entire 1214 mechanism. For example, in the case of a forked SIP INVITE carrying 1215 an offer, the UAC may receive two connection attempts to each of its 1216 passive TCP addresses, one from each branch of the fork. These are 1217 readily disambiguated by the STUN Binding Request which will follow, 1218 as the tid in the USERNAME tells the UAC which branch has initiated 1219 the connection. 1221 More importantly, however, the STUN Binding Request is an essential 1222 part of the security properties of ICE. Without it, an entity 1223 eavesdropping the signaling messages would be able to deny service or 1224 hijack media connections, and such attacks would require encryption 1225 of the offer/answer exchanges (using a mechanism like SIPS [3]) to 1226 prevent. However, when a STUN Binding Request exchange is added, 1227 these attacks are completely foiled without the need for SIPS, 1228 raising the overall security of ICE substantially with minimal cost. 1229 These properties of ICE are discussed thoroughly in Section 12. 1231 As such, once an agent has actively opened a TCP connection to the 1232 remote agent, it sends a STUN Binding Request over that connection. 1233 Recall that STUN messages include length indicators, allowing them to 1234 be framed over a connection-oriented transport protocol. The Binding 1235 Request MUST contain the USERNAME attribute. This attribute MUST be 1236 set to the transport address pair ID of the corresponding transport 1237 address pair as seen by its peer. Thus, for the first transport 1238 address pair in Figure 2, if the agent on the left sends the STUN 1239 Binding Request, the USERNAME will have the value YW. The request 1240 MAY contain the MESSAGE-INTEGRITY attribute, computed according to 1241 RFC 3489 procedures. The MESSAGE-INTEGRITY The Binding Request MUST 1242 NOT contain the CHANGE-REQUEST or ANSWER-ADDRESS attribute. The STUN 1243 BindingRequest message SHOULD NOT be retransmitted over the 1244 connection. 1246 The STUN will generate either a timeout, or a response. If the 1247 response is a 420, 500, or 401, the agent should try again as 1248 described in RFC 3489. Either initially, or after such a retry, the 1249 STUN transaction might produce a non-recoverable failure response 1250 (error codes 400, 431, or 600) or a failure result inapplicable to 1251 this usage of STUN and thus unrecoverable (432, 433). If this 1252 happens the connection is considered invalid. If the STUN 1253 transaction produces a 430 error or times out, the client SHOULD 1254 retry with a new STUN Binding Request transaction. The 430 response 1255 code is a result of a failed race between the BindingRequest and the 1256 answer. This is remedied by retrying, which allows the "slower" 1257 answer to be received. These retry transactions carry the same 1258 USERNAME value as the original Binding Request, and differ only in 1259 their STUN transaction ID. If these retries have not produced a 1260 success response after Tg seconds, the connection is considered 1261 invalid. Tg SHOULD be configurable. It is RECOMMENDED that it 1262 default to 50 seconds. This is a reasonable approximation of the 1263 maximum SIP transaction duration. 1265 If the STUN Binding Request generates a successful response, the 1266 connection over which it was sent is considered valid. Furthermore, 1267 the agent stores the IP address and port from the MAPPED-ADDRESS 1268 response in the STUN Binding Response. This is called the "apparent" 1269 native transport address for the active side of the connection. It 1270 will be used later if this connection is used for media transport. 1272 Once a connection is valid, the agent which initiated the connection 1273 MUST generate a new STUN Binding Request transaction every Tr 1274 seconds. This transaction ensures that NAT bindings for the 1275 connection remain open while the connection is under consideration as 1276 a candidate. Tr SHOULD be configurable, and SHOULD default to 15 1277 seconds. Each new Binding Request transaction is processed according 1278 to the procedures in this section. It is possible for a previously 1279 valid candidate to later be invalidated by a subsequent STUN 1280 transaction. This happens in cases where the NAT bindings expire. 1281 Note that, unlike the UDP case, STUN is sent only while a connection 1282 is is not active for media. If the connection is used as the active 1283 connection for media, STUN MUST NOT be sent. 1285 7.4.2.3 Receiving STUN Requests 1287 When an agent acted as the passive side of a TCP connection, it will 1288 receive a STUN Binding Request over that connection. 1290 One of the candidates will be in use as the active candidate. For 1291 the transport addresses comprising that candidate, the agent will 1292 receive both STUN requests and media packets on its associated local 1293 transport addresses. The agent MUST be able to disambiguate them. 1294 In the case of RTP/RTCP, this disambiguation is easy. RTP and RTCP 1295 packets start with the bits 0b10 (v=2). The first two bits in STUN 1296 are always 0b00. This disambiguation also works for packets sent 1297 using Secure RTP [23], since the RTP header is in the clear. 1298 Disambiguating STUN with other media stream protocols may be more 1299 complicated. However, it can always be possible with arbitrarily 1300 high probabilities by selecting an appropriately random username (see 1301 below). 1303 The STUN Binding Request can only be usefully processed once an 1304 offer/answer exchange has completed. As a result, if an offeror 1305 receives a STUN Binding Request message prior to the receipt of an 1306 answer to its offer, it MUST reject the request with a 430 response. 1307 This will cause the answerer to retry, and give time for the answer 1308 (which is in transit) to arrive at the offerer. 1310 If the offer/answer exchange has completed, the agent MUST follow the 1311 procedures defined in RFC 3489 and verify that the USERNAME attribute 1312 is known to the server. Here, this is done by taking the USERNAME 1313 attribute, and comparing it against the transport address pair 1314 identifiers for each transport address pair as seen by that agent. 1315 If there is no match, the STUN Binding Request generates a 400. If 1316 there is a match, the resulting transport address pair is called the 1317 matching transport address pair. The user agent proceeds with the 1318 processing of the request and generation of a response as per RFC 1319 3489. In addition, the agent stores the source IP address and port 1320 of the Binding Request, and associates it with the connection. This 1321 address is called the "apparent" remote transport address for this 1322 connection. 1324 An agent will continue to receive periodic STUN transactions as long 1325 as it had listed its transport address in an a=candidate attribute. 1326 It MUST process those transactions according to this section. It is 1327 possible that a transport address pair that was previously valid may 1328 become invalidated as a result of a subsequent failed STUN 1329 transaction. 1331 Note that, unlike the UDP case, there will never be simultaneous 1332 transmission of media and STUN packets over TCP connections. This is 1333 because the connection is listed as on hold according to comedia 1334 procedures, and no media will be transmitted. ICE will establish the 1335 connections as described here. Once established, an updated offer/ 1336 answer exchange can promote those connections to active usage through 1337 the comedia "exist" mechanism, as described below. The additional 1338 offer/answer exchange provides a barrier synchronization point at 1339 which a TCP connection switches from ICE control to control by the 1340 media source and sinks. Once it is active, STUN packets will no 1341 longer be sent on the connection. 1343 7.5 Promoting a Valid Candidate to Active 1345 7.5.1 Minimum Requirements 1347 As the STUN connectivity checks run, they will result in the 1348 validation of pairings. Once validated, a pairing can be used by 1349 promoting it to active. This promotion occurs by placing the 1350 transport addresses for the native candidate of the pairing into the 1351 m/c line and sending an updated offer. It MAY promote a candidate 1352 associated with any validated pairing at any time, as long as the 1353 candidate had been provided in series of a=candidate attributes in 1354 the most recent offer (in other words, an agent can't validate a 1355 candidate, omit that candidate from the a=candidate attribute of an 1356 offer, and then later on, generate a new offer that promotes the 1357 candidate to active). The procedures for doing so are described 1358 here. 1360 Any candidates which the agent would like to retain as valid 1361 candidates are also included in a=candidate lines in the offer. It 1362 SHOULD include any candidates learned from the peer-to-peer discovery 1363 processing of Section 7.4.1.3, and SHOULD include any candidates of 1364 higher priority than the one just promoted to active. It SHOULD omit 1365 candidates of lower priority than the one being promoted to active. 1366 It SHOULD omit any for whom all pairings that include that candidate 1367 have become invalid. 1369 If a candidate is omitted, and that candidate was a TURN-derived 1370 transport address, the agent SHOULD de-allocate the address from the 1371 TURN server. If a local candidate was omitted, along with all of its 1372 derived transport addresses, local operating system resources for 1373 that candidate SHOULD be de-allocated. 1375 Once it has decided on the set of candidates to provide in the 1376 updated offer, the agent constructs the offer and follows the 1377 procedures in Section 7.6 which defines general subsequent offer/ 1378 answer processing. 1380 7.5.2 Suggested Algorithm 1382 ICE leaves substantial variability to implementors around when an 1383 agent decides to generate a new offer. However, there are good ways 1384 to do this, and bad ways. Perhaps the worst algorithm possible would 1385 be to generate a new offer every time a candidate with higher 1386 priority than the active one becomes valid. This algorithm will 1387 likely result in a large number of offer/answer exchanges in rapid 1388 succession, many of which will produce "glare" as each agent will 1389 independently initiate an exchange. This will consume CPU and 1390 network resources for little benefit. Rather, the ideal algorithm 1391 strikes a balance between usage of network resources and the desire 1392 to use the ideal pair of candidates. 1394 The following algorithm provides a good tradeoff, and usage of this 1395 algorithm is RECOMMENDED. The algorithm results in a bounded number 1396 of additional offer/answer exchanges after the initial one - never 1397 more than two, and frequently one or zero. The algorithm almost 1398 never produces a glare condition. 1400 Once the initial offer/answer exchange completes, media flow will 1401 happen, though not optimally (where optimal is defined by the 1402 policies used to set the priorities of the candidates), as long as 1403 the candidate that is active has been validated. Thus, the objective 1404 of the algorithm is to quickly make sure that there is a valid path 1405 for media (to avoid clipping), and then do a single offer/answer 1406 exchange to use the highest priority pairing that was validated. 1408 After the initial offer/answer exchange, each agent sets a timer Tu. 1409 This timer SHOULD have a configurable baseline value, which SHOULD 1410 default to 3 seconds. The actual timer is set to this baseline, plus 1411 a time value chosen uniformly beween -1 and 1 seconds. This causes 1412 the actual timer to be randomized so that the timer doesnt fire 1413 simultaneously at each agent. In addition, each agent monitors the 1414 status of the active pairing. If the active media stream is UDP- 1415 based, the status of the active candidates is equal to the status of 1416 the pairing with matching transport addresses. In the case of TCP- 1417 based media, the active media stream is never active initially, since 1418 it always begins with the "holdconn" state. 1420 If, when Tu fires, the active pairing has not been validated, and 1421 there exists at least one pairing that has been validated, the agent 1422 generates a new offer. This offer promotes its highest priority 1423 candidate with a validated pairing to the active candidate. If there 1424 are no pairings that have been validated when the timer fires, the 1425 agent waits until one is validated, and once that happens, sets a 1426 timer to fire randomly between 0 and 2 seconds. When the timer 1427 fires, a new offer is generated that promotes the candidate from this 1428 validating pairing to active. If the active pairing is validated 1429 when the timer fires, the agent does nothing at this time. 1431 If new offer is to be sent, the agent includes the new active 1432 candidate in the a=candidate attribute list. It also includes all 1433 candidates with higher priority than the one that is active, 1434 including ones it learned from the connectivity checks themselves. 1436 At this point, media is flowing successfully, since a valid candidate 1437 is active. However, it may not be optimal. So, the next stage of 1438 the algorithm is to let the connectivity checks continue. If those 1439 checks indicate that a pairing between the two highest priority 1440 candidates from both agents has been validated, each agent sets a 1441 timer whose value is randomly set between 0 and 2 seconds. When the 1442 timer fires, a new offer is generated that promotes the candidate 1443 from this validating pairing to active. Otherwise, when the 1444 connectivity checks have all concluded, such that no pairing exists 1445 in the invalid state, each agent sets a timer whose value is randomly 1446 set between 0 and 2 seconds. When the timer fires, a new offer is 1447 generated that promotes the candidate from the valid pairing with the 1448 highest priority to active. 1450 7.6 Subsequent Offer/Answer Exchanges 1452 An offer/answer exchange within a session can occur at any time, 1453 whether it is the result of the algorithm described in Section 7.5.2, 1454 or because one of the agents wishes to add or remove a media stream, 1455 or add a codec, and so on. 1457 7.6.1 Sending of an Offer 1459 The meaning of a=candidate attributes within a subsequent offer have 1460 the same meaning they do in an initial offer. They are a request for 1461 the peer to attempt (or continue to attempt if the candidate was 1462 provided previously) a connectivity check using STUN from each of its 1463 own candidates. As such, an a=candidate attribute is included in 1464 subsequent offers when (1) connectivity checks haven't concluded yet 1465 to that candidate, or (2) the checks have concluded, and the 1466 candidate is currently active. In that case, STUN is used to keep 1467 the bindings active. 1469 If an agent sends an offer which omits candidates it had sent to its 1470 peer previously, it MUST cease connectivity checks from that 1471 candidate. Any pairings that include the absent native candidate are 1472 discarded. Any STUN transactions in progress from that candidate are 1473 immediately terminated - no further retransmissions take place, and 1474 no further transactions from that candidate will be made. If a TCP 1475 connection was opened to or from that candidate, and that connection 1476 is not listed as the active one in the offer, the connection is torn 1477 down. 1479 The offer MAY contain a new active candidate in the m/c line. If the 1480 new active transprot address is UDP, candidate is encoded into an 1481 update offer as described in Section 7.2. The transport addresses 1482 constituting the candidate SHOULD also be listed in a=candidate 1483 attributes, so that STUN can be used as an ongoing keepalive. 1485 If the new active transport address is TCP, it is more complicated. 1486 Recall that each TCP connection is opened from one of the agents to 1487 the other, such that, for each connection, one agent has the active 1488 role, and the other, the passive. The ICE mechanisms allow the 1489 active agent to actually choose a specific connection for use in an 1490 offer, so long as the agent has used a different ephemeral port for 1491 each connection it initiated (which is almost always the case). If, 1492 however, an agent was in the passive role, it cannot choose a 1493 specific connection. Rather, it can choose a specific native 1494 transport address which may have been used to receive multiple 1495 connections. This assymetric behavior brings with it some important 1496 security properties, which are discussed in Section 12. 1498 If the agent was the active one and established the connection, it 1499 includes its apparent native transport address in the m/c line of the 1500 SDP (recall that this address was discovered via the STUN exchange 1501 over the connection). Note that this is instead of the SHOULD- 1502 strength recommendation in comedia, which recommends that the port 1503 number sent by the entity which initiated the connection should be 1504 '9'. The actual port number is present to facilitate identification 1505 of the connection. The a=setup attribute MUST be present and MUST 1506 contain the value "active". The a=connection attribute MUST be 1507 present and MUST have the value of "existing". 1509 If the agent was the passive one and was the recipient of the 1510 connection, it includes its transport address in the m/c line of the 1511 SDP. In this case, that address will be the same as the one it had 1512 placed into the a=candidate line of the SDP. The a=setup attribute 1513 MUST be present and MUST contain the value of "passive". The 1514 a=connection attribute MUST be present and MUST have the value of 1515 "existing". 1517 7.6.2 Receiving the Offer and Sending an Answer 1519 If an agent receives an updated offer with a=candidate attributes, it 1520 checks to see if it already knows about the listed candidates. This 1521 is done by comparing the tid with the candidates it had received in 1522 the previous offer or answer from the peer. If the tid is already 1523 known, processing for that candidate continues as if no offer had 1524 been made. Any connectivity checks in progress continue, and any 1525 ongoing STUN keepalives continue. 1527 If a candidate which had been listed previously is no longer present 1528 in the offer, this tells the answerer to cease connectivity checks. 1529 Any pairings that include the absent remote candidate are discarded. 1530 Any STUN transactions in progress to that candidate are immediately 1531 terminated - no further retransmissions take place, and no further 1532 transactions to that candidate will be made. If a TCP connection was 1533 opened to or from that candidate, and that connection is not listed 1534 as the active one in the offer, the connection is torn down. 1536 The agent then sends its answer. Like the offerer, it can add or 1537 remove candidates from its answer. If it removed candidates from its 1538 answer, it ceases STUN connectivity checks from those candidates, and 1539 any pairings that include those candidates are discarded. Any STUN 1540 transactions in progress to that candidate are immediately terminated 1541 - no further retransmissions take place, and no further transactions 1542 to that candidate will be made. If a TCP connection was opened to or 1543 from that candidate, and that connection is not listed as the active 1544 one in the answer, the connection is torn down. 1546 After transmission of the answer, there may be a set of candidates 1547 which were new in the offer, and a set that were new in the answer. 1548 The agent begins connectivity checks as described in Section 7.4, 1549 pairing each new candidate in its answer with all candidates in the 1550 offer, and each new candidate in the offer with all of its candidates 1551 in the answer. 1553 The m/c line may have also changed, indicating a new active 1554 candidate. If the m/c line contains a UDP stream, the agent begins 1555 sending media to the transport addresses listed there. In addition, 1556 it checks to see if those transport addresses correspond to a remote 1557 candidate in a valid pairing. So long as the remote agent has 1558 offered up a candidate that has been validated by ICE, it should be 1559 the case. Indeed, there may be a multitude of valid pairings 1560 containing the transport addresses in the m/c line as the remote 1561 candidate. In that case, the agent MUST choose the pairing whose 1562 native candidate has the highest priority. It MUST place this 1563 candidate in the m/c line. Transmission of media occurs as defined 1564 in Section 7.8. 1566 If the m/c line has changed, and now indicates a new TCP candidate, 1567 the agent examines it. The comedia "a=connection" attribute will 1568 normally be present and normally contain the value of "existing". If 1569 not present, or if present but with a value of "new", comedia process 1570 is followed, as apparently the peer has abandoned ICE operation for 1571 this media stream. Assuming it contains a value of "existing", the 1572 agent looks at whether the a=setup attribute is present. If its 1573 value is "active", it means that a connection that was initiated by 1574 the remote agent is to be used. The agent examines the transport 1575 address in the m/c line. It looks for a matching value in the 1576 apparent remote transport addresses of existing connections. If it 1577 matches multiple connections (though it should normally match just 1578 one), one of those connections is chosen. The native transport 1579 address of that connection is then placed into the m/c line of the 1580 answer. If no existing connections where matched, an error has 1581 occured. The agent SHOULD respond with "holdconn", and then generate 1582 its own offer with a connection to the peer which it believes is 1583 valid. 1585 If the a=setup attribute had a value of "passive", it means that a 1586 connection that was initiated by the agent itself is to be used. The 1587 agent examines the transport address in the m/c line. It looks for a 1588 matching value amongst the remote transport addresses in valid 1589 pairings. If multiple pairings match, it MUST choose the one whose 1590 native transport address has the highest priority. The apparent 1591 native transport address associated with an active connection 1592 initiated by the agent is then placed into the m/c line, and that TCP 1593 connection is used to send and receive media. If no pairings match, 1594 an error has occured. The agent SHOULD respond with "holdconn", and 1595 then generate its own offer with a connection to the peer which it 1596 believes is valid. 1598 7.6.3 Receiving the Answer 1600 If an agent receives an answer with a=candidate attributes, it checks 1601 to see if it already knows about the listed candidates. This is done 1602 by comparing the tid with the candidates it had received in the 1603 previous offer or answer from the peer. If the tid is already known, 1604 processing for that candidate continues as if no offer had been made. 1605 Any connectivity checks in progress continue, and any ongoing STUN 1606 keepalives continue. 1608 If a candidate which had been listed previously is no longer present 1609 in the answer, this tells the offerer to cease connectivity checks. 1610 Any pairings that include the absent remote candidate are discarded. 1611 Any STUN transactions in progress to that candidate are immediately 1612 terminated - no further retransmissions take place, and no further 1613 transactions to that candidate will be made. If a TCP connection was 1614 opened to or from that candidate, and that connection is not listed 1615 as the active one in the answer, the connection is torn down. 1617 Furthermore, there may be a set of candidates which were new in the 1618 offer, and a set that were new in the answer. The agent begins 1619 connectivity checks as described in Section 7.4, pairing each new 1620 candidate in its offer with all candidates in the answer, and each 1621 new candidate in the answer with all of its candidates in the offer. 1623 The m/c line may have also changed, indicating a new active 1624 candidate. If the m/c line contains a UDP stream, the agent begins 1625 sending media to the transport addresses listed there as defined in 1626 Section 7.8. It will send from the m/c line it had signaled in the 1627 offer. 1629 If the m/c line has changed, and now indicates a new TCP candidate, 1630 the agent examines it. If the agent had, in its offer, indicated the 1631 desire to use a specific connection that it had initiated, it would 1632 have used the a=connection attribute with the value of "existing", 1633 and the a=setup attribute with the value of "active", and have placed 1634 its apparent native transport address in the m/c line. In that case, 1635 the m/c line in the answer will normally have the a=connection 1636 attribute with the value "existing", which means that the remote 1637 agent agrees with the usage of that connection. The transport 1638 addresses in the m/c line should correspond to the remote transport 1639 addresses that the agent had initiated its connection to. If so, 1640 that connection is used. 1642 If the agent had, in its offer, indicated the desire to use any 1643 connection that had been established to a specific native transport 1644 address, it would have, in its offer, used the a=connection attribute 1645 with the value of "existing" and the a=setup attribute with the value 1646 of "passive", and placed that address in the m/c line. In that case, 1647 the m/c line in the answer will normally have the a=connection 1648 attribute with the value of "existing" and the a=setup attribute with 1649 the value of "active". The transport address in the m/c line will 1650 correspond to the apparent remote transport address. The agent MUST 1651 scan its existing connections to the native transport address it had 1652 advertised in the offer, and find the one whose apparent remote 1653 transport address matches the m/c line in the answer. If there is a 1654 match, that connection is used for sending media. If there is no 1655 match, an error has occurred. 1657 7.7 Binding Keepalives 1659 Once the candidates are promoted to active, and media begins flowing, 1660 it is still necessary to keep the bindings alive at intermediate NATs 1661 for the duration of the session. Normally, the RTP packets 1662 themselves meet this objective. However, several cases merit further 1663 discussion. Firstly, in some RTP usages, such as SIP, the media 1664 streams can be "put on hold". This is accomplished by using the SDP 1665 "sendonly" or "inactive" attributes, as defined in RFC 3264 [4]. RFC 1666 3264 directs implementations to cease transmission of media in these 1667 cases. However, doing so may cause NAT bindings to timeout, and 1668 media won't be able to come off hold. 1670 Secondly, some RTP payload formats, such as the payload format for 1671 text conversation [28], may send packets so infrequently that the 1672 interval exceeds the NAT binding timeouts. 1674 Thirdly, if silence suppression is in use, long periods of silence 1675 may cause media transmission to cease sufficiently long for NAT 1676 bindings to time out. 1678 To prevent these problems, ICE implementations MUST continue to list 1679 their active transport addresses as candidates in a=candidate lines. 1680 As a consequence of this, STUN packets will be transmitted 1681 periodically independently of the transmission (or lack thereof) of 1682 media packets. This provides a media independent, RTP independent, 1683 and codec independent solution for keeping the NAT bindings alive. 1685 If an ICE implementation is communciating with one that does not 1686 support ICE, keepalives MUST still be sent. In that case, it is 1687 RECOMMENDED that an agent support the RTP No-Op payload format [15], 1688 and send it at least once every 20 seconds if media is not otherwise 1689 being sent. This No-Op MUST be sent even if the media stream is 1690 inactive or recvonly. 1692 7.8 Sending Media 1694 When an agent sends media packets, it MUST send them from the same IP 1695 address and port it has advertised in the m/c-line. This provides a 1696 property known as symmetry, which is an essential facet of NAT 1697 travresal. 1699 In the case of a STUN-derived transport address, this means that the 1700 RTP packets are sent from the local transport address used to obtain 1701 the STUN address. In the case of a TURN-derived transport address, 1702 this means that media packets are sent through the TURN server (using 1703 the TURN SEND primitive). For local transport addresses, media is 1704 sent from that local transport address. 1706 This symmetric behavior MUST be followed by an agent even if its peer 1707 in the session doesn't support ICE. 1709 8. Interactions with Forking 1711 SIP allows INVITE requests carrying offers to fork, which means that 1712 they are delivered to multiple user agents. Each of those user 1713 agents then provides an answer to the offer in the INVITE. The 1714 result is that a single offer generated by the UAC produces multiple 1715 answers. 1717 ICE interacts very well with forking. Indeed, ICE fixes some of the 1718 problems associated with forking. Once the offer/answer exchange has 1719 completed, the UAC will have an answer from each UAS that received 1720 the INVITE. The ICE connectivity checks that ensue will carry tids 1721 that correlate each of those checks (and thus their corresponding 1722 source IP address and port or TCP connection) with a specific remote 1723 user agent. As these checks happen before any media is transmitted, 1724 ICE allows a UAC to disambiguate subsequent media traffic, and 1725 corelate that traffic with a particular remote UA. When SIP is used 1726 without ICE, the incoming media traffic cannot be disambiguated 1727 without an additional offer/answer exchange. 1729 9. Interactions with Preconditions 1731 Because ICE involves multiple addresses and pre-session activities, 1732 its interactions with preconditions [10] merits further discussion. 1734 Quality of Service (QoS) preconditions, which are defined in RFC 1735 3312, apply only to the IP addresses and ports listed in the m/c 1736 lines in an offer/answer. If ICE changes the address and port where 1737 media is received, this change is reflected in the m/c lines of a new 1738 offer/answer. As such, it appears like any other re-INVITE would, 1739 and is fully treated in RFC 3312, which applies without regard to the 1740 fact that the m/c lines are changing due to ICE negotiations ocurring 1741 "in the background". 1743 ICE also has (purposeful) interactions with connectivity 1744 preconditions [12]. As described there, the precondition is 1745 satisfied once ICE has verified that there exists a valid path of 1746 connectivity for each media stream to which the precondition applies. 1747 More specifically, it is satisfied when there is at least one valid 1748 UDP transport address pairing or TCP connection for such a media 1749 stream. Furthermore, when a subsequent offer is made to promote one 1750 of those valid transport address pairings or connections into the 1751 m/c-line, the preconditions is marked as met in that same offer/ 1752 answer exchange. 1754 10. Example 1756 In the example that follows, messages are labeled with "message name 1757 A,B" to mean a message from transport address A to B. For STUN 1758 Requests, this is followed by curly brackets enclosing the username 1759 (which is also the password). For STUN answers, this is followed by 1760 square brackets containing the value of MAPPED ADDRESS. The example 1761 shows a flow of two agents where one is behind a full cone NAT, and 1762 the other is behind a symmetric NAT. 1764 TODO: Fill in. This is a big complicated flow! 1766 11. Grammar 1768 This specification defines a new SDP attribute. It is called 1769 "candidate". The candidate attribute MUST be present within a media 1770 block of the SDP. It contains a transport address for a candidate 1771 that can be used for connectivity checks. There MAY be multiple 1772 candidate attributes in a media block. 1774 The syntax of this attribute is: 1776 candidate-attribute = "candidate" ":" candidate-id SP tid SP 1777 transport SP 1778 qvalue SP ;qvalue from RFC 3261 1779 addr SP 1780 port SP 1781 ;addr, port from RFC 2327 1782 transport = "UDP" / "TCP" / transport-extension 1783 transport-extension = token 1784 candidate-id = 1*DIGIT 1785 id = non-ws-string 1787 The candidate-id is used to group together the transport addresses 1788 for a particular candidate. It MUST be a positive integer whose 1789 value is less than (2^31 -1). It MUST have the same value for all 1790 transport addresses within the same candidate. It MUST have a 1791 different value for transport addresses within different candidates 1792 for the same media stream. The tid production contains an 1793 identifier, chosen with 128 bits of randomness, that identifies the 1794 transport address. The tid of a pair of transport addresses is 1795 combined to for the username and password of a STUN request from one 1796 transport address to another. The transport production indicates the 1797 transport protocol for the candidate. This can be either UDP or TCP. 1798 Extensibility is provided to allow for future transport protocols to 1799 be used with ICE, such as the Datagram Congestion Control Protocol 1800 (DCCP) [26]. The unicast-address production is from RFC 2327, and 1801 contains the IPv4 or IPv6 address of the candidate. The port 1802 production contains its port. 1804 12. Security Considerations 1806 There are numerous threats in a system using ICE. This section 1807 overviews these threats and discusses how they are mitigated. 1809 STUN itself introduces many security considerations, which receive an 1810 extensive treatment in RFC 3489. STUN is used within ICE in two ways 1811 - one, as a technique for address gathering, and two, as a peer-to- 1812 peer connectivity check. All of the security considerations of RFC 1813 3489 apply directly to the former usage. However, the latter usage, 1814 as a peer-to-peer connectivity check, is sufficiently different that 1815 a discussion of its security considerations is appropriate. 1817 It remains the case that many attacks are rooted in a single 1818 primitive - an attacker attempts to inject a STUN response with an 1819 invalid MAPPED-ADDRESS attribute. In the usages of STUN described in 1820 RFC 3489, this injection can occur as a result of compromises of STUN 1821 servers, attacks on the DNS, rogue NATs, injection of faked responses 1822 coupled with a dos attack, and replaying modified requests. With 1823 peer-to-peer STUN, compromises of STUN servers are not much of a 1824 concern, since the STUN servers are embedded in endpoints and 1825 distributed throughout the network. Thus, compromising the STUN 1826 server is equivalent to comprimising the endpoint, and if that 1827 happens, far more problematic attacks are possible than those against 1828 ICE. Similarly, DNS attacks are irrelevant since STUN servers are 1829 not discovered via DNS, they are signaled via SIP. Rogue NATs, 1830 injection of fake responses and relaying modified requests all can be 1831 handled in ICE with the countermeasures discussed below. 1833 Consider an attacker that intercepts a STUN packet used for 1834 connectivity checks, and replays it using its own source address. If 1835 successful, this would fool an endpoint into thinking that this faked 1836 source address was a valid destination for media (recall that the 1837 source transport address of received STUN packets is used as a 1838 potential candidate address). However, the recipient of the replayed 1839 packet will not just send media to that candidate. It will verify it 1840 with a STUN connectivity check. This check will be sent to that 1841 faked source address, and if there is no answer, the address will not 1842 be used. The attacker cannot answer the STUN request without access 1843 to the username and password, which are exchanged as part of the 1844 signaling. Thus, if the signaling is protected as recommended above, 1845 the attacker cannot obtain the username or password. 1847 If an attacker instead intercepts and replays STUN packets used for 1848 the purposes of unilateral allocation, a similar result occurs. The 1849 target of the attack will be fooled into thinking it has a STUN 1850 derived transport address that it does not. Its peer will perform a 1851 connectivity check to this address, which will fail. The attacker 1852 cannot force this check to succeed without access to the username and 1853 password, which are protected. Thus, this address will not be used. 1855 In the worst case, an attacker can generate enough traffic so that 1856 none of the valid STUN checks or unilateral allocations succeed. 1857 This would result in a service disruption. However, this attack is 1858 no worse than any pure packet flood disruption attack launched 1859 against any other protocol. These attacks cannot be prevented by any 1860 protocol means. 1862 If an attacker could intercept and modify the contents of the Offer 1863 or Accept messages, they could disrupt the session, divert the media, 1864 and otherwise take control over the session. This attack is 1865 prevented by encryption, authentication and message integrity of the 1866 signaling channel used for ICE. 1868 SIP-based implementations of ICE SHOULD use the sips URI scheme when 1869 transporting SDP with ICE information, and MAY use S/MIME [3]. 1871 13. IANA Considerations 1873 This specification defines one new SDP attribute per the procedures 1874 of Appendix B of RFC 2327. The required information for the 1875 registration is: 1877 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 1879 Attribute Name: candidate 1881 Long Form: candidiate 1883 Type of Attribute: media level 1885 Charset Considerations: The attribute is not subject the the charset 1886 attribute. 1888 Purpose: This attribute is used with Interactive Connectivity 1889 Establishment (ICE), and provides one of many possible candidate 1890 addresses for communication. These addresses are validated with 1891 an end-to-end connectivity check using Simple Traversal of UDP 1892 with NAT (STUN). 1894 Appropriate Values: See Section 11 of RFC XXXX [Note to RFC-ed: 1895 please replace XXXX with the RFC number of this specification]. 1897 14. IAB Considerations 1899 The IAB has studied the problem of "Unilateral Self Address Fixing", 1900 which is the general process by which a agent attempts to determine 1901 its address in another realm on the other side of a NAT through a 1902 collaborative protocol reflection mechanism [21]. ICE is an example 1903 of a protocol that performs this type of function. Interestingly, 1904 the process for ICE is not unilateral, but bilateral, and the 1905 difference has a signficant impact on the issues raised by IAB. The 1906 IAB has mandated that any protocols developed for this purpose 1907 document a specific set of considerations. This section meets those 1908 requirements. 1910 14.1 Problem Definition 1912 From RFC 3424 any UNSAF proposal must provide: 1914 Precise definition of a specific, limited-scope problem that is to 1915 be solved with the UNSAF proposal. A short term fix should not be 1916 generalized to solve other problems; this is why "short term 1917 fixes usually aren't". 1919 The specific problems being solved by ICE are: 1921 Provide a means for two peers to determine the set of transport 1922 addresses which can be used for communication. 1924 Provide a means for resolving many of the limitations of other 1925 UNSAF mechanisms by wrapping them in an additional layer of 1926 processing (the ICE methodology). 1928 Provide a means for a agent to determine an address that is 1929 reachable by another peer with which it wishes to communicate. 1931 14.2 Exit Strategy 1933 From RFC 3424, any UNSAF proposal must provide: 1935 Description of an exit strategy/transition plan. The better short 1936 term fixes are the ones that will naturally see less and less use 1937 as the appropriate technology is deployed. 1939 ICE itself doesn't easily get phased out. However, it is useful even 1940 in a globally connected Internet, to serve as a means for detecting 1941 whether a router failure has temporarily disrupted connectivity, for 1942 example. However, what ICE does is help phase out other UNSAF 1943 mechanisms. ICE effectively selects amongst those mechanisms, 1944 prioritizing ones that are better, and deprioritizing ones that are 1945 worse. Local IPv6 addresses can be preferred. As NATs begin to 1946 dissipate as IPv6 is introduced, derived transport addresses from 1947 other UNSAF mechanisms simply never get used, because higher priority 1948 connectivity exists. Therefore, the servers get used less and less, 1949 and can eventually be remove when their usage goes to zero. 1951 Indeed, ICE can assist in the transition from IPv4 to IPv6. It can 1952 be used to determine whether to use IPv6 or IPv4 when two dual-stack 1953 hosts communicate with SIP (IPv6 gets used). It can also allow a 1954 network with both 6to4 and native v6 connectivity to determine which 1955 address to use when communicating with a peer. 1957 14.3 Brittleness Introduced by ICE 1959 From RFC3424, any UNSAF proposal must provide: 1961 Discussion of specific issues that may render systems more 1962 "brittle". For example, approaches that involve using data at 1963 multiple network layers create more dependencies, increase 1964 debugging challenges, and make it harder to transition. 1966 ICE actually removes brittleness from existing UNSAF mechanisms. In 1967 particular, traditional STUN (the usage described in RFC 3489) has 1968 several points of brittleness. One of them is the discovery process 1969 which requires a agent to try and classify the type of NAT it is 1970 behind. This process is error-prone. With ICE, that discovery 1971 process is simply not used. Rather than unilaterally assessing the 1972 validity of the address, its validity is dynamically determined by 1973 measuring connectivity to a peer. The process of determining 1974 connectivity is very robust. The only potential problem is that 1975 bilaterally fixed addresses through STUN can expire if traffic does 1976 not keep them alive. However, that is substantially less brittleness 1977 than the STUN discovery mechanisms. 1979 Another point of brittleness in STUN, TURN, and any other unilateral 1980 mechanism is its absolute reliance on an additional server. ICE 1981 makes use of a server for allocating unilateral addresses, but allows 1982 agents to directly connect if possible. Therefore, in some cases, 1983 the failure of a STUN or TURN server would still allow for a call to 1984 progress when ICE is used. 1986 Another point of brittleness in traditional STUN is that it assumes 1987 that the STUN server is on the public Internet. Interestingly, with 1988 ICE, that is not necessary. There can be a multitude of STUN servers 1989 in a variety of address realms. ICE will discover the one that has 1990 provided a usable address. 1992 The most troubling point of brittleness in traditional STUN is that 1993 it doesn't work in all network topologies. In cases where there is a 1994 shared NAT between each agent and the STUN server, traditional STUN 1995 may not work. With ICE, that restriction can be lifted. 1997 Traditional STUN also introduces some security considerations. 1998 Fortunately, those security considerations are also mitigated by ICE. 2000 14.4 Requirements for a Long Term Solution 2002 From RFC 3424, any UNSAF proposal must provide: 2004 Identify requirements for longer term, sound technical solutions 2005 -- contribute to the process of finding the right longer term 2006 solution. 2008 Our conclusions from STUN remain unchanged. However, we feel ICE 2009 actually helps because we believe it can be part of the long term 2010 solution. 2012 14.5 Issues with Existing NAPT Boxes 2014 From RFC 3424, any UNSAF proposal must provide: 2016 Discussion of the impact of the noted practical issues with 2017 existing, deployed NA[P]Ts and experience reports. 2019 A number of NAT boxes are now being deployed into the market which 2020 try and provide "generic" ALG functionality. These generic ALGs hunt 2021 for IP addresses, either in text or binary form within a packet, and 2022 rewrite them if they match a binding. This will interfere with 2023 proper operation of any UNSAF mechanism, including ICE. 2025 15. Acknowledgements 2027 The authors would like to thank Douglas Otis, Francois Audet and 2028 Magnus Westerland for their comments and input. 2030 16. References 2032 16.1 Normative References 2034 [1] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 2035 - Simple Traversal of User Datagram Protocol (UDP) Through 2036 Network Address Translators (NATs)", RFC 3489, March 2003. 2038 [2] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 2039 Session Description Protocol (SDP)", RFC 3605, October 2003. 2041 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2042 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2043 Session Initiation Protocol", RFC 3261, June 2002. 2045 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2046 Session Description Protocol (SDP)", RFC 3264, June 2002. 2048 [5] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 2049 Comfort Noise (CN)", RFC 3389, September 2002. 2051 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2052 January 2004. 2054 [7] Handley, M. and V. Jacobson, "SDP: Session Description 2055 Protocol", RFC 2327, April 1998. 2057 [8] Casner, S., "Session Description Protocol (SDP) Bandwidth 2058 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 2059 July 2003. 2061 [9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 2062 Responses in Session Initiation Protocol (SIP)", RFC 3262, 2063 June 2002. 2065 [10] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 2066 Resource Management and Session Initiation Protocol (SIP)", 2067 RFC 3312, October 2002. 2069 [11] Camarillo, G., "The Alternative Network Address Types Semantics 2070 (ANAT) for theSession Description Protocol (SDP) Grouping 2071 Framework", draft-ietf-mmusic-anat-02 (work in progress), 2072 October 2004. 2074 [12] Andreasen, F., "Connectivity Preconditions for Session 2075 Description Protocol Media Streams", 2076 draft-ietf-mmusic-connectivity-precon-00 (work in progress), 2077 May 2005. 2079 [13] Yon, D., "Connection-Oriented Media Transport in the Session 2080 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10 2081 (work in progress), November 2004. 2083 [14] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 2084 draft-rosenberg-midcom-turn-07 (work in progress), 2085 February 2005. 2087 [15] Andreasen, F., "A No-Op Payload Format for RTP", 2088 draft-ietf-avt-rtp-no-op-00 (work in progress), May 2005. 2090 16.2 Informative References 2092 [16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 2093 Protocol (RTSP)", RFC 2326, April 1998. 2095 [17] Senie, D., "Network Address Translator (NAT)-Friendly 2096 Application Design Guidelines", RFC 3235, January 2002. 2098 [18] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 2099 Rayhan, "Middlebox communication architecture and framework", 2100 RFC 3303, August 2002. 2102 [19] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm 2103 Specific IP: Framework", RFC 3102, October 2001. 2105 [20] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm 2106 Specific IP: Protocol Specification", RFC 3103, October 2001. 2108 [21] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 2109 Address Fixing (UNSAF) Across Network Address Translation", 2110 RFC 3424, November 2002. 2112 [22] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2113 "RTP: A Transport Protocol for Real-Time Applications", 2114 RFC 3550, July 2003. 2116 [23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2117 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2118 RFC 3711, March 2004. 2120 [24] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 2121 IPv4 Clouds", RFC 3056, February 2001. 2123 [25] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 2124 draft-huitema-v6ops-teredo-05 (work in progress), April 2005. 2126 [26] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 2127 draft-ietf-dccp-spec-11 (work in progress), March 2005. 2129 [27] Lazzaro, J., "Framing RTP and RTCP Packets over Connection- 2130 Oriented Transport", draft-ietf-avt-rtp-framing-contrans-05 2131 (work in progress), January 2005. 2133 [28] Hellstrom, G., "RTP Payload for Text Conversation", 2134 draft-ietf-avt-rfc2793bis-09 (work in progress), August 2004. 2136 Author's Address 2138 Jonathan Rosenberg 2139 Cisco Systems 2140 600 Lanidex Plaza 2141 Parsippany, NJ 07054 2142 US 2144 Phone: +1 973 952-5000 2145 Email: jdrosen@cisco.com 2146 URI: http://www.jdrosen.net 2148 Intellectual Property Statement 2150 The IETF takes no position regarding the validity or scope of any 2151 Intellectual Property Rights or other rights that might be claimed to 2152 pertain to the implementation or use of the technology described in 2153 this document or the extent to which any license under such rights 2154 might or might not be available; nor does it represent that it has 2155 made any independent effort to identify any such rights. Information 2156 on the procedures with respect to rights in RFC documents can be 2157 found in BCP 78 and BCP 79. 2159 Copies of IPR disclosures made to the IETF Secretariat and any 2160 assurances of licenses to be made available, or the result of an 2161 attempt made to obtain a general license or permission for the use of 2162 such proprietary rights by implementers or users of this 2163 specification can be obtained from the IETF on-line IPR repository at 2164 http://www.ietf.org/ipr. 2166 The IETF invites any interested party to bring to its attention any 2167 copyrights, patents or patent applications, or other proprietary 2168 rights that may cover technology that may be required to implement 2169 this standard. Please address the information to the IETF at 2170 ietf-ipr@ietf.org. 2172 Disclaimer of Validity 2174 This document and the information contained herein are provided on an 2175 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2176 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2177 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2178 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2179 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2180 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2182 Copyright Statement 2184 Copyright (C) The Internet Society (2005). This document is subject 2185 to the rights, licenses and restrictions contained in BCP 78, and 2186 except as set forth therein, the authors retain all their rights. 2188 Acknowledgment 2190 Funding for the RFC Editor function is currently provided by the 2191 Internet Society.