idnits 2.17.1 draft-ietf-sipping-nat-scenarios-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2344. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 339: '... RECOMMENDED. This mechanism is not...' RFC 2119 keyword, line 343: '... requests SHOULD use the same IP add...' RFC 2119 keyword, line 374: '... documented in [15]. 'Symmetric RTP' SHOULD only be used for...' RFC 2119 keyword, line 424: '... to a SIP entity but it is RECOMMENDED...' RFC 2119 keyword, line 432: '...Establishment (ICE) is the RECOMMENDED...' (5 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 26, 2006) is 6511 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '4' is defined on line 2231, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2269, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (ref. '2') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2327 (ref. '3') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2766 (ref. '4') (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 3388 (ref. '8') (Obsoleted by RFC 5888) ** Downref: Normative reference to an Informational RFC: RFC 3424 (ref. '9') == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-03 == Outdated reference: A later version (-08) exists of draft-ietf-behave-nat-udp-07 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-00 -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-09 -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-08 == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-00 Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group C. Boulton, Ed. 3 Internet-Draft Ubiquity Software Corporation 4 Expires: December 28, 2006 J. Rosenberg 5 Cisco Systems 6 G. Camarillo 7 Ericsson 8 June 26, 2006 10 Best Current Practices for NAT Traversal for SIP 11 draft-ietf-sipping-nat-scenarios-05 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 28, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 Traversal of the Session Initiation Protocol (SIP) and the sessions 45 it establishes through Network Address Translators (NAT) is a complex 46 problem. Currently there are many deployment scenarios and traversal 47 mechanisms for media traffic. This document aims to provide concrete 48 recommendations and a unified method for NAT traversal as well as 49 documenting corresponding call flows. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Solution Technology Outline Description . . . . . . . . . . . 6 56 3.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 7 58 3.1.2. Connection Re-use . . . . . . . . . . . . . . . . . . 8 59 3.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 8 60 3.2.1. Symmetric RTP . . . . . . . . . . . . . . . . . . . . 8 61 3.2.2. STUN . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.2.3. TURN . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.2.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.2.5. Solution Profiles . . . . . . . . . . . . . . . . . . 10 65 4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 11 66 4.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 11 67 4.1.1. Registration (Registrar/Proxy Co-Located) . . . . . . 11 68 4.1.2. Registration(Registrar/Proxy not Co-Located) . . . . . 15 69 4.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 18 70 4.1.4. Receiving an Invitation to a Session . . . . . . . . . 20 71 4.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 23 72 4.2.1. Endpoint independent NAT . . . . . . . . . . . . . . . 24 73 4.2.2. Port and Address Dependant NAT . . . . . . . . . . . . 40 74 4.3. Address independent Port Restricted NAT --> Address 75 independent Port Restricted NAT traversal . . . . . . . . 46 76 4.4. Internal TURN Usage (Enterprise Deployment) . . . . . . . 46 77 5. Intercepting Intermediary (B2BUA) . . . . . . . . . . . . . . 46 78 6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 47 79 6.1. IPv4-IPv6 Transition for SIP Signalling . . . . . . . . . 47 80 6.2. IPv4-IPv6 Transition for Media . . . . . . . . . . . . . . 47 81 7. ICE with RTP/TCP . . . . . . . . . . . . . . . . . . . . . . . 50 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 50 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 52 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 87 Intellectual Property and Copyright Statements . . . . . . . . . . 54 89 1. Introduction 91 NAT (Network Address Translators) traversal has long been identified 92 as a large problem when considered in the context of the Session 93 Initiation Protocol (SIP)[1] and it's associated media such as Real 94 Time Protocol (RTP)[2]. The problem is further confused by the 95 variety of NATs that are available in the market place today and the 96 large number of potential deployment scenarios. Detail of different 97 NAT behaviors can be found in 'NAT Behavioral Requirements for 98 Unicast UDP' [11]. 100 The IETF has produced many specifications for the traversal of NAT, 101 including STUN, ICE, rport, symmetric RTP, TURN, SIP Outbound, SDP 102 attribute for RTCP, and others. These each represent a part of the 103 solution, but none of them gives the overall context for how the NAT 104 traversal problem is decomposed and solved through this collection of 105 specifications. This document serves to meet that need. 107 This document attempts to provide a definitive set of 'Best Common 108 Practices' to demonstrate the traversal of SIP and its associated 109 media through NAT devices. The document does not propose any new 110 functionality but does draw on existing solutions for both core SIP 111 signaling and media traversal (as defined in Section 3). 113 The draft will be split into distinct sections as follows: 114 1. A clear definition of the problem statement 115 2. Description of proposed solutions for both SIP protocol signaling 116 and media signaling 117 3. A set of basic and advanced call flow scenarios 119 2. Problem Statement 121 The traversal of SIP through NAT can be split into two categories 122 that both require attention - The core SIP signaling and associated 123 media traversal. 125 The core SIP signaling has a number of issues when traversing through 126 NATs. 128 Firstly, the default operation for SIP response generation using 129 unreliable protocols such as the Unicast Datagram Protocol (UDP) 130 results in responses generated at the User Agent Server (UAS) being 131 sent to the source address, as specified in either the SIP 'Via' 132 header or the 'received' parameter (as defined in RFC 3261 [1]). The 133 port is extracted from the SIP 'Via' header to complete the IP 134 address/port combination for returning the SIP response. While the 135 destination is correct, the port contained in the SIP 'Via' header 136 represents the listening port of the originating client and not the 137 port representing the open pin hole on the NAT. This results in 138 responses being sent back to the NAT but to a port that is likely not 139 open for SIP traffic. The SIP response will then be dropped at the 140 NAT. This is illustrated in Figure 1 which depicts a SIP response 141 being returned to port 5060. 143 Private NAT Public 144 Network | Network 145 | 146 | 147 -------- SIP Request |open port 5650 -------- 148 | |-------------------->--->-----------------------| | 149 | | | | | 150 | Client | |port 5060 SIP Response | Proxy | 151 | | x<------------------------| | 152 | | | | | 153 -------- | -------- 154 | 155 | 156 | 158 Figure 1 160 Secondly, when using a reliable, connection orientated transport 161 protocol such as TCP, SIP has an inherent mechanism that results in 162 SIP responses reusing the connection that was created/used for the 163 corresponding transactional request. The SIP protocol does not 164 provide a mechanism that allows new requests generated in the reverse 165 direction of the originating client to use the existing TCP 166 connection created between the client and the server during 167 registration. This results in the registered contact address not 168 being bound to the "connection" in the case of TCP. Requests are 169 then blocked at the NAT, as illustrated in Figure 2. This problem 170 also exists for unreliable transport protocols such as UDP where 171 external NAT mappings need to be re-used to reach a SIP entity on the 172 private side of the network. 174 Private NAT Public 175 Network | Network 176 | 177 | 178 -------- (UAC 8023) REGISTER/Response (UAS 5060) -------- 179 | |-------------------->---<-----------------------| | 180 | | | | | 181 | Client | |5060 INVITE (UAC 8015)| Proxy | 182 | | x<------------------------| | 183 | | | | | 184 -------- | -------- 185 | 186 | 187 | 189 Figure 2 191 In Figure 2 the original REGISTER request is sent from the client on 192 port 8023 and received on port 5060, establishing a reliable 193 connection and opening a pin-hole in the NAT. The generation of a 194 new request from the proxy results in a request destined for the 195 registered entity (Contact IP address) which is not reachable from 196 the public network. This results in the new SIP request attempting 197 to create a connection to a private network address. This problem 198 would be solved if the original connection was re-used. While this 199 problem has been discussed in the context of connection orientated 200 protocols such as TCP, the problem exists for SIP signaling using any 201 transport protocol. The solution proposed for this problem in 202 section 3 of this document is relevant for all SIP signaling, 203 regardless of the transport protocol. 205 NAT policy can dictate that connections should be closed after a 206 period of inactivity. This period of inactivity can range 207 drastically from a number seconds to hours. Pure SIP signaling can 208 not be relied upon to keep alive connections for a number of reasons. 209 Firstly, SIP entities can sometimes have no signaling traffic for 210 long periods of time which has the potential to exceed the inactivity 211 timer, and this can lead to problems where endpoints are not 212 available to receive incoming requests as the connection has been 213 closed. Secondly, if a low inactivity timer is specified, SIP 214 signaling is not appropriate as a keep-alive mechanism as it has the 215 potential to add a large amount of traffic to the network which uses 216 up valuable resource and also requires processing at a SIP stack, 217 which is also a waste of processing resources. 219 Media associated with SIP calls also has problems traversing NAT. 220 RTP [2]] is one of the most common media transport types used in SIP 221 signaling. Negotiation of RTP occurs with a SIP session 222 establishment using the Session Description Protocol(SDP) [3] and a 223 SIP offer/answer exchange[5]. During a SIP offer/answer exchange an 224 IP address and port combination are specified by each client in a 225 session as a means of receiving media such as RTP. The problem 226 arises when a client advertises its address to receive media and it 227 exists in a private network that is not accessible from outside the 228 NAT. Figure 3 illustrates this problem. 230 NAT Public Network NAT 231 | | 232 | | 233 | | 234 -------- | SIP Signaling Session | -------- 235 | |----------------------->---<--------------------| | 236 | | | | | | 237 | Client | | | | Client | 238 | A |>=====>RTP>==Unknown Address==>X | | B | 239 | | | X<==Unknown Address==>---------<<->>-----port 5060| Client | 305 | A | | | B | 306 | | | | | 307 -------- | -------- 308 | 309 | 310 | 312 Figure 4 314 The exact functionality for this method of response traversal is 315 called 'Symmetric Response' and the details are documented in RFC 316 3581 [6]. Additional requirements are imposed on SIP entities in 317 this specification such as listening and sending SIP requests/ 318 responses from the same port. 320 3.1.2. Connection Re-use 322 The second problem with sip signaling, as defined in Section 2 and 323 illustrated in Figure 2, is to allow incoming requests to be properly 324 routed. 326 Guidelines for devices such as User Agents that can only generate 327 outbound connections through a NAT are documented in 'SIP Conventions 328 for UAs with Outbound Only Connections'[13]. The document provides 329 techniques that use a unique User Agent instance identifier 330 (instance-id) in association with a flow identifier (Reg-id). The 331 combination of the two identifiers provides a key to a particular 332 connections (both UDP and TCP) that are stored in association with 333 registration bindings. On receiving an incoming request to a SIP 334 Address-Of-Record (AOR), a proxy routes to the associated flow 335 created by the registration and thus a route through a NAT. It also 336 provides a keepalive mechanism for clients to keep NAT bindings 337 alive. This is achieved using peer-to-peer STUN multiplexed over the 338 SIP signaling connection. Usage of this specification is 339 RECOMMENDED. This mechanism is not transport specific and should be 340 used for any transport protocol. 342 Even if the SIP Outbound draft is not used, clients generating SIP 343 requests SHOULD use the same IP address and port (i.e., socket) for 344 both transmission and receipt of SIP messages. Doing so allows for 345 the vast majority of industry provided solutions to properly 346 function. 348 3.2. Media Traversal 350 This document has already provided guidelines that recommend using 351 extensions to the core SIP protocol to enable traversal of NATs. 352 While ultimately not desirable, the additions are relatively straight 353 forward and provide a simple, universal solution for varying types of 354 NAT deployment. The issues of media traversal through NATs is not 355 straight forward and requires the combination of a number of 356 traversal methodologies. The technologies outlined in the remainder 357 of this section provide the required solution set. 359 3.2.1. Symmetric RTP 361 The primary problem identified in section 2 of this document is that 362 internal IP address/port combinations can not be reached from the 363 public side of a NAT. In the case of media such as RTP, this will 364 result in no audio traversing a NAT(as illustrated in Figure 3). To 365 overcome this problem, a technique called 'Symmetric' RTP can be 366 used. This involves an SIP endpoint both sending and receiving RTP 367 traffic from the same IP Address/Port combination. This technique 368 also requires intelligence by a client on the public internet as it 369 identifies that incoming media for a particular session does not 370 match the information that was conveyed in the SDP. In this case the 371 client will ignore the SDP address/port combination and return RTP to 372 the IP address/port combination identified as the source of the 373 incoming media. This technique is known as 'Symmetric RTP' and is 374 documented in [15]. 'Symmetric RTP' SHOULD only be used for 375 traversal of RTP through NAT when one of the participants in a media 376 session definitively knows that it is on the public network. 378 3.2.1.1. RTCP Attribute 380 Normal practice when selecting a port for defining Real Time Control 381 Protocol(RTCP) [2] is for consecutive order numbering (i.e select an 382 incremented port for RTCP from that used for RTP). This assumption 383 causes RTCP traffic to break when traversing many NATs due to blocked 384 ports. To combat this problem a specific address and port need to be 385 specified in the SDP rather than relying on such assumptions. RFC 386 3605 [6] defines an SDP attribute that is included to explicitly 387 specify transport connection information for RTCP. The address 388 details can be obtained using any appropriate method including those 389 detailed previously in this section (e.g. STUN, TURN). 391 3.2.2. STUN 393 Simple Traversal of User Datagram Protocol (UDP) through Network 394 Address Translators(NAT) or STUN is defined in RFC 3489bis [10]. 395 STUN is a lightweight tool kit and protocol that provides details of 396 the external IP address/port combination used by the NAT device to 397 represent the internal entity on the public facing side of a NAT. On 398 learning of such an external representation, a client can use it 399 accordingly as the connection address in SDP to provide NAT 400 traversal. Using terminology defined in the draft 'NAT Behavioral 401 Requirements for Unicast UDP' [11], STUN does work with 'Endpoint 402 Independent Mapping' but does not work with either 'Address Dependent 403 Mapping' or 'Address Dependent and Port Mapping' type NATs. Using 404 STUN with either of the previous two NAT mappings to probe for the 405 external IP address/port representation will provide a different 406 result to that required for traversal by an alternative SIP entity. 407 The IP address/port combination deduced for the STUN server would be 408 blocked for incoming packets from an alterative SIP entity. 410 As mentioned in Section 3.1.2, STUN is also used as a peer-to-peer 411 keep-alive mechanism. 413 3.2.3. TURN 415 As described in the previous section, the STUN protocol does not work 416 for UDP traversal through certain identified NAT mappings. 417 'Obtaining Relay Addresses from Simple Traversal of UDP Through NAT 418 (known as TURN)' is a usage of the STUN protocol for deriving (from a 419 STUN server) an address that will be used to relay packet towards a 420 client. TURN provides an external address (globally routable) at a 421 STUN server that will act as a media relay which guarantees traffic 422 will reach the associated internal address. The full details of the 423 TURN specification are defined in [12]. A TURN service will almost 424 always provide media traffic to a SIP entity but it is RECOMMENDED 425 that this method only be used as a last resort and not as a general 426 mechanism for NAT traversal. This is because using TURN has high 427 performance costs when relaying media traffic and can lead to 428 unwanted latency. 430 3.2.4. ICE 432 Interactive Connectivity Establishment (ICE) is the RECOMMENDED 433 method for traversal of existing NAT if Symmetric RTP is not 434 appropriate. ICE is a methodology for using existing technologies 435 such as STUN, TURN and any other UNSAF[9] compliant protocol to 436 provide a unified solution. This is achieved by obtaining as many 437 representative IP address/port combinations as possible using 438 technologies such as STUN/TURN etc. Once the addresses are 439 accumulated, they are all included in the SDP exchange in a new media 440 attribute called 'candidate'. Each 'candidate' SDP attribute entry 441 has detailed connection information including a media addresses 442 (including optional RTCP information), priority, username, password 443 and a unique session ID. The appropriate IP address/port 444 combinations are used in the correct order depending on the specified 445 priority. A client compliant to the ICE specification will then 446 locally run instances of STUN servers on all addresses being 447 advertised using ICE. Each instance will undertake connectivity 448 checks to ensure that a client can successfully receive media on the 449 advertised address. Only connections that pass the relevant 450 connectivity checks are used for media exchange. The full details of 451 the ICE methodology are contained in [16]. 453 3.2.5. Solution Profiles 455 This draft has documented a number of technology solutions for the 456 traversal of media through differing NAT deployments. A number of 457 'profiles' will now be defined that categorize varying levels of 458 support for the technologies described. 460 3.2.5.1. Primary Profile 462 A client falling into the 'Primary' profile supports ICE in 463 conjunction with STUN, TURN and RFC 3605 [6] for RTCP. ICE is used 464 in all cases and falls back to standard operation when dealing with 465 non-ICE clients. A client which falls into the 'Primary' profile 466 will be maximally interoperable and function in a rich variety of 467 environments including enterprise, consumer and behind all varieties 468 of NAT. 470 3.2.5.2. Consumer Profile 472 A client falling into the 'Consumer' profile supports STUN and RFC 473 3605 [6] for RTCP. It uses STUN to allocate bindings, and can also 474 detect when it is in the unfortunate situation of being behind a 475 'Symmetric' NAT, although it simply cannot function in this case. 476 These clients will only work in deployment situations where the 477 access is sufficiently controlled to know definitively that there 478 won't be Symmetric NAT. This is hard to guarantee as users can 479 always pick up their client and connect via a different access 480 network. 482 3.2.5.3. Minimal Profile 484 A client falling into the 'Minimal' profile will send/receive RTP 485 form the same IP/port combination. This client requires proprietary 486 network based solutions to function in any NAT traversal scenario. 488 All clients SHOULD support the 'Primary Profile', MUST support the 489 'Minimal Profile' and MAY support the 'Consumer Profile'. 491 4. NAT Traversal Scenarios 493 This section of the document includes detailed NAT traversal 494 scenarios for both SIP signaling and the associated media. 496 4.1. Basic NAT SIP Signaling Traversal 498 The following sub-sections concentrate on SIP signaling traversal of 499 NAT. The scenarios include traversal for both reliable and un- 500 reliable transport protocols. 502 4.1.1. Registration (Registrar/Proxy Co-Located) 504 The set of scenarios in this section document basic signaling 505 traversal of a SIP REGISTER method through a NAT. 507 4.1.1.1. UDP 509 Client NAT Proxy 510 | | | 511 |(1) REGISTER | | 512 |----------------->| | 513 | | | 514 | |(1) REGISTER | 515 | |----------------->| 516 | | | 517 | |(2) 401 Unauth | 518 | |<-----------------| 519 | | | 520 |(2) 401 Unauth | | 521 |<-----------------| | 522 | | | 523 |(3) REGISTER | | 524 |----------------->| | 525 | | | 526 | |(3) REGISTER | 527 | |----------------->| 528 | | | 529 |*************************************| 530 | Create Connection Re-use Tuple | 531 |*************************************| 532 | | | 533 | |(4) 200 OK | 534 | |<-----------------| 535 | | | 536 |(4) 200 OK | | 537 |<-----------------| | 538 | | | 540 Figure 5 542 In this example the client sends a SIP REGISTER request through a NAT 543 which is challenged using the Digest authentication scheme. The 544 client will include an 'rport' parameter as described in section 545 3.1.1 of this document for allowing traversal of UDP responses. The 546 original request as illustrated in (1) in Figure 5 is a standard 547 REGISTER message: 549 REGISTER sip:proxy.example.com SIP/2.0 550 Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK 551 Max-Forwards: 70 552 Supported: path,gruu 553 From: Client ;tag=djks8732 554 To: Client 555 Call-ID: 763hdc73y7dkb37@example.com 556 CSeq: 1 REGISTER 557 Contact: ;reg-id=1 558 ;+sip.instance="" 559 Content-Length: 0 561 This proxy now generates a SIP 401 response to challenge for 562 authentication, as depicted in (2) from Figure 5: 564 SIP/2.0 401 Unauthorized 565 Via: SIP/2.0/UDP client.example.com:5060 566 ;rport=8050;branch=z9hG4bK;received=192.0.1.2 567 From: Client ;tag=djks8732 568 To: Client ;tag=876877 569 Call-ID: 763hdc73y7dkb37@example.com 570 CSeq: 1 REGISTER 571 WWW-Authenticate: [not shown] 572 Content-Length: 0 574 The response will be sent to the address appearing in the 'received' 575 parameter of the SIP 'Via' header (address 192.0.1.2). The response 576 will not be sent to the port deduced from the SIP 'Via' header, as 577 per standard SIP operation but will be sent to the value that has 578 been stamped in the 'rport' parameter of the SIP 'Via' header (port 579 8050). For the response to successfully traverse the NAT, all of the 580 conventions defined in RFC 3581 [6] MUST be obeyed. Make note of the 581 both the 'connectionID' and 'sip.instance' contact header parameters. 582 They are used to establish a connection re-use tuple as defined in 583 [13]. The connection tuple creation is clearly shown in Figure 5. 584 This ensures that any inbound request that causes a registration 585 lookup will result in the re-use of the connection path established 586 by the registration. This exonerates the need to manipulate contact 587 header URI's to represent a globally routable address as perceived on 588 the public side of a NAT. The subsequent messages defined in (3) and 589 (4) from Figure 5 use the same mechanics for NAT traversal. 591 [Editors note: Will provide more details on heartbeat mechanism in 592 next revision] 594 [Editors note: Can complete full flows if required on heartbeat 595 inclusion] 597 4.1.1.2. Reliable Transport 599 Client NAT Registrar 600 | | | 601 |(1) REGISTER | | 602 |----------------->| | 603 | | | 604 | |(1) REGISTER | 605 | |----------------->| 606 | | | 607 | |(2) 401 Unauth | 608 | |<-----------------| 609 | | | 610 |(2) 401 Unauth | | 611 |<-----------------| | 612 | | | 613 |(3) REGISTER | | 614 |----------------->| | 615 | | | 616 | |(3) REGISTER | 617 | |----------------->| 618 | | | 619 |*************************************| 620 | Create Connection Re-use Tuple | 621 |*************************************| 622 | | | 623 | |(4) 200 OK | 624 | |<-----------------| 625 | | | 626 |(4) 200 OK | | 627 |<-----------------| | 628 | | | 630 Figure 6. 632 Traversal of SIP REGISTER requests/responses using a reliable, 633 connection orientated protocol such as TCP does not require any 634 additional core SIP signaling extensions. SIP responses will re-use 635 the connection created for the initial REGISTER request, (1) from 636 Figure 6: 638 REGISTER sip:proxy.example.com SIP/2.0 639 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKyilassjdshfu 640 Max-Forwards: 70 641 Supported: path,gruu 642 From: Client ;tag=djks809834 643 To: Client 644 Call-ID: 763hdc783hcnam73@example.com 645 CSeq: 1 REGISTER 646 Contact: ;reg-id=1 647 ;+sip.instance="" 648 Content-Length: 0 650 This example was included to show the inclusion of the connection re- 651 use Contact header parameters as defined in the Connection Re-use 652 draft [13]. This creates an association tuple as described in the 653 previous example for future inbound requests directed at the newly 654 created registration binding with the only difference that the 655 association is with a TCP connection, not a UDP pin hole binding. 657 [Editors note: Will provide more details on heartbeat mechanism in 658 next revision] 660 [Editors note: Can complete full flows on inclusion of heartbeat 661 mechanism] 663 4.1.2. Registration(Registrar/Proxy not Co-Located) 665 This section demonstrates traversal mechanisms when the Registrar 666 component is not co-located with the edge proxy element. The 667 procedures described in this section are identical, regardless of 668 transport protocol and so only one example will be documented in the 669 form of TCP. 671 Client NAT Proxy Registrar 672 | | | | 673 |(1) REGISTER | | | 674 |----------------->| | | 675 | | | | 676 | |(1) REGISTER | | 677 | |----------------->| | 678 | | | | 679 | | |(2) REGISTER | 680 | | |----------------->| 681 | | | | 682 | | |(3) 401 Unauth | 683 | | |<-----------------| 684 | | | | 685 | |(4) 401 Unauth | | 686 | |<-----------------| | 687 | | | | 688 |(4)401 Unauth | | | 689 |<-----------------| | | 690 | | | | 691 |(5)REGISTER | | | 692 |----------------->| | | 693 | | | | 694 | |(5)REGISTER | | 695 | |----------------->| | 696 | | | | 697 | | |(6)REGISTER | 698 | | |----------------->| 699 | | | | 700 | | |(7)200 OK | 701 | | |<-----------------| 702 | | | | 703 |********************************************************| 704 | Create Connection Re-use Tuple | 705 |********************************************************| 706 | | | | 707 | |(8)200 OK | | 708 | |<-----------------| | 709 | | | | 710 |(8)200 OK | | | 711 |<-----------------| | | 712 | | | | 714 Figure 7. 716 This scenario builds on the previous example contained in 717 Section 4.1.1.2. The primary difference being that the REGISTER 718 request is routed onwards from a Proxy Server to a separated 719 Registrar. The important message to note is (6) in Figure 7. The 720 Edge proxy, on receiving a REGISTER request that contains a 721 'sip.instance' media feature tag, forms a unique flow identifier 722 token as discussed in [13] . At this point, the proxy server routes 723 the SIP REGISTER message to the Registrar. The proxy will create the 724 connection tuple as described in SIP Outbound at the same moment as 725 the co-located example, but for subsequent messages to arrive at the 726 Proxy, the element needs to request to remain in the signaling path. 727 To achieve this the proxy inserts to REGISTER message (5) a SIP PATH 728 extension header, as defined in RFC 3327 [7]. The previously created 729 flow token is inserted in a position within the Path header where it 730 can easily be retrieved at a later point when receiving messages to 731 be routed to the registration binding. REGISTER message (5) would 732 look as follows: 734 REGISTER sip:registrar.example.com SIP/2.0 735 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4njkca8398hadjaa 736 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKyilassjdshfu 737 Max-Forwards: 70 738 Supported: path,gruu 739 From: Client ;tag=djks809834 740 To: Client 741 Call-ID: 763hdc783hcnam73@example.com 742 CSeq: 1 REGISTER 743 Path: 744 Contact: ; 745 ;+sip.instance="";reg-id=1 746 Content-Length: 0 748 This REGISTER request results in the Path header being stored along 749 with the AOR and it's associated binding at the Registrar. The URI 750 contained in the Path header will be inserted as a pre-loaded SIP 751 'Route' header into any request that arrives at the Registrar and is 752 directed towards the associated binding. This guarantees that all 753 requests for the new Registration will be forwarded to the Edge 754 Proxy. In our example, the user part of the SIP 'Path' header URI 755 that was inserted by the Edge Proxy contains the unique token 756 identifying the flow to the client. On receiving subsequent 757 requests, the edge proxy will examine the user part of the pre-loaded 758 SIP 'route' header and extract the unique flow token for use in its 759 connection tuple comparison, as defined in the SIP Outbound 760 specification [13]. An example which builds on this scenario 761 (showing an inbound request to the AOR) is detailed in section 762 4.1.4.2 of this document. 764 4.1.3. Initiating a Session 766 This section covers basic SIP signaling when initiating a call from 767 behind a NAT. 769 4.1.3.1. UDP 771 Initiating a call using UDP. 773 Client NAT Proxy [..] 774 | | | 775 |(1) INVITE | | | 776 |----------------->| | | 777 | | | | 778 | |(1) INVITE | | 779 | |----------------->| | 780 | | | | 781 | |(2) 407 Unauth | | 782 | |<-----------------| | 783 | | | | 784 |(2) 407 Unauth | | | 785 |<-----------------| | | 786 | | | | 787 |(3) INVITE | | | 788 |----------------->| | | 789 | | | | 790 | |(3) INVITE | | 791 | |----------------->| | 792 | | | | 793 | | |(4) INVITE | 794 | | |---------------->| 795 | | | | 796 | | |(5)180 RINGING | 797 | | |<----------------| 798 | | | | 799 | |(6)180 RINGING | | 800 | |<-----------------| | 801 | | | | 802 |(6)180 RINGING | | | 803 |<-----------------| | | 804 | | | | 805 | | |(7)200 OK | 806 | | |<----------------| 807 | | | | 808 | |(8)200 OK | | 809 | |<-----------------| | 810 | | | | 811 |(8)200 OK | | | 812 |<-----------------| | | 813 | | | | 814 |(9)ACK | | | 815 |----------------->| | | 816 | | | | 817 | |(9)ACK | | 818 | |----------------->| | 819 | | | | 820 | | |(10) ACK | 821 | | |---------------->| 822 | | | | 824 Figure 8. 826 The initiating client generates an INVITE request that is to be sent 827 through the NAT to a Proxy server. The INVITE message is represented 828 in Figure 8 by (1) and is as follows: 830 INVITE sip:clientB@example.com SIP/2.0 831 Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK74husdHG 832 Max-Forwards: 70 833 Route: 834 From: clientA ;tag=7skjdf38l 835 To: clientB 836 Call-ID: 8327468763423@example.com 837 CSeq: 1 INVITE 838 Contact: 840 Content-Type: application/sdp 841 Content-Length: .. 843 [SDP not shown] 845 There are a number of points to note with this message: 846 1. Firstly, as with the registration example in Section 4.1.1.1, 847 responses to this request will not automatically pass back 848 through a NAT and so the SIP 'Via' header 'rport' is included as 849 described in the 'Symmetric response' Section 3.1.1 and defined 850 in RFC 3581 [6]. 851 2. Secondly, the contact inserted contains the GRUU previously 852 obtained from the SIP 200 OK response to the registration. Use 853 of the GRUU ensures that any SIP requests within the dialog that 854 in the opposite direction will be able to traverse the NAT. This 855 occurs using the mechanisms defined in the SIP Outbound 856 specification[13]. A request arriving at the entity which 857 resolves to the GRUU is then able to determine a previously 858 registered connection that will allow the request to traverse the 859 NAT and reach the intended endpoint. 861 4.1.3.2. Reliable Transport 863 When using a reliable transport such as TCP the call flow and 864 procedures for traversing a NAT are almost identical to those 865 described in Section 4.1.3.1. The primary difference when using 866 reliable transport protocols is that Symmetric response[6] are not 867 required for SIP responses to traverse a NAT. RFC 3261[1] defines 868 procedures for SIP response messages to be sent back on the same 869 connection on which the request arrived. 871 4.1.4. Receiving an Invitation to a Session 873 This section details scenarios where a client behind a NAT receives 874 an inbound request through a NAT. These scenarios build on the 875 previous registration scenario from Section 4.1.1 and Section 4.1.2 876 in this document. 878 4.1.4.1. Registrar/Proxy Co-located 880 The core SIP signaling associated with this call flow is not impacted 881 directly by the transport protocol and so only one example scenario 882 is necessary. The example uses UDP and follows on from the 883 registration installed in the example from Section 4.1.1.1. 885 Client NAT Registrar/Proxy SIP Entity 886 | | | | 887 |*******************************************************| 888 | Registration Binding Installed in | 889 | section 4.1.1.1 | 890 |*******************************************************| 891 | | | | 892 | | |(1)INVITE | 893 | | |<----------------| 894 | | | | 895 | |(2)INVITE | | 896 | |<-----------------| | 897 | | | | 898 |(2)INVITE | | | 899 |<-----------------| | | 900 | | | | 901 | | | | 903 Figure 9. 905 An INVITE request arrives at the Registrar with a destination 906 pointing to the AOR of that inserted in section 4.1.1.1. The message 907 is illustrated by (1) in Figure 9 and looks as follows: 909 INVITE sip:client@example.com SIP/2.0 910 Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d 911 Max-Forwards: 70 912 From: External ;tag=7893hd 913 To: client 914 Call-ID: 8793478934897@external.example.com 915 CSeq: 1 INVITE 916 Contact: 917 Content-Type: application/sdp 918 Content-Length: .. 920 [SDP not shown] 922 The INVITE request matches the registration binding previously 923 installed at the Registrar and the INVITE request-URI is re-written 924 to the selected onward address. The proxy then examines the request 925 URI of the INVITE and compares with its list of current open flows. 926 It uses the incoming AOR to commence the check for associated open 927 connections/mappings. Once matched, the proxy checks to see if the 928 unique instance identifier (+sip.instance) associated with the 929 binding equals the same instance identifier associated with the flow. 930 The request is then dispatched on the appropriate flow. This is 931 message (2) from Figure 9 and is as follows: 933 INVITE sip:sip:client@client.example.com SIP/2.0 934 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4kmlds893jhsd 935 Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d 936 Max-Forwards: 70 937 From: External ;tag=7893hd 938 To: client 939 Call-ID: 8793478934897@external.example.com 940 CSeq: 1 INVITE 941 Contact: 942 Content-Type: application/sdp 943 Content-Length: .. 945 [SDP not shown] 947 It is a standard SIP INVITE request with no additional functionality. 948 The major difference being that this request will not follow the 949 address specified in the Request-URI, as standard SIP rules would 950 enforce but will be sent on the flow associated with the registration 951 binding (look-up procedures in RFC 3263 [6] are overridden). This 952 then allows the original connection/mapping from the initial 953 registration process to be re-used. 955 4.1.4.2. Registrar/Proxy Not Co-located 956 Client NAT Proxy Registrar SIP Entity 957 | | | | | 958 |***********************************************************| 959 | Registration Binding Installed in | 960 | section 4.1.2 | 961 |***********************************************************| 962 | | | | | 963 | | | |(1)INVITE | 964 | | | |<-------------| 965 | | | | | 966 | | |(2)INVITE | | 967 | | |<-------------| | 968 | | | | | 969 | |(3)INVITE | | | 970 | |<-------------| | | 971 | | | | | 972 |(3)INVITE | | | | 973 |<-------------| | | | 974 | | | | | 975 | | | | | 977 Figure 9. 979 4.2. Basic NAT Media Traversal 981 This section provides example scenarios to demonstrate basic media 982 traversal using the techniques outlined earlier in this document. 984 In the flow diagrams STUN messages have been annotated for simplicity 985 as follows: 986 o The "Src" attribute represents the source transport address of the 987 message. 988 o The "Dest" attribute represents the destination transport address 989 of the message. 990 o The "Map" attribute represents the reflexive transport address. 991 o The "Rel" attribute represents the relayed transport address. 993 The meaning of each STUN attribute is extensively explained in the 994 core STUN[10] and TURN usage[12] drafts. 996 The examples also contain a mechanism for representing transport 997 addresses. It would be confusing to include representations of 998 network addresses in the call flows and make them hard to follow. 999 For this reason network addresses will be represented using the 1000 following annotation. The first component will contain the a 1001 representation of the client responsible for the address. For 1002 example in the majority of the examples "L" (left client), "R" (right 1003 client), NAT-PUB" (NAT public), PRIV (Private), and "STUN-PUB" (STUN 1004 Public) are used. To allow for multiple addresses from the same 1005 network element, each representation can also be followed by a 1006 number. These can also be used in combination. For example "L-NAT- 1007 PUB-1" would represent a public network address on the left hand side 1008 NAT while "R-NAT-PUB-1" would represent a public network address in 1009 the right hand side of the NAT. "L-PRIV-1" would represent a private 1010 network address on the left hand side of the NAT while "R-PRIV-1" 1011 represents a private address on the right hand side of the NAT. 1013 It should also be noted that during the examples it might be 1014 appropriate to signify an explicit part of a transport address. This 1015 is achieved by adding either the '.address' or '.port' tag on the end 1016 of the representation. For example, 'L-PRIV-1.address' and 'L-PRIV- 1017 1.port'. 1019 4.2.1. Endpoint independent NAT 1021 This section demonstrates an example of a client both initiating and 1022 receiving calls behind an 'Endpoint independent' NAT. An example is 1023 included for both STUN and ICE with ICE being the RECOMMENDED 1024 mechanism for media traversal. 1026 4.2.1.1. STUN Solution 1028 It is possible to traverse media through an 'Endpoint Independent NAT 1029 using STUN. The remainder of this section provides a simplified 1030 examples of the 'Binding Discovery' STUN usage as defined in [10]. 1031 The STUN messages have been simplified and do not include 'Shared 1032 Secret' requests used to obtain the temporary username and password. 1034 [Editors Note: Expand to show full flow in including Auth?.] 1036 4.2.1.1.1. Initiating Session 1038 The following example demonstrates media traversal through a NAT 1039 demonstrating 'Address Independent' NAT behavior using STUN. It is 1040 assumed in this example that the STUN client and SIP Client are co- 1041 located on the same machine. Note that some SIP signalling messages 1042 have been left out for simplicity. 1044 Client NAT STUN [..] 1045 Server 1046 | | | | 1047 |(1) STUN Req | | | 1048 |Src=L-PRIV-1 | | | 1049 |Dest=STUN-PUB | | | 1050 |----------------->| | | 1051 | | | | 1052 | |(2) STUN Req | | 1053 | |Src=NAT-PUB-1 | | 1054 | |Dest=STUN-PUB | | 1055 | |----------------->| | 1056 | | | | 1057 | |(3) STUN Resp | | 1058 | |<-----------------| | 1059 | |Src=STUN-PUB | | 1060 | |Dest=NAT-PUB-1 | | 1061 | |Map=NAT-PUB-1 | | 1062 | | | | 1063 |(4) STUN Resp | | | 1064 |<-----------------| | | 1065 |Src=STUN-PUB | | | 1066 |Dest=L-PRIV-1 | | | 1067 |Map=NAT-PUB-1 | | | 1068 | | | | 1069 |(5) STUN Req | | | 1070 |Src=L-PRIV-2 | | | 1071 |Dest=STUN-PUB | | | 1072 |----------------->| | | 1073 | | | | 1074 | |(6) STUN Req | | 1075 | |Src=NAT-PUB-2 | | 1076 | |Dest=STUN-PUB | | 1077 | |----------------->| | 1078 | | | | 1079 | |(7) STUN Resp | | 1080 | |<-----------------| | 1081 | |Src=STUN-PUB | | 1082 | |Dest=NAT-PUB-2 | | 1083 | |Map=NAT-PUB-2 | | 1084 | | | | 1085 |(8) STUN Resp | | | 1086 |<-----------------| | | 1087 |Src=STUN-PUB | | | 1088 |Dest=L-PRIV-2 | | | 1089 |Map=NAT-PUB-2 | | | 1090 | | | | 1091 |(9)SIP INVITE | | | 1092 |----------------->| | | 1093 | | | | 1094 | |(10)SIP INVITE | | 1095 | |------------------------------------>| 1096 | | | | 1097 | | |(11)SIP 200 OK | 1098 | |<------------------------------------| 1099 | | | | 1100 |(12)SIP 200 OK | | | 1101 |<-----------------| | | 1102 | | | | 1103 |========================================================| 1104 |>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>| 1105 |========================================================| 1106 | | 1107 |========================================================| 1108 |<<<<<<<<<<<>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>| 1113 |========================================================| 1114 | | 1115 |========================================================| 1116 |<<<<<<<<<<<| | | 1121 | | | | 1122 | |(14) SIP ACK | | 1123 | |------------------------------------>| 1124 | | | | 1126 Figure 18: Address and Port Dependant NAT with STUN - Initiating 1128 o On deciding to initiate a SIP voice session the client starts a 1129 local STUN client on the interface and port that is to be used for 1130 media (send/receive). The STUN client generates a standard STUN 1131 request as indicated in (1) from Figure 18 which also highlights 1132 the source address and port for which the client device wishes to 1133 obtain a mapping. The STUN request is sent through the NAT 1134 towards the public internet and STUN server. 1135 o STUN message (2) traverses the NAT and breaks out onto the public 1136 internet towards the public STUN server. Note that the source 1137 address of the STUN requests now represents the public address and 1138 port from the public side of the NAT. 1139 o The STUN server receives the request and processes it 1140 appropriately. This results in a successful STUN response being 1141 generated and returned (3). The message contains details of the 1142 mapped public address (contained in the STUN MAPPED-ADDRESS 1143 attribute) which is to be used by the originating client to 1144 receive media (see 'Map=NAT-PUB-1' from (3)). 1145 o The STUN response traverses back through the NAT using the binding 1146 created by the STUN request and presents the new mapped address to 1147 the client (4). At this point the process is repeated to obtain a 1148 second mapped address (as shown in (5)-(8)) for an alternative 1149 local address (Address has changed from "L-PRIV-1" to "L-PRIV-2"). 1150 o The client now constructs a SIP INVITE message(9). Note that 1151 traversal of SIP is not covered in this example and is discussed 1152 in earlier sections of the document. The INVITE request will use 1153 the addresses it has obtained in the previous STUN transactions to 1154 populate the SDP of the SIP INVITE as shown below: 1156 v=0 1157 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address 1158 c=IN IP4 $NAT-PUB-1.address 1159 t=0 0 1160 m=audio $NAT-PUB-1.port RTP/AVP 0 1161 a=rtcp:$NAT-PUB-2.port 1163 o Note that the mapped address obtained from the STUN transactions 1164 are inserted as the connection address for the SDP (c=NAT-PUB- 1165 1.address). The Primary port for RTP is also inserted in the SDP 1166 (m=audio NAT-PUB-1.port RTP/AVP 0). Finally, the port gained from 1167 the additional STUN binding is placed in the RTCP attribute (as 1168 discussed in Section 3.2.1.1) for traversal of RTCP (a=rtcp:NAT- 1169 PUB-2.port). 1170 o The SIP signalling then traverses the NAT and sets up the SIP 1171 session (10-12). Note that the client transmits media as soon as 1172 the 200 OK to the INVITE arrives at the client (12). Up until 1173 this point the incoming media and RTCP will not pass through the 1174 NAT as no outbound association has been created with the far end 1175 client. Two way media communication has now been established. 1177 4.2.1.1.2. Receiving Session Invitation 1179 Receiving a session for an 'Address and Port dependant' NAT using 1180 STUN is very similar to the example outlined in Section 4.2.1.1.1. 1181 Figure 20 illustrates the associated flow of messages. 1183 Client NAT STUN [..] 1184 Server 1185 | | | (1)SIP INVITE | 1186 | |<-----------------|------------------| 1187 | | | | 1188 |(2) SIP INVITE | | | 1189 |<-----------------| | | 1190 | | | | 1191 |(3) STUN Req | | | 1192 |Src=L-PRIV-1 | | | 1193 |Dest=STUN-PUB | | | 1194 |----------------->| | | 1195 | | | | 1196 | |(4) STUN Req | | 1197 | |Src=NAT-PUB-1 | | 1198 | |Dest=STUN-PUB | | 1199 | |----------------->| | 1200 | | | | 1201 | |(5) STUN Resp | | 1202 | |<-----------------| | 1203 | |Src=STUN-PUB | | 1204 | |Dest=NAT-PUB-1 | | 1205 | |Map=NAT-PUB-1 | | 1206 | | | | 1207 |(6) STUN Resp | | | 1208 |<-----------------| | | 1209 |Src=STUN-PUB | | | 1210 |Dest=L-PRIV-1 | | | 1211 |Map=NAT-PUB-1 | | | 1212 | | | | 1213 |(7) STUN Req | | | 1214 |Src=L-PRIV-2 | | | 1215 |Dest=STUN-PUB | | | 1216 |----------------->| | | 1217 | | | | 1218 | |(8) STUN Req | | 1219 | |Src=NAT-PUB-2 | | 1220 | |Dest=STUN-PUB | | 1221 | |----------------->| | 1222 | | | | 1223 | |(9) STUN Resp | | 1224 | |<-----------------| | 1225 | |Src=STUN-PUB | | 1226 | |Dest=NAT-PUB-2 | | 1227 | |Map=NAT-PUB-2 | | 1228 | | | | 1229 |(10) STUN Resp | | | 1230 |<-----------------| | | 1231 |Src=STUN-PUB | | | 1232 |Dest=L-PRIV-2 | | | 1233 |Map=NAT-PUB-2 | | | 1234 | | | | 1235 |(11)SIP 200 OK | | | 1236 |----------------->| | | 1237 | |(12)SIP 200 OK | | 1238 | |------------------------------------>| 1239 | | | | 1240 |========================================================| 1241 |>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>| 1242 |========================================================| 1243 | | | | 1244 |========================================================| 1245 |<<<<<<<<>><<>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>| 1250 |========================================================| 1251 | | | | 1252 |========================================================| 1253 |<<<<<<<<<<<<| | | | 1342 | | | | | 1343 | |(2) Alloc Req | | | 1344 | |Src=L-NAT-PUB-1 | | | 1345 | |Des=STUN-PUB-1 | | | 1346 | |--------------->| | | 1347 | | | | | 1348 | |(3) Alloc Resp | | | 1349 | |<---------------| | | 1350 | |Src=STUN-PUB-1 | | | 1351 | |Dest=L-NAT-PUB-1| | | 1352 | |Map=L-NAT-PUB-1 | | | 1353 | |Rel=STUN-PUB-2 | | | 1354 | | | | | 1355 |(4) Alloc Resp | | | | 1356 |<---------------| | | | 1357 |Src=STUN-PUB-1 | | | | 1358 |Dest=L-PRIV-1 | | | | 1359 |Map=L-NAT-PUB-1 | | | | 1360 |Rel=STUN-PUB-2 | | | | 1361 | | | | | 1362 |(5) STUN Req | | | | 1363 |Src=L-PRIV-2 | | | | 1364 |Dest=STUN-PUB-1 | | | | 1365 |--------------->| | | | 1366 | | | | | 1367 | |(6) Alloc Req | | | 1368 | |Src=L-NAT-PUB-2 | | | 1369 | |Dest=STUN-PUB-1 | | | 1370 | |--------------->| | | 1371 | | | | | 1372 | |(7) Alloc Resp | | | 1373 | |<---------------| | | 1374 | |Src=STUN-PUB-1 | | | 1375 | |Dest=NAT-PUB-2 | | | 1376 | |Map=NAT-PUB-2 | | | 1377 | |Rel=STUN-PUB-3 | | | 1378 | | | | | 1379 |(8) Alloc Resp | | | | 1380 |<---------------| | | | 1381 |Src=STUN-PUB-1 | | | | 1382 |Dest=L-PRIV-2 | | | | 1383 |Map=L-NAT-PUB-2 | | | | 1384 |Rel=STUN-PUB-3 | | | | 1385 | | | | | 1386 |(9) SIP INVITE | | | | 1387 |------------------------------------------------->| | 1388 | | | | | 1389 | | | |(10) SIP INVITE | 1390 | | | |--------------->| 1391 | | | | | 1392 | | | |(11) Alloc Req | 1393 | | | |<---------------| 1394 | | | |Src=R-PRIV-1 | 1395 | | | |Dest=STUN-PUB-1 | 1396 | | | | | 1397 | | |(12) Alloc Req | | 1398 | | |<---------------| | 1399 | | |Src=R-NAT-PUB-1 | | 1400 | | |Dest=STUN-PUB-1 | | 1401 | | | | | 1402 | | |(13) Alloc Res | | 1403 | | |--------------->| | 1404 | | |Src=STUN-PUB-1 | | 1405 | | |Dest=R-NAT-PUB-1| | 1406 | | |Map=R-NAT-PUB-1 | | 1407 | | |Rel=STUN-PUB-4 | | 1408 | | | | | 1409 | | | |(14) Alloc Res | 1410 | | | |--------------->| 1411 | | | |Src=STUN-PUB-1 | 1412 | | | |Dest=R-PRIV-1 | 1413 | | | |Map=R-NAT-PUB-1 | 1414 | | | |Rel=STUN-PUB-4 | 1415 | | | | | 1416 | | | |(15) Alloc Req | 1417 | | | |<---------------| 1418 | | | |Src=R-PRIV-2 | 1419 | | | |Dest=STUN-PUB-1 | 1420 | | | | | 1421 | | |(16) Alloc Req | | 1422 | | |<---------------| | 1423 | | |Src=R-NAT-PUB-2 | | 1424 | | |Dest=STUN-PUB-1 | | 1425 | | | | | 1426 | | |(17) Alloc Res | | 1427 | | |--------------->| | 1428 | | |Src=STUN-PUB-1 | | 1429 | | |Dest=R-NAT-PUB-2| | 1430 | | |Map=R-NAT-PUB-2 | | 1431 | | |Rel=STUN-PUB-5 | | 1432 | | | | | 1433 | | | |(18) Alloc Res | 1434 | | | |--------------->| 1435 | | | |Src=STUN-PUB-1 | 1436 | | | |Dest=R-PRIV-2 | 1437 | | | |Map=R-NAT-PUB-2 | 1438 | | | |Rel=STUN-PUB-5 | 1439 | | | | | 1440 | | | |(19) SIP 200 OK | 1441 | |<-------------------------------------------------| 1442 | | | | | 1443 |(20) SIP 200 OK | | | | 1444 |<---------------| | | | 1445 | | | | | 1446 |(21) SIP ACK | | | | 1447 |------------------------------------------------->| | 1448 | | | | | 1449 | | | |(22) SIP ACK | 1450 | | | |--------------->| 1451 | | | | | 1452 |(23) Bind Req | | | | 1453 |------------------------>x | | | 1454 |Src=L-PRIV-1 | | | | 1455 |Dest=R-PRIV-1 | | | | 1456 | | | | | 1457 |(24) Bind Req | | | | 1458 |--------------->| | | | 1459 |Src=L-PRIV-1 | | | | 1460 |Dest=R-NAT-PUB-1| | | | 1461 | | | | | 1462 | |(25) Bind Req | | | 1463 | |-------------------------------->| | 1464 | |Src=L-NAT-PUB-1 | | | 1465 | |Dest=R-NAT-PUB-1| | | 1466 | | | | | 1467 | | | |(26) Bind Req | 1468 | | | |--------------->| 1469 | | | |Src=L-NAT-PUB-1 | 1470 | | | |Dest=R-PRIV-1 | 1471 | | | | | 1472 | | | |(27) Bind Res | 1473 | | | |<---------------| 1474 | | | |Src=R-PRIV-1 | 1475 | | | |Dest=L-NAT-PUB-1| 1476 | | | |Map=L-NAT-PUB-1 | 1477 | | | | | 1478 | | |(28) Bind Res | | 1479 | |<--------------------------------| | 1480 | | |Src=R-NAT-PUB-1 | | 1481 | | |Dest=L-NAT-PUB-1| | 1482 | | |Map=L-NAT-PUB-1 | | 1483 | | | | | 1484 |(29) Bind Res | | | | 1485 |<---------------| | | | 1486 |Src=R-NAT-PUB-1 | | | | 1487 |Dest=L-PRIV-1 | | | | 1488 |Map=L-NAT-PUB-1 | | | | 1489 | | | | | 1490 |===================================================================| 1491 |>>>>>>>>>>>>>>>>>>>>>Outgoing RTP sent from >>>>>>>>>>>>>>>>>>>>>>>| 1492 |===================================================================| 1493 | | | | | 1494 | | | |(30) Bind Req | 1495 | | | x<-----------------------| 1496 | | | |Src=R-PRIV-1 | 1497 | | | |Dest=L-PRIV-1 | 1498 | | | | | 1499 | | | |(31) Bind Req | 1500 | | | |<---------------| 1501 | | | |Src=R-PRIV-1 | 1502 | | | |Dest=L-NAT-PUB-1| 1503 | | | | | 1504 | | |(32) Bind Req | | 1505 | |<--------------------------------| | 1506 | | |Src=R-NAT-PUB-1 | | 1507 | | |Dest=L-NAT-PUB-1| | 1508 | | | | | 1509 |(33) Bind Req | | | | 1510 |<---------------| | | | 1511 |Src=R-NAT-PUB-1 | | | | 1512 |Dest=L-PRIV-1 | | | | 1513 | | | | | 1514 |(34) Bind Res | | | | 1515 |--------------->| | | | 1516 |Src=L-PRIV-1 | | | | 1517 |Dest=R-NAT-PUB-1| | | | 1518 |Map=R-NAT-PUB-1 | | | | 1519 | | | | | 1520 | |(35) Bind Res | | | 1521 | |-------------------------------->| | 1522 | |Src=L-NAT-PUB-1 | | | 1523 | |Dest=R-NAT-PUB-1| | | 1524 | |Map=R-NAT-PUB-1 | | | 1525 | | | | | 1526 | | | |(36) Bind Res | 1527 | | | |--------------->| 1528 | | | |Src=L-NAT-PUB-1 | 1529 | | | |Dest=R-PRIV-1 | 1530 | | | |Map=R-NAT-PUB-1 | 1531 | | | | | 1532 |===================================================================| 1533 |<<<<<<<<<<<<<<<<<<<<| | | | 1538 |Src=L-PRIV-2 | | | | 1539 |Dest=R-NAT-PUB-2| | | | 1540 | | | | | 1541 | |(38) Bind Req | | | 1542 | |-------------------------------->| | 1543 | |Src=L-NAT-PUB-2 | | | 1544 | |Dest=R-NAT-PUB-2| | | 1545 | | | | | 1546 | | | |(39) Bind Req | 1547 | | | |--------------->| 1548 | | | |Src=L-NAT-PUB-2 | 1549 | | | |Dest=R-PRIV-2 | 1550 | | | | | 1551 | | | |(40) Bind Res | 1552 | | | |<---------------| 1553 | | | |Src=R-PRIV-2 | 1554 | | | |Dest=L-NAT-PUB-2| 1555 | | | |Map=L-NAT-PUB-2 | 1556 | | | | | 1557 | | |(41) Bind Res | | 1558 | |<--------------------------------| | 1559 | | |Src=R-NAT-PUB-2 | | 1560 | | |Dest=L-NAT-PUB-2| | 1561 | | |Map=L-NAT-PUB-2 | | 1562 | | | | | 1563 |(42) Bind Res | | | | 1564 |<---------------| | | | 1565 |Src=R-NAT-PUB-2 | | | | 1566 |Dest=L-PRIV-2 | | | | 1567 |Map=L-NAT-PUB-2 | | | | 1568 | | | | | 1569 |===================================================================| 1570 |>>>>>>>>>>>>>>>>>>>>>Outgoing RTCP sent from >>>>>>>>>>>>>>>>>>>>>>| 1571 |===================================================================| 1572 | | | | | 1573 | | | |(43) Bind Req | 1574 | | | |<---------------| 1575 | | | |Src=R-PRIV-2 | 1576 | | | |Dest=L-NAT-PUB-2| 1577 | | | | | 1578 | | |(44) Bind Req | | 1579 | |<--------------------------------| | 1580 | | |Src=R-NAT-PUB-2 | | 1581 | | |Dest=L-NAT-PUB-2| | 1582 | | | | | 1583 |(45) Bind Req | | | | 1584 |<---------------| | | | 1585 |Src=R-NAT-PUB-2 | | | | 1586 |Dest=L-PRIV-2 | | | | 1587 | | | | | 1588 |(46) Bind Res | | | | 1589 |--------------->| | | | 1590 |Src=L-PRIV-2 | | | | 1591 |Dest=R-NAT-PUB-2| | | | 1592 |Map=R-NAT-PUB-2 | | | | 1593 | | | | | 1594 | |(47) Bind Res | | | 1595 | |-------------------------------->| | 1596 | |Src=L-NAT-PUB-2 | | | 1597 | |Dest=R-NAT-PUB-2| | | 1598 | |Map=R-NAT-PUB-2 | | | 1599 | | | | | 1600 | | | |(48) Bind Res | 1601 | | | |--------------->| 1602 | | | |Src=L-NAT-PUB-2 | 1603 | | | |Dest=R-PRIV-2 | 1604 | | | |Map=R-NAT-PUB-2 | 1605 | | | | | 1606 |===================================================================| 1607 |<<<<<<<<<<<<<<<<<<<<| | 1612 | | | | | 1613 | | | |(50) SIP INVITE | 1614 | | | |--------------->| 1615 | | | | | 1616 | | | |(51) SIP 200 OK | 1617 | |<-------------------------------------------------| 1618 | | | | | 1619 |(52) SIP 200 OK | | | | 1620 |<---------------| | | | 1621 | | | | | 1622 |(53) SIP ACK | | | | 1623 |------------------------------------------------->| | 1624 | | | | | 1625 | | | |(54) SIP ACK | 1626 | | | |--------------->| 1627 | | | | | 1629 Figure 22: Endpoint Independent NAT with ICE 1631 o On deciding to initiate a SIP voice session the SIP client 'L' 1632 starts a local STUN client. The STUN client generates a standard 1633 Allocate request as indicated in (1) from Figure 22 which also 1634 highlights the source address and port combination for which the 1635 client device wishes to obtain a mapping. The STUN request is 1636 sent through the NAT towards the public internet. 1637 o Allocate message (2) traverses the NAT and breaks out onto the 1638 public internet towards the public STUN server. Note that the 1639 source address of the Allocate request now represents the public 1640 address and port from the public side of the NAT (L-NAT-PUB-1). 1641 o The STUN server receives the Allocate request and processes 1642 appropriately. This results in a successful Allocate response 1643 being generated and returned (3). The message contains details of 1644 the reflexive address which is to be used by the originating 1645 client to receive media (see 'Map=L-NAT-PUB-1') from (3)). It 1646 also contains an appropriate relay address that can be used at the 1647 STUN server (see 'Rel=STUN-PUB-2'). 1648 o The STUN response traverses back through the NAT using the binding 1649 created by the initial Allocate request and presents the new 1650 mapped address to the client (4). The process is repeated and a 1651 second STUN derived set of address' are obtained, as illustrated 1652 in (5)-(8) in Figure 22. At this point the User Agent behind the 1653 NAT has pairs of derived external reflexive and relayed 1654 representations. The client would be free to gather any number of 1655 external representations using any UNSAF[9] compliant protocol. 1656 o The client now constructs a SIP INVITE message (9). The INVITE 1657 request will use the addresses it has obtained in the previous 1658 STUN/TURN interactions to populate the SDP of the SIP INVITE. 1659 This should be carried out in accordance with the semantics 1660 defined in the ICE specification[16], as shown below in Figure 23 1661 (*note - /* signifies line continuation): 1663 v=0 1664 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1 1665 c=IN IP4 $L-PRIV-1.address 1666 t=0 0 1667 a=ice-pwd:$LPASS 1668 m=audio $L-PRIV-1.port RTP/AVP 0 1669 a=rtpmap:0 PCMU/8000 1670 a=rtcp:$L-PRIV-2.port 1671 a=candidate:$L1 1 UDP 1.0 $L-PRIV-1.address $L-PRIV-1.port 1672 a=candidate:$L1 2 UDP 1.0 $L-PRIV-2.address $L-PRIV-2.port 1673 a=candidate:$L2 1 UDP 0.7 $L-NAT-PUB-1.address $L-NAT-PUB-1.port 1674 a=candidate:$L2 2 UDP 0.7 $L-NAT-PUB-2.address $L-NAT-PUB-2.port 1675 a=candidate:$L3 1 UDP 0.3 $STUN-PUB-2.address $STUN-PUB-2.port 1676 a=candidate:$L3 2 UDP 0.3 $STUN-PUB-3.address $STUN-PUB-3.port 1678 Figure 23: ICE SDP Offer 1680 o The SDP has been constructed to include all the available 1681 candidate pairs that have been assembled. The first candidate 1682 pair (as identified by $L1) contain two local addresses that have 1683 the highest priority (1.0). They are also encoded into the 1684 connection (c=) and media (m=) lines of the SDP. The second 1685 'candidate' address pair, as identified by the component-id, 1686 contains the two NAT reflexive addresses obtained from the STUN 1687 server for both RTP and RTCP traffic (identified by candidate-id 1688 $L2). This entry has been given a priority (0.7) by the client. 1689 The third and final candidate pair represents the relayed 1690 addresses (as identified by $L3) obtained from the STUN server. 1691 This pair has the lowest priority (0.3) and will be used as a last 1692 resort. 1693 o The SIP signalling then traverses the NAT and sets up the SIP 1694 session (9)-(10). On advertising a candidate address, the client 1695 should have a local STUN server running on each advertised 1696 candidate address. This is for the purpose of responding to 1697 incoming connectivity checks. 1698 o On receiving the SIP INVITE request (10) client 'R' also starts 1699 local STUN servers on appropriate address/port combinations and 1700 gathers potential candidate addresses to be encoded into the SDP. 1701 Steps (11-18) involve client 'R' carrying out the same steps as 1702 client 'L'. This involves obtaining local, reflexive and relayed 1703 addresses. Client 'R' is now ready to generate an appropriate 1704 answer in the SIP 200 OK message (19). The example answer follows 1705 in Figure 23 (*note - /* signifies line continuation): 1707 v=0 1708 o=test 3890844516 3890842803 IN IP4 $R-PRIV-1 1709 c=IN IP4 $R-PRIV-1.address 1710 t=0 0 1711 a=ice-pwd:$RPASS 1712 m=audio $R-PRIV-1.port RTP/AVP 0 1713 a=rtpmap:0 PCMU/8000 1714 a=rtcp:$R-PRIV-2.port 1715 a=candidate:$L1 1 UDP 1.0 $R-PRIV-1.address $R-PRIV-1.port 1716 a=candidate:$L1 2 UDP 1.0 $R-PRIV-2.address $R-PRIV-2.port 1717 a=candidate:$L2 1 UDP 0.7 $R-NAT-PUB-1.address $R-NAT-PUB-1.port 1718 a=candidate:$L2 2 UDP 0.7 $R-NAT-PUB-2.address $R-NAT-PUB-2.port 1719 a=candidate:$L3 1 UDP 0.3 $STUN-PUB-2.address $STUN-PUB-4.port 1720 a=candidate:$L3 2 UDP 0.3 $STUN-PUB-3.address $STUN-PUB-5.port 1722 Figure 24: ICE SDP Answer 1724 o The two clients will now form candidate pairs and the transport 1725 address check list as specified in ICE. Both 'L' and 'R' will 1726 start the check list with the currently active component pair 1727 (contained in the 'c=' and 'm=' of the SDP). As illustrated in 1728 (23), client 'L' constructs a STUN Bind request in an attempt to 1729 validate the connection address received in the SDP of the 200 OK 1730 (20). As a private address was specified in the active address in 1731 the SDP, the Stun Bind request fails to reach its destination 1732 causing a bind failure. Client 'L' now attempts a STUN Bind 1733 request for the first candidate pair in the returned SDP with the 1734 highest priority (24). As can be seen from messages (24) to (29), 1735 the STUN Bind request is successful and returns a positive outcome 1736 for the connectivity check. Client 'L' is now free to steam media 1737 to the candidate pair. Client 'R' also carries out the same set 1738 of binding requests. It firstly (in parallel) tries to contact 1739 the active address contained in the SDP (30). Client 'R' now 1740 attempts a STUN Bind request for the first candidate pair in the 1741 returned SDP with the highest priority (31). As can be seen from 1742 messages (31) to (36), the STUN bind request is successful and 1743 returns a positive outcome for the connectivity check. The 1744 previously described check confirm on both sides that connectivity 1745 can be achieved through appropriate candidates. As part of the 1746 process in this example, both 'L' and 'R' will now complete the 1747 same connectivity checks for part 2 of the component named for 1748 each candidate for use with RTCP. The connectivity checks for 1749 part '2' of the candidate component are shown in 'L'(37-42) and 1750 'R'(43-48). 1751 o The candidates have now been fully verified (Valid status) and as 1752 they are the highest priority, an updated offer (49-50) is now 1753 sent from the offerer (client 'L') to the answerer (client 'R' 1754 representing the new active candidates. The new offer would look 1755 as follows: 1757 v=0 1758 o=test 2890844526 2890842808 IN IP4 $L-PRIV-1 1759 c=IN IP4 $L-NAT-PUB-1.address 1760 t=0 0 1761 a=ice-pwd:$LPASS 1762 m=audio $L-NAT-PUB-1.port RTP/AVP 0 1763 a=rtpmap:0 PCMU/8000 1764 a=rtcp:$L-NAT-PUB-2.port 1765 a=candidate:$L2 1 UDP 0.7 $L-NAT-PUB-1.address $L-NAT-PUB-1.port 1766 a=candidate:$L2 2 UDP 0.7 $L-NAT-PUB-2.address $L-NAT-PUB-2.port 1768 Figure 25: ICE SDP Updated Offer 1770 o The resulting answer (51-52) for 'R' would look as follows: 1772 v=0 1773 o=test 3890844516 3890842803 IN IP4 $R-PRIV-1 1774 c=IN IP4 $R-PRIV-1.address 1775 t=0 0 1776 a=ice-pwd:$RPASS 1777 m=audio $R-PRIV-1.port RTP/AVP 0 1778 a=rtpmap:0 PCMU/8000 1779 a=rtcp:$R-PRIV-2.port 1780 a=candidate:$L2 1 UDP 0.7 $R-NAT-PUB-1.address $R-NAT-PUB-1.port 1781 a=candidate:$L2 2 UDP 0.7 $R-NAT-PUB-2.address $R-NAT-PUB-2.port 1783 Figure 26: ICE SDP Updated Answer 1785 4.2.2. Port and Address Dependant NAT 1787 4.2.2.1. STUN Failure 1789 This section highlights that while STUN is the preferred mechanism 1790 for traversal of NAT, it does not solve every case. The use of basic 1791 STUN on its own will not guarantee traversal through every NAT type, 1792 hence the recommendation that ICE is the preferred option. 1794 Client PORT/ADDRESS Dependant STUN [..] 1795 NAT Server 1796 | | | | 1797 |(1) STUN Req | | | 1798 |Src=L-PRIV-1 | | | 1799 |Dest=STUN-PUB | | | 1800 |----------------->| | | 1801 | | | | 1802 | |(2) STUN Req | | 1803 | |Src=NAT-PUB-1 | | 1804 | |Dest=STUN-PUB | | 1805 | |----------------->| | 1806 | | | | 1807 | |(3) STUN Resp | | 1808 | |<-----------------| | 1809 | |Src=STUN-PUB | | 1810 | |Dest=NAT-PUB-1 | | 1811 | |Map=NAT-PUB-1 | | 1812 | | | | 1813 |(4) STUN Resp | | | 1814 |<-----------------| | | 1815 |Src=STUN-PUB | | | 1816 |Dest=L-PRIV-1 | | | 1817 |Map=NAT-PUB-1 | | | 1818 | | | | 1819 |(5)SIP INVITE | | | 1820 |------------------------------------------------------->| 1821 | | | | 1822 | | |(6)SIP 200 OK | 1823 | |<------------------------------------| 1824 | | | | 1825 |(7)SIP 200 OK | | | 1826 |<-----------------| | | 1827 | | | | 1828 |========================================================| 1829 |>>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>| 1830 |========================================================| 1831 | | | | 1832 | x=====================================| 1833 | xIncoming Media sent to L-PRIV-1<<<<<<| 1834 | x=====================================| 1835 | | | | 1836 |(8)SIP ACK | | | 1837 |----------------->| | | 1838 | |(9) SIP ACK | | 1839 | |------------------------------------>| 1840 | | | | 1842 Figure 27: Port/Address Dependant NAT with STUN - Failure 1844 The example in Figure 27 is conveyed in the context of a client 1845 behind the 'Port/Address Dependant' NAT initiating a call. It should 1846 be noted that the same problem applies when a client receives a SIP 1847 invitation and is behind a Port/Address Dependant NAT. 1848 o In Figure 27 the client behind the NAT obtains an external 1849 representation using standard STUN mechanisms (1)-(4) that have 1850 been used in previous examples in this document (e.g 1851 Section 4.2.1.1.1). 1852 o The external mapped address (reflexive) obtained is also used in 1853 the outgoing SDP contained in the SIP INVITE request(5). 1854 o In this example the client is still able to send media to the 1855 external client. The problem occurs when the client outside the 1856 NAT tries to use the reflexive address supplied in the outgoing 1857 INVITE request to traverse media back through the 'Port/Address 1858 Dependent' NAT. 1859 o A 'Port/Address Dependant' NAT has differing rules from the 1860 'Endpoint Independent' type of NAT (as defined in [11]). For any 1861 internal IP address and port combination, data sent to a different 1862 external destination does not provide the same public mapping at 1863 the NAT. In Figure 27 the STUN query produced a valid external 1864 mapping or receiving media. This mapping, however, can only be 1865 used in the context of the original STUN request that was sent to 1866 the STUN server. Any packets that attempt to use the mapped 1867 address, that does not come from the STUN server IP address and 1868 optionally port, will be dropped at the NAT. Figure 27 shows the 1869 media being dropped at the NAT after (7) and before (8). This 1870 then leads to one way audio. 1872 4.2.2.2. TURN Usage Solution 1874 As identified in Section 4.2.2.1, STUN provides a useful tool kit for 1875 the traversal of the majority of NATs but fails with Port/Address 1876 Dependant NAT. This led to the development of the TURN usage 1877 solution [12] which uses the STUN toolkit. It allows a client to 1878 request a relayed address at the STUN server rather than a reflexive 1879 representation. This then introduces a media relay in the path for 1880 NAT traversal (as described in Section 3.2.3). The following example 1881 explains how the TURN usage solves the previous failure when using 1882 STUN to traverse a 'Port/Address Dependant' type NAT. 1884 L Port/Address Dependant STUN [..] 1885 NAT Server 1886 | | | | 1887 |(1) Alloc Req | | | 1888 |Src=L-PRIV-1 | | | 1889 |Dest=STUN-PUB-1 | | | 1890 |----------------->| | | 1891 | | | | 1892 | |(2) Alloc Req | | 1893 | |Src=NAT-PUB-1 | | 1894 | |Dest=STUN-PUB-1 | | 1895 | |----------------->| | 1896 | | | | 1897 | |(3) Alloc Resp | | 1898 | |<-----------------| | 1899 | |Src=STUN-PUB-1 | | 1900 | |Dest=NAT-PUB-1 | | 1901 | |Map=NAT-PUB-1 | | 1902 | |Rel=STUN-PUB-2 | | 1903 | | | | 1904 |(4) Alloc Resp | | | 1905 |<-----------------| | | 1906 |Src=STUN-PUB-1 | | | 1907 |Dest=L-PRIV-1 | | | 1908 |Map=NAT-PUB-1 | | | 1909 |Rel=STUN-PUB-2 | | | 1910 | | | | 1911 |(5) Alloc Req | | | 1912 |Src=L-PRIV-2 | | | 1913 |Dest=STUN-PUB-1 | | | 1914 |----------------->| | | 1915 | | | | 1916 | |(6) Alloc Req | | 1917 | |Src=NAT-PUB-2 | | 1918 | |Dest=STUN-PUB-1 | | 1919 | |----------------->| | 1920 | | | | 1921 | |(7) Alloc Resp | | 1922 | |<-----------------| | 1923 | |Src=STUN-PUB-1 | | 1924 | |Dest=NAT-PUB-2 | | 1925 | |Map=NAT-PUB-2 | | 1926 | |Rel=STUN-PUB-3 | | 1927 | | | | 1928 |(8) Alloc Resp | | | 1929 |<-----------------| | | 1930 |Src=STUN-PUB-1 | | | 1931 |Dest=L-PRIV-2 | | | 1932 |Map=NAT-PUB-2 | | | 1933 |Rel=STUN-PUB-3 | | | 1934 | | | | 1935 |(9)SIP INVITE | | | 1936 |----------------->| | | 1937 | | | | 1938 | |(10)SIP INVITE | | 1939 | |------------------------------------>| 1940 | | | | 1941 | | |(11)SIP 200 OK | 1942 | |<------------------------------------| 1943 | | | | 1944 |(12)SIP 200 OK | | | 1945 |<-----------------| | | 1946 | | | | 1947 |========================================================| 1948 |>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>| 1949 |========================================================| 1950 | | | | 1951 | | |==================| 1952 | | |<<| 1962 | | |<<<| | | 1971 | | | | 1972 | |(14) SIP ACK | | 1973 | |------------------------------------>| 1974 | | | | 1976 Figure 28: Port/Address Dependant NAT with TURN Usage - Success 1978 o In this example, client 'L' issues a TURN allocate request(1) to 1979 obtained a relay address at the STUN server. The request 1980 traverses through the 'Port/Address Dependant' NAT and reaches the 1981 STUN server (2). The STUN server generates an Allocate response 1982 (3) that contains both a reflexive address (Map=NAT-PUB-1) of the 1983 client and also a relayed address (Rel=STUN-PUB-2). The relayed 1984 address maps to an address mapping on the STUN server which is 1985 bound to the public pin hole that has been opened on the NAT by 1986 the Allocate request. This results in any traffic sent to the 1987 STUN server relayed address (Rel=STUN-PUB-2) being forwarded to 1988 the external representation of the pin hole created by the 1989 Allocate request(NAT-PUB-1). 1990 o The TURN derived address (STUN-PUB-2) arrives back at the 1991 originating client(4) in an Allocate response. This address can 1992 then be used in the SDP for the outgoing SIP INVITE request as 1993 shown in the following example (note that the example also 1994 includes client 'L' obtaining a second relay address for use in 1995 the RTCP attribute (5-8)): 1996 o 1998 v=0 1999 o=test 2890844342 2890842164 IN IP4 $L-PRIV-1 2000 c=IN IP4 $STUN-PUB-2.address 2001 t=0 0 2002 m=audio $STUN-PUB-2.port RTP/AVP 0 2003 a=rtcp:$STUN-PUB-3.port 2005 o On receiving the INVITE request, the UAS is able to stream media 2006 and RTCP to the relay address (STUN-PUB-2 and STUN-PUB-3) at the 2007 STUN server. As shown in Figure 28 (between messages (12) and 2008 (13), the media from the UAS is directed to the relayed address at 2009 the STUN server. The STUN server then forwards the traffic to the 2010 open pin holes in the Port/Address Dependant NAT (NAT-PUB-1 and 2011 NAT-PUB-2). The media traffic is then able to traverse the 'Port/ 2012 Address Dependant' NAT and arrives back at client 'L'. 2013 o The TURN usage of STUN on its own will work for 'Port/Address 2014 Dependent' and other types of NAT mentioned in this specification 2015 but should only be used as a last resort. The relaying of media 2016 through an external entity is not an efficient mechanism for NAT 2017 traversal and comes at a high processing cost. 2019 4.2.2.3. ICE Solution 2021 The previous two examples have highlighted the problem with using 2022 core STUN usage for all forms of NAT traversal and a solution using 2023 TURN usage for the Port/Address Dependant NAT case. As mentioned 2024 previously in this document, the RECOMMENDED mechanism for traversing 2025 all varieties of NAT is using ICE, as detailed in Section 3.2.4. ICE 2026 makes use of core STUN, TURN usage and any other UNSAF[9] compliant 2027 protocol to provide a list of prioritised addresses that can be used 2028 for media traffic. Detailed examples of ICE can be found in 2029 Section 4.2.1.2.1. These examples are associated with an 'Endpoint 2030 Independent' type NAT but can be applied to any NAT type variation, 2031 including 'Port/Address Dependant' type NAT. The procedures are the 2032 same and of the list of candidate addresses, a client will choose 2033 where to send media dependant on the results of the STUN connectivity 2034 checks on each candidate address and the associated priority (highest 2035 priority wins). For more information see the core ICE 2036 specification[16] 2038 [Editors Note: TODO - a detailed example will be included here which 2039 includes promotion of a TURN relayed address to the active candidate 2040 to traverse a 'Port/Address Dependent' type NAT.] 2042 4.3. Address independent Port Restricted NAT --> Address independent 2043 Port Restricted NAT traversal 2045 [Editors Note: TODO - a detailed example will be included where User 2046 A and B are both behind Address Independent NATs that have Port 2047 restricted properties. This means that the stun-derived addresses 2048 will work, but each side must send a 'suicide' or 'primer' STUN 2049 packet that creates a permission in the NAT. So, the main thing to 2050 show here is how the first packet from B to A will create a 2051 permission in B's NAT but gets dropped at A. When A gets the answer 2052 it starts its STUN checks and the packet from A to B creates a 2053 permission in A's NAT and gets through B's NAT because of the 2054 previously installed permission. This now triggers B to resend its 2055 stun request which now works.] 2057 4.4. Internal TURN Usage (Enterprise Deployment) 2059 [Editors Note: TODO - a detailed example will be included for User A 2060 and User B. User A is in an enterprise, which has a address and port 2061 restricted NAT. User B is on the public internet. There is a TURN+ 2062 STUN server deployed INSIDE the enterprise NAT. The NAT has a static 2063 set of ports forwarded to the internal TURN server (say, 100 ports). 2064 The TURN server is configured with those ports. So, when user A 2065 talks to the TURN server it gets an address and port on the *public* 2066 side of the NAT, with a preconfigured port forwarding rule. Indeed, 2067 the client is configured with two TURN servers. Both are physically 2068 the same TURN server. However, when talking to one instance the 2069 client gets the public address. When talking to the other instance 2070 it gets a private address inside the NAT. The ice process ends up 2071 selecting the public address given out by the TURN server usage.] 2073 5. Intercepting Intermediary (B2BUA) 2075 [Editors Note: TODO - a detailed example demonstrating how a B2BUA 2076 can obtain STUN/TURN addresses for the purpose of allocating to 2077 Clients. This example shows how intermediaries can control the flow 2078 of media without having to directly access SDP on the signalling 2079 plane. 2081 6. IPv4-IPv6 Transition 2083 This section describes how IPv6-only SIP user agents can communicate 2084 with IPv4-only SIP user agents. 2086 6.1. IPv4-IPv6 Transition for SIP Signalling 2088 IPv4-IPv6 translations at the SIP level usually take place at dual- 2089 stack proxies that have both IPv4 and IPv6 DNS entries. Since this 2090 translations do not involve NATs that are placed in the middle of two 2091 SIP entities, they fall outside the scope of this document. A 2092 detailed description of this type of translation can be found in [19] 2094 6.2. IPv4-IPv6 Transition for Media 2096 Figure 30 shows a network of IPv6 SIP user agents that has a relay 2097 with a pool of public IPv4 addresses. The IPv6 SIP user agents of 2098 this IPv6 network need to communicate with users on the IPv4 2099 Internet. To do so, the IPv6 SIP user agents use TURN to obtain a 2100 public IPv4 address from the relay. The mechanism that an IPv6 SIP 2101 user agent follows to obtain a public IPv4 address from a relay using 2102 TURN is the same as the one followed by a user agent with a private 2103 IPv4 address to obtain a public IPv4 address. The example in 2104 Figure 31 explains how to use TURN to obtain an IPv4 address and how 2105 to use the ANAT semantics [17] of the SDP grouping framework [8] to 2106 provide both IPv4 and IPv6 addresses for a particular media stream. 2108 +----------+ 2109 | / \ | 2110 /SIP \ 2111 /Phone \ 2112 / \ 2113 ------------ 2115 IPv4 Network 2116 192.0.2.0/8 2117 +---------+ 2118 | | 2119 ----------------------| NAT |-------------------------- 2120 | | 2121 +---------+ 2122 IPv6 Network 2124 ++ 2125 || 2126 +-----++ 2127 | IPv6 | 2128 | SIP | 2129 | user | 2130 | agent| 2131 +------+ 2133 Figure 30: IPv6-IPv4 transition scenario 2134 IPv6 SIP TURN IPv4 SIP 2135 User Agent Server User Agent 2136 | | | 2137 | (1) TURN Allocate | | 2138 | src=[2001:DB8::1]:30000 | | 2139 |------------------------------------>| | 2140 | (2) TURN Resp | | 2141 | map=192.0.2.2:25000 | | 2142 | dest=[2001:DB8::1]:30000 | | 2143 |<------------------------------------| | 2144 | (3) SIP INVITE | | 2145 |------------------------------------------------------->| 2146 | (4) SIP 200 OK | | 2147 |<-------------------------------------------------------| 2148 | | | 2149 |=====================================| | 2150 |>>>>>>>>>> Outgoing Media >>>>>>>>>>>| | 2151 |=====================================| | 2152 | |==================| 2153 | |>>>>>> Media >>>>>| 2154 | |==================| 2155 | | | 2156 | |==================| 2157 | |<<<<<< Media <<<<<| 2158 | |==================| 2159 |=====================================| | 2160 |<<<<<<<<<< Outgoing Media <<<<<<<<<<<| | 2161 |=====================================| | 2162 | | | 2163 | (5) SIP ACK | | 2164 |------------------------------------------------------->| 2165 | | | 2167 Figure 31: IPv6-IPv4 translation with TURN 2169 o The IPv6 SIP user agent obtains a TURN-derived IPv4 address by 2170 issuing a TURN allocate request (1). The TURN server generates a 2171 response that contains the public IPv4 address. This IPv4 address 2172 maps to the IPv6 source address of the TURN allocate request, 2173 which the IPv6 address of the SIP user agent. This results in any 2174 traffic being sent to the IPv4 address provided by TURN server 2175 (192.0.2.2:25000) will be redirected to the IPv6 address of the 2176 SIP user agent ([2001:DB8::1]:30000). 2177 o The TURN-derived address (192.0.2.2:25000) arrives back at the 2178 originating user agent (2). This address can then be used in the 2179 SDP for the outgoing SIP INVITE request. The user agent builds 2180 two media lines, one with its IPv6 address and the other with the 2181 IPv4 address that was just obtained. The user agent groups both 2182 media lines using the ANAT semantics as shown below (note that the 2183 RTCP attribute in the IPv4 media line would have been obtained by 2184 another TURN-derived address which is not shown in the call flow 2185 for simplicity). 2187 v=0 2188 o=test 2890844342 2890842164 IN IP6 2001:DB8::1 2189 t=0 0 2190 a=group:ANAT 1 2 2191 m=audio 20000 RTP/AVP 0 2192 c=IN IP6 2001:DB8::1 2193 a=mid:1 2194 m=audio 25000 RTP/AVP 0 2195 c=IN IP4 192.0.2.2 2196 a=rtcp:25001 2197 a=mid:2 2199 o On receiving the INVITE request, the user agent server rejects the 2200 IPv6 media line by setting its port to zero in the answer and 2201 starts sending media to the IPv4 address in the offer. The IPv6 2202 user agent sends media through the relay as well, as shown in 2203 Figure 31. 2205 7. ICE with RTP/TCP 2207 [Editors Note: TODO - a detailed example will be included on using 2208 ICE with RTP/TCP - as define in [18] 2210 8. Acknowledgments 2212 The authors would like to thank the members of the IETF SIPPING WG 2213 for their comments and suggestions. Detailed comments were provided 2214 by Francois Audet, kaiduan xie and Hans Persson. 2216 9. References 2218 9.1. Normative References 2220 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2221 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2222 Session Initiation Protocol", RFC 3261, June 2002. 2224 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2225 "RTP: A Transport Protocol for Real-Time Applications", 2226 RFC 1889, January 1996. 2228 [3] Handley, M. and V. Jacobson, "SDP: Session Description 2229 Protocol", RFC 2327, April 1998. 2231 [4] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 2232 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 2234 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2235 Session Description Protocol (SDP)", RFC 3264, June 2002. 2237 [6] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session 2238 Initiation Protocol (SIP) for Symmetric Response Routing", 2239 RFC 3581, August 2003. 2241 [7] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 2242 Extension Header Field for Registering Non-Adjacent Contacts", 2243 RFC 3327, December 2002. 2245 [8] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, 2246 "Grouping of Media Lines in the Session Description Protocol 2247 (SDP)", RFC 3388, December 2002. 2249 [9] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 2250 Address Fixing (UNSAF) Across Network Address Translation", 2251 RFC 3424, November 2002. 2253 [10] Rosenberg, J., "Simple Traversal of UDP Through Network Address 2254 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-03 2255 (work in progress), March 2006. 2257 [11] Audet, F. and C. Jennings, "NAT Behavioral Requirements for 2258 Unicast UDP", draft-ietf-behave-nat-udp-07 (work in progress), 2259 June 2006. 2261 [12] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 2262 of UDP Through NAT (STUN)", draft-ietf-behave-turn-00 (work in 2263 progress), March 2006. 2265 [13] Jennings, C. and A. Hawrylyshen, "SIP Conventions for UAs with 2266 Outbound Only Connections", draft-jennings-sipping-outbound-01 2267 (work in progress), February 2005. 2269 [14] Rosenberg, J., "Obtaining and Using Globally Routable User 2270 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 2271 (SIP)", draft-ietf-sip-gruu-09 (work in progress), June 2006. 2273 [15] Wing, D., "Symmetric RTP and RTCP Considered Helpful", 2274 draft-wing-mmusic-symmetric-rtprtcp-01 (work in progress), 2275 October 2004. 2277 [16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 2278 Methodology for Network Address Translator (NAT) Traversal for 2279 Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in 2280 progress), March 2006. 2282 [17] Camarillo, G., "The Alternative Network Address Types Semantics 2283 (ANAT) for theSession Description Protocol (SDP) Grouping 2284 Framework", draft-ietf-mmusic-anat-02 (work in progress), 2285 October 2004. 2287 [18] Rosenberg, J., "TCP Candidates with Interactive Connectivity 2288 Establishment (ICE)", draft-ietf-mmusic-ice-tcp-00 (work in 2289 progress), March 2006. 2291 9.2. Informative References 2293 [19] Camarillo, G., "IPv6 Transcition in the Session Initiation 2294 Protocol (SIP)", draft-camarillo-sipping-v6-transition-00 (work 2295 in progress), February 2005. 2297 Authors' Addresses 2299 Chris Boulton 2300 Ubiquity Software Corporation 2301 Eastern Business Park 2302 St Mellons 2303 Cardiff, South Wales CF3 5EA 2305 Email: cboulton@ubiquitysoftware.com 2307 Jonathan Rosenberg 2308 Cisco Systems 2309 600 Lanidex Plaza 2310 Parsippany, NJ 07054 2312 Email: jdrosen@cisco.com 2314 Gonzalo Camarillo 2315 Ericsson 2316 Hirsalantie 11 2317 Jorvas 02420 2318 Finland 2320 Email: Gonzalo.Camarillo@ericsson.com 2322 Intellectual Property Statement 2324 The IETF takes no position regarding the validity or scope of any 2325 Intellectual Property Rights or other rights that might be claimed to 2326 pertain to the implementation or use of the technology described in 2327 this document or the extent to which any license under such rights 2328 might or might not be available; nor does it represent that it has 2329 made any independent effort to identify any such rights. Information 2330 on the procedures with respect to rights in RFC documents can be 2331 found in BCP 78 and BCP 79. 2333 Copies of IPR disclosures made to the IETF Secretariat and any 2334 assurances of licenses to be made available, or the result of an 2335 attempt made to obtain a general license or permission for the use of 2336 such proprietary rights by implementers or users of this 2337 specification can be obtained from the IETF on-line IPR repository at 2338 http://www.ietf.org/ipr. 2340 The IETF invites any interested party to bring to its attention any 2341 copyrights, patents or patent applications, or other proprietary 2342 rights that may cover technology that may be required to implement 2343 this standard. Please address the information to the IETF at 2344 ietf-ipr@ietf.org. 2346 Disclaimer of Validity 2348 This document and the information contained herein are provided on an 2349 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2350 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2351 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2352 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2353 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2354 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2356 Copyright Statement 2358 Copyright (C) The Internet Society (2006). This document is subject 2359 to the rights, licenses and restrictions contained in BCP 78, and 2360 except as set forth therein, the authors retain all their rights. 2362 Acknowledgment 2364 Funding for the RFC Editor function is currently provided by the 2365 Internet Society.