idnits 2.17.1 draft-rosenberg-sipping-ice-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 121 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 64 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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** 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 259: '...ost. A multi-homed host SHOULD attempt...' RFC 2119 keyword, line 272: '...ess, the offerer SHOULD address-fix ag...' RFC 2119 keyword, line 295: '... the server SHOULD reject any reques...' RFC 2119 keyword, line 325: '... client MUST choose a username and p...' RFC 2119 keyword, line 351: '...r is started, it MUST run until the fi...' (37 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 (June 30, 2003) is 7603 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: '1' is defined on line 2967, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2995, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3388 (ref. '9') (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '10') (Obsoleted by RFC 3550) == Outdated reference: A later version (-01) exists of draft-ietf-sip-symmetric-response-00 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '13') (Obsoleted by RFC 5389) == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-01 == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-05 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-nat-scenarios-00 == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-00 == Outdated reference: A later version (-02) exists of draft-camarillo-mmusic-alt-01 Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: December 29, 2003 June 30, 2003 6 Interactive Connectivity Establishment (ICE): A Methodology for 7 Network Address Translator (NAT) Traversal for the Session Initiation 8 Protocol (SIP) 9 draft-rosenberg-sipping-ice-01 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 29, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document describes a methodology for Network Address Translator 40 (NAT) traversal for the Session Initiation Protocol (SIP). This 41 methodology is called Interactive Connectivity Establishment (ICE). 42 ICE is not a new protocol, but rather makes use of existing 43 protocols, such as Simple Traversal of UDP Through NAT (STUN), 44 Traversal Using Relay NAT (TURN) and even Real Specific IP (RSIP). 45 ICE works through the mutual cooperation of both endpoints in a SIP 46 dialog. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4. Core ICE Algorithm . . . . . . . . . . . . . . . . . . . . . 7 54 5. Detailed ICE Algorithm . . . . . . . . . . . . . . . . . . . 8 55 5.1 Gathering Transport Addresses . . . . . . . . . . . . . . . 8 56 5.2 Enabling STUN on Each Transport Address . . . . . . . . . . 8 57 5.3 Prioritizing the Transport Addresses . . . . . . . . . . . . 10 58 5.4 Constructing the Offer . . . . . . . . . . . . . . . . . . . 10 59 5.5 Answerer Processing - Connectivity Checks and Gathering . . 11 60 5.6 Generating the Answer . . . . . . . . . . . . . . . . . . . 14 61 5.7 Offerer Processing of the Answer . . . . . . . . . . . . . . 14 62 5.8 Additional ICE Cycles . . . . . . . . . . . . . . . . . . . 14 63 6. Running STUN on Derived Transport Addresses . . . . . . . . 16 64 6.1 STUN on a TURN Derived Transport Address . . . . . . . . . . 16 65 6.2 STUN on a STUN Derived Transport Address . . . . . . . . . . 17 66 7. SDP Extensions for STUN . . . . . . . . . . . . . . . . . . 19 67 8. Connectivity Preconditions . . . . . . . . . . . . . . . . . 22 68 9. Example Use Cases . . . . . . . . . . . . . . . . . . . . . 24 69 9.1 Residential Users . . . . . . . . . . . . . . . . . . . . . 24 70 9.1.1 Full Cone NAT . . . . . . . . . . . . . . . . . . . . . . . 25 71 9.1.2 Symmetric NAT . . . . . . . . . . . . . . . . . . . . . . . 37 72 9.2 Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . 44 73 9.2.1 Intra-Enterprise Call . . . . . . . . . . . . . . . . . . . 46 74 9.2.2 Extra-Enterprise Call . . . . . . . . . . . . . . . . . . . 51 75 9.2.3 Disconnected Intra-Enterprise . . . . . . . . . . . . . . . 51 76 9.3 Centrex . . . . . . . . . . . . . . . . . . . . . . . . . . 58 77 9.3.1 Intra-Enterprise Call . . . . . . . . . . . . . . . . . . . 59 78 10. Security Considerations . . . . . . . . . . . . . . . . . . 67 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 68 80 11.1 Precondition Type . . . . . . . . . . . . . . . . . . . . . 68 81 11.2 SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 68 82 12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 69 83 12.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . 69 84 12.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . 69 85 12.3 Brittleness Introduced by ICE . . . . . . . . . . . . . . . 70 86 12.4 Requirements for a Long Term Solution . . . . . . . . . . . 71 87 12.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . . 71 88 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72 89 Informative References . . . . . . . . . . . . . . . . . . . 73 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . 75 91 Intellectual Property and Copyright Statements . . . . . . . 76 93 1. Introduction 95 The subject of NAT traversal for SIP has received a profound amount 96 of attention. SIP extensions have been defined for routing responses 97 [11] through NAT, and for routing requests from a public network to a 98 private one through persistent connections [12]. 100 However, far more troubling is the traversal of SIP's media sessions 101 through NAT. Numerous solutions have been proposed for that. These 102 include Application Layer Gateways (ALGs), the Middlebox Control 103 Protocol [2], Simple Traversal of UDP through NAT (STUN) [13], 104 Traversal Using Relay NAT [14], Realm Specific IP [3][4], Topology 105 Insensitive Service Traversal (TIST) [15], symmetric RTP [16], along 106 with protocol extensions needed to make them work, such as [17]. The 107 sum total is so complex, that an extensive scenarios document [18] 108 has been written. The latter outlines various network situations, and 109 analyzes the various solutions in each. Unsurprisingly, each 110 situation has a specific ideal solution. 112 However, the result is a system which is incredibly complex and very 113 brittle. What is needed is a single solution which is flexible enough 114 to work well in all situations. 116 Our proposal for such a solution is called Interactive Connectivity 117 Establishment, or ICE. ICE makes use of many of the protocols above, 118 but uses them in a specific methodology which avoids many of the 119 pitfalls of using any one alone. ICE is not a new protocol, and does 120 not require extensions from STUN, TURN or RSIP. However, it does 121 require some additional SDP attributes, which are discussed below. 123 2. Overview of ICE 125 ICE makes the fundamental assumption that clients exist in a network 126 of segmented connectivity. This segmentation is the result of a 127 number of addressing realms in which a client can simultaneously be 128 connected. We use "realms" here in the broadest sense. A realm is 129 defined purely by connectivity. Two clients are in the same realm if, 130 when they exchange the addresses each has in that realm, they are 131 able to send packets to each other. This includes IPv6 and IPv4 132 realms, which actually use different address spaces, in addition to 133 private networks connected to the public Internet through NAT. 135 The key assumption in ICE is that a client cannot know, apriori, 136 whether the peer it wishes to communicate with is connected to one or 137 all of the address realms it is in. Therefore, in order to 138 communicate, it has to try them all, and choose the best one that 139 works. 141 Before a UA makes a call, it obtains as many IP address and port 142 combinations in as many address realms as it can. These adresses all 143 represent potential points at which the UA will receive a specific 144 media stream. Any protocol that provides a client with an IP address 145 and port on which it can receive traffic can be used. These include 146 STUN, TURN, RSIP, and even a VPN. The client also uses any local 147 interface addresses. A dual-stack v4/v6 client will obtain both a v6 148 and a v4 address/port. The only requirement is that, across all of 149 these addresses, the client can be certain that at least one of them 150 will work for any peer. This is easily guaranteed by using TURN, 151 RSIP, MIDCOM or a VPN from a server on the public Internet to obtain 152 one of the addresses. 154 The UAC then makes a STUN server available on each of the address/ 155 port combinations it has obtained. This STUN server is running 156 locally, on the UA. 158 All of these addresses are placed into the SDP offer [5] sent by the 159 UAC. Each of them is represented by a separate SDP attribute, called 160 "alt". They are ordered in terms of preference. Local IPv6 addresses 161 always have the highest preference, followed by local IPv4 addresses, 162 followed by STUN-allocated addresses, followed last by addresses 163 allocated through protocols using relays, such as TURN and VPN. The 164 alt attribute is also used to convey the STUN username and password 165 which are required to gain access to the STUN server on each address/ 166 port combination. 168 This offer is sent to the called party. ICE also assumes that SIP 169 itself can provide global connectivity across address realms. Indeed, 170 the point of the SIP URI is to act as a globally useful identifier 171 for reaching a user wherever they are. 173 Once the offer arrives at the UAS, it sends STUN requests to each 174 alternate address/port in the SDP offer, similar to the intra-realm 175 STUN mechanism [21] proposed previously. These STUN requests include 176 the username and password obtained from the SDP. None of the flags 177 are used. The STUN requests serve two purposes. The first is to check 178 for connectivity. If a response is received, the UAS knows that it 179 can reach the UAC at that address. The second purpose is to obtain 180 more addresses at which the UAS can be contacted. If there were NATs 181 between the UAS and UAC, the UAS may discover another address through 182 the STUN responses. In its answer, the UAS includes all addresses 183 that it can unilaterally determine (just as the UAC did), in addition 184 to any that were discovered using the STUN messages to the UAC. 186 When the answer arrives at the UAC, it performs a similar operation. 187 Using STUN, it checks connectivity to each of the addresses in the 188 answer. Through the STUN responses, it may learn of additional 189 addresses that it can use to receive media. It can therefore generate 190 a re-INVITE or UPDATE [6] request to pass this address to the callee. 191 Generally, at the end of the first exchange, both sides will have 192 discovered one of more addresses which they are capable of 193 successfully sending to. Each side uses the most preferred address 194 amongst the ones which worked. 196 3. Terminology 198 Several new terms are introduced in this specification: 200 Transport Address: The combination of an IP address and port. 202 Local Transport Address: A local transport address is transport 203 address that has been allocated from the operating system on the 204 host. This includes transport addresses obtained through VPNs, and 205 also transport addresses obtained through RSIP (which lives at the 206 operating system level). Transport addresses are typically 207 obtained by binding to an interface. 209 Derived Transport Address: A derived transport address is a 210 transport address which is associated with, but different from, a 211 local transport address. The derived transport address is 212 associated with the local transport address in that packets sent 213 to the derived transport address are received on the socket bound 214 to that local transport address. Derived addresses are obtained 215 using protocols like STUN and TURN, and more generally, any UNSAF 216 protocol [8]. 218 Peer Derived Transport Address: A peer derived transport address 219 is a derived transport address learned from a STUN server 220 advertised by a peer in a media session. 222 TURN Derived Transport Address: A derived transport address 223 obtained from a TURN server. 225 STUN Derived Transport Address: A derived transport address 226 obtained from a STUN server that has been provisioned into the UA. 227 This, by definition, excludes Peer Derived Transport Addresses. 229 Unilateral Allocations: Queries made to a network server which 230 provides an UNSAF service. 232 4. Core ICE Algorithm 234 At its core, the ICE algorithm is an iterative process in which two 235 cooperating entities, A and B, exchange addresses with each other in 236 an attempt to connect. One side (say A) starts, collecting all of the 237 addresses it can find. It sends those to B. B also collects all of 238 the addresses it can find, including those obtained by sending 239 address-fixing requests (such as STUN requests) to A itself. Those 240 are passed to A. B also checks connectivity to the addresses provided 241 by A. When A gets the set of addresses, it performs connectivity 242 checks, and attempts to obtain further addresses based on the 243 information sent by B. If A learns more addresses, it sends these to 244 B, which checks connectivity to those addresses. This process 245 iterates back and forth until both sides have obtain all the 246 addresses which can be obtained. At least one address passed in each 247 direction should work. 249 5. Detailed ICE Algorithm 251 This section describes the detailed processing needed for ICE. 253 5.1 Gathering Transport Addresses 255 The offerer begins the process by gathering transport addresses. 256 There are two types of addresses it can gather - local transport 257 addresses, and derived transport addresses. Local transport addresses 258 are obtained by binding to an ephemeral port on an interface 259 (physical or virtual) on the host. A multi-homed host SHOULD attempt 260 to bind on all interfaces for all media streams it wishes to receive. 261 For media streams carried using the Real Time Transport Protocol 262 (RTP) [10], the offerer will need to bind to an ephemeral port for 263 both RTP and RTCP. 265 The result will be a set of local transport addresses. The offerer 266 may also have access to servers that provide unilateral self-address 267 fixing (UNSAF) [8]. Examples of such protocols include STUN, TURN, 268 and TEREDO [22]. For each of these protocols, the offerer may have 269 access to a multiplicity of servers. For example, a user connected to 270 a natted cable access network might have access to a STUN server in 271 the private cable network and in the public Internet. For each local 272 transport address, the offerer SHOULD address-fix against every 273 server for each protocol it supports. The result of this will be a 274 set of derived transport addresses, with each derived address 275 associated with the local transport address it is derived from. 277 ICE works better the more options exist for connectivity. However, in 278 order to communicate with the peer, at least one of the offered 279 addresses has to be guaranteed to work with any peer that might be 280 called. This generally requires that one of the derived addresses be 281 obtained from a relay service (such as TURN or TEREDO) that exist 282 within the public Internet. 284 5.2 Enabling STUN on Each Transport Address 286 Once the offerer has obtained a set of transport addresses, it starts 287 a STUN server on each local transport address (including ones used 288 for RTCP). This, by definition, means that the STUN service will be 289 reached for requests sent to the derived addresses. 291 However, the client does not need to provide STUN service on any 292 other IP address or port, unlike the normal STUN usage as described 293 in [13]. The need to run the service on multiple ports is to support 294 the change flags. However, those flags are not needed with ICE, and 295 the server SHOULD reject any requests with these flags set. 297 Furthermore, there is no need to support TLS or to be prepared to 298 receive SharedSecret request messages. Those messages are used to 299 obtain shared secrets to be used with BindingRequests. However, with 300 ICE, usernames and passwords are exchanged in SIP itself. 302 It is important to note that the transport address being used by the 303 STUN server will also need to support the media stream which is to be 304 sent to that transport address. This will require the offerer to 305 disambiguate STUN messages from messages for the underlying media 306 stream protocol. In the case of RTP/RTCP, this disambiguation is 307 easy. RTP and RTCP packets start with the bits 0b10 (v=2). The first 308 two bits in STUN are always 0b00. Disambiguating STUN with other 309 media stream protocols may be more complicated. However, it is 310 guaranteed to always be possible by selecting an appropriately random 311 username (see below). 313 The need to run STUN on the same transport address as the media 314 stream represents the "ugliest" piece of ICE. However, it is an 315 essential part of the story. By sending STUN requests to the very 316 same place media is sent, any bindings learned through STUN will be 317 useful even when communicating through symmetric NATs. This results 318 in a substantial increase in the scope of applicability of STUN, in 319 terms of cases where it can provide connectivity. In that sense, the 320 usage of STUN here is radically different than the usage models 321 outlined in [13], where STUN is generally useless for dealing with 322 symmetric NAT. 324 For each local transport address where a STUN server is running, the 325 client MUST choose a username and password. The username MUST be 326 globally unique, so that no other host will select a username with 327 the same value. This username and password will be passed to the 328 answerer in the SDP. They are used by the answerer to authenticate 329 the STUN requests to the server. 331 The global uniqueness requirement stems from the lack of uniquenes 332 afforded by IP addresses. Consider user agents A, B, and C. A and B 333 are within private enterprise 1, which is using 10.0.0.0/8. C is 334 within private enterprise 2, which is also using 10.0.0.0/8. As it 335 turns out, B and C both have IP address 10.0.1.1. A makes a call to 336 C. C, in its answer, provides A with its transport addresses. In this 337 case, thats 10.0.1.1:8866 and 8877. As it turns out, B is on a call 338 at that same time, and is also using 10.0.1.1:8866 and 8877. This 339 means that B has a STUN server running on those ports, just as C 340 does. A will send a STUN request to 10.0.1.1:8866 and 8877. However, 341 these do not go to C as expected. Instead, they go to B. If B just 342 replied to them, A would believe it has connectivity to C, when in 343 fact it has connectivity to a completely different user, B. To fix 344 this, the STUN username takes on the role of a unique identifier. C 345 provides A with a unique username. A uses this username in its STUN 346 query to 10.0.1.1:8866. This STUN query arrives at B. However, the 347 username is unknown to B, and so the request is rejected. A treats 348 the rejected STUN request as if there were no connectivity to C 349 (which is actually true). Therefore, the error is avoided. 351 Once the STUN server is started, it MUST run until the first media 352 packet arrives on that address. Once that occurs, the agent MAY 353 terminate the server. It is still possible that a late or lost STUN 354 message will show up, but these will generally fail any media stream 355 validity checks and be discarded (STUN packets always fail the RTP 356 validity checks). 358 While the server is running, it MUST act as a normal STUN server, but 359 MUST only accept STUN requests from clients that authenticate using 360 the username and password handed out for the dialog. 362 5.3 Prioritizing the Transport Addresses 364 With the STUN servers starting, the next step is to prioritize the 365 transport addresses. This priority reflects the desire that the UA 366 has to receive media on that address, and is assigned as a value from 367 0 to 1 (1 being most preferred). Although any prioritization is 368 possible, it is RECOMMENDED that the prioritization be based on the 369 number of intermediaries that will be traversed. The fewer 370 intermediaries, the higher the priority. Furthermore, it is 371 RECOMMENDED that, given an equal number of intermediaries, an IPv6 372 address receive higher priority than an IPv4 address. As a result of 373 this, local IPv6 transport addresses obtained from physical 374 interfaces have highest priority. Next are local IPv4 transport 375 addresses obtained from physical interfaces. Next are STUN derived 376 transport addresses, followed by TURN, RSIP or TEREDO derived 377 transport addresses. Last up are local transport addresses obtained 378 from VPN interfaces. 380 5.4 Constructing the Offer 382 The next step is to construct the offer. For each media stream, the 383 client chooses the transport address which has the highest 384 probability of working with any arbitrary peer. Generally, this will 385 be a transport address learned from a relay service on the public 386 Internet, such as TURN. Frequently this is also the lowest priority 387 transport address. This transport address is placed into the m and c 388 lines of the offer. This is the address that will be used by a peer 389 that doesn't understand ICE. Therefore, to maximize the ability to 390 complete a call, the address which is most likely to succeed is used. 391 In the case of RTP, the corresponding RTCP address would be placed 392 into the rtcp attribute [17] if its not on the port one higher than 393 the RTP. 395 OPEN ISSUE: There are cases where there is no clear "highest 396 probability" address. The example intra-enterprise call shows such 397 a case. The TURN relay returns two addresses, and the right one to 398 use as a default depends on who you are calling. This may be 399 unavoidable. 401 The client then encodes all of its available transport addresses 402 (including the one that was just placed into the m and c lines) as a 403 series of alt attributes (see Section 7. Each alt attribute conveys a 404 single transport address (or, in the case of RTP, two transport 405 addresses - one for RTP, and one for RTCP). Each will have a unique 406 identifier. The priority for the transport address, as computed 407 above, is included in the attribute as well. 409 The usage of the alt attribute implies that a STUN server is running 410 on the transport addresses associated with that attribute. In the 411 case of RTP, this means that STUN servers are running on both the RTP 412 and RCP ports, independently of whether the RTCP port is equal to the 413 RTP port plus one, or explicitly signaled using the second transport 414 address. The alt attribute also contains the username and password to 415 be used for sending STUN requests. 417 Once the offer is constructed, it is sent. 419 The previous version of this specification used the ALT grouping 420 semantic [20]. However, this revision uses a new alt attribute in 421 order to improve backwards compatibility between ICE and non-ICE 422 clients. These attributes are ignored by non-ICE clients, and the 423 result is that media is sent to a single address and port - the 424 one present in the m and c lines. By choosing those to be the 425 TURN-allocated address, we maximize the likelihood of successful 426 call completion even when communicating to a non-ICE client. 428 5.5 Answerer Processing - Connectivity Checks and Gathering 430 Once the answerer receives the offer, it does several things in 431 parallel. First, it performs the same processing described in Section 432 5.1. Specifically, for each media stream in the offer, , the answerer 433 allocates a set of local transport addresses and the full set of 434 derived transport addresses. 436 Note that these addresses can be "pre-gathered" before the call is 437 even received, so that a set is always "on-deck". This will avoid any 438 increase in call setup times, at the expense of holding onto 439 addresses which may not get used. Retaining these addresses may also 440 require refresh traffic that consumes network bandwidth. 442 While the unilateral derived addresses are being obtained, the 443 answerer sends a STUN BindingRequest from each local transport 444 address to each STUN server identified in an alt attribute in the 445 offer. This BindingRequest MUST contain the USERNAME attribute, and 446 the value of the USERNAME MUST equal the username from that alt 447 attribute. Similarly, the BindingRequest MUST contain a PASSWORD 448 attribute, and the value of the PASSWORD MUST equal the password from 449 the alt attribute. The BindingRequest MUST contain a 450 MESSAGE-INTEGRITY attribute, computed using the username and password 451 from the alt attribute in the offer. The BindingRequest MUST NOT 452 contain the CHANGE-REQUEST or RESPONSE-ADDRESS attribute. 454 It is RECOMMENDED that these STUN requests be sent in parallel. The 455 answerer MAY alert the user during this time. Generally, if the user 456 is a human (and not an automata), the STUN transactions will have 457 completed before the call is answered. 459 If the STUN BindingRequest elicits a BindingResponse before the STUN 460 transaction times out, the result is considered a success. For 461 successful transactions, the answerer stores the offered transport 462 address (which identifies both the STUN server and the place where 463 media is sent), the local transport address from which the STUN 464 request was sent, the id of that alternative from the offer, and the 465 qvalue from that alternative. If the STUN transaction succeeds, the 466 client knows for certain that the media can reach the destination as 467 well. That is because the media traffic will be sent from the same 468 transport address, to the same trasport address, as the STUN packet 469 was. 471 When a client receives an offer, it MAY begin sending media 472 immediately to the address and port in the m and c-lines. If that 473 address and port was also encoded in an alt attribute, the client 474 MUST send media from the same address and port used to send a STUN 475 request to the peer. As the STUN transactions begin to complete, the 476 client begins to learn about alternative addresses which have 477 connectivity. If one of those alternatives has a higher priority than 478 the one currently in use, that transport address MUST be used instead 479 (along with its corresponding local address). Note that, between two 480 transport addresses with the same q-value, a STUN derived address 481 always has higher priority. Furthermore, once an agent sends media to 482 a transport address with a specified priority, it MUST NOT, during 483 the lifetime of the dialog, send media to a connected transport 484 address with a lower priority. 486 This restriction allows an agent to free derived transport addresses 487 once it knows that its peer has been able to connect to a transport 488 address with higher priority, or one of equal priority if it was peer 489 derived. An agent can know that a peer was able to connect to a 490 transport address based on the receipt of a STUN BindingRequest 491 against that transport address. The username and password in the STUN 492 BindingRequest can be used to determine which transport address the 493 STUN request was generated against. Note that the transport address 494 that the STUN request was received on does not say anything about 495 which transport address the peer sent to, and so the username and 496 password are used. Such an address SHOULD be freed no earlier than 3 497 seconds after receipt of the STUN request. This provides a window of 498 time for the peer to cease using the address and switch to a better 499 one. 501 This connectivity check makes an important assumption. It assumes 502 that if a STUN request is able to get from A to B, the STUN 503 response will get from B to A (packet losses aside). To our 504 knowledge this is generally true, since it is one of the 505 definining characteristics of the client-server protocols that 506 NATs have been designed to pass. We need to make this assumption 507 in order to free up resources and also eliminate additional ICE 508 cycles. 510 The drawback of this restriction is that if connectivity should be 511 lost during the dialog, the client cannot fall back to lower priority 512 address. We believe that it is more important to free unneeded 513 resources than to hold onto them in case of the unlikely event of a 514 problem. 516 For those successful STUN transactions, the answerer compares the 517 MAPPED-ADDRESS attribute in the response to the local transport 518 address from which the STUN request was sent. If the two differ, the 519 answerer considers the MAPPED-ADDRESS as another transport address 520 that has been gathered for usage in this dialog. This transport 521 address is referred to as a peer derived transport address. The 522 priority of this transport address is set to the value of the qvalue 523 of that alternative from the offer. For example, if the offerer 524 provides a transport address obtained from a local interface, it 525 would set the qvalue to 1.0. If the answerer sends a STUN request to 526 the server and obtains a new transport address, that transport 527 address is assigned a qvalue of 1.0. That qvalue will be used in 528 comparison to other addresses gathered by the answerer. 530 If any STUN BindingRequest results in a BindingErrorResponse, the 531 ERROR-CODE is examined. If it is 401, 430, 432 or 500, the client 532 SHOULD retry the request, applying any appropriate fixes specified by 533 the error code. In the case of 400, 431 and 600, the client MUST NOT 534 retry. This case is treated identically to a timeout, so that it is 535 equal to no connectivity at all. 537 5.6 Generating the Answer 539 At some point, the called party will decide to accept or reject the 540 call. A rejection terminates ICE processing, of course. In the case 541 of acceptance, the answer is constructed as follows. 543 At the time when the answer is to be sent, the answerer will have 544 gathered some number of transport addresses. Some of these will be 545 local transport addresses, some will be unilaterally derived 546 addresses, and some will be stun derived from the peer in the dialog. 547 Each of these will have a qvalue, based on either the rules in 548 Section 5.1 or Section 5.5. 550 Constructing the answer proceeds identically to the way in which the 551 offer is constructed (Section 5.4). The transport address with the 552 highest probability of success is placed into the m and c lines. 553 Furthermore, all of the alternatives are placed into an "alt" 554 attribute. Each is assigned a unique ID. Those addresses which were 555 peer-derived STUN addresses contain the "id" attribute identifying 556 the address they were derived from. Each alternative contains its 557 qvalue as computed above. Each alternative contains a username and 558 password that must be used to contact the STUN server listening on 559 that address. Each address SHOULD have a different username and 560 password. 562 The answer is then sent. 564 5.7 Offerer Processing of the Answer 566 The processing of the answer by the offerer is nearly identical to 567 that of the answerer processing the offer. Specifically, the offerer 568 will send STUN requests to the STUN servers listed in the answer. 569 This results in the same connectivity processing, and will also 570 result in the gathering of new STUN derived addresses. The offerer 571 can begin sending media to the answerer immediately (using the 572 address in the m and c lines). Once STUN has verified connectivity of 573 higher priority addresses, media is sent to those addresses instead. 575 5.8 Additional ICE Cycles 577 After the completion of the offer/answer exchange, both sides may 578 continue to obtain more derived transport addresses. This may occur 579 because a STUN transaction took too long to complete, and thus missed 580 the "window" of the previous offer/answer exchange. Or, it may occur 581 because the previous offer/answer exchange provided additional 582 addresses which resulted in new STUN derived attributes. 584 At any point when either agent has one or more new gathered 585 addresses, it MAY initiate a new offer/answer exchange, and a new 586 corresponding ICE cycle. It would add alt attributes to the existing 587 set containing those new gathered addresses. However, if the qvalue 588 of those new gathered addresses is lower than the qvalue for an 589 address that the peer has established connectivity to, the agent 590 SHOULD NOT initiate a new offer/answer exchange just to convey this 591 address. If an offer/answer exchange is taking place anyway (because 592 a higher priority address is available), the lower qvalue addresses 593 SHOULD be included. An agent can determine which addresses a peer has 594 established connectivity to by checking if a STUN request was sent by 595 the peer to that address. 597 Typically, there won't be more than a small number (2-3) ICE cycles 598 before convergence. Assuming that there is no network packet loss 599 (which can extend the STUN transaction) and zero network latency, it 600 appears that a maximum of two ICE cycles are needed to reach 601 convergence. 603 6. Running STUN on Derived Transport Addresses 605 One of the seemingly bizarre operations done during the ICE 606 processing is the transmission of a STUN request to a transport 607 address which is obtained through TURN or STUN itself. This actually 608 does work, and in fact, has extremely useful properties. The 609 subsections below go through the detailed operations that would occur 610 at each point to demonstrate correctness and the properties derived 611 from it. 613 6.1 STUN on a TURN Derived Transport Address 615 Consider a client A that is behind a NAT. It connects to a TURN 616 server on the public side of the NAT. To do that, A binds to a local 617 transport address, say 10.0.1.1:8866, and then sends a TURN request 618 to the TURN server. The NAT translates the net-10 address to 619 192.0.2.88:5063. Assume that the TURN server is running on 192.0.2.1 620 and listening for TURN traffic on port 7764. The TURN server 621 allocates a derived transport address 192.0.2.1:26524 to the client, 622 and returns it in the TURN response. Remember that all traffic from 623 the TURN server to the client is sent from 192.0.2.1:7764 to 624 10.0.1.1:8866. 626 Now, the client runs a STUN server on 10.0.1.1:8866, and advertises 627 that its server actually runs on 192.0.2.1:26524. Another client, B, 628 sends a STUN request to this server. It sends it from a local 629 transport address, 192.0.2.77:1296. When it arrives at 630 192.0.2.1:26524, the TURN server "locks down" outgoing traffic, so 631 that data packets received from A are sent to 192.0.2.77:1296. The 632 STUN request is then forwarded to the client, sent with a source 633 address of 192.0.2.1:7764 and a destination address of 634 192.0.2.88:5063. This passes through the NAT, which rewrites the 635 source address to 10.0.1.1:8866. This arrives at A's STUN server. The 636 server observes the source address of 192.0.2.1:7764, and generates a 637 STUN response containing this value in the MAPPED-ADDRESS attribute. 638 The STUN response is sent with a source address fo 10.0.1.1:8866, and 639 a destination of 192.0.2.1:7764. This arrives at the TURN server, 640 which, because of the lock-down, sends the STUN response with a 641 source address of 192.0.2.1:26524 and destination of 192.0.2.77:1296, 642 which is B's STUN client. 644 Now, as far as B is concerned, it has obtained a new STUN derived 645 transport address of 192.0.2.1:7764. And indeed, it has! STUN derived 646 transport addresses are scoped to the dialog, so they can only be 647 used by the peer in the dialog. Furthermore, that peer has to send 648 requests from the socket on which the STUN server was running. In 649 this case, A is the peer, and its STUN server was on 10.0.1.1:8866. 650 If it sends to 192.0.2.1:7764, the packet goes to the TURN server, 651 and due to lock-down, is forwarded to B, and specifically, is 652 forwarded to the transport address B sent the STUN request from. 653 Therefore, the address is indeed a valid STUN derived transport 654 address. 656 The benefit of this is that it allows two clients to share the same 657 TURN server for media traffic in both directions. With "normal" TURN 658 usage, both clients would obtain a derived address from their own 659 TURN servers. The result is that, for a single call, there are two 660 bindings allocated by each side from their respective servers, and 661 all four are used. With ICE, that drops to two bindings allocated 662 from a single server. Of course, all four bindings are allocated 663 initially. However, once one of the clients begins receiving media on 664 its STUN derived address, it can deallocate its TURN resources. 666 [[TODO: Include a diagram that shows this pictorially.]] 668 6.2 STUN on a STUN Derived Transport Address 670 Consider a client A that is behind a NAT. It connects to a STUN 671 server on the public side of the NAT. To do that, A binds to a local 672 transport address, say 10.0.1.1:8866, and then sends a STUN request 673 to the STUN server. The NAT translates the net-10 address to 674 192.0.2.88:5063. Assume that the STUN server is running on 192.0.2.1 675 and listening for STUN traffic on port 3478, the default STUN port. 676 The STUN server sees a source IP address of 192.0.2.88:5063, and 677 returns that to the client in the STUN response. The NAT forwards the 678 response to the client. 680 Now, the client runs a STUN server on 10.0.1.1:8866, and advertises 681 that its server actually runs on 192.0.2.88:5063. Another client, B, 682 sends a STUN request to this address. It sends it from a local 683 transport address, 192.0.2.77:1296. When it arrives at 684 192.0.2.88:5063 (on the NAT), the NAT rewrites the source address to 685 10.0.1.1:8866, assuming that it is of the full-cone variety [13], or 686 is restricted, and the permission for 192.0.2.77:1296 is open. This 687 arrives at A's STUN server. The server observes the source address of 688 192.0.2.77:1296, and generates a STUN response containing this value 689 in the MAPPED-ADDRESS attribute. The STUN response is sent with a 690 source address of 10.0.1.1:8866, and a destination of 691 192.0.2.77:1296. This arrives at B's STUN client. 693 Now, as far as B is concerned, it has obtained a new STUN derived 694 transport address of 192.0.2.77:1296. Of course, this is the same 695 address as the local transport address, and therefore this derived 696 address is not used. However, had there been additonal NATs between B 697 and A's NAT, B would end up seeing the binding allocated by that 698 outermost NAT. The net result is that STUN requests sent to a STUN 699 derived address behave as normal STUN would. However, these STUN 700 requests have the side-effect of creating permissions in the NATs 701 which see those requests in the public to private direction. This 702 turns out to be very useful for traversing restricted NATs. 704 7. SDP Extensions for STUN 706 A new SDP attribute is defined to support ICE. It is called "alt". 707 The alt attribute MUST be present within a media block of the SDP. It 708 contains an alternative IP address and port (or pair of IP addresses 709 and ports in the case of RTP) that the recipient of the SDP can use 710 instead of the ones indicated in the m and c lines. There MAY be 711 multiple alt attributes in a media block. In that case, each of them 712 MUST contain a different IP address and port (or a differing pair of 713 IP address and ports in the case of RTP). 715 An agent including an alt attribute in an SDP MUST be prepared to 716 receive STUN requests on the advertised address and port. In the case 717 of RTP, this includes both the RTP and RTCP transport addresses. The 718 username and password that are expected in such STUN requests are 719 advertised using the username and password conveyed in the attribute. 720 It is RECOMMENDED that the agent use different usernames and 721 passwords in each alternate. This allows the agent to know which 722 alternates the peer has been able to establish connectivity to. This 723 knowledge can be used as an optimization to eliminate additional ICE 724 cycles. 726 The transport addresses in the alt attribute MAY repeat those present 727 in the m and c-lines. In that case, the alt attribute is conveying 728 additional information about the transport addresses in the m and c 729 lines. In particular, it is conveying an identifier for them, an 730 indication of whether the address was peer derived, and a weight 731 indicating a preference for the address. It also implies that the 732 agent is prepared to receive STUN requests on the IP address and port 733 in the m and c lines. 735 In fact, it is RECOMMENDED that there be an alt attribute for the 736 address and port in the m and c lines. 738 The syntax of this attribute is: 740 alt-attribute = "alt" ":" id SP qvalue SP derived-from SP 741 username SP password SP 742 unicast-address SP port [unicast-address SP port] 743 ;qvalue from RFC 3261 744 ;unicast-address, port from RFC 2327 745 usernam = non-ws-string 746 passwor = non-ws-string 747 id = token 748 derived-from = ":" / id 750 "id" is a unique identifier (unique within the set of alt-attributes 751 present in offers and answers sent by that agent within the scope of 752 a dialog) that identifies this particular alternative address. 753 "qvalue" is a priority value that indicates the relative preference 754 of this address amongst any others conveyed in alt-attributes in this 755 media stream. The "derived-from" attribute either contains a colon or 756 an id. When it contains a colon, it means that the address is not a 757 peer derived transport address. When it contains an id, it means that 758 the address is a peer derived transport address. The id mirrors the 759 value of i" that identifies the alt-attribute from the peer from 760 which the address was derived. As an example, consider users A and B. 761 User A sends an SDP offer to B, as part of an offer/answer exchange 762 [5]. A indicates, using the alt attribute, that an alternative 763 address exists with "id" 23. B sends a STUN request to this server, 764 and obtains a MAPPED-ADDRESS in the STUN response. This transport 765 address is used in the answer. The m-line containing this address 766 would contain the alt attribute with a "derived-from" of 23. 768 When a user sends media to a transport address that has 769 "derived-from" containing an id, it MUST do so by sending from the 770 transport address indicated by the id. Continuing the example above, 771 if the transport address provided by A in id 23 was 192.0.2.3:3344, 772 when A sends media to a STUN derived transport address derived from 773 id 23, it MUST send the media from 192.0.2.3:3344. The need for this 774 requirement is described in Section 6. 776 The "username" and "password" are the username and password that the 777 recipient of the SDP MUST use when connecting to the agent to test 778 connectivity to that alternate. The username and password are scoped 779 to the lifetime of the dialog on which the SDP is being exchanged. If 780 the dialog terminates, the username and password are invalid. 782 Note that STUN allows both the username and password to contain the 783 space character. However, usernames and passwords used with ICE 784 cannot contain the space. 786 The security considerations associated with carrying a username and 787 password in the clear in SIP are not as bad as one might think. If an 788 eavesdropper should see the username and password, the worst they can 789 do is send STUN requests to the host. Since STUN is a stateless 790 protocol, the attacker can not alter the processing of the call or 791 otherwise disrupt it. They could flood the server with BindingRequest 792 packets. However, this would be no worse than if the attacker simply 793 floods the host with any kind of packet. 795 However, integrity protection of the username and password are more 796 important. If an attacker is capable of intercepting the message and 797 modifying the username or password, they could prevent connectivity 798 from being established between peers, and therefore disrupt the call. 800 Of course, if the attacker can intercept the SIP message, there are 801 many other ways in which they could do that, such as simply 802 discarding the message. Injecting fake SDP with incorect usernames 803 and passwords can also disrupt a call, and does not require the 804 compromise of an intermediate server. A similar attack is possible by 805 modifying most of the SDP attributes. To prevent these kinds of 806 attacks, it is RECOMMENDED that sips be used. 808 When used with a non-RTP stream, the second address and port MUST NOT 809 be present. In the case of RTP, it MAY be present, in which case it 810 indicates the IP address and port where RTCP is to be sent. When its 811 not present for an RTP stream, it implies that the RTCP packets are 812 sent to the port one higher than the RTP packets. 814 8. Connectivity Preconditions 816 One of the benefits of ICE is that each side knows with certainty 817 when it is able to communicate with its peer. However, neither side 818 knows for certainty when both sides can communicate with each other. 819 That information represents distributed state spread between both 820 peers. It would be extremely useful to know this piece of 821 information, so that a device can hold off on alerting a user until 822 connectivity has been confirmed. This is exactly the kind of function 823 that SIP preconditions [7] has been designed to provide. 825 This specification therefore defines the "connected" precondition 826 type. A media stream is considered connected from A to B when 827 connectivity from A to B has been confirmed with STUN for at least 828 one of the alternate transport addresses contained in an "alt" 829 attribute. 831 A B 832 |(1) INVITE SDP1 | 833 |----------------------->| 834 |(2) 183 SDP2 | 835 |<-----------------------| 836 |(3) PRACK | 837 |----------------------->| 838 |(4) 200 PRACK | 839 |<-----------------------| 840 |(5) STUN connectivity | 841 |........................| 842 |(6) UPDATE SDP3 | 843 |----------------------->| 844 |(7) 200 UPDATE SDP4 | 845 |<-----------------------| 846 |(8) 180 Ringing | 847 |<-----------------------| 848 |(9) PRACK | 849 |----------------------->| 850 |(10) 200 PRACK | 851 |<-----------------------| 852 |(11) 200 INVITE | 853 |<-----------------------| 854 |(12) ACK | 855 |----------------------->| 857 Figure 2 859 Figure 2 shows a typical call flow used in conjunction with 860 preconditions. User A does not want the phone to ring unless 861 connectivity is guaranteed. As a result, it sends an INVITE with a 862 connectivity precondition (message 1) that is mandatory in the 863 sendrecv direction. When this arrives at B, B decides to accept the 864 precondition, and therefore generates an answer indicating that the 865 precondition is mandatory in the sendrecv direction. The current 866 status is none, since connectivity hasn't been established in either 867 direction yet. At that point, the ICE cycles begin (which may 868 themselves use UPDATE for the offer/answer exchanges). Assume that B 869 has established connectivity to A. When A establishes connectivity to 870 B, it sends an UPDATE (message 6) with a current status of sendrecv. 871 This meets the precondition. As a result, B's phone rings, causing a 872 180 to be sent (message 8). 874 9. Example Use Cases 876 This section contains a number of example use cases. They help to 877 demonstrate that the core ICE algorithm always results in the best 878 connectivity. In all cases, only RTP is shown and discussed, to 879 simplify the discussion. RTCP related operations (generally STUN 880 queries parallel to the RTP ones) are omitted. 882 The use cases were chosen to represent a superset of those cases 883 described in the current NAT scenarios document [18]. This is to 884 demonstrate that ICE allows for a single solution to be applied to 885 all of the cases described there, and furthermore, that the optimal 886 media flow occurs in all of those cases. 888 9.1 Residential Users 890 In this scenario, a user has a broadband connection to the Internet, 891 using a cable modem or DSL, for example. In order to provide 892 security, or to run multiple machines, the user has purchased an 893 off-the-shelf "DSL Router" as they are called. These devices, 894 manufactured by companies such as Linksys, Netgear, 2wire, and 895 Netopia, generally include a NAT, simple firewall, DHCP server and 896 client, and a built in ethernet switch of some sort. The firewall 897 generally allows all outgoing traffic, but disallows incoming traffic 898 unless specific port forwarding or a DMZ host has been configured. 899 The NAT treatment of UDP in these boxes varies. The most common types 900 appear to be full-cone and restricted cone. 902 The user in this scenario wishes to use a communications service from 903 a retail provider, such as net2phone or deltathree, for example. The 904 connection between the user and the provider is through the cable 905 modem or DSL, through the public Internet. The user may have multiple 906 PCs in their home accessing this service, but they are not related in 907 any way. This scenario also includes the case where its not a PC, but 908 a standalone SIP phone. In this case, the provider might be providing 909 some kind of second line VoIP service. This scenario is depicted in 910 Figure 3. 912 +--------+ +--------+ 913 |Provider| |TURN/ | 914 | Proxy | | STUN | 915 | | | Server | 916 +----+---+ +----+---+ 917 | | 918 | | 919 --+-------------+-- 920 /////// \\\\\\\ 922 /// \\\ 923 || || 924 | Internet | 925 | | 926 | | 927 || || 928 \\\ /// 929 \\\\\\\ /////// 930 ---------+--------- 931 | DSL, Cable 932 +--------+-------+ 933 | Home NAT | 934 +----------------+ 936 +--------+ +----------+ 937 | | | / \ | 938 | PC | /SIP \ 939 | | /Phone \ 940 | | / \ 941 +--------+ ------------ 943 Figure 3: Residence with Single NAT 945 In this case, the provider administers a SIP proxy and a TURN/STUN 946 server. This server is running STUN on the default port (3478) and 947 TURN on port 5556. 949 9.1.1 Full Cone NAT 951 A As NAT STUN+TURN Server 952 |(1) STUN Bind | | 953 |s=10.0.1.1:1010 | | 954 |d=192.0.2.10:3478 | | 955 |----------------------->| | 956 | |(2) STUN Bind | 957 | |s=192.0.2.1:9988 | 958 | |d=192.0.2.10:3478 | 959 | |----------------------->| 960 | |(3) STUN Resp | 961 | |s=192.0.2.10:3478 | 962 | |d=192.0.2.1:9988 | 963 | |M=192.0.2.1:9988 | 964 | |<-----------------------| 965 |(4) STUN Resp | | 966 |s=192.0.2.10:3478 | | 967 |d=10.0.1.1:1010 | | 968 |M=192.0.2.1:9988 | | 969 |<-----------------------| | 970 |(5) STUN Bind | | 971 |s=10.0.1.1:1011 | | 972 |d=192.0.2.10:3478 | | 973 |----------------------->| | 974 | |(6) STUN Bind | 975 | |s=192.0.2.1:9990 | 976 | |d=192.0.2.10:3478 | 977 | |----------------------->| 978 | |(7) STUN Resp | 979 | |s=192.0.2.10:3478 | 980 | |d=192.0.2.1:9990 | 981 | |M=192.0.2.1:9990 | 982 | |<-----------------------| 983 |(8) STUN Resp | | 984 |s=192.0.2.10:3478 | | 985 |d=10.0.1.1:1011 | | 986 |M=192.0.2.1:9990 | | 987 |<-----------------------| | 988 |(9) TURN Alloc | | 989 |s=10.0.1.1:1010 | | 990 |d=192.0.2.10:5556 | | 991 |----------------------->| | 992 | |(10) TURN Alloc | 993 | |s=192.0.2.1:9988 | 994 | |d=192.0.2.10:5556 | 995 | |----------------------->| 996 | |(11) TURN Resp | 997 | |s=192.0.2.10:5556 | 998 | |d=192.0.1.1:9988 | 999 | |M=192.0.2.10:8076 | 1000 | |<-----------------------| 1001 |(12) TURN Resp | | 1002 |s=192.0.2.10:5556 | | 1003 |d=10.0.1.1:1010 | | 1004 |M=192.0.2.10:8076 | | 1005 |<-----------------------| | 1006 |(13) TURN Alloc | | 1007 |s=10.0.1.1:1011 | | 1008 |d=192.0.2.10:5556 | | 1009 |----------------------->| | 1010 | |(14) TURN Alloc | 1011 | |s=192.0.2.1:9990 | 1012 | |d=192.0.2.10:5556 | 1013 | |----------------------->| 1014 | |(15) TURN Resp | 1015 | |s=192.0.2.10:5556 | 1016 | |d=192.0.1.1:9990 | 1017 | |M=192.0.2.10:8077 | 1018 | |<-----------------------| 1019 |(16) TURN Resp | | 1020 |s=192.0.2.10:5556 | | 1021 |d=10.0.1.1:1011 | | 1022 |M=192.0.2.10:8077 | | 1023 |<-----------------------| | 1025 Figure 4: Message sequence for A's Unilateral Allocations 1027 We first consider the case where two such residential users call each 1028 other, and both are using NATs of the full-cone variety. The caller 1029 follows the ICE algorithm. As such, it firsts allocates a pair of 1030 ports on its local interface for RTP and RTCP traffic (10.0.1.1:1010 1031 and 10.0.1.1:1011). As shown in Figure 4, the client issues a STUN 1032 request from the RTP port (message 1), which passes through the NAT 1033 on its way to the STUN server. In the figure, the "s=" indicates the 1034 source transport address of the message, and "d=" indicates the 1035 destination transport address. The NAT translates the 10.0.1.1:1010 1036 to 192.0.2.1:9988, and this request arrives at the STUN server 1037 (message 2). The STUN server copies the source address into the 1038 MAPPED-ADDRESS field in the STUN response (the M= line in message 3), 1039 and this passes through the NAT, back to the client. The client now 1040 has a STUN derived transport address of 192.2.0.1:9988. It follows a 1041 similar process for RTCP (messages 5-8). This STUN derived transport 1042 address, 192.0.2.1:9990 is not adjacent to the RTP port. 1044 Next, the client follows a similar process to obtain a TURN port for 1045 RTP (messages 9-12) and RTCP (messages 13-16). The TURN requests are 1046 also sent from the same local transport address. Note, however, that 1047 the TURN derived transport addresses for RTP (192.0.2.10:8076) and 1048 RTCP (192.0.2.10:8077) are on adjacent ports. This is because the 1049 TURN pre-allocation procedure was used in the TURN request for the 1050 RTP port (message 9). 1052 The client prioritizes these addresses, choosing the local interface 1053 address with priority 1.0, the STUN address with priority 0.8, and 1054 the TURN address with priority 0.4. From this, it generates an offer 1055 that looks like this: 1057 v=0 1058 o=alice 2890844730 2890844731 IN IP4 host.example.com 1059 s= 1060 c=IN IP4 192.0.2.10 1061 t=0 0 1062 m=audio 8076 RTP/AVP 0 1063 a=alt:1 1.0 : user 9kksj== 10.0.1.1 1010 1064 a=alt:2 0.8 : user1 9kksk== 192.0.2.1 9988 192.0.2.1 9990 1065 a=alt:3 0.4 : user2 9kksl== 192.0.2.10 8076 1067 Figure 5: A's Offer 1069 Note how the TURN derived transport address is used in the m and c 1070 lines, since this is the address with the highest probability of 1071 working with a non-ICE peer. That address is also included in the 1072 list of alteratives (with ID 3). Also note that because the STUN 1073 derived transport address for RTP and RTCP were not adjacent, two 1074 transport addresses are provided for alternate 2. 1076 B Bs NAT STUN+TURN Server 1077 |(1) STUN Bind | | 1078 |s=192.168.3.1:23766 | | 1079 |d=192.0.2.10:3478 | | 1080 |----------------------->| | 1081 | |(2) STUN Bind | 1082 | |s=192.0.2.2:10892 | 1083 | |d=192.0.2.10:3478 | 1084 | |----------------------->| 1085 | |(3) STUN Resp | 1086 | |s=192.0.2.10:3478 | 1087 | |d=192.0.2.2:10892 | 1088 | |M=192.0.2.2:10892 | 1089 | |<-----------------------| 1090 |(4) STUN Resp | | 1091 |s=192.0.2.10:3478 | | 1092 |d=192.168.3.1:23766 | | 1093 |M=192.0.2.2:10892 | | 1094 |<-----------------------| | 1095 |(5) STUN Bind | | 1096 |s=192.168.3.1:23767 | | 1097 |d=192.0.2.10:3478 | | 1098 |----------------------->| | 1099 | |(6) STUN Bind | 1100 | |s=192.0.2.2:10893 | 1101 | |d=192.0.2.10:3478 | 1102 | |----------------------->| 1103 | |(7) STUN Resp | 1104 | |s=192.0.2.10:3478 | 1105 | |d=192.0.2.2:10893 | 1106 | |M=192.0.2.2:10893 | 1107 | |<-----------------------| 1108 |(8) STUN Resp | | 1109 |s=192.0.2.10:3478 | | 1110 |d=192.168.3.1:23767 | | 1111 |M=192.0.2.2:10893 | | 1112 |<-----------------------| | 1113 |(9) TURN Alloc | | 1114 |s=192.168.3.1:23766 | | 1115 |d=192.0.2.10:5556 | | 1116 |----------------------->| | 1117 | |(10) TURN Alloc | 1118 | |s=192.0.2.2:10892 | 1119 | |d=192.0.2.10:5556 | 1120 | |----------------------->| 1121 | |(11) TURN Resp | 1122 | |s=192.0.2.10:5556 | 1123 | |d=192.0.2.2:10892 | 1124 | |M=192.0.2.10:8078 | 1125 | |<-----------------------| 1126 |(12) TURN Resp | | 1127 |s=192.0.2.10:5556 | | 1128 |d=192.168.3.1:23766 | | 1129 |M=192.0.2.10:8078 | | 1130 |<-----------------------| | 1131 |(13) TURN Alloc | | 1132 |s=192.168.3.1:23767 | | 1133 |d=192.0.2.10:5556 | | 1134 |----------------------->| | 1135 | |(14) TURN Alloc | 1136 | |s=192.0.2.2:10893 | 1137 | |d=192.0.2.10:5556 | 1138 | |----------------------->| 1139 | |(15) TURN Resp | 1140 | |s=192.0.2.10:5556 | 1141 | |d=192.0.2.2:10893 | 1142 | |M=192.0.2.10:8079 | 1143 | |<-----------------------| 1144 |(16) TURN Resp | | 1145 |s=192.0.2.10:5556 | | 1146 |d=192.168.3.1:23767 | | 1147 |M=192.0.2.10:8079 | | 1148 |<-----------------------| | 1150 Figure 6: Message sequence for B's Unilateral Allocations 1152 This offer arrives at the called party, user B. User B is also behind 1153 a full-cone NAT, and is using the 192.168/16 private address space 1154 internally. It happens to be using the same service provider as A, 1155 and is therefore using the same TURN server, at 192.0.2.10:5556. User 1156 B follows the same set of procedures followed by user A. It uses 1157 local interfaces, STUN, and TURN, and obtains a set of transport 1158 addresses that it can use. This process is shown in Figure 6. This 1159 process differs from that of Figure 4 only in the actual addresses 1160 and ports used and obtained. 1162 A As NAT TURN + STUN Server Bs NAT B 1163 | | | |(1) STUN Bind| 1164 | | | |s=192.168.3.1:23766 1165 | | | |d=10.0.1.1:1010 1166 | | | |<------------| 1167 | | |Unreachable | | 1168 | | | |(2) STUN Bind| 1169 | | | |s=192.168.3.1:23766 1170 | | | |d=192.0.2.1:9988 1171 | | | |<------------| 1172 | |(3) STUN Bind| | | 1173 | |s=192.0.2.2:10892 | | 1174 | |d=192.0.2.1:9988 | | 1175 | |<--------------------------| | 1176 |(4) STUN Bind| | | | 1177 |s=192.0.2.2:10892 | | | 1178 |d=10.0.1.1:1010 | | | 1179 |<------------| | | | 1180 |(5) STUN Reply | | | 1181 |s=10.0.1.1:1010 | | | 1182 |d=192.0.2.2:10892 | | | 1183 |M=192.0.2.2:10892 | | | 1184 |------------>| | | | 1185 | |(6) STUN Reply | | 1186 | |s=192.0.2.1:9988 | | 1187 | |d=192.0.2.2:10892 | | 1188 | |M=192.0.2.2:10892 | | 1189 | |-------------------------->| | 1190 | | | |(7) STUN Reply 1191 | | | |s=192.0.2.1:9988 1192 | | | |d=192.168.3.1:23766 1193 | | | |M=192.0.2.2:10892 1194 | | | |------------>| 1195 | | | |(8) STUN Bind| 1196 | | | |s=192.168.3.1:23766 1197 | | | |d=192.0.2.10:8076 1198 | | | |<------------| 1199 | | |(9) STUN Bind| | 1200 | | |s=192.0.2.2:10892 | 1201 | | |d=192.0.2.10:8076 | 1202 | | |<------------| | 1203 | |(10) STUN Bind | | 1204 | |s=192.0.2.10:5556 | | 1205 | |d=192.0.2.1:9988 | | 1206 | |<------------| | | 1207 |(11) STUN Bind | | | 1208 |s=192.0.2.10:5556 | | | 1209 |d=10.0.1.1:1010 | | | 1210 |<------------| | | | 1211 |(12) STUN Reply | | | 1212 |s=10.0.1.1:1010 | | | 1213 |d=192.0.2.10:5556 | | | 1214 |M=192.0.2.10:5556 | | | 1215 |------------>| | | | 1216 | |(13) STUN Reply | | 1217 | |s=192.0.2.1:9988 | | 1218 | |d=192.0.2.10:5556 | | 1219 | |M=192.0.2.10:5556 | | 1220 | |------------>| | | 1221 | | |(14) STUN Reply | 1222 | | |s=192.0.2.10:8076 | 1223 | | |d=192.0.2.2:10892 | 1224 | | |M=192.0.2.10:5556 | 1225 | | |------------>| | 1226 | | | |(15) STUN Reply 1227 | | | |s=192.0.2.10:8076 1228 | | | |d=192.168.3.1:23766 1229 | | | |M=192.0.2.10:5556 1230 | | | |------------>| 1232 Figure 7: B's Connectivity Checks 1234 While B's phone is ringing, B's user agent uses STUN to test 1235 connectivity from its local transport address pair (192.168.3.1:23766 1236 and 192.168.3.1:23767) to the three alternates listed in the offer. 1237 The flow for that is shown in Figure 7. This flow, and the 1238 discussions, only consider the RTP transport addresses. The 1239 procedures would all be identical for RTCP. First, B tests 1240 connectivity to the alternate with ID 1, which is 10.0.1.1:1010. It 1241 does so by attempting to send a STUN request to this address (message 1242 1). Of course, this is a private address, and not in the same network 1243 as B. Therefore, it is unreachable, and no STUN response is received. 1245 In parallel, B tests connectivity to the alternate with ID 2, which 1246 is 192.0.2.1:9988. To do this, it sends a STUN request to that 1247 address. It sends it with a source address equal to its local 1248 transport address; the same one that it used to send the previous 1249 TURN and STUN packets (192.168.3.1:23766). This request (message 2) 1250 arrives at the NAT. Since the NAT is full cone, and since this 1251 address has an existing binding, the NAT translates the source 1252 address to that existing binding, 192.0.2.2:10892. This request 1253 (message 3) continues onwards to A's NAT. Since A's NAT is also full 1254 cone, the existing binding for 192.0.2.1:9988 is used, and the 1255 destination address is translated to 10.0.1.1:1010 and then forwarded 1256 towards A (message 4). A receives this. It verifies the username and 1257 password, and then generates a response. The response contains a 1258 MAPPED-ADDRESS equal to the source address seen in the STUN request 1259 (192.0.2.2:10892). It passes back through A's NAT (message 5), 1260 through B's NAT (message 6), and back to B (message 7). 1262 B examines the MAPPED-ADDRESS in the STUN response. Its 1263 192.0.2.2:10892. However, this is not a new address. B is already 1264 aware of this address as a result of its initial STUN Binding 1265 requests to the TURN/STUN server (Figure 6). As such, no additional 1266 addresses were learned. 1268 In parallel with the tests against ID 2, B tests connectivity to the 1269 alternate with ID 3. This is the address A allocated through TURN. Of 1270 course, B does not know this. B sends a STUN request to this address 1271 (192.0.2.10:8076), and sends it from the same local transport address 1272 (192.168.3.1:23766) (message 8). The NAT, once again, translates the 1273 source address to 192.0.2.2:10892 (message 9). This is routed to the 1274 TURN server. The TURN server locks down the binding allocated to A, 1275 such that it will now begin relaying packets sent from A to 1276 192.0.2.2:10892. The TURN server forwards the packet towards A 1277 (message 10). This reaches A's NAT, which translates the destination 1278 address based on the existing binding. The STUN request is then 1279 delivered to A (message 11). A verifies the username and password, 1280 and then generates a STUN response. This response contains the source 1281 address that the request came from. In this case, that source address 1282 is the public transport address of the TURN server (192.0.2.10:5556). 1283 This STUN response is relayed all the way back to B (messages 12-15). 1285 B examines the MAPPED-ADDRESS in this STUN response. It's 1286 192.0.2.10:5556, which is a new address. As a result, B has now 1287 obtained a peer derived STUN address. It adds this to its list of 1288 transport addresses. Its priority equals that of the address it was 1289 derived from - ID 3 - which has a qvalue of 0.4. 1291 At some point, B picks up, and an answer is generated. The answer 1292 would look like this: 1294 v=0 1295 o=bob 2890844730 289084871 IN IP4 host2.example.com 1296 s= 1297 c=IN IP4 192.0.2.10 1298 t=0 0 1299 m=audio 8078 RTP/AVP 0 1300 a=alt:4 1.0 : peer as88jl 192.168.3.1 23766 1301 a=alt:5 0.8 : peer1 as88kl 192.0.2.2 10892 1302 a=alt:6 0.4 : peer2 as88ll 192.0.2.10 8078 1303 a=alt:7 0.4 3 peer3 as88ml 192.0.2.10 5556 1305 Figure 8: B's Answer 1307 Note how the alternative with ID 7 indicates that it was derived from 1308 the alternate with ID 3. Also, note that the four alternates use 1309 different IDs than the ones from the offer. This is for readability 1310 purposes only. The IDs are scoped to that specific agent, and there 1311 is no requirement that they do not use the same values. 1313 This answer is sent to A. At the same time, B can send audio to A 1314 using the highest priority alternate that connectivity was 1315 established to. That is the alternate with ID 2, A's STUN derived 1316 transport address. 1318 A As NAT TURN + STUN Server Bs NAT B 1319 |(1) STUN Bind| | | | 1320 |s=10.0.1.1:1010 | | | 1321 |d=192.168.3.1:23766 | | | 1322 |------------>| | | | 1323 | |Unreachable | | | 1324 |(2) STUN Bind| | | | 1325 |s=10.0.1.1:1010 | | | 1326 |d=192.0.2.2:10892 | | | 1327 |------------>| | | | 1328 | |(3) STUN Bind| | | 1329 | |s=192.0.2.1:9988 | | 1330 | |d=192.0.2.2:10892 | | 1331 | |-------------------------->| | 1332 | | | |(4) STUN Bind| 1333 | | | |s=192.0.2.1:9988 1334 | | | |d=192.168.3.1:23766 1335 | | | |------------>| 1336 | | | |(5) STUN Reply 1337 | | | |s=192.168.3.1:23766 1338 | | | |d=192.0.2.1:9988 1339 | | | |M=192.0.2.1:9988 1340 | | | |<------------| 1341 | |(6) STUN Reply | | 1342 | |s=192.0.2.2:10892 | | 1343 | |d=192.0.2.1:9988 | | 1344 | |M=192.0.2.1:9988 | | 1345 | |<--------------------------| | 1346 |(7) STUN Reply | | | 1347 |s=192.0.2.2:10892 | | | 1348 |d=10.0.1.1:1010 | | | 1349 |M=192.0.2.1:9988 | | | 1350 |<------------| | | | 1351 |(8) STUN Bind| | | | 1352 |s=10.0.1.1:1010 | | | 1353 |d=192.0.2.10:8078 | | | 1354 |------------>| | | | 1355 | |(9) STUN Bind| | | 1356 | |s=192.0.2.1:9988 | | 1357 | |d=192.0.2.10:8078 | | 1358 | |------------>| | | 1359 | | |(10) STUN Bind | 1360 | | |s=192.0.2.10:5556 | 1361 | | |d=192.0.2.2:10892 | 1362 | | |------------>| | 1363 | | | |(11) STUN Bind 1364 | | | |s=192.0.2.10:5556 1365 | | | |d=192.168.3.1:23766 1366 | | | |------------>| 1367 | | | |(12) STUN Reply 1368 | | | |s=192.168.3.1:23766 1369 | | | |d=192.0.2.10:5556 1370 | | | |M=192.0.2.10:5556 1371 | | | |<------------| 1372 | | |(13) STUN Reply | 1373 | | |s=192.0.2.2:10892 | 1374 | | |d=192.0.2.10:5556 | 1375 | | |M=192.0.2.10:5556 | 1376 | | |<------------| | 1377 | |(14) STUN Reply | | 1378 | |s=192.0.2.10:8078 | | 1379 | |d=192.0.2.1:9988 | | 1380 | |M=192.0.2.10:5556 | | 1381 | |<------------| | | 1382 |(15) STUN Reply | | | 1383 |s=192.0.2.10:8078 | | | 1384 |d=10.0.1.1:1010 | | | 1385 |M=192.0.2.10:5556 | | | 1386 |<------------| | | | 1387 |(16) STUN Bind | | | 1388 |s=10.0.1.1:1010 | | | 1389 |d=192.0.2.10:5556 | | | 1390 |------------>| | | | 1391 | |(17) STUN Bind | | 1392 | |s=192.0.2.1:9988 | | 1393 | |d=192.0.2.10:5556 | | 1394 | |------------>| | | 1395 | | |(18) STUN Bind | 1396 | | |s=192.0.2.10:8076 | 1397 | | |d=192.0.2.2:10892 | 1398 | | |------------>| | 1399 | | | |(19) STUN Bind 1400 | | | |s=192.0.2.10:8076 1401 | | | |d=192.168.3.1:23766 1402 | | | |------------>| 1403 | | | |(20) STUN Reply 1404 | | | |s=192.168.3.1:23766 1405 | | | |d=192.0.2.10:8076 1406 | | | |M=192.0.2.10:8076 1407 | | | |<------------| 1408 | | |(21) STUN Reply | 1409 | | |s=192.0.2.2:10892 | 1410 | | |d=192.0.2.10:8076 | 1411 | | |M=192.0.2.10:8076 | 1412 | | |<------------| | 1413 | |(22) STUN Reply | | 1414 | |s=192.0.2.10:5556 | | 1415 | |d=192.0.2.1:9988 | | 1416 | |M=192.0.2.10:8076 | | 1417 | |<------------| | | 1418 |(23) STUN Reply | | | 1419 |s=192.0.2.10:5556 | | | 1420 |d=10.0.1.1:1010 | | | 1421 |M=192.0.2.10:8076 | | | 1422 |<------------| | | | 1424 Figure 9: A's Connectivity Checks 1426 When the answer arrives at A, A performs similar connectivity checks, 1427 shown in Figure 9. Each connectivity check is a STUN request sent 1428 from its local transport address (10.0.1.1:1010). The first is to the 1429 alternate with ID 4, which is 192.168.3.1:23766. The STUN request to 1430 this address (message 1) fails, since this is an unreachable private 1431 address. The second check is to the alternate with ID 5 1432 (192.0.2.2:10892), which is the public address for B obtained as a 1433 result of STUN requests to the network server. Messages 2-7 represent 1434 the flow for this case. It is similar to the sequence in Figure 7 1435 messages 2-7, differing only in the IP addresses. The result of this 1436 check provides a peer derived transport address of 192.0.2.1:9988. A 1437 already knows this address. The third connectivity check is to the 1438 alternate with ID 6 (192.0.2.10:8078). This represents A's TURN 1439 derived transport address. Messages 8-15 represent the check for this 1440 address, and they are also similar to messages 8-15 of Figure 7. This 1441 check provides A with a peer derived transport address of 1442 192.0.2.10:5556. This represents a new address for A. It has a 1443 priority equal to the address it was derived from, which is 0.4. 1445 The final connectivity check is to the alternate with ID 7 1446 (192.0.2.10 5556). The SDP indicates that this address itself is a 1447 peer derived transport address. It was derived from A's transport 1448 address with ID 3, which is 192.0.2.10:8076, its TURN derived 1449 transport address. Because of that, the STUN request is sent from the 1450 local transport address that 192.0.2.10:8076 was derived from. This 1451 local address is 10.0.1.1:1010. The message sequence for this check 1452 is represented by messages 16-23 of Figure 9. The STUN request is 1453 sent with a source address of 10.0.1.1:1010, to 192.0.2.10:5556. This 1454 is the well-known address of the TURN relay. This message passes 1455 through the NAT, and the source address is translated to A's public 1456 address, 192.0.2.1:9988 (message 17). Note that this same public 1457 address is used for all requests sent from 10.0.1.1:1010 because the 1458 NAT is full-cone. This arrives at the TURN server. The TURN server 1459 associates this message (which is just an arbitrary UDP packet as far 1460 as the TURN server is concerned) with the binding created for A. The 1461 peer in this case has been locked down. So, the packet is forwarded 1462 with a source address equal to the binding allocated to A 1463 (192.0.2.10:8076) and a destination address equal to the locked-down 1464 address (192.0.2.2:10892) (message 18). This arrives at B's NAT, 1465 where the destination address is translated to B's private address, 1466 192.168.3.1:23766 (message 19). This arrives at B, which notes the 1467 source address in the STUN reply (192.0.2.10:8076). This reply is 1468 forwarded back to A (messages 20-23). From this, A sees a peer 1469 derived transport address of 192.0.2.10:8076. However, it already 1470 knows this address. 1472 The result of the connectivity checks is that A determines it has 1473 connectivity to the alternates with IDs 5, 6 and 7. Of these, the one 1474 with ID 5 has the highest priority, and so this one is used to send 1475 media. Of course, A could have been sending media to B during these 1476 tests using the address in the m and c lines, which represents B's 1477 TURN derived transport address. Once the connectivity checks 1478 complete, A can switch to the one with ID 5, which is B's STUN 1479 derived transport address. 1481 The connectivity checks also provided A with a new peer derived 1482 transport address - 192.0.2.10:5556 - with a priority of 0.4. 1483 However, A had received STUN requests on its alternates with IDs 2 1484 and 3. The one with ID 2 (its STUN derived transport address) has 1485 higher priority than 0.4. So, A knows that generating a new ICE cycle 1486 to convey this address would not be useful. Thus, no new offer is 1487 sent. Indeed, since A had received a STUN request from B on its STUN 1488 derived transport address, A knows that its lower priority derived 1489 transport address is no longer needed. So, it is able to free up the 1490 TURN derived transport address a few seconds later. The same goes for 1491 B. Once it receives the STUN request to its TURN derived transport 1492 address (message 11 of Figure 9, it can free its TURN derived 1493 transport address. 1495 In conclusion, the result in this case is that A and B will 1496 communicate with each other using their STUN derived transport 1497 addresses. 1499 9.1.2 Symmetric NAT 1501 A As NAT STUN+TURN Server 1502 |(1) STUN Bind | | 1503 |s=10.0.1.1:1010 | | 1504 |d=192.0.2.10:3478 | | 1505 |----------------------->| | 1506 | |(2) STUN Bind | 1507 | |s=192.0.2.1:9988 | 1508 | |d=192.0.2.10:3478 | 1509 | |----------------------->| 1510 | |(3) STUN Resp | 1511 | |s=192.0.2.10:3478 | 1512 | |d=192.0.2.1:9988 | 1513 | |M=192.0.2.1:9988 | 1514 | |<-----------------------| 1515 |(4) STUN Resp | | 1516 |s=192.0.2.10:3478 | | 1517 |d=10.0.1.1:1010 | | 1518 |M=192.0.2.1:9988 | | 1519 |<-----------------------| | 1520 |(5) STUN Bind | | 1521 |s=10.0.1.1:1011 | | 1522 |d=192.0.2.10:3478 | | 1523 |----------------------->| | 1524 | |(6) STUN Bind | 1525 | |s=192.0.2.1:9990 | 1526 | |d=192.0.2.10:3478 | 1527 | |----------------------->| 1528 | |(7) STUN Resp | 1529 | |s=192.0.2.10:3478 | 1530 | |d=192.0.2.1:9990 | 1531 | |M=192.0.2.1:9990 | 1532 | |<-----------------------| 1533 |(8) STUN Resp | | 1534 |s=192.0.2.10:3478 | | 1535 |d=10.0.1.1:1011 | | 1536 |M=192.0.2.1:9990 | | 1537 |<-----------------------| | 1538 |(9) TURN Alloc | | 1539 |s=10.0.1.1:1010 | | 1540 |d=192.0.2.10:5556 | | 1541 |----------------------->| | 1542 | |(10) TURN Alloc | 1543 | |s=192.0.2.1:9991 | 1544 | |d=192.0.2.10:5556 | 1545 | |----------------------->| 1546 | |(11) TURN Resp | 1547 | |s=192.0.2.10:5556 | 1548 | |d=192.0.1.1:9991 | 1549 | |M=192.0.2.10:8076 | 1550 | |<-----------------------| 1551 |(12) TURN Resp | | 1552 |s=192.0.2.10:5556 | | 1553 |d=10.0.1.1:1010 | | 1554 |M=192.0.2.10:8076 | | 1555 |<-----------------------| | 1556 |(13) TURN Alloc | | 1557 |s=10.0.1.1:1011 | | 1558 |d=192.0.2.10:5556 | | 1559 |----------------------->| | 1560 | |(14) TURN Alloc | 1561 | |s=192.0.2.1:9992 | 1562 | |d=192.0.2.10:5556 | 1563 | |----------------------->| 1564 | |(15) TURN Resp | 1565 | |s=192.0.2.10:5556 | 1566 | |d=192.0.1.1:9992 | 1567 | |M=192.0.2.10:8077 | 1568 | |<-----------------------| 1569 |(16) TURN Resp | | 1570 |s=192.0.2.10:5556 | | 1571 |d=10.0.1.1:1011 | | 1572 |M=192.0.2.10:8077 | | 1573 |<-----------------------| | 1575 Figure 10: A's Unilateral Allocations 1577 In this case, both residential users have symmetric NATs. The call 1578 starts again with A performing its unilateral allocations, as is 1579 shown in Figure 10. This message sequence is nearly identical to that 1580 of Figure 4. The only difference is that, because the NAT is 1581 symmetric, different bindings are allocated for the two STUN and two 1582 TURN queries. A's discovers an identical set of addresses, however, 1583 and so generates the same offer as in Figure 5. 1585 B Bs NAT STUN+TURN Server 1586 |(1) STUN Bind | | 1587 |s=192.168.3.1:23766 | | 1588 |d=192.0.2.10:3478 | | 1589 |----------------------->| | 1590 | |(2) STUN Bind | 1591 | |s=192.0.2.2:10892 | 1592 | |d=192.0.2.10:3478 | 1593 | |----------------------->| 1594 | |(3) STUN Resp | 1595 | |s=192.0.2.10:3478 | 1596 | |d=192.0.2.2:10892 | 1597 | |M=192.0.2.2:10892 | 1598 | |<-----------------------| 1599 |(4) STUN Resp | | 1600 |s=192.0.2.10:3478 | | 1601 |d=192.168.3.1:23766 | | 1602 |M=192.0.2.2:10892 | | 1603 |<-----------------------| | 1604 |(5) STUN Bind | | 1605 |s=192.168.3.1:23767 | | 1606 |d=192.0.2.10:3478 | | 1607 |----------------------->| | 1608 | |(6) STUN Bind | 1609 | |s=192.0.2.2:10893 | 1610 | |d=192.0.2.10:3478 | 1611 | |----------------------->| 1612 | |(7) STUN Resp | 1613 | |s=192.0.2.10:3478 | 1614 | |d=192.0.2.2:10893 | 1615 | |M=192.0.2.2:10893 | 1616 | |<-----------------------| 1617 |(8) STUN Resp | | 1618 |s=192.0.2.10:3478 | | 1619 |d=192.168.3.1:23767 | | 1620 |M=192.0.2.2:10893 | | 1621 |<-----------------------| | 1622 |(9) TURN Alloc | | 1623 |s=192.168.3.1:23766 | | 1624 |d=192.0.2.10:5556 | | 1625 |----------------------->| | 1626 | |(10) TURN Alloc | 1627 | |s=192.0.2.2:10894 | 1628 | |d=192.0.2.10:5556 | 1629 | |----------------------->| 1630 | |(11) TURN Resp | 1631 | |s=192.0.2.10:5556 | 1632 | |d=192.0.2.2:10894 | 1633 | |M=192.0.2.10:8078 | 1634 | |<-----------------------| 1635 |(12) TURN Resp | | 1636 |s=192.0.2.10:5556 | | 1637 |d=192.168.3.1:23766 | | 1638 |M=192.0.2.10:8078 | | 1639 |<-----------------------| | 1640 |(13) TURN Alloc | | 1641 |s=192.168.3.1:23767 | | 1642 |d=192.0.2.10:5556 | | 1643 |----------------------->| | 1644 | |(14) TURN Alloc | 1645 | |s=192.0.2.2:10895 | 1646 | |d=192.0.2.10:5556 | 1647 | |----------------------->| 1648 | |(15) TURN Resp | 1649 | |s=192.0.2.10:5556 | 1650 | |d=192.0.2.2:10895 | 1651 | |M=192.0.2.10:8079 | 1652 | |<-----------------------| 1653 |(16) TURN Resp | | 1654 |s=192.0.2.10:5556 | | 1655 |d=192.168.3.1:23767 | | 1656 |M=192.0.2.10:8079 | | 1657 |<-----------------------| | 1659 Figure 11: B's Unilateral Allocations 1661 When B receives this offer, it performs its unilateral allocations. 1662 Like A's, these allocations (shown in Figure 11) are almost identical 1663 to those in Figure 6. They differ in the same way - the NAT will 1664 allocate a different binding for each of the two STUN and two TURN 1665 queries. However, the set of derived transport address is the same. B 1666 now begins performing connectivity checks. These are shown in Figure 1667 12. As in the previous case (Figure 7), the STUN request to 1668 10.0.1.1:1010 fails. However, here, the STUN request to 1669 192.0.2.1:9988 also fails. Thats because this packet arrives at A's 1670 NAT, and the NAT finds that the public transport address 1671 192.0.2.1:9988 has been allocated, however, it was allocated when the 1672 client sent to 192.0.2.10:3478. Here, the source address is not 1673 192.0.2.10:3478, and so the packet is discarded. The STUN request to 1674 192.0.2.10:8076 does work, however. Thats because the TURN server 1675 sends the request from the same IP address and port that it received 1676 the original TURN allocation request on. 1678 A As NAT TURN + STUN Server Bs NAT B 1679 | | | |(1) STUN Bind| 1680 | | | |s=192.168.3.1:23766 1681 | | | |d=10.0.1.1:1010 1682 | | | |<------------| 1683 | | |Unreachable | | 1684 | | | |(2) STUN Bind| 1685 | | | |s=192.168.3.1:23766 1686 | | | |d=192.0.2.1:9988 1687 | | | |<------------| 1688 | |(3) STUN Bind| | | 1689 | |s=192.0.2.2:10896 | | 1690 | |d=192.0.2.1:9988 | | 1691 | |<--------------------------| | 1692 | |Unreachable | | | 1693 | | | |(4) STUN Bind| 1694 | | | |s=192.168.3.1:23766 1695 | | | |d=192.0.2.10:8076 1696 | | | |<------------| 1697 | | |(5) STUN Bind| | 1698 | | |s=192.0.2.2:10897 | 1699 | | |d=192.0.2.10:8076 | 1700 | | |<------------| | 1701 | |(6) STUN Bind| | | 1702 | |s=192.0.2.10:5556 | | 1703 | |d=192.0.2.1:9991 | | 1704 | |<------------| | | 1705 |(7) STUN Bind| | | | 1706 |s=192.0.2.10:5556 | | | 1707 |d=10.0.1.1:1010 | | | 1708 |<------------| | | | 1709 |(8) STUN Reply | | | 1710 |s=10.0.1.1:1010 | | | 1711 |d=192.0.2.10:5556 | | | 1712 |M=192.0.2.10:5556 | | | 1713 |------------>| | | | 1714 | |(9) STUN Reply | | 1715 | |s=192.0.2.1:9991 | | 1716 | |d=192.0.2.10:5556 | | 1717 | |M=192.0.2.10:5556 | | 1718 | |------------>| | | 1719 | | |(10) STUN Reply | 1720 | | |s=192.0.2.10:8076 | 1721 | | |d=192.0.2.2:10897 | 1722 | | |M=192.0.2.10:5556 | 1723 | | |------------>| | 1724 | | | |(11) STUN Reply 1725 | | | |s=192.0.2.10:8076 1726 | | | |d=192.168.3.1:23766 1727 | | | |M=192.0.2.10:5556 1728 | | | |------------>| 1730 Figure 12: B's Connectivity Checks 1732 B's answer to A is the same as in Figure 8. However, B has only 1733 established connectivity to A's TURN derived transport address, and 1734 so it sends media there. 1736 A As NAT TURN + STUN Server Bs NAT B 1737 |(1) STUN Bind| | | | 1738 |s=10.0.1.1:1010 | | | 1739 |d=192.168.3.1:23766 | | | 1740 |------------>| | | | 1741 | |Unreachable | | | 1742 |(2) STUN Bind| | | | 1743 |s=10.0.1.1:1010 | | | 1744 |d=192.0.2.2:10892 | | | 1745 |------------>| | | | 1746 | |(3) STUN Bind| | | 1747 | |s=192.0.2.1:9993 | | 1748 | |d=192.0.2.2:10892 | | 1749 | |-------------------------->| | 1750 | | | |Unreachable | 1751 |(4) STUN Bind| | | | 1752 |s=10.0.1.1:1010 | | | 1753 |d=192.0.2.10:8078 | | | 1754 |------------>| | | | 1755 | |(5) STUN Bind| | | 1756 | |s=192.0.2.1:9994 | | 1757 | |d=192.0.2.10:8078 | | 1758 | |------------>| | | 1759 | | |(6) STUN Bind| | 1760 | | |s=192.0.2.10:5556 | 1761 | | |d=192.0.2.2:10894 | 1762 | | |------------>| | 1763 | | | |(7) STUN Bind| 1764 | | | |s=192.0.2.10:5556 1765 | | | |d=192.168.3.1:23766 1766 | | | |------------>| 1767 | | | |(8) STUN Reply 1768 | | | |s=192.168.3.1:23766 1769 | | | |d=192.0.2.10:5556 1770 | | | |M=192.0.2.10:5556 1771 | | | |<------------| 1772 | | |(9) STUN Reply | 1773 | | |s=192.0.2.2:10894 | 1774 | | |d=192.0.2.10:5556 | 1775 | | |M=192.0.2.10:5556 | 1776 | | |<------------| | 1777 | |(10) STUN Reply | | 1778 | |s=192.0.2.10:8078 | | 1779 | |d=192.0.2.1:9994 | | 1780 | |M=192.0.2.10:5556 | | 1781 | |<------------| | | 1782 |(11) STUN Reply | | | 1783 |s=192.0.2.10:8078 | | | 1784 |d=10.0.1.1:1010 | | | 1785 |M=192.0.2.10:5556 | | | 1786 |<------------| | | | 1787 |(12) STUN Bind | | | 1788 |s=10.0.1.1:1010 | | | 1789 |d=192.0.2.10:5556 | | | 1790 |------------>| | | | 1791 | |(13) STUN Bind | | 1792 | |s=192.0.2.1:9991 | | 1793 | |d=192.0.2.10:5556 | | 1794 | |------------>| | | 1795 | | |(14) STUN Bind | 1796 | | |s=192.0.2.10:8076 | 1797 | | |d=192.0.2.2:10897 | 1798 | | |------------>| | 1799 | | | |(15) STUN Bind 1800 | | | |s=192.0.2.10:8076 1801 | | | |d=192.168.3.1:23766 1802 | | | |------------>| 1803 | | | |(16) STUN Reply 1804 | | | |s=192.168.3.1:23766 1805 | | | |d=192.0.2.10:8076 1806 | | | |M=192.0.2.10:8076 1807 | | | |<------------| 1808 | | |(17) STUN Reply | 1809 | | |s=192.0.2.2:10897 | 1810 | | |d=192.0.2.10:8076 | 1811 | | |M=192.0.2.10:8076 | 1812 | | |<------------| | 1813 | |(18) STUN Reply | | 1814 | |s=192.0.2.10:5556 | | 1815 | |d=192.0.2.1:9991 | | 1816 | |M=192.0.2.10:8076 | | 1817 | |<------------| | | 1818 |(19) STUN Reply | | | 1819 |s=192.0.2.10:5556 | | | 1820 |d=10.0.1.1:1010 | | | 1821 |M=192.0.2.10:8076 | | | 1822 |<------------| | | | 1824 Figure 13: A's Connectivity Checks 1826 When A gets the answer, it too performs its connectivity checks, as 1827 shown in Figure 13. As expected, the connectivity checks to B's 1828 private address and its STUN derived transport addresses fail. The 1829 checks to B's TURN derived transport address succeeds, as does the 1830 check to B's peer derived transport address. Both have a qvalue of 1831 0.4. However, a peer-derived address is always preferred. So, A will 1832 send media to B using 192.0.2.10:5556, which will reach B as a result 1833 of the lock-down on its own TURN binding. As in the full-cone case, A 1834 won't bother to perform another offer with the new peer derived 1835 transport address it learned from message 19 (192.0.2.10:5556), since 1836 it knows that this is not of higher priority than ones that B has 1837 already connected to. 1839 Once A connects to B's peer derived address (messages 12 to 19 in 1840 Figure 13), B knows that its equal priority TURN derived transport 1841 address won't be used, so it can free it. 1843 OPEN ISSUE: The same argument can be made about A, in which case 1844 both sides would free their TURN addresses, and nothing works. 1845 Need to come up with a sane prioritization so it doesnt happen. 1847 9.2 Enterprise 1849 Public Internet 1851 192.0.2.1 1852 +---------+ 1853 | | 1854 ----------------------| Firewall|-------------------------- 1855 | NAT | 1856 10.0.0.0/16 +---------+ DMZ 1858 +---------+ +---------+ 1859 | | | TURN/ | 1860 | Proxy | | STUN | 1861 | | | Server | 1862 +---------+ +---------+ 1864 ........................................................... 1866 +----------+ 1867 | / \ | 1868 +---------+ /SIP \ +----------+ 1869 | +---------+ /Phone \ | / \ | 1870 | | +---------+ / \ /SIP \ 1871 | | | | ------------ /Phone \ 1872 +-| | PC | / \ 1873 +-| | ------------ 1874 +---------+ 1876 Enterprise 1878 Figure 14: Enterprise Configuration 1880 In this scenario, shown in Figure 14 there is an enterprise that 1881 wishes to deploy VoIP. The enterprise has a single site, and there is 1882 a firewall/NAT at the border to the public Internet. This NAT is 1883 symmetric. Internally, the enterprise is using 10.0.0.0/16. Behind 1884 the firewall, within the DMZ, is a TURN/STUN server and a SIP proxy. 1885 The firewall has been configured to allow incoming traffic to port 1886 5060 to go to the SIP proxy. It has also allowed incoming UDP traffic 1887 on a specific port range to go to the TURN/STUN server. The TURN 1888 server has an internal address of 10.0.1.10. This port range contains 1889 enough addresses to allow simultaneous conversations to cover the 1890 needs of the enterprise, but no more. That range is configured on the 1891 TURN/STUN server, so that the TURN server allocates addresses within 1892 this range. The TURN server is also configured to allocate two 1893 addresses for each allocation request, using the MORE-AVAILABLE 1894 feature in TURN [14]. Thats because different addresses need to be 1895 used if the TURN server is contacted externally (192.0.2.1) vs. 1896 internally (10.0.1.10). 1898 Within the enterprise, PCs and hardphones are used for VoIP. All of 1899 them are configured to use the proxy and TURN/STUN server that is run 1900 by the enterprise. 1902 All call flows in this section only indicate RTP. The flows for RTCP 1903 are not shown. 1905 9.2.1 Intra-Enterprise Call 1907 A STUN+TURN Server 1908 |(1) STUN Bind | 1909 |s=10.0.1.1:1010 | 1910 |d=10.0.1.10:3478 | 1911 |----------------------->| 1912 |(2) STUN Resp | 1913 |s=10.0.1.10:3478 | 1914 |d=10.0.1.1:1010 | 1915 |M=10.0.1.1:1010 | 1916 |<-----------------------| 1917 |(3) TURN Alloc | 1918 |s=10.0.1.1:1010 | 1919 |d=10.0.1.10:5556 | 1920 |----------------------->| 1921 |(4) TURN Resp | 1922 |s=10.0.1.10:5556 | 1923 |d=10.0.1.1:1010 | 1924 |M=192.0.2.1:8076 | 1925 |M=10.0.1.10:8076 | 1926 |<-----------------------| 1928 Figure 15: A's Unilateral Allocations 1930 TODO: The flows here don't align yet with the MORE-AVAILABLE 1931 mechanism in TURN. Need to update to do so. 1933 The first case to consider is that where a user within the enterprise 1934 calls another user within the same enterprise. First, user A performs 1935 its unilateral allocations. This is shown in Figure 15. The STUN 1936 allocation does not yield a new address, but the TURN allocation, of 1937 course, does. In fact, the TURN allocation yields two addresses. The 1938 first of these, 192.0.2.1, has a higher priority. As a result, the 1939 offer from A to B has three addresses, as shown in Figure 16. 1941 v=0 1942 o=alice 2890844730 2890844731 IN IP4 host.example.com 1943 s= 1944 c=IN IP4 192.0.2.1 1945 t=0 0 1946 m=audio 8076 RTP/AVP 0 1947 a=alt:1 1.0 : user 9kksj== 10.0.1.1 1010 1948 a=alt:2 0.5 : user1 9kksk== 192.0.2.1 8076 1949 a=alt:3 0.4 : user2 9kksl== 10.0.1.10 8076 1951 Figure 16: A's Offer 1953 B receives this offer. It performs its own unilateral allocations, 1954 shown in Figure 17. 1956 B STUN+TURN Server 1957 |(1) STUN Bind | 1958 |s=10.0.1.2:23766 | 1959 |d=10.0.1.10:3478 | 1960 |----------------------->| 1961 |(2) STUN Resp | 1962 |s=10.0.1.10:3478 | 1963 |d=10.0.1.2:23766 | 1964 |M=10.0.1.2:23766 | 1965 |<-----------------------| 1966 |(3) TURN Alloc | 1967 |s=10.0.1.2:23766 | 1968 |d=10.0.1.10:5556 | 1969 |----------------------->| 1970 |(4) TURN Resp | 1971 |s=10.0.1.10:5556 | 1972 |d=10.0.1.2:23766 | 1973 |M=192.0.2.1:8078 | 1974 |M=10.0.1.10:8078 | 1975 |<-----------------------| 1977 Figure 17: B's Unilateral Allocations 1979 The STUN derived transport address equals its local transport 1980 address, so no additional addresses are obtained through that route. 1981 TURN provided B with two new addresses. Next, B performs connectivity 1982 checks against the three alternatives provided by A. These checks are 1983 shown in Figure 18. The connectivity check to the alternate with ID 1984 1, A's local transport address, succeeds, since both users are within 1985 the same address realm. The connectivity to check to the alternate 1986 with ID 2, which is the TURN server address on the public Internet, 1987 fails. This is because the NAT does not support receipt of requests 1988 from internal hosts that are targeted towards internal bindings. As a 1989 result, the STUN request is dropped by the NAT. The connectivity 1990 check through the TURN relay using its private address succeeds, 1991 however, and yields B a new peer derived transport address - 1992 10.0.1.10:5566. 1994 A TURN + STUN Server B NAT 1995 |(1) STUN Bind| | | 1996 |s=10.0.1.2:23766 | | 1997 |d=10.0.1.1:1010 | | 1998 |<--------------------------| | 1999 | | | | 2000 |(2) STUN Reply | | 2001 |s=10.0.1.1:1010 | | 2002 |d=10.0.1.2:23766 | | 2003 |M=10.0.1.2:23766 | | 2004 |-------------------------->| | 2005 | | | | 2006 | | | | 2007 | | |(3) STUN Bind| 2008 | | |s=10.0.1.2:23766 2009 | | |d=192.0.2.1:8076 2010 | | |------------>| 2011 | | | | 2012 | | |Dropped by NAT 2013 | | | | 2014 | | | | 2015 | |(4) STUN Bind| | 2016 | |s=10.0.1.2:23766 | 2017 | |d=10.0.1.10:8076 | 2018 | |<------------| | 2019 | | | | 2020 | | | | 2021 |(5) STUN Bind| | | 2022 |s=10.0.1.10:5556 | | 2023 |d=10.0.1.1:1010 | | 2024 |<------------| | | 2025 | | | | 2026 |(6) STUN Reply | | 2027 |s=10.0.1.1:1010 | | 2028 |d=10.0.1.10:5556 | | 2029 |M=10.0.1.10:5566 | | 2030 |------------>| | | 2031 | | | | 2032 | |(7) STUN Reply | 2033 | |s=10.0.1.10:8076 | 2034 | |d=10.0.1.2:23766 | 2035 | |M=10.0.1.10:5566 | 2036 | |------------>| | 2037 | | | | 2038 | | | | 2039 | | | | 2040 | | | | 2041 | | | | 2042 | | | | 2044 Figure 18: B's Connectivity Test 2046 Based on this, B generates the answer shown in Figure 19. Since B has 2047 established connectivity to A's local transport address, it begins 2048 sending media there. 2050 v=0 2051 o=bob 2890844730 289084871 IN IP4 host2.example.com 2052 s= 2053 c=IN IP4 192.0.2.1 2054 t=0 0 2055 m=audio 8078 RTP/AVP 0 2056 a=alt:4 1.0 : peer as88jl 10.0.1.2 23766 2057 a=alt:5 0.5 : peer1 as88kl 192.0.2.1 8078 2058 a=alt:6 0.4 : peer2 as88ll 10.0.1.10 8078 2059 a=alt:7 0.4 2 peer3 as88ml 10.0.1.10 5556 2061 Figure 19: B's Answer 2063 Now, A performs its connectivity checks, shown in Figure 20. These 2064 checks indicate that connectivity is established to B's local 2065 transport address (10.0.1.2:23766), B's TURN derived transport 2066 address (10.0.1.10:8078) and B's peer derived transport address 2067 (10.0.1.10:5556). The highest priority address is the local transport 2068 address, and so A sends media there. A also discovered a new peer 2069 derived transport address, 10.0.1.10:5556. However, it doesn't bother 2070 sending it in a new offer, since B connected using a higher priority 2071 address. In fact, both A and B can now free their TURN derived 2072 addresses. The call proceeds with media flowing directly between A 2073 and B, as desired. 2075 A TURN + STUN Server B NAT 2076 |(1) STUN Bind | | | 2077 |s=10.0.1.1:1010 | | | 2078 |d=10.0.1.2:23766 | | | 2079 |---------------------------------->| | 2080 |(2) STUN Reply | | | 2081 |s=10.0.1.2:23766 | | | 2082 |d=10.0.1.1:1010 | | | 2083 |M=10.0.1.1:1010 | | | 2084 |<----------------------------------| | 2085 |(3) STUN Bind | | | 2086 |s=10.0.1.1:1010 | | | 2087 |d=192.0.2.1:8078 | | | 2088 |---------------------------------------------------->| 2089 | | |Dropped by NAT | 2090 |(4) STUN Bind | | | 2091 |s=10.0.1.1:1010 | | | 2092 |d=10.0.1.10:8078 | | | 2093 |---------------->| | | 2094 | |(5) STUN Bind | | 2095 | |s=10.0.1.10:5556 | | 2096 | |d=10.0.1.2:23766 | | 2097 | |---------------->| | 2098 | |(6) STUN Reply | | 2099 | |s=10.0.1.2:23766 | | 2100 | |d=10.0.1.10:5556 | | 2101 | |M=10.0.1.10:5556 | | 2102 | |<----------------| | 2103 |(7) STUN Reply | | | 2104 |s=10.0.1.10:8078 | | | 2105 |d=10.0.1.1:1010 | | | 2106 |M=10.0.1.10:5556 | | | 2107 |<----------------| | | 2108 |(8) STUN Bind | | | 2109 |s=10.0.1.1:1010 | | | 2110 |d=10.0.1.10:5556 | | | 2111 |---------------->| | | 2112 | |(9) STUN Bind | | 2113 | |s=10.0.1.10:8076 | | 2114 | |d=10.0.1.2:23766 | | 2115 | |---------------->| | 2116 | |(10) STUN Reply | | 2117 | |s=10.0.1.2:23766 | | 2118 | |d=10.0.1.10:8076 | | 2119 | |M=10.0.1.10:8076 | | 2120 | |<----------------| | 2121 |(11) STUN Reply | | | 2122 |s=10.0.1.10:5556 | | | 2123 |d=10.0.1.1:1010 | | | 2124 |M=10.0.1.10:8076 | | | 2125 |<----------------| | | 2127 Figure 20: A's Connectivity Checks 2129 9.2.2 Extra-Enterprise Call 2131 In this case, user A within the enterprise calls some user B, not 2132 within the enterprise. B is connected to the Internet through a PSTN 2133 gateway, and as a result, appears as a UA on the public Internet. 2134 Presumably this is some gateway run by a third party termination 2135 provider that is being used by the enterprise. Furthermore, this 2136 gateway does not support ICE at all, and so will ignore the alt 2137 parameters in the SDP. 2139 First, A performs its unilateral allocations. This proceeds 2140 identically as shown in Figure 15. It generates the same offer as 2141 shown in Figure 16. This gets routed to the called party on the 2142 public Internet. This party generates an answer. However, since the 2143 called party does not support ICE, the answer has no alt attributes. 2144 It has a single IP address and port listed in the c and m lines. As a 2145 result, the caller, A, sends media there. Furthermore the called 2146 party uses the IP address and port in the m and c lines of A's offer. 2147 This is 192.0.2.1:8076, which routes to the enterprise NAT, and is 2148 then forwarded to the TURN server, and from there, relayed to the 2149 caller. As a result, media now flows in both directions. 2151 OPEN ISSUE: This assumes that the firewall policy admits outbound 2152 UDP packets towards any destination. It is likely that some 2153 enterprises will not permit this. To fix this, it would require 2154 the ability of a client to send media using a TURN relay, similar 2155 to the way instant message senders can use a relay in the Message 2156 Session Relay Protocol (MSRP) [19]. 2158 9.2.3 Disconnected Intra-Enterprise 2160 In this scenario, A and B are both within the enterprise. However, 2161 they work in different departments. Both departments are connected to 2162 the company backbone. However, A's department has a symmetric NAT 2163 between it and the company backbone, with user A on the private side. 2164 A's department NATs into 10.0.2.0/24. That is, it has allocated 256 2165 of the company's addresses to NAT into. B's department has decided to 2166 use 192.168.0.0/16 in its private network. 2168 A Dept NAT STUN+TURN Server 2169 |(1) STUN Bind | | 2170 |s=192.168.1.1:1010 | | 2171 |d=10.0.1.10:3478 | | 2172 |----------------------->| | 2173 | |(2) STUN Bind | 2174 | |s=10.0.2.88:6584 | 2175 | |d=10.0.1.10:3478 | 2176 | |----------------------->| 2177 | |(3) STUN Resp | 2178 | |s=10.0.1.10:3478 | 2179 | |d=10.0.2.88:6584 | 2180 | |M=10.0.2.88:6584 | 2181 | |<-----------------------| 2182 |(4) STUN Resp | | 2183 |s=10.0.1.10:3478 | | 2184 |d=192.168.1.1:1010 | | 2185 |M=10.0.2.88:6584 | | 2186 |<-----------------------| | 2187 |(5) TURN Alloc | | 2188 |s=192.168.1.1:1010 | | 2189 |d=10.0.1.10:5556 | | 2190 |----------------------->| | 2191 | |(6) TURN Alloc | 2192 | |s=10.0.2.88:6585 | 2193 | |d=10.0.1.10:5556 | 2194 | |----------------------->| 2195 | |(7) TURN Alloc | 2196 | |s=10.0.1.10:5556 | 2197 | |d=10.0.2.88:6585 | 2198 | |M=192.2.0.1:8076 | 2199 | |M=10.0.1.10:8076 | 2200 | |<-----------------------| 2201 |(8) TURN Alloc | | 2202 |s=10.0.1.10:5556 | | 2203 |d=192.168.1.1:1010 | | 2204 |M=192.2.0.1:8076 | | 2205 |M=10.0.1.10:8076 | | 2206 |<-----------------------| | 2208 Figure 21: A's Unilateral Allocations 2210 A starts by performing its usual unilateral allocations, as shown in 2211 Figure 21. These allocations provide it a STUN derived and two TURN 2212 derived transport address. Based on these, it sends the offer shown 2213 in Figure 22. 2215 v=0 2216 o=alice 2890844730 2890844731 IN IP4 host.example.com 2217 s= 2218 c=IN IP4 192.0.2.1 2219 t=0 0 2220 m=audio 8076 RTP/AVP 0 2221 a=alt:1 1.0 : user 9kksj== 192.168.1.1 1010 2222 a=alt:2 0.8 : user5 sad87 10.0.2.88:6584 2223 a=alt:3 0.5 : user1 9kksk== 192.0.2.1 8076 2224 a=alt:4 0.4 : user2 9kksl== 10.0.1.10 8076 2226 Figure 22: A's Offer 2228 B performs its unilateral allocations. (Figure 17. Then it performs 2229 its connectivity checks. This is where things differ. B's checks are 2230 shown in Figure 23. The STUN request to A's local transport address, 2231 192.168.1.1:1010 fails (message 1), because 192.168.0.0/16 is not 2232 reachable from B. The STUN request (message 2) to A's STUN derived 2233 transport address, 10.0.2.88:6584, also fails, because the department 2234 NAT is symmetric (it would have worked if it was full-cone). The STUN 2235 request to A's public TURN derived transport address, 192.0.2.1:8076, 2236 also fails since the NAT won't "turn around" such packets. The final 2237 attempt, B's STUN request to A's private TURN derived transport 2238 address, does in fact succeed. It yields a new peer derived transport 2239 address for B, 10.0.1.10:5566. 2241 A Dept NAT TURN + STUN Server B Corp. NAT 2242 | | | |(1) STUN Bind| 2243 | | | |s=10.0.1.2:23766 2244 | | | |d=192.168.1.1:1010 2245 | | | |------------>| 2246 | | | |Dropped | 2247 | |(2) STUN Bind| | | 2248 | |s=10.0.1.2:23766 | | 2249 | |d=10.0.2.88:6584 | | 2250 | |<--------------------------| | 2251 | |Dropped | | | 2252 | | | |(3) STUN Bind| 2253 | | | |s=10.0.1.2:23766 2254 | | | |d=192.0.2.1:8076 2255 | | | |------------>| 2256 | | | |Dropped by NAT 2257 | | |(4) STUN Bind| | 2258 | | |s=10.0.1.2:23766 | 2259 | | |d=10.0.1.10:8076 | 2260 | | |<------------| | 2261 | |(5) STUN Bind| | | 2262 | |s=10.0.1.10:5556 | | 2263 | |d=10.0.2.88:6585 | | 2264 | |<------------| | | 2265 |(6) STUN Bind| | | | 2266 |s=10.0.1.10:5556 | | | 2267 |d=192.168.1.1:1010 | | | 2268 |<------------| | | | 2269 |(7) STUN Reply | | | 2270 |s=192.168.1.1:1010 | | | 2271 |d=10.0.1.10:5556 | | | 2272 |M=10.0.1.10:5566 | | | 2273 |------------>| | | | 2274 | |(8) STUN Reply | | 2275 | |s=10.0.2.88:6585 | | 2276 | |d=10.0.1.10:5556 | | 2277 | |M=10.0.1.10:5566 | | 2278 | |------------>| | | 2279 | | |(9) STUN Reply | 2280 | | |s=10.0.1.10:8076 | 2281 | | |d=10.0.1.2:23766 | 2282 | | |M=10.0.1.10:5566 | 2283 | | |------------>| | 2285 Figure 23: B's Connectivity Checks 2287 Based on this, B generates the answer shown in Figure 24. 2289 v=0 2290 o=bob 2890844730 289084871 IN IP4 host2.example.com 2291 s= 2292 c=IN IP4 192.0.2.1 2293 t=0 0 2294 m=audio 8078 RTP/AVP 0 2295 a=alt:5 1.0 : peer as88jl 10.0.1.2 23766 2296 a=alt:6 0.5 : peer1 as88kl 192.0.2.1 8078 2297 a=alt:7 0.4 : peer2 as88ll 10.0.1.10 8078 2298 a=alt:8 0.4 4 peer3 as88ml 10.0.1.10 5556 2300 Figure 24: B's Answer 2302 B receives this answer. It performs its connectivity checks against 2303 the four addresses provided by B. These checks are shown in Figure 2304 25. The first check, to B's local transport address (10.0.1.2:23766) 2305 actually succeeds. Indeed, it also provides A with a new peer derived 2306 transport address - 10.0.2.88:6586. The second check, to B's TURN 2307 derived transport address on the public Internet, fails, because the 2308 NAT won't turn around packets. The third check, to B's TURN derived 2309 transport address on the private corporate network, succeeds as 2310 expected, and provides A with a new peer derived transport address, 2311 10.0.1.10:5556. The fourth check, to B's peer derived transport 2312 address (through the TURN relay), also succeeds. 2314 A Dept NAT TURN + STUN Server B Corp. NAT 2315 |(1) STUN Bind | | | | 2316 |s=192.168.1.1:1010 | | | 2317 |d=10.0.1.2:23766| | | | 2318 |--------------->| | | | 2319 | |(2) STUN Bind | | | 2320 | |s=10.0.2.88:6586| | | 2321 | |d=10.0.1.2:23766| | | 2322 | |-------------------------------->| | 2323 | |(3) STUN Reply | | | 2324 | |s=10.0.1.2:23766| | | 2325 | |d=10.0.2.88:6586| | | 2326 | |M=10.0.2.88:6586| | | 2327 | |<--------------------------------| | 2328 |(4) STUN Reply | | | | 2329 |s=10.0.1.2:23766| | | | 2330 |d=192.168.1.1:1010 | | | 2331 |M=10.0.2.88:6586| | | | 2332 |<---------------| | | | 2333 |(5) STUN Bind | | | | 2334 |s=192.168.1.1:1010 | | | 2335 |d=192.0.2.1:8078| | | | 2336 |------------------------------------------------------------------>| 2337 | | | |Dropped by NAT | 2338 |(6) STUN Bind | | | | 2339 |s=192.168.1.1:1010 | | | 2340 |d=10.0.1.10:8078| | | | 2341 |--------------->| | | | 2342 | |(7) STUN Bind | | | 2343 | |s=10.0.2.88:6587| | | 2344 | |d=10.0.1.10:8078| | | 2345 | |--------------->| | | 2346 | | |(8) STUN Bind | | 2347 | | |s=10.0.1.10:5556| | 2348 | | |d=10.0.1.2:23766| | 2349 | | |--------------->| | 2350 | | |(9) STUN Reply | | 2351 | | |s=10.0.1.2:23766| | 2352 | | |d=10.0.1.10:5556| | 2353 | | |M=10.0.1.10:5556| | 2354 | | |<---------------| | 2355 | |(10) STUN Reply | | | 2356 | |s=10.0.1.10:8078| | | 2357 | |d=10.0.2.88:6587| | | 2358 | |M=10.0.1.10:5556| | | 2359 | |<---------------| | | 2360 |(11) STUN Reply | | | | 2361 |s=10.0.1.10:8078| | | | 2362 |d=192.168.1.1:1010 | | | 2363 |M=10.0.1.10:5556| | | | 2364 |<---------------| | | | 2365 |(12) STUN Bind | | | | 2366 |s=192.168.1.1:1010 | | | 2367 |d=10.0.1.10:5556| | | | 2368 |--------------->| | | | 2369 | |(13) STUN Bind | | | 2370 | |s=10.0.2.88:6585| | | 2371 | |d=10.0.1.10:5556| | | 2372 | |--------------->| | | 2373 | | |(14) STUN Bind | | 2374 | | |s=10.0.1.10:8076| | 2375 | | |d=10.0.1.2:23766| | 2376 | | |--------------->| | 2377 | | |(15) STUN Reply | | 2378 | | |s=10.0.1.2:23766| | 2379 | | |d=10.0.1.10:8076| | 2380 | | |M=10.0.1.10:8076| | 2381 | | |<---------------| | 2382 | |(16) STUN Reply | | | 2383 | |s=10.0.1.10:5556| | | 2384 | |d=10.0.2.88:6585| | | 2385 | |M=10.0.1.10:8076| | | 2386 | |<---------------| | | 2387 |(17) STUN Reply | | | | 2388 |s=10.0.1.10:5556| | | | 2389 |d=192.168.1.1:1010 | | | 2390 |M=10.0.1.10:8076| | | | 2391 |<---------------| | | | 2393 Figure 25: A's Connectivity Checks 2395 At this point, the highest priority address that A has established 2396 connectivity to is B's local transport address. So, A begins sending 2397 media there. However, the connectivity checks provided A with two new 2398 addresses. One of them is of higher priority than the highest 2399 priority address that B has connected to. So, using a re-INVITE or an 2400 UPDATE [6], A will generate a new offer to B: 2402 v=0 2403 o=alice 2890844730 2890844732 IN IP4 host.example.com 2404 s= 2405 c=IN IP4 192.0.2.1 2406 t=0 0 2407 m=audio 8076 RTP/AVP 0 2408 a=alt:1 1.0 : user 9kksj== 192.168.1.1 1010 2409 a=alt:2 0.8 : user5 sad87 10.0.2.88:6584 2410 a=alt:3 0.5 : user1 9kksk== 192.0.2.1 8076 2411 a=alt:4 0.4 : user2 9kksl== 10.0.1.10 8076 2412 a=alt:5 1.0 5 user6 77==8ja 10.0.2.88 6586 2413 a=alt:6 0.4 7 user7 a8kkzu 10.0.1.10 5556 2415 Figure 26: A's 2nd Offer 2417 When B receives this offer, it sees two new alternates, 5 and 6. So, 2418 it performs connectivity checks to them, as shown in Figure 27. The 2419 first check succeeds, and tells B that its address as seen by A is 2420 10.0.1.2:23766. This is not a new address. The second check also 2421 succeeds, but doesn't provide B with a new address. However, B now 2422 has a higher priority address with connectivity to A. It therefore 2423 begins sending media there. B will generate an answer, of course, but 2424 it is identical to its previous answer, in terms of addresses. 2426 A Dept NAT TURN + STUN Server B Corp. NAT 2427 | |(1) STUN Bind| | | 2428 | |s=10.0.1.2:23766 | | 2429 | |d=10.0.2.88:6586 | | 2430 | |<--------------------------| | 2431 |(2) STUN Bind| | | | 2432 |s=10.0.1.2:23766 | | | 2433 |d=192.168.1.1:1010 | | | 2434 |<------------| | | | 2435 |(3) STUN Reply | | | 2436 |s=192.168.1.1:1010 | | | 2437 |d=10.0.1.2:23766 | | | 2438 |M=10.0.1.2:23766 | | | 2439 |------------>| | | | 2440 | |(4) STUN Reply | | 2441 | |s=10.0.2.88:6586 | | 2442 | |d=10.0.1.2:23766 | | 2443 | |M=10.0.1.2:23766 | | 2444 | |-------------------------->| | 2445 | | |(5) STUN Bind| | 2446 | | |s=10.0.1.2:23766 | 2447 | | |d=10.0.1.10:5556 | 2448 | | |<------------| | 2449 | |(6) STUN Bind| | | 2450 | |s=10.0.1.10:8078 | | 2451 | |d=10.0.2.88:6585 | | 2452 | |<------------| | | 2453 |(7) STUN Bind| | | | 2454 |s=10.0.1.10:8078 | | | 2455 |d=192.168.1.1:1010 | | | 2456 |<------------| | | | 2457 |(8) STUN Reply | | | 2458 |s=192.168.1.1:1010 | | | 2459 |d=10.0.1.10:8078 | | | 2460 |M=10.0.1.10:8078 | | | 2461 |------------>| | | | 2462 | |(9) STUN Reply | | 2463 | |s=10.0.2.88:6585 | | 2464 | |d=10.0.1.10:8078 | | 2465 | |M=10.0.1.10:8078 | | 2466 | |------------>| | | 2467 | | |(10) STUN Reply | 2468 | | |s=10.0.1.10:5556 | 2469 | | |d=10.0.1.2:23766 | 2470 | | |M=10.0.1.10:8078 | 2471 | | |------------>| | 2473 Figure 27: B's 2nd Connectivity Checks 2475 The net result of this scenario is that, after two ICE cycles, A and 2476 B are able to send media to each other directly, even though there is 2477 a symmetric NAT between them. 2479 9.3 Centrex 2481 In a centrex scenario, a third party provider owns and operates the 2482 SIP and TURN/STUN servers. The enterprise merely changes their 2483 firewall configuration to allow SIP traffic out to port 5060 to the 2484 provider's SIP proxy, and to allow TURN traffic out to port 5556 and 2485 3478, on the provider's TURN/STUN server. The corporate NAT is 2486 symmetric. The TURN/STUN server runs on 192.0.2.10. This scenario is 2487 shown in Figure 28. 2489 Provider Equipment 2491 +---------+ +---------+ 2492 | | | TURN/ | 2493 | Proxy | | STUN | 2494 | | | Server | 2495 +---------+ +---------+ 2496 Public 2497 Internet 2499 192.0.2.1 2500 +---------+ 2501 | | 2502 ----------------------| Firewall|-------------------------- 2503 | NAT | 2504 10.0.0.0/16 +---------+ 2506 +----------+ 2507 | / \ | 2508 +---------+ /SIP \ +----------+ 2509 | +---------+ /Phone \ | / \ | 2510 | | +---------+ / \ /SIP \ 2511 | | | | ------------ /Phone \ 2512 +-| | PC | / \ 2513 +-| | ------------ 2514 +---------+ 2516 Enterprise 2518 Figure 28: Centrex Configuration 2520 9.3.1 Intra-Enterprise Call 2522 In this scenario, user A calls user B. Both are within the 2523 enterprise. First, A performs its unilateral allocations. These are 2524 shown in Figure 29. These yield a STUN derived transport address and 2525 a TURN derived transport address. A sends these in the offer shown in 2526 Figure 30. 2528 A Corp. NAT STUN+TURN Server 2529 |(1) STUN Bind | | 2530 |s=10.0.1.1:1010 | | 2531 |d=192.0.2.10:3478 | | 2532 |----------------------->| | 2533 | |(2) STUN Bind | 2534 | |s=192.0.2.1:9988 | 2535 | |d=192.0.2.10:3478 | 2536 | |----------------------->| 2537 | |(3) STUN Resp | 2538 | |s=192.0.2.10:3478 | 2539 | |d=192.0.2.1:9988 | 2540 | |M=192.0.2.1:9988 | 2541 | |<-----------------------| 2542 |(4) STUN Resp | | 2543 |s=192.0.2.10:3478 | | 2544 |d=10.0.1.1:1010 | | 2545 |M=192.0.2.1:9988 | | 2546 |<-----------------------| | 2547 |(5) TURN Alloc | | 2548 |s=10.0.1.1:1010 | | 2549 |d=192.0.2.10:5556 | | 2550 |----------------------->| | 2551 | |(6) TURN Alloc | 2552 | |s=192.0.2.1:9989 | 2553 | |d=192.0.2.10:5556 | 2554 | |----------------------->| 2555 | |(7) TURN Resp | 2556 | |s=192.0.2.10:5556 | 2557 | |d=192.0.1.1:9989 | 2558 | |M=192.0.2.10:8076 | 2559 | |<-----------------------| 2560 |(8) TURN Resp | | 2561 |s=192.0.2.10:5556 | | 2562 |d=10.0.1.1:1010 | | 2563 |M=192.0.2.10:8076 | | 2564 |<-----------------------| | 2566 Figure 29: A's Unilateral Allocations 2568 v=0 2569 o=alice 2890844730 2890844731 IN IP4 host.example.com 2570 s= 2571 c=IN IP4 192.0.2.10 2572 t=0 0 2573 m=audio 8076 RTP/AVP 0 2574 a=alt:1 1.0 : user 9kksj== 10.0.1.1 1010 2575 a=alt:2 0.5 : user1 9kksk== 192.0.2.1 9988 2576 a=alt:3 0.4 : user2 9kksl== 192.0.2.10 8076 2578 Figure 30: A's Offer 2580 This offer is received by B. B performs its unilateral allocations, 2581 shown in Figure 31. These yield a STUN derived and TURN derived 2582 transport address. 2584 B Corp. NAT STUN+TURN Server 2585 |(1) STUN Bind | | 2586 |s=10.0.1.2:23766 | | 2587 |d=192.0.2.10:3478 | | 2588 |----------------------->| | 2589 | |(2) STUN Bind | 2590 | |s=192.0.2.1:9990 | 2591 | |d=192.0.2.10:3478 | 2592 | |----------------------->| 2593 | |(3) STUN Resp | 2594 | |s=192.0.2.10:3478 | 2595 | |d=192.0.2.1:9990 | 2596 | |M=192.0.2.1:9990 | 2597 | |<-----------------------| 2598 |(4) STUN Resp | | 2599 |s=192.0.2.10:3478 | | 2600 |d=10.0.1.2:23766 | | 2601 |M=192.0.2.1:9990 | | 2602 |<-----------------------| | 2603 |(5) TURN Alloc | | 2604 |s=10.0.1.2:23766 | | 2605 |d=192.0.2.10:5556 | | 2606 |----------------------->| | 2607 | |(6) TURN Alloc | 2608 | |s=192.0.2.1:9991 | 2609 | |d=192.0.2.10:5556 | 2610 | |----------------------->| 2611 | |(7) TURN Resp | 2612 | |s=192.0.2.10:5556 | 2613 | |d=192.0.2.1:9991 | 2614 | |M=192.0.2.10:8078 | 2615 | |<-----------------------| 2616 |(8) TURN Resp | | 2617 |s=192.0.2.10:5556 | | 2618 |d=10.0.1.2:23766 | | 2619 |M=192.0.2.10:8078 | | 2620 |<-----------------------| | 2622 Figure 31: B's Unilateral Allocations 2624 Now, B begins its connectivity checks, as shown in Figure 32. The 2625 first check (message 1), to A's local transport address, 2626 10.0.1.1:1010, succeeds, since A and B are behind the same NAT. The 2627 second check, to A's STUN derived transport address, fails, since the 2628 enterprise NAT won't turn around packets. The third check, to A's 2629 TURN derived transport address, 192.0.2.10:8076, also succeeds, and 2630 yields B a new peer derived transport address, 192.0.2.10:5556. 2632 A B Corp. NAT TURN + STUN Server 2633 |(1) STUN Bind | | | 2634 |s=10.0.1.2:23766| | | 2635 |d=10.0.1.1:1010 | | | 2636 |<---------------| | | 2637 |(2) STUN Reply | | | 2638 |s=10.0.1.1:1010 | | | 2639 |d=10.0.1.2:23766| | | 2640 |M=10.0.1.2:23766| | | 2641 |--------------->| | | 2642 | |(3) STUN Bind | | 2643 | |s=10.0.1.2:23766| | 2644 | |d=192.0.2.1:9988| | 2645 | |--------------->| | 2646 | | |Dropped | 2647 | |(4) STUN Bind | | 2648 | |s=10.0.1.2:23766| | 2649 | |d=192.0.2.10:8076 | 2650 | |--------------->| | 2651 | | |(5) STUN Bind | 2652 | | |s=192.0.2.1:9992| 2653 | | |d=192.0.2.10:8076 2654 | | |--------------->| 2655 | | |(6) STUN Bind | 2656 | | |s=192.0.2.10:5556 2657 | | |d=192.0.2.1:9988| 2658 | | |<---------------| 2659 |(7) STUN Bind | | | 2660 |s=192.0.2.10:5556 | | 2661 |d=10.0.1.1:1010 | | | 2662 |<--------------------------------| | 2663 |(8) STUN Reply | | | 2664 |s=10.0.1.1:1010 | | | 2665 |d=192.0.2.10:5556 | | 2666 |M=192.0.2.10:5556 | | 2667 |-------------------------------->| | 2668 | | |(9) STUN Reply | 2669 | | |s=192.0.2.1:9988| 2670 | | |d=192.0.2.10:5556 2671 | | |M=192.0.2.10:5556 2672 | | |--------------->| 2673 | | |(10) STUN Reply | 2674 | | |s=192.0.2.10:8076 2675 | | |d=192.0.2.1:9992| 2676 | | |M=192.0.2.10:5556 2677 | | |<---------------| 2678 | |(11) STUN Reply | | 2679 | |s=192.0.2.10:8076 | 2680 | |d=10.0.1.2:23766| | 2681 | |M=192.0.2.10:5556 | 2682 | |<---------------| | 2684 Figure 32: B's Connectivity Checks 2686 B can now send media to A directly. It also generates an answer, 2687 shown in Figure 33. 2689 v=0 2690 o=bob 2890844730 289084871 IN IP4 host2.example.com 2691 s= 2692 c=IN IP4 192.0.2.10 2693 t=0 0 2694 m=audio 8078 RTP/AVP 0 2695 a=alt:4 1.0 : peer as88jl 10.0.1.2 23766 2696 a=alt:5 0.8 : peer1 as88kl 192.0.2.1 9990 2697 a=alt:6 0.4 : peer2 as88ll 192.0.2.10 8078 2698 a=alt:7 0.4 : peer3 as88ml 192.0.2.10 5556 2700 Figure 33: B's Answer 2702 This arrives at A. A is able to send media immediately to B using the 2703 default, 192.0.2.10:8078. It also starts its connectivity checks to 2704 find a better choice. These checks are shown in Figure 34. As 2705 expected, the check for connectivity to 10.0.1.2:23766 succeeds, 2706 representing the highest priority address. The check to 2707 192.0.2.1:9990 fails, because the NAT won't turn around internal 2708 packets. The checks to 192.0.2.10:8078 and 192.0.2.10:5556 succeed, 2709 and the former resuls in a peer-derived transport address of 2710 192.0.2.10:5556. However, A knows that B has already connected to a 2711 higher priority address, so it doesn't bother with an additional 2712 offer/answer exchange. 2714 A B Corp. NAT TURN + STUN Server 2715 |(1) STUN Bind | | | 2716 |s=10.0.1.1:1010 | | | 2717 |d=10.0.1.2:23766 | | | 2718 |---------------->| | | 2719 |(2) STUN Reply | | | 2720 |s=10.0.1.2:23766 | | | 2721 |d=10.0.1.1:1010 | | | 2722 |M=10.0.1.1:1010 | | | 2723 |<----------------| | | 2724 |(3) STUN Bind | | | 2725 |s=10.0.1.1:1010 | | | 2726 |d=192.0.2.1:9990 | | | 2727 |---------------------------------->| | 2728 | | |Dropped | 2729 |(4) STUN Bind | | | 2730 |s=10.0.1.1:1010 | | | 2731 |d=192.0.2.10:8078| | | 2732 |---------------------------------->| | 2733 | | |(5) STUN Bind | 2734 | | |s=192.0.2.1:9992 | 2735 | | |d=192.0.2.10:8078| 2736 | | |---------------->| 2737 | | |(6) STUN Bind | 2738 | | |s=192.0.2.10:5556| 2739 | | |d=192.0.2.1:9991 | 2740 | | |<----------------| 2741 | |(7) STUN Bind | | 2742 | |s=192.0.2.10:5556| | 2743 | |d=10.0.1.2:23766 | | 2744 | |<----------------| | 2745 | |(8) STUN Reply | | 2746 | |s=10.0.1.2:23766 | | 2747 | |d=192.0.2.10:5556| | 2748 | |M=192.0.2.10:5556| | 2749 | |---------------->| | 2750 | | |(9) STUN Reply | 2751 | | |s=192.0.2.1:9991 | 2752 | | |d=192.0.2.10:5556| 2753 | | |M=192.0.2.10:5556| 2754 | | |---------------->| 2755 | | |(10) STUN Reply | 2756 | | |s=192.0.2.10:8078| 2757 | | |d=192.0.2.1:9992 | 2758 | | |M=192.0.2.10:5556| 2759 | | |<----------------| 2760 |(11) STUN Reply | | | 2761 |s=192.0.2.10:8078| | | 2762 |d=10.0.1.1:1010 | | | 2763 |M=192.0.2.10:5556| | | 2764 |<----------------------------------| | 2765 |(12) STUN Bind | | | 2766 |s=10.0.1.1:1010 | | | 2767 |d=192.0.2.10:5556| | | 2768 |---------------------------------->| | 2769 | | |(13) STUN Bind | 2770 | | |s=192.0.2.1:9989 | 2771 | | |d=192.0.2.10:5556| 2772 | | |---------------->| 2773 | | |(14) STUN Bind | 2774 | | |s=192.0.2.10:8076| 2775 | | |d=192.0.2.1:9991 | 2776 | | |<----------------| 2777 | |(15) STUN Bind | | 2778 | |s=192.0.2.10:8076| | 2779 | |d=10.0.1.2:23766 | | 2780 | |<----------------| | 2781 | |(16) STUN Reply | | 2782 | |s=10.0.1.2:23766 | | 2783 | |d=192.0.2.10:8076| | 2784 | |M=192.0.2.10:8076| | 2785 | |---------------->| | 2786 | | |(17) STUN Reply | 2787 | | |s=192.0.2.1:9991 | 2788 | | |d=192.0.2.10:8076| 2789 | | |M=192.0.2.10:8076| 2790 | | |---------------->| 2791 | | |(18) STUN Reply | 2792 | | |s=192.0.2.10:5556| 2793 | | |d=192.0.2.1:9989 | 2794 | | |M=192.0.2.10:8076| 2795 | | |<----------------| 2796 |(19) STUN Reply | | | 2797 |s=192.0.2.10:5556| | | 2798 |d=10.0.1.1:1010 | | | 2799 |M=192.0.2.10:8076| | | 2800 |<----------------------------------| | 2802 Figure 34: A's Connectivity Checks 2804 The conclusion is that A and B communicate directly, without using 2805 the provider's relay. They can proceed to de-allocate the TURN 2806 addresses once the call is active. 2808 10. Security Considerations 2810 Security considerations are discussed throughout the document. 2811 [[Editors Note: Need to summarize here anyway.]]. 2813 11. IANA Considerations 2815 This specification registers a new precondition type and a new SDP 2816 attributes. 2818 11.1 Precondition Type 2820 Name: connectivity 2822 Description: Confirm end-to-end connectivity with STUN. 2824 11.2 SDP Attributes 2826 This specification defines one new media attribute: alt. Its syntax 2827 is defined in Section 7. 2829 12. IAB Considerations 2831 The IAB has studied the problem of "Unilateral Self Address Fixing", 2832 which is the general process by which a client attempts to determine 2833 its address in another realm on the other side of a NAT through a 2834 collaborative protocol reflection mechanism [8]. ICE is an example of 2835 a protocol that performs this type of function. Interestingly, the 2836 process for ICE is not unilateral, but bilateral, and the difference 2837 has a signficant impact on the issues raised by IAB. The IAB has 2838 mandated that any protocols developed for this purpose document a 2839 specific set of considerations. This section meets those 2840 requirements. 2842 12.1 Problem Definition 2844 From RFC 3424 any UNSAF proposal must provide: 2846 Precise definition of a specific, limited-scope problem that is to 2847 be solved with the UNSAF proposal. A short term fix should not 2848 be generalized to solve other problems; this is why "short term 2849 fixes usually aren't". 2851 The specific problems being solved by ICE are: 2853 Provide a means for two peers to determine the set of transport 2854 addresses which can be used for communication. 2856 Provide a means for resolving many of the limitations of other 2857 UNSAF mechanisms by wrapping them in an additional layer of 2858 processing (the ICE methodology). 2860 Provide a means for a client to determine an address that is 2861 reachable by another peer with which it wishes to communicate. 2863 12.2 Exit Strategy 2865 From RFC 3424, any UNSAF proposal must provide: 2867 Description of an exit strategy/transition plan. The better short 2868 term fixes are the ones that will naturally see less and less use 2869 as the appropriate technology is deployed. 2871 ICE itself doesn't easily get phased out. However, it is useful even 2872 in a globally connected Internet, to serve as a means for detecting 2873 whether a router failure has temporarily disrupted connectivity, for 2874 example. However, what ICE does is help phase out other UNSAF 2875 mechanisms. ICE effectively selects amongst those mechanisms, 2876 prioritizing ones that are better, and deprioritizing ones that are 2877 worse. Local IPv6 addresses are always the most preferred. As NATs 2878 begin to dissipate as IPv6 is introduced, derived transport addresses 2879 from other UNSAF mechanisms simply never get used, because higher 2880 priority connectivity exists. Therefore, the servers get used less 2881 and less, and can eventually be remove when their usage goes to zero. 2883 Indeed, ICE can assist in the transition from IPv4 to IPv6. It can be 2884 used to determine whether to use IPv6 or IPv4 when two dual-stack 2885 hosts communicate with SIP (IPv6 gets used). It can also allow a 2886 client in a v6 island to communicate with a v4 host on the other side 2887 of a 6to4 NAT, by allowing the v6 host to address-fix against the v4 2888 host, and in the process, obtain a v4 address which can be handed to 2889 the v4 client. 2891 12.3 Brittleness Introduced by ICE 2893 From RFC3424, any UNSAF proposal must provide: 2895 Discussion of specific issues that may render systems more 2896 "brittle". For example, approaches that involve using data at 2897 multiple network layers create more dependencies, increase 2898 debugging challenges, and make it harder to transition. 2900 ICE actually removes brittleness from existing UNSAF mechanisms. In 2901 particular, traditional STUN (the usage described in RFC 3489) has 2902 several points of brittleness. One of them is the discovery process 2903 which requires a client to try and classify the type of NAT it is 2904 behind. This process is error-prone. With ICE, that discovery process 2905 is simply not used. Rather than unilaterally assessing the validity 2906 of the address, its validity is dynamically determined by measuring 2907 connectivity to a peer. The process of determining connectivity is 2908 very robust. The only potential problem is that bilaterally fixed 2909 addresses through STUN can expire if traffic does not keep them 2910 alive. However, that is substantially less brittleness than the STUN 2911 discovery mechanisms. 2913 Another point of brittleness in STUN, TURN, and any other unilateral 2914 mechanism is its absolute reliance on an additional server. ICE makes 2915 use of a server for allocating unilateral addresses, but allows 2916 clients to directly connect if possible. Therefore, in some cases, 2917 the failure of a STUN or TURN server would still allow for a call to 2918 progress when ICE is used. 2920 Another point of brittleness in traditional STUN is that it assumes 2921 that the STUN server is on the public Internet. Interestingly, with 2922 ICE, that is not necessary. There can be a multitude of STUN servers 2923 in a variety of address realms. ICE will discover the one that has 2924 provided a usable address. 2926 The most troubling point of brittleness in traditional STUN is that 2927 it doesn't work in all network topologies. In cases where there is a 2928 shared NAT between each client and the STUN server, traditional STUN 2929 may not work. With ICE, that restriction can be lifted. 2931 Traditional STUN also introduces some security considerations. 2932 Unfortunately, since ICE still uses network resident STUN servers, 2933 those security considerations still exist. 2935 12.4 Requirements for a Long Term Solution 2937 From RFC 3424, any UNSAF proposal must provide: 2939 Identify requirements for longer term, sound technical solutions 2940 -- contribute to the process of finding the right longer term 2941 solution. 2943 Our conclusions from STUN remain unchanged. However, we feel ICE 2944 actually helps because we believe it can be part of the long term 2945 solution. 2947 12.5 Issues with Existing NAPT Boxes 2949 From RFC 3424, any UNSAF proposal must provide: 2951 Discussion of the impact of the noted practical issues with 2952 existing, deployed NA[P]Ts and experience reports. 2954 A number of NAT boxes are now being deployed into the market which 2955 try and provide "generic" ALG functionality. These generic ALGs hunt 2956 for IP addresses, either in text or binary form within a packet, and 2957 rewrite them if they match a binding. This will interfere with proper 2958 operation of any UNSAF mechanism, including ICE. 2960 13. Acknowledgements 2962 The authors would like to thank Douglas Otis and Francois Audet for 2963 their comments and input. 2965 Informative References 2967 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2968 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2969 Session Initiation Protocol", RFC 3261, June 2002. 2971 [2] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 2972 Rayhan, "Middlebox communication architecture and framework", 2973 RFC 3303, August 2002. 2975 [3] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm 2976 Specific IP: Framework", RFC 3102, October 2001. 2978 [4] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm 2979 Specific IP: Protocol Specification", RFC 3103, October 2001. 2981 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2982 Session Description Protocol (SDP)", RFC 3264, June 2002. 2984 [6] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 2985 Method", RFC 3311, October 2002. 2987 [7] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of 2988 Resource Management and Session Initiation Protocol (SIP)", RFC 2989 3312, October 2002. 2991 [8] Daigle, L. and IAB, "IAB Considerations for UNilateral 2992 Self-Address Fixing (UNSAF) Across Network Address 2993 Translation", RFC 3424, November 2002. 2995 [9] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, 2996 "Grouping of Media Lines in the Session Description Protocol 2997 (SDP)", RFC 3388, December 2002. 2999 [10] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 3000 "RTP: A Transport Protocol for Real-Time Applications", RFC 3001 1889, January 1996. 3003 [11] Rosenberg, J., Schulzrinne, H. and J. Weinberger, "An Extension 3004 to the Session Initiation Protocol (SIP) for Symmetric 3005 Response Routing", draft-ietf-sip-symmetric-response-00 (work 3006 in progress), September 2002. 3008 [12] Mahy, R., "Requirements for Connection Reuse in the Session 3009 Initiation Protocol (SIP)", 3010 draft-ietf-sipping-connect-reuse-reqs-00 (work in progress), 3011 October 2002. 3013 [13] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 3014 Simple Traversal of User Datagram Protocol (UDP) Through 3015 Network Address Translators (NATs)", RFC 3489, March 2003. 3017 [14] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 3018 draft-rosenberg-midcom-turn-01 (work in progress), March 2003. 3020 [15] Shore, M., "The TIST (Topology-Insensitive Service Traversal) 3021 Protocol", draft-shore-tist-prot-00 (work in progress), May 3022 2002. 3024 [16] Yon, D., "Connection-Oriented Media Transport in SDP", 3025 draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 3026 2003. 3028 [17] Huitema, C., "RTCP attribute in SDP", 3029 draft-ietf-mmusic-sdp4nat-05 (work in progress), June 2003. 3031 [18] Rosenberg, J., Mahy, R. and S. Sen, "NAT and Firewall Scenarios 3032 and Solutions for SIP", draft-ietf-sipping-nat-scenarios-00 3033 (work in progress), June 2002. 3035 [19] Campbell, B., "Instant Message Sessions in SIMPLE", 3036 draft-ietf-simple-message-sessions-00 (work in progress), May 3037 2003. 3039 [20] Camarillo, G. and J. Rosenberg, "The Alternative Semantics for 3040 the Session Description Protocol Grouping Framework", 3041 draft-camarillo-mmusic-alt-01 (work in progress), June 2003. 3043 [21] Audet, F., Aoun, C., Sen, S. and F. Meijer, "Identifying 3044 Intra-realm Calls using STUN", 3045 draft-sen-sipping-intrarealm-stun-00 (work in progress), 3046 September 2002. 3048 [22] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 3049 draft-ietf-ngtrans-shipworm-08 (work in progress), September 3050 2002. 3052 Author's Address 3054 Jonathan Rosenberg 3055 dynamicsoft 3056 600 Lanidex Plaza 3057 Parsippany, NJ 07054 3058 US 3060 Phone: +1 973 952-5000 3061 EMail: jdrosen@dynamicsoft.com 3062 URI: http://www.jdrosen.net 3064 Intellectual Property Statement 3066 The IETF takes no position regarding the validity or scope of any 3067 intellectual property or other rights that might be claimed to 3068 pertain to the implementation or use of the technology described in 3069 this document or the extent to which any license under such rights 3070 might or might not be available; neither does it represent that it 3071 has made any effort to identify any such rights. Information on the 3072 IETF's procedures with respect to rights in standards-track and 3073 standards-related documentation can be found in BCP-11. Copies of 3074 claims of rights made available for publication and any assurances of 3075 licenses to be made available, or the result of an attempt made to 3076 obtain a general license or permission for the use of such 3077 proprietary rights by implementors or users of this specification can 3078 be obtained from the IETF Secretariat. 3080 The IETF invites any interested party to bring to its attention any 3081 copyrights, patents or patent applications, or other proprietary 3082 rights which may cover technology that may be required to practice 3083 this standard. Please address the information to the IETF Executive 3084 Director. 3086 Full Copyright Statement 3088 Copyright (C) The Internet Society (2003). All Rights Reserved. 3090 This document and translations of it may be copied and furnished to 3091 others, and derivative works that comment on or otherwise explain it 3092 or assist in its implementation may be prepared, copied, published 3093 and distributed, in whole or in part, without restriction of any 3094 kind, provided that the above copyright notice and this paragraph are 3095 included on all such copies and derivative works. However, this 3096 document itself may not be modified in any way, such as by removing 3097 the copyright notice or references to the Internet Society or other 3098 Internet organizations, except as needed for the purpose of 3099 developing Internet standards in which case the procedures for 3100 copyrights defined in the Internet Standards process must be 3101 followed, or as required to translate it into languages other than 3102 English. 3104 The limited permissions granted above are perpetual and will not be 3105 revoked by the Internet Society or its successors or assignees. 3107 This document and the information contained herein is provided on an 3108 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3109 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3110 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3111 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3112 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3114 Acknowledgement 3116 Funding for the RFC Editor function is currently provided by the 3117 Internet Society.