idnits 2.17.1 draft-ietf-sipping-nat-scenarios-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 14 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (February 2, 2011) is 4804 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-media-path-middleboxes-03 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group C. Boulton 3 Internet-Draft NS-Technologies 4 Intended status: Informational J. Rosenberg 5 Expires: August 6, 2011 Skype 6 G. Camarillo 7 Ericsson 8 F. Audet 9 Skype 10 February 2, 2011 12 Best Current Practices for NAT Traversal for Client-Server SIP 13 draft-ietf-sipping-nat-scenarios-15 15 Abstract 17 Traversal of the Session Initiation Protocol (SIP) and the sessions 18 it establishes through Network Address Translators (NATs) is a 19 complex problem. Currently there are many deployment scenarios and 20 traversal mechanisms for media traffic. This document provides 21 concrete recommendations and a unified method for NAT traversal as 22 well as documenting corresponding flows. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 6, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Solution Technology Outline Description . . . . . . . . . . . 10 62 4.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 10 63 4.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 10 64 4.1.2. Client Initiated Connections . . . . . . . . . . . . . 11 65 4.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 11 66 4.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 12 67 4.2.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.2.3. STUN/TURN/ICE . . . . . . . . . . . . . . . . . . . . 12 69 5. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 15 70 5.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 15 71 5.1.1. Registration (Registrar/Edge Proxy Co-Located) . . . . 15 72 5.1.2. Registration(Registrar/Edge Proxy not Co-Located) . . 18 73 5.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 21 74 5.1.4. Receiving an Invitation to a Session . . . . . . . . . 24 75 5.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 29 76 5.2.1. Endpoint Independent NAT . . . . . . . . . . . . . . . 30 77 5.2.2. Address/Port-Dependent NAT . . . . . . . . . . . . . . 50 78 6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 59 79 6.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 59 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 60 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 82 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 62 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 64 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 65 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 89 1. Introduction 91 NAT (Network Address Translators) traversal has long been identified 92 as a complex problem when considered in the context of the Session 93 Initiation Protocol (SIP)[RFC3261] and it's associated media such as 94 Real Time Protocol (RTP)[RFC3550]. The problem is exacerbated by the 95 variety of NATs that are available in the market place today and the 96 large number of potential deployment scenarios. Details of different 97 NATs behavior can be found in 'NAT Behavioral Requirements for 98 Unicast UDP' [RFC4787]. 100 The IETF has been active on many specifications for the traversal of 101 NATs, including STUN[RFC5389], ICE[RFC5245], symmetric 102 response[RFC3581], symmetric RTP[RFC4961], TURN[RFC5766], SIP 103 Outbound[RFC5626], SDP attribute for RTCP[RFC3605], Multiplexing RTP 104 Data and Control Packets on a Single Port[RFC5761] and others. These 105 each represent a part of the solution, but none of them gives the 106 overall context for how the NATs traversal problem is decomposed and 107 solved through this collection of specifications. This document 108 serves to meet that need. It should be noted that this document 109 intentionally does not invoke Best Common Practice machinery as 110 defined in RFC 2026 [RFC2026]. 112 The draft is split into two distinct sections as follows: 114 o Section 4 provides a definitive set of 'Best Common Practices' to 115 demonstrate the traversal of SIP and its associated media through 116 NAT devices. 118 o Section 5 provides non-normative examples representing 119 interactions of SIP using various NAT type deployments. 121 The document does not propose any new functionality but does draw on 122 existing solutions for both core SIP signaling and media traversal 123 (as defined in Section 4). 125 The best practices described in this document are for traditional 126 "client-server"-style SIP. This term refers to the traditional use 127 of the SIP protocol where User Agents talk to a series of 128 intermediaries on a path to connect to a remote User Agent. It seems 129 likely that other groups using SIP, for example "Peer-to-Peer- 130 SIP(P2PSIP), will recommend these same practices between a P2PSIP 131 client and a P2PSIP peer, but will recommend different practices for 132 use between peers in a peer-to-peer network. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 It should be noted that the use of the term 'Endpoint Independent 141 NAT' in this document refers to a NAT that is both 'Endpoint 142 Independent Filtering NAT' and 'Endpoint Independent Mapping NAT' per 143 RFC 4787 [RFC4787] definition. 145 3. Problem Statement 147 The traversal of SIP through NATs can be split into two categories 148 that both require attention - The core SIP signaling and associated 149 media traversal. This document assumes NATs that do not contain SIP- 150 aware Application Layer Gateways(ALG), which makes much of the issues 151 discussed in the document not applicable. ALGs have limitations (as 152 per RFC 4787 [RFC4787]/section 7, RFC 3424 [RFC3424], and [RFC5245]/ 153 section 18.6) and experience shows they can have an adverse impact on 154 the functionality of SIP. This includes problems such as requiring 155 the media and signaling to traverse the same device and not working 156 with encrypted signaling and/or payload. 158 The use of non-TURN based media intermediaries is not considered in 159 this document. More information can be obtained from [RFC5853] and 160 [I-D.ietf-mmusic-media-path-middleboxes]. 162 The core SIP signaling has a number of issues when traversing through 163 NATs. 165 SIP response routing over UDP as defined in RFC 3261 [RFC3261] 166 without extensions causes the response to be delivered to the source 167 IP address specified in the topmost Via header, or the "received" 168 parameter of the topmost Via header. The port is extracted from the 169 SIP 'Via' header to complete the IP address/port combination for 170 returning the SIP response. While the destination for the response 171 is correct, the port contained in the SIP 'Via' header represents the 172 listening port of the originating client and not the port 173 representing the open pin hole on the NAT. This results in responses 174 being sent back to the NAT but to a port that is likely not open for 175 SIP traffic. The SIP response will then be dropped at the NAT. This 176 is illustrated in Figure 1 which depicts a SIP response being 177 returned to port 5060. 179 Private NAT Public 180 Network | Network 181 | 182 | 183 -------- SIP Request |open port 10923 -------- 184 | |-------------------->--->-----------------------| | 185 | | | | | 186 | Client | |port 5060 SIP Response | Proxy | 187 | | x<------------------------| | 188 | | | | | 189 -------- | -------- 190 | 191 | 192 | 194 Figure 1: Failed Response 196 Secondly, there are two cases where new requests re-use existing 197 connections. The first is when using a reliable, connection 198 orientated transport protocol such as TCP, SIP has an inherent 199 mechanism that results in SIP responses reusing the connection that 200 was created/used for the corresponding transactional request. The 201 SIP protocol does not provide a mechanism that allows new requests 202 generated in the reverse direction of the originating client to use, 203 for example, the existing TCP connection created between the client 204 and the server during registration. This results in the registered 205 contact address not being bound to the "connection" in the case of 206 TCP. Requests are then blocked at the NAT, as illustrated in 207 Figure 2. The second case is when unreliable transport protocols 208 such as UDP where external NAT mappings need to be re-used to reach a 209 SIP entity on the private side of the network. 211 Private NAT Public 212 Network | Network 213 | 214 | 215 -------- (UAC 8023) REGISTER/Response (UAS 5060) -------- 216 | |-------------------->---<-----------------------| | 217 | | | | | 218 | Client | |5060 INVITE (UAC 8015)| Proxy | 219 | | x<------------------------| | 220 | | | | | 221 -------- | -------- 222 | 223 | 224 | 226 Figure 2: Failed Request 228 In Figure 2 the original REGISTER request is sent from the client on 229 port 8023 and received by the proxy on port 5060, establishing a 230 connection and opening a pin-hole in the NAT. The generation of a 231 new request from the proxy results in a request destined for the 232 registered entity (Contact IP address) which is not reachable from 233 the public network. This results in the new SIP request attempting 234 to create a connection to a private network address. This problem 235 would be solved if the original connection was re-used. While this 236 problem has been discussed in the context of connection orientated 237 protocols such as TCP, the problem exists for SIP signaling using any 238 transport protocol. The impact of connection reuse of connection 239 orientated transports (TCP, TLS, etc) is discussed in more detail in 240 the connection reuse specification[RFC5923]. The approach proposed 241 for this problem in Section 4 of this document is relevant for all 242 SIP signaling in conjunction with connection reuse, regardless of the 243 transport protocol. 245 NAT policy can dictate that connections should be closed after a 246 period of inactivity. This period of inactivity may vary from a 247 number seconds to hours. SIP signaling can not be relied upon to 248 keep alive connections for the following two reasons. Firstly, SIP 249 entities can sometimes have no signaling traffic for long periods of 250 time which has the potential to exceed the inactivity timer, and this 251 can lead to problems where endpoints are not available to receive 252 incoming requests as the connection has been closed. Secondly, if a 253 low inactivity timer is specified, SIP signaling is not appropriate 254 as a keep-alive mechanism as it has the potential to add a large 255 amount of traffic to the network which uses up valuable resource and 256 also requires processing at a SIP stack, which is also a waste of 257 processing resources. 259 Media associated with SIP calls also has problems traversing NAT. 260 RTP [RFC3550] runs over UDP and is one of the most common media 261 transport types used in SIP signaling. Negotiation of RTP occurs 262 with a SIP session establishment using the Session Description 263 Protocol(SDP) [RFC4566] and a SIP offer/answer exchange[RFC3264]. 264 During a SIP offer/answer exchange an IP address and port combination 265 are specified by each client in a session as a means of receiving 266 media such as RTP. The problem arises when a client advertises its 267 address to receive media and it exists in a private network that is 268 not accessible from outside the NAT. Figure 3 illustrates this 269 problem. 271 NAT Public Network NAT 272 | | 273 | | 274 | | 275 -------- | SIP Signaling Session | -------- 276 | |---------------------->Proxy<-------------------| | 277 | | | | | | 278 | Client | | | | Client | 279 | A |>=====>RTP>==Unknown Address==>X | | B | 280 | | | X<==Unknown Address==| | 366 | Client |<---------------------------------send response| SIP | 367 | A | | | Proxy | 368 | | | | | 369 -------- | -------- 370 | 371 | 372 | 374 Figure 4: Symmetric Response 376 The outgoing request from Client A opens a pin hole in the NAT. The 377 SIP Proxy would normally respond to the port available in the SIP Via 378 header, as illustrated in Figure 1. The SIP Proxy honours the 379 'rport' parameter in the SIP Via header and routes the response to 380 port from which it was sent. The exact functionality for this method 381 of response traversal is called 'Symmetric Response' and the details 382 are documented in RFC 3581 [RFC3581]. Additional requirements are 383 imposed on SIP entities in RFC 3581 [RFC3581] such as listening and 384 sending SIP requests/responses from the same port. 386 4.1.2. Client Initiated Connections 388 The second problem with SIP signaling, as defined in Section 3 and 389 illustrated in Figure 2, is to allow incoming requests to be properly 390 routed. 392 Guidelines for devices such as User Agents that can only generate 393 outbound connections through NATs are documented in 'Managing Client 394 Initiated Connections in the Session Initiation 395 Protocol(SIP)'[RFC5626]. The document provides techniques that use a 396 unique User Agent instance identifier (instance-id) in association 397 with a flow identifier (reg-id). The combination of the two 398 identifiers provides a key to a particular connection (both UDP and 399 TCP) that is stored in association with registration bindings. On 400 receiving an incoming request to a SIP Address-Of-Record (AOR), a 401 proxy/registrar routes to the associated flow created by the 402 registration and thus a route through NATs. It also provides a 403 keepalive mechanism for clients to keep NATs bindings alive. This is 404 achieved by multiplexing a ping/pong mechanism over the SIP signaling 405 connection (STUN for UDP and CRLF/operating system keepalive for 406 reliable transports like TCP). Usage of [RFC5626] is RECOMMENDED. 407 This mechanism is not transport specific and should be used for any 408 transport protocol. 410 Even if the SIP Outbound mechanism is not used, clients generating 411 SIP requests SHOULD use the same IP address and port (i.e., socket) 412 for both transmission and receipt of SIP messages. Doing so allows 413 for the vast majority of industry provided solutions to properly 414 function(e.g., SBC hosted NAT traversal). Deployments should also 415 consider the mechanism described in the Connection Reuse[RFC5923] 416 specification for routing bi-directional messages securely between 417 trusted SIP Proxy servers. 419 4.2. Media Traversal 421 The issues of media traversal through NATs is not straight forward 422 and requires the combination of a number of traversal methodologies. 423 The technologies outlined in the remainder of this section provide 424 the required solution set. 426 4.2.1. Symmetric RTP/RTCP 428 The primary problem identified in Section 3 of this document is that 429 internal IP address/port combinations can not be reached from the 430 public side of NATs. In the case of media such as RTP, this will 431 result in no audio traversing NATs (as illustrated in Figure 3). To 432 overcome this problem, a technique called 'Symmetric RTP/ 433 RTCP'[RFC4961] can be used. This involves a SIP endpoint both 434 sending and receiving RTP/RTCP traffic from the same IP address/port 435 combination. When operating behind a NAT and using the 'latching' 436 technique described in [I-D.ietf-mmusic-media-path-middleboxes], SIP 437 user agents MUST implement 'Symmetric RTP/RTCP'. This allows 438 traversal of RTP across the NAT. 440 4.2.2. RTCP 442 Normal practice when selecting a port for defining RTP Control 443 Protocol (RTCP) [RFC3550] is for consecutive order numbering (i.e 444 select an incremented port for RTCP from that used for RTP). This 445 assumption causes RTCP traffic to break when traversing certain types 446 of NATs due to various reasons (e.g., already-allocated port, 447 randomized port allocation). To combat this problem a specific 448 address and port need to be specified in the SDP rather than relying 449 on such assumptions. RFC 3605 [RFC3605] defines an SDP attribute 450 that is included to explicitly specify transport connection 451 information for RTCP so a separate, explicit NAT binding can be set 452 up for the purpose. The address details can be obtained using any 453 appropriate method including those detailed in this section (e.g. 454 STUN, TURN, ICE). 456 A further enhancement to RFC 3605 [RFC3605] is defined in [RFC5761] 457 which specifies 'muxing' both RTP and RTCP on the same IP/PORT 458 combination. 460 4.2.3. STUN/TURN/ICE 462 ICE, STUN and TURN are a suite of 3 inter-related protocols that 463 combine to provide a complete media traversal solution for NATs. The 464 following sections provide details of each component part. 466 4.2.3.1. STUN 468 Session Traversal Utilities for NAT or STUN is defined in RFC 5389 469 [RFC5389]. STUN is a lightweight tool kit and protocol that provides 470 details of the external IP address/port combination used by the NAT 471 device to represent the internal entity on the public facing side of 472 NATs. On learning of such an external representation, a client can 473 use it accordingly as the connection address in SDP to provide NAT 474 traversal. Using terminology defined in the draft 'NAT Behavioral 475 Requirements for Unicast UDP' [RFC4787], STUN does work with 476 'Endpoint Independent Mapping' but does not work with either 'Address 477 Dependent Mapping' or 'Address and Port Dependent Mapping' type NATs. 478 Using STUN with either of the previous two NATs mappings to probe for 479 the external IP address/port representation will provide a different 480 result to that required for traversal by an alternative SIP entity. 481 The IP address/port combination deduced for the STUN server would be 482 blocked for RTP packets from the remote SIP user agent. 484 As mentioned in Section 4.1.2, STUN is also used as a client-to- 485 server keep-alive mechanism to refresh NAT bindings. 487 4.2.3.2. TURN 489 As described in the Section 4.2.3.1, the STUN protocol does not work 490 for UDP traversal through certain identified NAT mappings. 491 'Traversal Using Relays around NAT' is a usage of the STUN protocol 492 for deriving (from a TURN server) an address that will be used to 493 relay packets towards a client. TURN provides an external address 494 (globally routable) at a TURN server that will act as a media relay 495 which attempts to allow traffic to reach the associated internal 496 address. The full details of the TURN specification are defined in 497 [RFC5766]. A TURN service will almost always provide media traffic 498 to a SIP entity but it is RECOMMENDED that this method would only be 499 used as a last resort and not as a general mechanism for NAT 500 traversal. This is because using TURN has high performance costs 501 when relaying media traffic and can lead to unwanted latency. 503 4.2.3.3. ICE 505 Interactive Connectivity Establishment (ICE) is the RECOMMENDED 506 method for traversal of existing NATs if Symmetric RTP and media 507 latching is not sufficient. ICE is a methodology for using existing 508 technologies such as STUN, TURN and any other UNSAF[RFC3424] 509 compliant protocol to provide a unified solution. This is achieved 510 by obtaining as many representative IP address/port combinations as 511 possible using technologies such as STUN/TURN (*note - an ICE 512 endpoint can also use other mechanisms (e.g., NAT- 513 PMP[I-D.cheshire-nat-pmp], UPnP IGD[UPnP-IGD]) to learn public IP 514 addresses and ports, and populate a=candidate lines with that 515 information). Once the addresses are accumulated, they are all 516 included in the SDP exchange in a new media attribute called 517 'candidate'. Each 'candidate' SDP attribute entry has detailed 518 connection information including a media address, priority and 519 transport protocol. The appropriate IP address/port combinations are 520 used in the order specified by the priority. A client compliant to 521 the ICE specification will then locally run STUN servers on all 522 addresses being advertised using ICE. Each instance will undertake 523 connectivity checks to ensure that a client can successfully receive 524 media on the advertised address. Only connections that pass the 525 relevant connectivity checks are used for media exchange. The full 526 details of the ICE methodology are contained in [RFC5245]. 528 5. NAT Traversal Scenarios 530 This section of the document includes detailed NAT traversal 531 scenarios for both SIP signaling and the associated media. 532 Signalling NAT traversal is achieved using [RFC5626]. 534 5.1. Basic NAT SIP Signaling Traversal 536 The following sub-sections concentrate on SIP signaling traversal of 537 NATs. The scenarios include traversal for both reliable and un- 538 reliable transport protocols. 540 5.1.1. Registration (Registrar/Edge Proxy Co-Located) 542 The set of scenarios in this section document basic signaling 543 traversal of a SIP REGISTER method through NATs. 545 5.1.1.1. UDP 547 Registrar/ 548 Bob NAT Edge Proxy 549 | | | 550 |(1) REGISTER | | 551 |----------------->| | 552 | | | 553 | |(1) REGISTER | 554 | |----------------->| 555 | | | 556 |*************************************| 557 | Create Outbound Connection Tuple | 558 |*************************************| 559 | | | 560 | |(2) 200 OK | 561 | |<-----------------| 562 | | | 563 |(2) 200 OK | | 564 |<-----------------| | 565 | | | 567 Figure 5: UDP Registration 569 In this example the client sends a SIP REGISTER request through a 570 NAT. The client will include an 'rport' parameter as described in 571 Section 4.1.1 of this document for allowing traversal of UDP 572 responses. The original request as illustrated in (1) in Figure 5 is 573 a standard SIP REGISTER message: 575 Message 1: 577 REGISTER sip:example.com SIP/2.0 578 Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7 579 Max-Forwards: 70 580 From: Bob ;tag=7F94778B653B 581 To: Bob 582 Call-ID: 16CB75F21C70 583 CSeq: 1 REGISTER 584 Supported: path, outbound 585 Contact: ;reg-id=1 586 ;+sip.instance="" 587 Content-Length: 0 589 This SIP transaction now generates a SIP 200 OK response, as depicted 590 in (2) from Figure 5: 592 Message 2: 594 SIP/2.0 200 OK 595 Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7; 596 received=172.16.3.4 597 From: Bob ;tag=7F94778B653B 598 To: Bob ;tag=6AF99445E44A 599 Call-ID: 16CB75F21C70 600 CSeq: 1 REGISTER 601 Supported: path, outbound 602 Require: outbound 603 Contact: ;reg-id=1;expires=3600 604 ;+sip.instance="" 605 Content-Length: 0 607 The response will be sent to the address appearing in the 'received' 608 parameter of the SIP 'Via' header (address 172.16.3.4). The response 609 will not be sent to the port deduced from the SIP 'Via' header, as 610 per standard SIP operation but will be sent to the value that has 611 been stamped in the 'rport' parameter of the SIP 'Via' header (port 612 8050). For the response to successfully traverse the NAT, all of the 613 conventions defined in RFC 3581 [RFC3581] are to be obeyed. Make 614 note of both the 'reg-id' and 'sip.instance' contact header 615 parameters. They are used to establish an Outbound connection tuple 616 as defined in [RFC5626]. The connection tuple creation is clearly 617 shown in Figure 5. This ensures that any inbound request that causes 618 a registration lookup will result in the re-use of the connection 619 path established by the registration. This removes the need to 620 manipulate contact header URIs to represent a globally routable 621 address as perceived on the public side of a NAT. 623 5.1.1.2. Connection Oriented Transport 625 Registrar/ 626 Bob NAT Edge Proxy 627 | | | 628 |(1) REGISTER | | 629 |----------------->| | 630 | | | 631 | |(1) REGISTER | 632 | |----------------->| 633 | | | 634 |*************************************| 635 | Create Outbound Connection Tuple | 636 |*************************************| 637 | | | 638 | |(2) 200 OK | 639 | |<-----------------| 640 | | | 641 |(2) 200 OK | | 642 |<-----------------| | 643 | | | 645 Figure 6 647 Traversal of SIP REGISTER requests/responses using a reliable, 648 connection orientated protocol such as TCP does not require any 649 additional core SIP signaling extensions, beyond the procedures 650 defined in [RFC5626]. SIP responses will re-use the connection 651 created for the initial REGISTER request, (1) from Figure 6: 653 Message 1: 655 REGISTER sip:example.com SIP/2.0 656 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 657 Max-Forwards: 70 658 From: Bob ;tag=7F94778B653B 659 To: Bob 660 Call-ID: 16CB75F21C70 661 CSeq: 1 REGISTER 662 Supported: path, outbound 663 Contact: ;reg-id=1 664 ;+sip.instance="" 666 Content-Length: 0 668 Message 2: 670 SIP/2.0 200 OK 671 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 672 From: Bob ;tag=7F94778B653B 673 To: Bob ;tag=6AF99445E44A 674 Call-ID: 16CB75F21C70 675 CSeq: 1 REGISTER 676 Supported: path, outbound 677 Require: outbound 678 Contact: ;reg-id=1;expires=3600 679 ;+sip.instance="" 680 Content-Length: 0 682 This example was included to show the inclusion of the +sip.instance 683 Contact header parameter as defined in the SIP Outbound specification 684 [RFC5626]. This creates an association tuple as described in the 685 previous example for future inbound requests directed at the newly 686 created registration binding with the only difference that the 687 association is with a TCP connection, not a UDP pin hole binding. 689 5.1.2. Registration(Registrar/Edge Proxy not Co-Located) 691 This section demonstrates traversal mechanisms when the Registrar 692 component is not co-located with the edge proxy element. The 693 procedures described in this section are identical, regardless of 694 transport protocol and so only one example will be documented in the 695 form of TCP. 697 Bob NAT Edge Proxy Registrar 698 | | | | 699 |(1) REGISTER | | | 700 |----------------->| | | 701 | | | | 702 | |(1) REGISTER | | 703 | |----------------->| | 704 | | | | 705 | | |(2) REGISTER | 706 | | |----------------->| 707 | | | | 708 |*************************************| | 709 | Create Outbound Connection Tuple | | 710 |*************************************| | 711 | | | | 712 | | |(3) 200 OK | 713 | | |<-----------------| 714 | |(4)200 OK | | 715 | |<-----------------| | 716 | | | | 717 |(4)200 OK | | | 718 |<-----------------| | | 719 | | | | 721 Figure 7: Registration(Registrar/Proxy not Co-Located) 723 This scenario builds on the previous example contained in 724 Section 5.1.1.2. The primary difference being that the REGISTER 725 request is routed onwards from a Proxy Server to a separated 726 Registrar. The important message to note is (1) in Figure 7. The 727 Edge proxy, on receiving a REGISTER request that contains a 728 'sip.instance' media feature tag, forms a unique flow identifier 729 token as discussed in [RFC5626]. At this point, the proxy server 730 routes the SIP REGISTER message to the Registrar. The proxy will 731 create the connection tuple as described in SIP Outbound at the same 732 moment as the co-located example, but for subsequent messages to 733 arrive at the Proxy, the proxy needs to indicate its need to remain 734 in the SIP signaling path. To achieve this the proxy inserts to 735 REGISTER message (2) a SIP PATH extension header, as defined in RFC 736 3327 [RFC3327]. The previously created flow association token is 737 inserted in a position within the Path header where it can easily be 738 retrieved at a later point when receiving messages to be routed to 739 the registration binding (in this case the user part of the SIP URI). 740 The REGISTER message of (1) includes a SIP Route header for the edge 741 proxy. 743 Message 1: 745 REGISTER sip:example.com SIP/2.0 746 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 747 Max-Forwards: 70 748 From: Bob ;tag=7F94778B653B 749 To: Bob 750 Call-ID: 16CB75F21C70 751 CSeq: 1 REGISTER 752 Supported: path, outbound 753 Route: 754 Contact: ;reg-id=1 755 ;+sip.instance="" 756 Content-Length: 0 758 When proxied in (2) looks as follows: 760 Message 2: 762 REGISTER sip:example.com SIP/2.0 763 Via: SIP/2.0/TCP ep1.example.com;branch=z9hG4bKnuiqisi 764 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 765 Max-Forwards: 69 766 From: Bob ;tag=7F94778B653B 767 To: Bob 768 Call-ID: 16CB75F21C70 769 CSeq: 1 REGISTER 770 Supported: path, outbound 771 Contact: ;reg-id=1 772 ;+sip.instance="" 773 Path: 774 Content-Length: 0 776 This REGISTER request results in the Path header being stored along 777 with the AOR and it's associated binding at the Registrar. The URI 778 contained in the Path header will be inserted as a pre-loaded SIP 779 'Route' header into any request that arrives at the Registrar and is 780 directed towards the associated AOR binding. This all but guarantees 781 that all requests for the new registration will be forwarded to the 782 Edge Proxy. In our example, the user part of the SIP 'Path' header 783 URI that was inserted by the Edge Proxy contains the unique token 784 identifying the flow to the client. On receiving subsequent 785 requests, the edge proxy will examine the user part of the pre-loaded 786 SIP 'route' header and extract the unique flow token for use in its 787 connection tuple comparison, as defined in the SIP Outbound 788 specification [RFC5626]. An example which builds on this scenario 789 (showing an inbound request to the AOR) is detailed in 790 Section 5.1.4.2 of this document. 792 5.1.3. Initiating a Session 794 This section covers basic SIP signaling when initiating a call from 795 behind a NAT. 797 5.1.3.1. UDP 799 Initiating a call using UDP (the Edge Proxy and Authoritative Proxy 800 functionality are co-located). 802 Edge Proxy/ 803 Bob NAT Auth. Proxy Alice 804 | | | | 805 |(1) INVITE | | | 806 |----------------->| | | 807 | | | | 808 | |(1) INVITE | | 809 | |----------------->| | 810 | | | | 811 | | |(2) INVITE | 812 | | |---------------->| 813 | | | | 814 | | |(3)180 RINGING | 815 | | |<----------------| 816 | | | | 817 | |(4)180 RINGING | | 818 | |<-----------------| | 819 | | | | 820 |(4)180 RINGING | | | 821 |<-----------------| | | 822 | | | | 823 | | |(5)200 OK | 824 | | |<----------------| 825 | | | | 826 | |(6)200 OK | | 827 | |<-----------------| | 828 | | | | 829 |(6)200 OK | | | 830 |<-----------------| | | 831 | | | | 832 |(7)ACK | | | 833 |----------------->| | | 834 | | | | 835 | |(7)ACK | | 836 | |----------------->| | 837 | | | | 838 | | |(8) ACK | 839 | | |---------------->| 840 | | | | 842 Figure 8: Initiating a Session - UDP 844 The initiating client generates an INVITE request that is to be sent 845 through the NAT to a Proxy server. The INVITE message is represented 846 in Figure 8 by (1) and is as follows: 848 Message 1: 850 INVITE sip:alice@a.example SIP/2.0 851 Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7 852 Max-Forwards: 70 853 From: Bob ;tag=ldw22z 854 To: Alice 855 Call-ID: 95KGsk2V/Eis9LcpBYy3 856 CSeq: 1 INVITE 857 Supported: outbound 858 Route: 859 Contact: 860 Content-Type: application/sdp 861 Content-Length: ... 863 [SDP not shown] 865 There are a number of points to note with this message: 867 1. Firstly, as with the registration example in Section 5.1.1.1, 868 responses to this request will not automatically pass back 869 through a NAT and so the SIP 'Via' header 'rport' is included as 870 described in the 'Symmetric response' Section 4.1.1 and defined 871 in RFC 3581 [RFC3581]. 873 2. Secondly, the contact inserted contains to ensure that all new 874 requests will be sent to the same flow. Alternatively, a GRUU 875 might have been used. See 4.3/[RFC5626]. 877 In (2), the proxy inserts itself in the Via, adds the rport port 878 number in the previous Via header, adds the received parameter in the 879 previous Via, removes the Route header, and inserts a Record-Route 880 with a token. 882 Message 2: 884 INVITE sip:alice@172.16.1.4 SIP/2.0 885 Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi 886 Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7; 887 received=172.16.3.4 888 Max-Forwards: 69 889 From: Bob ;tag=ldw22z 890 To: Alice 891 Call-ID: 95KGsk2V/Eis9LcpBYy3 892 CSeq: 1 INVITE 893 Supported: outbound 894 Record-Route: 895 Contact: 896 Content-Type: application/sdp 897 Content-Length: ... 899 [SDP not shown] 901 5.1.3.2. Connection-oriented Transport 903 When using a reliable transport such as TCP the call flow and 904 procedures for traversing a NAT are almost identical to those 905 described in Section 5.1.3.1. The primary difference when using 906 reliable transport protocols is that Symmetric response[RFC3581] are 907 not required for SIP responses to traverse a NAT. RFC 3261[RFC3261] 908 defines procedures for SIP response messages to be sent back on the 909 same connection on which the request arrived. See section 9.5/ 910 [RFC5626] for an example call flow of an outgoing call. 912 5.1.4. Receiving an Invitation to a Session 914 This section details scenarios where a client behind a NAT receives 915 an inbound request through a NAT. These scenarios build on the 916 previous registration scenario from Section 5.1.1 and Section 5.1.2 917 in this document. 919 5.1.4.1. Registrar/Proxy Co-located 921 The SIP signaling on the interior of the network (behind the user's 922 proxy) is not impacted directly by the transport protocol and so only 923 one example scenario is necessary. The example uses UDP and follows 924 on from the registration installed in the example from 925 Section 5.1.1.1. 927 Edge Proxy 928 Bob NAT Auth. Proxy Alice 929 | | | | 930 |*******************************************************| 931 | Registration Binding Installed in | 932 | section 5.1.1.1 | 933 |*******************************************************| 934 | | | | 935 | | |(1)INVITE | 936 | | |<----------------| 937 | | | | 938 | |(2)INVITE | | 939 | |<-----------------| | 940 | | | | 941 |(2)INVITE | | | 942 |<-----------------| | | 943 | | | | 944 | | | | 946 Figure 9: Receiving an Invitation to a Session 948 An INVITE request arrives at the Authoritative Proxy with a 949 destination pointing to the AOR of that inserted in Section 5.1.1.1. 950 The message is illustrated by (1) in Figure 9 and looks as follows: 952 INVITE sip:bob@example.com SIP/2.0 953 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d 954 Max-Forwards: 70 955 From: External Alice ;tag=02935 956 To: Bob 957 Call-ID: klmvCxVWGp6MxJp2T2mb 958 CSeq: 1 INVITE 959 Contact: 960 Content-Type: application/sdp 961 Content-Length: .. 963 [SDP not shown] 965 The INVITE request matches the registration binding previously 966 installed at the Registrar and the INVITE request-URI is re-written 967 to the selected onward address. The proxy then examines the request 968 URI of the INVITE and compares with its list of connection tuples. 969 It uses the incoming AOR to commence the check for associated open 970 connections/mappings. Once matched, the proxy checks to see if the 971 unique instance identifier (+sip.instance) associated with the 972 binding equals the same instance identifier associated with that 973 connection tuple. The request is then dispatched on the appropriate 974 binding. This is message (2) from Figure 9 and is as follows: 976 INVITE sip:bob@192.168.1.2 SIP/2.0 977 Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4kmlds893jhsd 978 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d 979 Max-Forwards: 69 980 From: Alice ;tag=02935 981 To: client bob 982 Call-ID: klmvCxVWGp6MxJp2T2mb 983 CSeq: 1 INVITE 984 Contact: 985 Content-Type: application/sdp 986 Content-Length: .. 988 [SDP not shown] 990 It is a standard SIP INVITE request with no additional functionality. 991 The major difference being that this request will not be forwarded to 992 the address specified in the Request-URI, as standard SIP rules would 993 enforce but will be sent on the flow associated with the registration 994 binding (look-up procedures in RFC 3263 [RFC3263] are overridden by 995 RFC 5626 [RFC5626]). This then allows the original connection/ 996 mapping from the initial registration process to be re-used. 998 5.1.4.2. Edge Proxy/Authoritative Proxy Not Co-located 1000 The core SIP signaling associated with this call flow is not impacted 1001 directly by the transport protocol and so only one example scenario 1002 is necessary. The example uses UDP and follows on from the 1003 registration installed in the example from Section 5.1.2. 1005 Bob NAT Edge Proxy Auth. Proxy Alice 1006 | | | | | 1007 |***********************************************************| 1008 | Registration Binding Installed in | 1009 | section 5.1.2 | 1010 |***********************************************************| 1011 | | | | | 1012 | | | |(1)INVITE | 1013 | | | |<-------------| 1014 | | | | | 1015 | | |(2)INVITE | | 1016 | | |<-------------| | 1017 | | | | | 1018 | |(3)INVITE | | | 1019 | |<-------------| | | 1020 | | | | | 1021 |(3)INVITE | | | | 1022 |<-------------| | | | 1023 | | | | | 1024 | | | | | 1026 Figure 10: Registrar/Proxy Not Co-located 1028 An INVITE request arrives at the Authoritative Proxy with a 1029 destination pointing to the AOR of that inserted in Section 5.1.2. 1030 The message is illustrated by (1) in Figure 10 and looks as follows: 1032 INVITE sip:bob@example.com SIP/2.0 1033 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d 1034 Max-Forwards: 70 1035 From: Alice ;tag=02935 1036 To: Bob 1037 Call-ID: klmvCxVWGp6MxJp2T2mb 1038 CSeq: 1 INVITE 1039 Contact: 1040 Content-Type: application/sdp 1041 Content-Length: .. 1043 [SDP not shown] 1045 The INVITE request matches the registration binding previously 1046 installed at the Registrar and the INVITE request-URI is re-written 1047 to the selected onward address. The Registrar also identifies that a 1048 SIP PATH header was associated with the registration and pushes it 1049 into the INVITE request in the form of a pre-loaded SIP Route header. 1051 It then forwards the request on to the proxy identified in the SIP 1052 Route header as shown in (2) from Figure 10: 1054 INVITE sip:bob@client.example.com SIP/2.0 1055 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc 1056 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d 1057 Route: 1058 Max-Forwards: 69 1059 From: Alice ;tag=02935 1060 To: Bob 1061 Call-ID: klmvCxVWGp6MxJp2T2mb 1062 CSeq: 1 INVITE 1063 Contact: 1064 Content-Type: application/sdp 1065 Content-Length: .. 1067 [SDP not shown] 1069 The request then arrives at the outbound proxy for the client. The 1070 proxy examines the request URI of the INVITE in conjunction with the 1071 flow token that it previously inserted into the user part of the PATH 1072 header SIP URI (which now appears in the user part of the Route 1073 header in the incoming INVITE). The proxy locates the appropriate 1074 flow and sends the message to the client, as shown in (3) from 1075 Figure 10: 1077 INVITE sip:bob@192.168.1.2 SIP/2.0 1078 Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4nsi30dncmnl 1079 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc 1080 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d 1081 Record-Route: 1082 Max-Forwards: 68 1083 From: Alice ;tag=02935 1084 To: bob 1085 Call-ID: klmvCxVWGp6MxJp2T2mb 1086 CSeq: 1 INVITE 1087 Contact: 1088 Content-Type: application/sdp 1089 Content-Length: .. 1091 [SDP not shown] 1093 It is a standard SIP INVITE request with no additional functionality 1094 at the originator. The major difference being that this request will 1095 not follow the address specified in the Request-URI when it reaches 1096 the outbound proxy, as standard SIP rules would enforce but will be 1097 sent on the flow associated with the registration binding as 1098 indicated in the Route header(look-up procedures in RFC 3263 1099 [RFC3263] are overridden). This then allows the original connection/ 1100 mapping from the initial registration to the outbound proxy to be re- 1101 used. 1103 5.2. Basic NAT Media Traversal 1105 This section provides example scenarios to demonstrate basic media 1106 traversal using the techniques outlined earlier in this document. 1108 In the flow diagrams STUN messages have been annotated for simplicity 1109 as follows: 1111 o The "Src" attribute represents the source transport address of the 1112 message. 1114 o The "Dest" attribute represents the destination transport address 1115 of the message. 1117 o The "Map" attribute represents the server reflexive (XOR-MAPPED- 1118 ADDRESS STUN attribute) transport address. 1120 o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN 1121 attribute) transport address. 1123 The meaning of each STUN attribute is extensively explained in the 1124 core STUN[RFC5389] and TURN [RFC5766] specifications. 1126 A number of ICE SDP attributes have also been included in some of the 1127 examples. Detailed information on individual attributes can be 1128 obtained from the core ICE specification[RFC5245]. 1130 The examples also contain a mechanism for representing transport 1131 addresses. It would be confusing to include representations of 1132 network addresses in the call flows and make them hard to follow. 1133 For this reason network addresses will be represented using the 1134 following annotation. The first component will contain the 1135 representation of the client responsible for the address. For 1136 example in the majority of the examples "L" (left client), "R" (right 1137 client), NAT-PUB" (NAT public), PRIV (Private), and "STUN-PUB" (STUN 1138 Public) are used. To allow for multiple addresses from the same 1139 network element, each representation can also be followed by a 1140 number. These can also be used in combination. For example "L-NAT- 1141 PUB-1" would represent a public network address of the left hand side 1142 NAT while "R-NAT-PUB-1" would represent a public network address of 1143 the right hand side of the NAT. "L-PRIV-1" would represent a private 1144 network address of the left hand side of the NAT while "R-PRIV-1" 1145 represents a private address of the right hand side of the NAT. 1147 It should also be noted that during the examples it might be 1148 appropriate to signify an explicit part of a transport address. This 1149 is achieved by adding either the '.address' or '.port' tag on the end 1150 of the representation. For example, 'L-PRIV-1.address' and 'L-PRIV- 1151 1.port'. 1153 The use of '$' signifies variable parts in example SIP messages. 1155 5.2.1. Endpoint Independent NAT 1157 This section demonstrates an example of a client both initiating and 1158 receiving calls behind an 'Endpoint independent' NAT. An example is 1159 included for both STUN and ICE with ICE being the RECOMMENDED 1160 mechanism for media traversal. 1162 At this time there is no reliable test to determine if a host is 1163 behind an 'endpoint independent filtering' NAT or an 'endpoint 1164 independent mapping' NAT [RFC5780], and the sort of failure that 1165 occurs in this situation is described in Section 5.2.2.1. For this 1166 reason, ICE is RECOMMENDED over the mechanism described in this 1167 section. 1169 5.2.1.1. STUN Solution 1171 It is possible to traverse media through an 'Endpoint Independent NAT 1172 using STUN. The remainder of this section provides simplified 1173 examples of the 'Binding Discovery' STUN as defined in [RFC5389]. 1174 The STUN messages have been simplified and do not include 'Shared 1175 Secret' requests used to obtain the temporary username and password. 1177 5.2.1.1.1. Initiating Session 1179 The following example demonstrates media traversal through a NAT with 1180 'Endpoint-Independent Mapping' properties using the STUN 'Binding 1181 Discovery' usage. It is assumed in this example that the STUN client 1182 and SIP Client are co-located on the same physical machine. Note 1183 that some SIP signaling messages have been left out for simplicity. 1185 Client NAT STUN [..] 1186 Server 1187 | | | | 1188 |(1) BIND Req | | | 1189 |Src=L-PRIV-1 | | | 1190 |Dest=STUN-PUB | | | 1191 |----------------->| | | 1192 | | | | 1193 | |(2) BIND Req | | 1194 | |Src=NAT-PUB-1 | | 1195 | |Dest=STUN-PUB | | 1196 | |----------------->| | 1197 | | | | 1198 | |(3) BIND Resp | | 1199 | |<-----------------| | 1200 | |Src=STUN-PUB | | 1201 | |Dest=NAT-PUB-1 | | 1202 | |Map=NAT-PUB-1 | | 1203 | | | | 1204 |(4) BIND Resp | | | 1205 |<-----------------| | | 1206 |Src=STUN-PUB | | | 1207 |Dest=L-PRIV-1 | | | 1208 |Map=NAT-PUB-1 | | | 1209 | | | | 1210 |(5) BIND Req | | | 1211 |Src=L-PRIV-2 | | | 1212 |Dest=STUN-PUB | | | 1213 |----------------->| | | 1214 | | | | 1215 | |(6) BIND Req | | 1216 | |Src=NAT-PUB-2 | | 1217 | |Dest=STUN-PUB | | 1218 | |----------------->| | 1219 | | | | 1220 | |(7) BIND Resp | | 1221 | |<-----------------| | 1222 | |Src=STUN-PUB | | 1223 | |Dest=NAT-PUB-2 | | 1224 | |Map=NAT-PUB-2 | | 1225 | | | | 1226 |(8) BIND Resp | | | 1227 |<-----------------| | | 1228 |Src=STUN-PUB | | | 1229 |Dest=L-PRIV-2 | | | 1230 |Map=NAT-PUB-2 | | | 1231 | | | | 1232 |(9)SIP INVITE | | | 1233 |----------------->| | | 1234 | | | | 1235 | |(10)SIP INVITE | | 1236 | |------------------------------------>| 1237 | | | | 1238 | | |(11)SIP 200 OK | 1239 | |<------------------------------------| 1240 | | | | 1241 |(12)SIP 200 OK | | | 1242 |<-----------------| | | 1243 | | | | 1244 |========================================================| 1245 |>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>| 1246 |========================================================| 1247 | | 1248 |========================================================| 1249 |<<<<<<<<<<<>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>| 1254 |========================================================| 1255 | | 1256 |========================================================| 1257 |<<<<<<<<<<<| | | 1262 | | | | 1263 | |(14) SIP ACK | | 1264 | |------------------------------------>| 1265 | | | | 1267 Figure 11: Endpoint Independent NAT - Initiating 1269 o On deciding to initiate a SIP voice session the client starts a 1270 local STUN client on the interface and port that is to be used for 1271 media (send/receive). The STUN client generates a standard 1272 'Binding Discovery' request as indicated in (1) from Figure 11 1273 which also highlights the source address and port for which the 1274 client device wishes to obtain a mapping. The 'Binding Discovery' 1275 request is sent through the NAT towards the public internet and 1276 STUN server. 1278 o Message (2) traverses the NAT and breaks out onto the public 1279 internet towards the public STUN server. Note that the source 1280 address of the 'Binding Discovery' request now represents the 1281 public address and port from the public side of the NAT. 1283 o The STUN server receives the request and processes it 1284 appropriately. This results in a successful 'Binding Discovery' 1285 response being generated and returned (3). The message contains 1286 details of the XOR mapped public address (contained in the STUN 1287 XOR-MAPPED-ADDRESS attribute) which is to be used by the 1288 originating client to receive media (see 'Map=NAT-PUB-1' from 1289 (3)). 1291 o The 'Binding Discovery' response traverses back through the NAT 1292 using the path created by the 'Binding Discovery' request and 1293 presents the new XOR mapped address to the client (4). At this 1294 point the process is repeated to obtain a second XOR-mapped 1295 address (as shown in (5)-(8)) for a second local address (Address 1296 has changed from "L-PRIV-1" to "L-PRIV-2") for an RTCP port. 1298 o The client now constructs a SIP INVITE message(9). Note that 1299 traversal of SIP is not covered in this example and is discussed 1300 in Section 5.1. The INVITE request will use the addresses it has 1301 obtained in the previous STUN transactions to populate the SDP of 1302 the SIP INVITE as shown below: 1304 v=0 1305 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address 1306 c=IN IP4 $NAT-PUB-1.address 1307 t=0 0 1308 m=audio $NAT-PUB-1.port RTP/AVP 0 1309 a=rtcp:$NAT-PUB-2.port 1311 o Note that the XOR-mapped address obtained from the 'Binding 1312 Discovery' transactions are inserted as the connection address for 1313 the SDP (c=$NAT-PUB-1.address). The Primary port for RTP is also 1314 inserted in the SDP (m=audio $NAT-PUB-1.port RTP/AVP 0). Finally, 1315 the port gained from the additional 'Binding Discovery' is placed 1316 in the RTCP attribute (as discussed in Section 4.2.2) for 1317 traversal of RTCP (a=rtcp:$NAT-PUB-2.port). 1319 o The SIP signaling then traverses the NAT and sets up the SIP 1320 session (9-12). Note that the left client transmits media as soon 1321 as the 200 OK to the INVITE arrives at the client (12). Up until 1322 this point the incoming media and RTCP to the left hand client 1323 will not pass through the NAT as no outbound association has been 1324 created with the far end client. Two way media communication has 1325 now been established. 1327 5.2.1.1.2. Receiving Session Invitation 1329 Receiving a session for an 'Endpoint Independent' NAT using the STUN 1330 'Binding Discovery' usage is very similar to the example outlined in 1331 Section 5.2.1.1.1. Figure 12 illustrates the associated flow of 1332 messages. 1334 Client NAT STUN [..] 1335 Server 1336 | | | (1)SIP INVITE | 1337 | |<------------------------------------| 1338 | | | | 1339 |(2) SIP INVITE | | | 1340 |<-----------------| | | 1341 | | | | 1342 |(3) BIND Req | | | 1343 |Src=L-PRIV-1 | | | 1344 |Dest=STUN-PUB | | | 1345 |----------------->| | | 1346 | | | | 1347 | |(4) BIND Req | | 1348 | |Src=NAT-PUB-1 | | 1349 | |Dest=STUN-PUB | | 1350 | |----------------->| | 1351 | | | | 1352 | |(5) BIND Resp | | 1353 | |<-----------------| | 1354 | |Src=STUN-PUB | | 1355 | |Dest=NAT-PUB-1 | | 1356 | |Map=NAT-PUB-1 | | 1357 | | | | 1358 |(6) BIND Resp | | | 1359 |<-----------------| | | 1360 |Src=STUN-PUB | | | 1361 |Dest=L-PRIV-1 | | | 1362 |Map=NAT-PUB-1 | | | 1363 | | | | 1364 |(7) BIND Req | | | 1365 |Src=L-PRIV-2 | | | 1366 |Dest=STUN-PUB | | | 1367 |----------------->| | | 1368 | | | | 1369 | |(8) BIND Req | | 1370 | |Src=NAT-PUB-2 | | 1371 | |Dest=STUN-PUB | | 1372 | |----------------->| | 1373 | | | | 1374 | |(9) BIND Resp | | 1375 | |<-----------------| | 1376 | |Src=STUN-PUB | | 1377 | |Dest=NAT-PUB-2 | | 1378 | |Map=NAT-PUB-2 | | 1379 | | | | 1380 |(10) BIND Resp | | | 1381 |<-----------------| | | 1382 |Src=STUN-PUB | | | 1383 |Dest=L-PRIV-2 | | | 1384 |Map=NAT-PUB-2 | | | 1385 | | | | 1386 |(11)SIP 200 OK | | | 1387 |----------------->| | | 1388 | |(12)SIP 200 OK | | 1389 | |------------------------------------>| 1390 | | | | 1391 |========================================================| 1392 |>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>| 1393 |========================================================| 1394 | | | | 1395 |========================================================| 1396 |<<<<<<<<<<<<>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>| 1401 |========================================================| 1402 | | | | 1403 |========================================================| 1404 |<<<<<<<<<<<<| | | | 1503 | | | | | 1504 | |(2) Alloc Req | | | 1505 | |Src=L-NAT-PUB-1 | | | 1506 | |Dest=TURN-PUB-1 | | | 1507 | |--------------->| | | 1508 | | | | | 1509 | |(3) Alloc Resp | | | 1510 | |<---------------| | | 1511 | |Src=TURN-PUB-1 | | | 1512 | |Dest=L-NAT-PUB-1| | | 1513 | |Map=L-NAT-PUB-1 | | | 1514 | |Rel=TURN-PUB-2 | | | 1515 | | | | | 1516 |(4) Alloc Resp | | | | 1517 |<---------------| | | | 1518 |Src=TURN-PUB-1 | | | | 1519 |Dest=L-PRIV-1 | | | | 1520 |Map=L-NAT-PUB-1 | | | | 1521 |Rel=TURN-PUB-2 | | | | 1522 | | | | | 1523 |(5) Alloc Req | | | | 1524 |Src=L-PRIV-2 | | | | 1525 |Dest=TURN-PUB-1 | | | | 1526 |--------------->| | | | 1527 | | | | | 1528 | |(6) Alloc Req | | | 1529 | |Src=L-NAT-PUB-2 | | | 1530 | |Dest=TURN-PUB-1 | | | 1531 | |--------------->| | | 1532 | | | | | 1533 | |(7) Alloc Resp | | | 1534 | |<---------------| | | 1535 | |Src=TURN-PUB-1 | | | 1536 | |Dest=NAT-PUB-2 | | | 1537 | |Map=NAT-PUB-2 | | | 1538 | |Rel=TURN-PUB-3 | | | 1539 | | | | | 1540 |(8) Alloc Resp | | | | 1541 |<---------------| | | | 1542 |Src=TURN-PUB-1 | | | | 1543 |Dest=L-PRIV-2 | | | | 1544 |Map=L-NAT-PUB-2 | | | | 1545 |Rel=TURN-PUB-3 | | | | 1546 | | | | | 1547 |(9) SIP INVITE | | | | 1548 |------------------------------------------------->| | 1549 | | | | | 1550 | | | |(10) SIP INVITE | 1551 | | | |--------------->| 1552 | | | | | 1553 | | | |(11) Alloc Req | 1554 | | | |<---------------| 1555 | | | |Src=R-PRIV-1 | 1556 | | | |Dest=TURN-PUB-1 | 1557 | | | | | 1558 | | |(12) Alloc Req | | 1559 | | |<---------------| | 1560 | | |Src=R-NAT-PUB-1 | | 1561 | | |Dest=TURN-PUB-1 | | 1562 | | | | | 1563 | | |(13) Alloc Res | | 1564 | | |--------------->| | 1565 | | |Src=TURN-PUB-1 | | 1566 | | |Dest=R-NAT-PUB-1| | 1567 | | |Map=R-NAT-PUB-1 | | 1568 | | |Rel=TURN-PUB-4 | | 1569 | | | | | 1570 | | | |(14) Alloc Res | 1571 | | | |--------------->| 1572 | | | |Src=TURN-PUB-1 | 1573 | | | |Dest=R-PRIV-1 | 1574 | | | |Map=R-NAT-PUB-1 | 1575 | | | |Rel=TURN-PUB-4 | 1576 | | | | | 1577 | | | |(15) Alloc Req | 1578 | | | |<---------------| 1579 | | | |Src=R-PRIV-2 | 1580 | | | |Dest=TURN-PUB-1 | 1581 | | | | | 1582 | | |(16) Alloc Req | | 1583 | | |<---------------| | 1584 | | |Src=R-NAT-PUB-2 | | 1585 | | |Dest=TURN-PUB-1 | | 1586 | | | | | 1587 | | |(17) Alloc Res | | 1588 | | |--------------->| | 1589 | | |Src=TURN-PUB-1 | | 1590 | | |Dest=R-NAT-PUB-2| | 1591 | | |Map=R-NAT-PUB-2 | | 1592 | | |Rel=TURN-PUB-5 | | 1593 | | | | | 1594 | | | |(18) Alloc Res | 1595 | | | |--------------->| 1596 | | | |Src=TURN-PUB-1 | 1597 | | | |Dest=R-PRIV-2 | 1598 | | | |Map=R-NAT-PUB-2 | 1599 | | | |Rel=TURN-PUB-5 | 1600 | | | | | 1601 | | | |(19) SIP 200 OK | 1602 | |<-------------------------------------------------| 1603 | | | | | 1604 |(20) SIP 200 OK | | | | 1605 |<---------------| | | | 1606 | | | | | 1607 |(21) SIP ACK | | | | 1608 |------------------------------------------------->| | 1609 | | | | | 1610 | | | |(22) SIP ACK | 1611 | | | |--------------->| 1612 | | | | | 1613 |(23) Bind Req | | | | 1614 |------------------------>x | | | 1615 |Src=L-PRIV-1 | | | | 1616 |Dest=R-PRIV-1 | | | | 1617 | | | | | 1618 |(24) Bind Req | | | | 1619 |--------------->| | | | 1620 |Src=L-PRIV-1 | | | | 1621 |Dest=R-NAT-PUB-1| | | | 1622 | | | | | 1623 | |(25) Bind Req | | | 1624 | |-------------------------------->| | 1625 | |Src=L-NAT-PUB-1 | | | 1626 | |Dest=R-NAT-PUB-1| | | 1627 | | | | | 1628 | | | |(26) Bind Req | 1629 | | | |--------------->| 1630 | | | |Src=L-NAT-PUB-1 | 1631 | | | |Dest=R-PRIV-1 | 1632 | | | | | 1633 | | | |(27) Bind Res | 1634 | | | |<---------------| 1635 | | | |Src=R-PRIV-1 | 1636 | | | |Dest=L-NAT-PUB-1| 1637 | | | |Map=L-NAT-PUB-1 | 1638 | | | | | 1639 | | |(28) Bind Res | | 1640 | |<--------------------------------| | 1641 | | |Src=R-NAT-PUB-1 | | 1642 | | |Dest=L-NAT-PUB-1| | 1643 | | |Map=L-NAT-PUB-1 | | 1644 | | | | | 1645 |(29) Bind Res | | | | 1646 |<---------------| | | | 1647 |Src=R-NAT-PUB-1 | | | | 1648 |Dest=L-PRIV-1 | | | | 1649 |Map=L-NAT-PUB-1 | | | | 1650 | | | | | 1651 |===================================================================| 1652 |>>>>>>>>>>>>>>>>>>Outgoing RTP sent from L-PRIV-1 >>>>>>>>>>>>>>>>>| 1653 |===================================================================| 1654 | | | | | 1655 | | | |(30) Bind Req | 1656 | | | x<-----------------------| 1657 | | | |Src=R-PRIV-1 | 1658 | | | |Dest=L-PRIV-1 | 1659 | | | | | 1660 | | | |(31) Bind Req | 1661 | | | |<---------------| 1662 | | | |Src=R-PRIV-1 | 1663 | | | |Dest=L-NAT-PUB-1| 1664 | | | | | 1665 | | |(32) Bind Req | | 1666 | |<--------------------------------| | 1667 | | |Src=R-NAT-PUB-1 | | 1668 | | |Dest=L-NAT-PUB-1| | 1669 | | | | | 1670 |(33) Bind Req | | | | 1671 |<---------------| | | | 1672 |Src=R-NAT-PUB-1 | | | | 1673 |Dest=L-PRIV-1 | | | | 1674 | | | | | 1675 |(34) Bind Res | | | | 1676 |--------------->| | | | 1677 |Src=L-PRIV-1 | | | | 1678 |Dest=R-NAT-PUB-1| | | | 1679 |Map=R-NAT-PUB-1 | | | | 1680 | | | | | 1681 | |(35) Bind Res | | | 1682 | |-------------------------------->| | 1683 | |Src=L-NAT-PUB-1 | | | 1684 | |Dest=R-NAT-PUB-1| | | 1685 | |Map=R-NAT-PUB-1 | | | 1686 | | | | | 1687 | | | |(36) Bind Res | 1688 | | | |--------------->| 1689 | | | |Src=L-NAT-PUB-1 | 1690 | | | |Dest=R-PRIV-1 | 1691 | | | |Map=R-NAT-PUB-1 | 1692 | | | | | 1693 |===================================================================| 1694 |<<<<<<<<<<<<<<<<<| | | | 1698 |Src=L-PRIV-1 | | | | 1699 |Dest=R-NAT-PUB-1| | | | 1700 |USE-CANDIDATE | | | | 1701 | | | | | 1702 | |(38) Bind Req | | | 1703 | |-------------------------------->| | 1704 | |Src=L-NAT-PUB-1 | | | 1705 | |Dest=R-NAT-PUB-1| | | 1706 | |USE-CANDIDATE | | | 1707 | | | | | 1708 | | | |(39) Bind Req | 1709 | | | |--------------->| 1710 | | | |Src=L-NAT-PUB-1 | 1711 | | | |Dest=R-PRIV-1 | 1712 | | | |USE-CANDIDATE | 1713 | | | | | 1714 | | | |(40) Bind Res | 1715 | | | |<---------------| 1716 | | | |Src=R-PRIV-1 | 1717 | | | |Dest=L-NAT-PUB-1| 1718 | | | |Map=L-NAT-PUB-1 | 1719 | | | | | 1720 | | |(41) Bind Res | | 1721 | |<--------------------------------| | 1722 | | |Src=R-NAT-PUB-1 | | 1723 | | |Dest=L-NAT-PUB-1| | 1724 | | |Map=L-NAT-PUB-1 | | 1725 | | | | | 1726 |(42) Bind Res | | | | 1727 |<---------------| | | | 1728 |Src=R-NAT-PUB-1 | | | | 1729 |Dest=L-PRIV-1 | | | | 1730 |Map=L-NAT-PUB-1 | | | | 1731 | | | | | 1732 |(43) Bind Req | | | | 1733 |--------------->| | | | 1734 |Src=L-PRIV-2 | | | | 1735 |Dest=R-NAT-PUB-2| | | | 1736 | | | | | 1737 | |(44) Bind Req | | | 1738 | |-------------------------------->| | 1739 | |Src=L-NAT-PUB-2 | | | 1740 | |Dest=R-NAT-PUB-2| | | 1741 | | | | | 1742 | | | |(45) Bind Req | 1743 | | | |--------------->| 1744 | | | |Src=L-NAT-PUB-2 | 1745 | | | |Dest=R-PRIV-2 | 1746 | | | | | 1747 | | | |(46) Bind Res | 1748 | | | |<---------------| 1749 | | | |Src=R-PRIV-2 | 1750 | | | |Dest=L-NAT-PUB-2| 1751 | | | |Map=L-NAT-PUB-2 | 1752 | | | | | 1753 | | |(47) Bind Res | | 1754 | |<--------------------------------| | 1755 | | |Src=R-NAT-PUB-2 | | 1756 | | |Dest=L-NAT-PUB-2| | 1757 | | |Map=L-NAT-PUB-2 | | 1758 | | | | | 1759 |(48) Bind Res | | | | 1760 |<---------------| | | | 1761 |Src=R-NAT-PUB-2 | | | | 1762 |Dest=L-PRIV-2 | | | | 1763 |Map=L-NAT-PUB-2 | | | | 1764 | | | | | 1765 |===================================================================| 1766 |>>>>>>>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2 >>>>>>>>>>>>>>>>| 1767 |===================================================================| 1768 | | | | | 1769 | | | |(49) Bind Req | 1770 | | | |<---------------| 1771 | | | |Src=R-PRIV-2 | 1772 | | | |Dest=L-NAT-PUB-2| 1773 | | | | | 1774 | | |(50) Bind Req | | 1775 | |<--------------------------------| | 1776 | | |Src=R-NAT-PUB-2 | | 1777 | | |Dest=L-NAT-PUB-2| | 1778 | | | | | 1779 |(51) Bind Req | | | | 1780 |<---------------| | | | 1781 |Src=R-NAT-PUB-2 | | | | 1782 |Dest=L-PRIV-2 | | | | 1783 | | | | | 1784 |(52) Bind Res | | | | 1785 |--------------->| | | | 1786 |Src=L-PRIV-2 | | | | 1787 |Dest=R-NAT-PUB-2| | | | 1788 |Map=R-NAT-PUB-2 | | | | 1789 | | | | | 1790 | |(53) Bind Res | | | 1791 | |-------------------------------->| | 1792 | |Src=L-NAT-PUB-2 | | | 1793 | |Dest=R-NAT-PUB-2| | | 1794 | |Map=R-NAT-PUB-2 | | | 1795 | | | | | 1796 | | | |(54) Bind Res | 1797 | | | |--------------->| 1798 | | | |Src=L-NAT-PUB-2 | 1799 | | | |Dest=R-PRIV-2 | 1800 | | | |Map=R-NAT-PUB-2 | 1801 | | | | | 1802 |===================================================================| 1803 |<<<<<<<<<<<<<<<<<| | | | 1807 |Src=L-PRIV-2 | | | | 1808 |Dest=R-NAT-PUB-2| | | | 1809 |USE-CANDIDATE | | | | 1810 | | | | | 1811 | |(56) Bind Req | | | 1812 | |-------------------------------->| | 1813 | |Src=L-NAT-PUB-2 | | | 1814 | |Dest=R-NAT-PUB-2| | | 1815 | |USE-CANDIDATE | | | 1816 | | | | | 1817 | | | |(57) Bind Req | 1818 | | | |--------------->| 1819 | | | |Src=L-NAT-PUB-2 | 1820 | | | |Dest=R-PRIV-2 | 1821 | | | |USE-CANDIDATE | 1822 | | | | | 1823 | | | |(58) Bind Res | 1824 | | | |<---------------| 1825 | | | |Src=R-PRIV-2 | 1826 | | | |Dest=L-NAT-PUB-2| 1827 | | | |Map=L-NAT-PUB-2 | 1828 | | | | | 1829 | | |(59) Bind Res | | 1830 | |<--------------------------------| | 1831 | | |Src=R-NAT-PUB-2 | | 1832 | | |Dest=L-NAT-PUB-2| | 1833 | | |Map=L-NAT-PUB-2 | | 1834 | | | | | 1835 |(60) Bind Res | | | | 1836 |<---------------| | | | 1837 |Src=R-NAT-PUB-2 | | | | 1838 |Dest=L-PRIV-2 | | | | 1839 |Map=L-NAT-PUB-2 | | | | 1840 | | | | | 1841 | | | | | 1842 |(61) SIP INVITE | | | | 1843 |------------------------------------------------->| | 1844 | | | | | 1845 | | | |(62) SIP INVITE | 1846 | | | |--------------->| 1847 | | | | | 1848 | | | |(63) SIP 200 OK | 1849 | |<-------------------------------------------------| 1850 | | | | | 1851 |(64) SIP 200 OK | | | | 1852 |<---------------| | | | 1853 | | | | | 1854 |(65) SIP ACK | | | | 1855 |------------------------------------------------->| | 1856 | | | | | 1857 | | | |(66) SIP ACK | 1858 | | | |--------------->| 1859 | | | | | 1861 Figure 13: Endpoint Independent NAT with ICE 1863 o On deciding to initiate a SIP voice session the SIP client 'L' 1864 starts a local STUN client. The STUN client generates a TURN 1865 Allocate request as indicated in (1) from Figure 13 which also 1866 highlights the source address and port combination for which the 1867 client device wishes to obtain a mapping. The Allocate request is 1868 sent through the NAT towards the public internet. 1870 o The Allocate message (2) traverses the NAT to the public internet 1871 towards the public TURN server. Note that the source address of 1872 the Allocate request now represents the public address and port 1873 from the public side of the NAT (L-NAT-PUB-1). 1875 o The TURN server receives the Allocate request and processes it 1876 appropriately. This results in a successful Allocate response 1877 being generated and returned (3). The message contains details of 1878 the server reflexive address which is to be used by the 1879 originating client to receive media (see 'Map=L-NAT-PUB-1') from 1880 (3)). It also contains an appropriate TURN-relayed address that 1881 can be used at the STUN server (see 'Rel=TURN-PUB-2'). 1883 o The Allocate response traverses back through the NAT using the 1884 binding created by the initial Allocate request and presents the 1885 new mapped address to the client (4). The process is repeated and 1886 a second STUN derived set of address' are obtained, as illustrated 1887 in (5)-(8) in Figure 13. At this point the User Agent behind the 1888 NAT has pairs of derived external server reflexive and relayed 1889 representations. The client can also gather IP addresses and 1890 ports via other mechanisms (e.g., NAT-PMP[I-D.cheshire-nat-pmp], 1891 UPnP IGD[UPnP-IGD]) or similar. 1893 o The client now constructs a SIP INVITE message (9). The INVITE 1894 request will use the addresses it has obtained in the previous 1895 STUN/TURN interactions to populate the SDP of the SIP INVITE. 1896 This should be carried out in accordance with the semantics 1897 defined in the ICE specification[RFC5245], as shown below in 1898 Figure 14: 1900 v=0 1901 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1 1902 c=IN IP4 $L-PRIV-1.address 1903 t=0 0 1904 a=ice-pwd:$LPASS 1905 a=ice-ufrag:$LUNAME 1906 m=audio $L-PRIV-1.port RTP/AVP 0 1907 a=rtpmap:0 PCMU/8000 1908 a=rtcp:$L-PRIV-2.port 1909 a=candidate:$L1 1 UDP 2130706431 $L-PRIV-1.address $L-PRIV-1.port 1910 typ host 1911 a=candidate:$L1 2 UDP 2130706430 $L-PRIV-2.address $L-PRIV-2.port 1912 typ host 1913 a=candidate:$L2 1 UDP 1694498815 $L-NAT-PUB-1.address $L-NAT-PUB-1.port 1914 typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port 1915 a=candidate:$L2 2 UDP 1694498814 $L-NAT-PUB-2.address $L-NAT-PUB-2.port 1916 typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port 1917 a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-2.port 1918 typ relay raddr $L-PRIV-1.address rport $L-PRIV-1.port 1919 a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-3.port 1920 typ relay raddr $L-PRIV-1.address rport $L-PRIV-2.port 1922 Figure 14: ICE SDP Offer 1924 o The SDP has been constructed to include all the available 1925 candidates that have been assembled. The first set of candidates 1926 (as identified by Foundation $L1) contain two local addresses that 1927 have the highest priority. They are also encoded into the 1928 connection (c=) and media (m=) lines of the SDP. The second set 1929 of candidates, as identified by Foundation $L2, contains the two 1930 server reflexive addresses obtained from the STUN server for both 1931 RTP and RTCP traffic (identified by candidate-id $L2). This entry 1932 has been given a priority lower than the pair $L1 by the client. 1933 The third and final set of candidates represents the relayed 1934 addresses (as identified by $L3) obtained from the STUN server. 1935 This pair has the lowest priority and will be used as a last 1936 resort if both $L1 or $L2 fail. 1938 o The SIP signaling then traverses the NAT and sets up the SIP 1939 session (9)-(10). On advertising a candidate address, the client 1940 should have a local STUN server running on each advertised 1941 candidate address. This is for the purpose of responding to 1942 incoming STUN connectivity checks. 1944 o On receiving the SIP INVITE request (10) client 'R' also starts 1945 local STUN servers on appropriate address/port combinations and 1946 gathers potential candidate addresses to be encoded into the SDP 1947 (as the originating client did). Steps (11-18) involve client 'R' 1948 carrying out the same steps as client 'L'. This involves 1949 obtaining local, server reflexive and relayed addresses. Client 1950 'R' is now ready to generate an appropriate answer in the SIP 200 1951 OK message (19). The example answer follows in Figure 14: 1953 v=0 1954 o=test 3890844516 3890842803 IN IP4 $R-PRIV-1 1955 c=IN IP4 $R-PRIV-1.address 1956 t=0 0 1957 a=ice-pwd:$RPASS 1958 m=audio $R-PRIV-1.port RTP/AVP 0 1959 a=rtpmap:0 PCMU/8000 1960 a=rtcp:$R-PRIV-2.port 1961 a=candidate:$L1 1 UDP 2130706431 $R-PRIV-1.address $R-PRIV-1.port 1962 typ host 1963 a=candidate:$L1 2 UDP 2130706430 $R-PRIV-2.address $R-PRIV-2.port 1964 typ host 1965 a=candidate:$L2 1 UDP 1694498815 $R-NAT-PUB-1.address $R-NAT-PUB-1.port 1966 typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port 1967 a=candidate:$L2 2 UDP 1694498814 $R-NAT-PUB-2.address $R-NAT-PUB-2.port 1968 typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port 1969 a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-4.port 1970 typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port 1971 a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-5.port 1972 typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port 1974 Figure 15: ICE SDP Answer 1976 o The two clients have now exchanged SDP using offer/answer and can 1977 now continue with the ICE processing - User Agent 'L' assuming the 1978 role controlling agent, as specified by ICE. The clients are now 1979 required to form their Candidate check lists to determine which 1980 will be used for the media streams. In this example User Agent 1981 'L's 'Foundation 1' is paired with User Agent 'R's 'Foundation 1', 1982 User Agent 'L's 'Foundation 2' is paired with User Agent 'R's 1983 'Foundation 2', and finally User Agent 'L's 'Foundation 3' is 1984 paired with User Agent 'R's 'Foundation 3'. User Agents 'L' and 1985 'R' now have a complete candidate check list. Both clients now 1986 use the algorithm provided in ICE to determine candidate pair 1987 priorities and sort into a list of decreasing priorities. In this 1988 example, both User Agent 'L' and 'R' will have lists that firstly 1989 specifies the host address (Foundation $L1), then the server 1990 reflexive address (Foundation $L2) and lastly the relayed address 1991 (Foundation $L3). All candidate pairs have an associate state as 1992 specified in ICE. At this stage, all of the candidate pairs for 1993 User Agents 'L' and 'R' are initialized to the 'Frozen' state. 1994 The User Agents then scan the list and move the candidates to the 1995 'Waiting' state. At this point both clients will periodically, 1996 starting with the highest candidate pair priority, work their way 1997 down the list issuing STUN checks from the local candidate to the 1998 remote candidate (of the candidate pair). As a STUN Check is 1999 attempted from each local candidate in the list, the candidate 2000 pair state transitions to 'In-Progress'. As illustrated in (23), 2001 client 'L' constructs a STUN connectivity check in an attempt to 2002 validate the remote candidate address received in the SDP of the 2003 200 OK (20) for the highest priority in the check list. As a 2004 private address was specified in the active address in the SDP, 2005 the STUN connectivity check fails to reach its destination causing 2006 a STUN failure. Client 'L' transitions the state for this 2007 candidate pair to 'Failed'. In the mean time, Client 'L' is 2008 attempting a STUN connectivity check for the second candidate pair 2009 in the returned SDP with the second highest priority (24). As can 2010 be seen from messages (24) to (29), the STUN Bind request is 2011 successful and returns a positive outcome for the connectivity 2012 check. Client 'L' is now free to send media to the peer using the 2013 candidate pair. Immediately after sending its 200 Okay, Client 2014 'R' also carries out the same set of binding requests. It firstly 2015 (in parallel) tries to contact the active address contained in the 2016 SDP (30) which results in failure. 2018 o In the mean time, a successful response to a STUN connectivity 2019 check by User Agent 'R' (27) results in a tentative check in the 2020 reverse direction - this is illustrated by messages (31) to (36). 2021 Once this check has succeeded, User Agent 'R' can transition the 2022 state of the appropriate candidate to 'Succeeded', and media can 2023 be sent (RTP). The previously (31-36) described check confirm on 2024 both sides (User Agent 'L' and 'R') that connectivity can be 2025 achieved using the appropriate candidate pair. User Agent 'L', as 2026 the controlling client now sends another connectivity check for 2027 the candidate pair, this time including the 'USE-CANDIDATE' 2028 attribute as specified in ICE to signal the chosen candidate. 2029 This exchange is illustrated in messages (37) to (42). 2031 o As part of the process in this example, both 'L' and 'R' will now 2032 complete the same connectivity checks for part 2 of the component 2033 named for the favored 'Foundation' selected for use with RTCP. 2034 The connectivity checks for part '2' of the candidate component 2035 are shown in 'L'(43-48) and 'R'(49-54). Once this has succeeded, 2036 User Agent 'L' as the controlling client sends another 2037 connectivity check for the candidate pair. This time the 'USE- 2038 CANDIDATE' attribute is again specified to signal the chosen 2039 candidate for component '2'. 2041 o The candidates have now been fully verified (and selected) and as 2042 they are the highest priority, an updated offer (61-62) is now 2043 sent from the offerer (client 'L') to the answerer (client 'R') 2044 representing the new active candidates. The new offer would look 2045 as follows: 2047 v=0 2048 o=test 2890844526 2890842808 IN IP4 $L-PRIV-1 2049 c=IN IP4 $L-NAT-PUB-1.address 2050 t=0 0 2051 a=ice-pwd:$LPASS 2052 a=ice-ufrag:$LUNAME 2053 m=audio $L-NAT-PUB-1.port RTP/AVP 0 2054 a=rtpmap:0 PCMU/8000 2055 a=rtcp:$L-NAT-PUB-2.port 2056 a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port 2057 typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port 2058 a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port 2059 typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port 2061 Figure 16: ICE SDP Updated Offer 2063 o The resulting answer (63-64) for 'R' would look as follows: 2065 v=0 2066 o=test 3890844516 3890842804 IN IP4 $R-PRIV-1 2067 c=IN IP4 $R-PRIV-1.address 2068 t=0 0 2069 a=ice-pwd:$RPASS 2070 a=ice-ufrag:$RUNAME 2071 m=audio $R-PRIV-1.port RTP/AVP 0 2072 a=rtpmap:0 PCMU/8000 2073 a=rtcp:$R-PRIV-2.port 2074 a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port 2075 typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port 2076 a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port 2077 typ srflx raddr $R-PRIV-1.address rport $R-PRIV-2.port 2079 Figure 17: ICE SDP Updated Answer 2081 5.2.2. Address/Port-Dependent NAT 2083 5.2.2.1. STUN Failure 2085 This section highlights that while using STUN techniques is the 2086 preferred mechanism for traversal of NAT, it does not solve every 2087 case. The use of basic STUN on its own will not guarantee traversal 2088 through every NAT type, hence the recommendation that ICE is the 2089 preferred option. 2091 Client PORT/ADDRESS-Dependant STUN [..] 2092 NAT Server 2093 | | | | 2094 |(1) BIND Req | | | 2095 |Src=L-PRIV-1 | | | 2096 |Dest=STUN-PUB | | | 2097 |----------------->| | | 2098 | | | | 2099 | |(2) BIND Req | | 2100 | |Src=NAT-PUB-1 | | 2101 | |Dest=STUN-PUB | | 2102 | |----------------->| | 2103 | | | | 2104 | |(3) BIND Resp | | 2105 | |<-----------------| | 2106 | |Src=STUN-PUB | | 2107 | |Dest=NAT-PUB-1 | | 2108 | |Map=NAT-PUB-1 | | 2109 | | | | 2110 |(4) BIND Resp | | | 2111 |<-----------------| | | 2112 |Src=STUN-PUB | | | 2113 |Dest=L-PRIV-1 | | | 2114 |Map=NAT-PUB-1 | | | 2115 | | | | 2116 |(5)SIP INVITE | | | 2117 |------------------------------------------------------->| 2118 | | | | 2119 | | |(6)SIP 200 OK | 2120 | |<------------------------------------| 2121 | | | | 2122 |(7)SIP 200 OK | | | 2123 |<-----------------| | | 2124 | | | | 2125 |========================================================| 2126 |>>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>| 2127 |========================================================| 2128 | | | | 2129 | x=====================================| 2130 | xIncoming Media sent to L-PRIV-1<<<<<<| 2131 | x=====================================| 2132 | | | | 2133 |(8)SIP ACK | | | 2134 |----------------->| | | 2135 | |(9) SIP ACK | | 2136 | |------------------------------------>| 2137 | | | | 2138 Figure 18: Port/Address-Dependant NAT with STUN - Failure 2140 The example in Figure 18 is conveyed in the context of a client 2141 behind the 'Port/Address-Dependant' NAT initiating a call. It should 2142 be noted that the same problem applies when a client receives a SIP 2143 invitation and is behind a Port/Address-Dependant NAT. 2145 o In Figure 18 the client behind the NAT obtains a server reflexive 2146 representation using standard STUN mechanisms (1)-(4) that have 2147 been used in previous examples in this document (e.g 2148 Section 5.2.1.1.1). 2150 o The external mapped address (server reflexive) obtained is also 2151 used in the outgoing SDP contained in the SIP INVITE request(5). 2153 o In this example the client is still able to send media to the 2154 external client. The problem occurs when the client outside the 2155 NAT tries to use the reflexive address supplied in the outgoing 2156 INVITE request to traverse media back through the 'Port/Address 2157 Dependent' NAT. 2159 o A 'Port/Address-Dependant' NAT has differing rules from the 2160 'Endpoint Independent' type of NAT (as defined in RFC4787 2161 [RFC4787]). For any internal IP address and port combination, 2162 data sent to a different external destination does not provide the 2163 same public mapping at the NAT. In Figure 18 the STUN query 2164 produced a valid external mapping for receiving media. This 2165 mapping, however, can only be used in the context of the original 2166 STUN request that was sent to the STUN server. Any packets that 2167 attempt to use the mapped address, that do not originate from the 2168 STUN server IP address and optionally port, will be dropped at the 2169 NAT. Figure 18 shows the media being dropped at the NAT after (7) 2170 and before (8). This then leads to one way audio. 2172 5.2.2.2. TURN Solution 2174 As identified in Section 5.2.2.1, STUN provides a useful tool for the 2175 traversal of the majority of NATs but fails with Port/Address 2176 Dependent NAT. The TURN extensions [RFC5766] address this scenario. 2177 TURN extends STUN to allow a client to request a relayed address at 2178 the TURN server rather than a reflexive representation. This then 2179 introduces a media relay in the path for NAT traversal (as described 2180 in Section 4.2.3.2). The following example explains how TURN solves 2181 the previous failure when using STUN to traverse a 'Port/Address 2182 Dependent' type NAT. It should be noted that TURN works most 2183 effectively when used in conjunction with ICE. Using TURN on its own 2184 results in all media being relayed through a TURN server which is not 2185 efficient. 2187 L Port/Address-Dependant TURN [..] 2188 NAT Server 2189 | | | | 2190 |(1) Alloc Req | | | 2191 |Src=L-PRIV-1 | | | 2192 |Dest=STUN-PUB-1 | | | 2193 |----------------->| | | 2194 | | | | 2195 | |(2) Alloc Req | | 2196 | |Src=NAT-PUB-1 | | 2197 | |Dest=STUN-PUB-1 | | 2198 | |----------------->| | 2199 | | | | 2200 | |(3) Alloc Resp | | 2201 | |<-----------------| | 2202 | |Src=STUN-PUB-1 | | 2203 | |Dest=NAT-PUB-1 | | 2204 | |Map=NAT-PUB-1 | | 2205 | |Rel=STUN-PUB-2 | | 2206 | | | | 2207 |(4) Alloc Resp | | | 2208 |<-----------------| | | 2209 |Src=STUN-PUB-1 | | | 2210 |Dest=L-PRIV-1 | | | 2211 |Map=NAT-PUB-1 | | | 2212 |Rel=STUN-PUB-2 | | | 2213 | | | | 2214 |(5) Alloc Req | | | 2215 |Src=L-PRIV-2 | | | 2216 |Dest=STUN-PUB-1 | | | 2217 |----------------->| | | 2218 | | | | 2219 | |(6) Alloc Req | | 2220 | |Src=NAT-PUB-2 | | 2221 | |Dest=STUN-PUB-1 | | 2222 | |----------------->| | 2223 | | | | 2224 | |(7) Alloc Resp | | 2225 | |<-----------------| | 2226 | |Src=STUN-PUB-1 | | 2227 | |Dest=NAT-PUB-2 | | 2228 | |Map=NAT-PUB-2 | | 2229 | |Rel=STUN-PUB-3 | | 2230 | | | | 2231 |(8) Alloc Resp | | | 2232 |<-----------------| | | 2233 |Src=STUN-PUB-1 | | | 2234 |Dest=L-PRIV-2 | | | 2235 |Map=NAT-PUB-2 | | | 2236 |Rel=STUN-PUB-3 | | | 2237 | | | | 2238 |(9)SIP INVITE | | | 2239 |----------------->| | | 2240 | | | | 2241 | |(10)SIP INVITE | | 2242 | |------------------------------------>| 2243 | | | | 2244 | | |(11)SIP 200 OK | 2245 | |<------------------------------------| 2246 | | | | 2247 |(12)SIP 200 OK | | | 2248 |<-----------------| | | 2249 | | | | 2250 |========================================================| 2251 |>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>| 2252 |========================================================| 2253 | | | | 2254 | | |==================| 2255 | | |<<| 2265 | | |<<<| | | 2274 | | | | 2275 | |(14) SIP ACK | | 2276 | |------------------------------------>| 2277 | | | | 2279 Figure 19: Port/Address-Dependant NAT with TURN - Success 2281 o In this example, client 'L' issues a TURN allocate request(1) to 2282 obtained a relay address at the STUN server. The request 2283 traverses through the 'Port/Address-Dependant' NAT and reaches the 2284 STUN server (2). The STUN server generates an Allocate response 2285 (3) that contains both a server reflexive address (Map=NAT-PUB-1) 2286 of the client and also a relayed address (Rel=STUN-PUB-2). The 2287 relayed address maps to an address mapping on the STUN server 2288 which is bound to the public pin hole that has been opened on the 2289 NAT by the Allocate request. This results in any traffic sent to 2290 the TURN server relayed address (Rel=STUN-PUB-2) being forwarded 2291 to the external representation of the pin hole created by the 2292 Allocate request(NAT-PUB-1). 2294 o The TURN derived address (STUN-PUB-2) arrives back at the 2295 originating client (4) in an Allocate response. This address can 2296 then be used in the SDP for the outgoing SIP INVITE request as 2297 shown in the following example (note that the example also 2298 includes client 'L' obtaining a second relay address for use in 2299 the RTCP attribute (5-8)): 2301 v=0 2302 o=test 2890844342 2890842164 IN IP4 $L-PRIV-1 2303 c=IN IP4 $STUN-PUB-2.address 2304 t=0 0 2305 m=audio $STUN-PUB-2.port RTP/AVP 0 2306 a=rtcp:$STUN-PUB-3.port 2308 o On receiving the INVITE request, the UAS is able to stream media 2309 and RTCP to the relay address (STUN-PUB-2 and STUN-PUB-3) at the 2310 STUN server. As shown in Figure 19 (between messages (12) and 2311 (13), the media from the UAS is directed to the relayed address at 2312 the STUN server. The STUN server then forwards the traffic to the 2313 open pin holes in the Port/Address-Dependant NAT (NAT-PUB-1 and 2314 NAT-PUB-2). The media traffic is then able to traverse the 'Port/ 2315 Address-Dependant' NAT and arrives back at client 'L'. 2317 o TURN on its own will work for 'Port/Address-Dependent' and other 2318 types of NAT mentioned in this specification but should only be 2319 used as a last resort. The relaying of media through an external 2320 entity is not an efficient mechanism for NAT traversal and comes 2321 at a high processing cost. 2323 5.2.2.3. ICE Solution 2325 The previous two examples have highlighted the problem with using 2326 core STUN for all forms of NAT traversal and a solution using TURN 2327 for the Address/Port-Dependent NAT case. The RECOMMENDED mechanism 2328 for traversing all varieties of NAT is using ICE, as detailed in 2329 Section 4.2.3.3. ICE makes use of core STUN, TURN and any other 2330 mechanism (e.g., NAT-PMP[I-D.cheshire-nat-pmp], UPnP IGD[UPnP-IGD]) 2331 to provide a list of prioritized addresses that can be used for media 2332 traffic. Detailed examples of ICE can be found in Section 5.2.1.2.1. 2333 These examples are associated with an 'Endpoint-Independent' type NAT 2334 but can be applied to any NAT type variation, including 'Address/ 2335 Port-Dependant' type NAT. The ICE procedures carried out are the 2336 same. For a list of candidate addresses, a client will choose where 2337 to send media dependant on the results of the STUN connectivity 2338 checks and associated priority (highest priority wins). It should be 2339 noted that the inclusion of a NAT displaying Address/Port-Dependent 2340 properties does not automatically result in relayed media. In fact, 2341 ICE processing will avoid use of media relay with the exception of 2342 two clients which both happen to be behind a NAT using Address/ 2343 Port-Dependent characteristics. The connectivity checks and 2344 associated selection algorithm enable traversal in this case. 2345 Figure 20 and following description provide a guide as to how this is 2346 achieved using the ICE connectivity checks. This is an abbreviated 2347 example that assumes successful SIP offer/answer exchange and 2348 illustrates the connectivity check flow. 2350 L Port/Address-Dependent Endpoint-Independent R 2351 L-NAT R-NAT 2352 |========================================================| 2353 | SIP OFFER/ANSWER EXCHANGE | 2354 |========================================================| 2355 | | | | 2356 | | |(1)Bind Req | 2357 | | |<-----------------| 2358 | | |Src=R=PRIV-1 | 2359 | | |Dest=L-NAT-PUB-1 | 2360 | | | | 2361 | |(2)Bind Req | | 2362 | x<-----------------| | 2363 | |Src=R-NAT-PUB-1 | | 2364 | |Dest=L-NAT-PUB-1 | | 2365 | | | | 2366 |(3)Bind Req | | | 2367 |----------------->| | | 2368 |Src=L-PRIV-1 | | | 2369 |Dest=R-NAT-PUB-1 | | | 2370 | | | | 2371 | |(4)Bind Req | | 2372 | |----------------->| | 2373 | |Src=L-NAT-PUB-1 | | 2374 | |Dest=R-NAT-PUB-1 | | 2375 | | | | 2376 | | |(5)Bind Req | 2377 | | |----------------->| 2378 | | |Src=L-NAT-PUB-1 | 2379 | | |Dest=R-PRIV-1 | 2380 | | | | 2381 | | |(6)Bind Resp | 2382 | | |<-----------------| 2383 | | |Src=R-PRIV-1 | 2384 | | |Dest=L-NAT-PUB-1 | 2385 | | | | 2386 | |(7)Bind Resp | | 2387 | |<-----------------| | 2388 | |Src=R-NAT-PUB-1 | | 2389 | |Dest=L-NAT-PUB-1 | | 2390 | | | | 2391 |(8)Bind Resp | | | 2392 |<-----------------| | | 2393 |Src=R-NAT-PUB-1 | | | 2394 |Dest=L-PRIV-1 | | | 2395 | | | | 2396 | | |(9)Bind Req | 2397 | | |<-----------------| 2398 | | |Src=R-Priv-1 | 2399 | | |Dest=L-NAT-PUB-1 | 2400 | |(10)Bind Req | | 2401 | |<-----------------| | 2402 | |Src=R-NAT-PUB-1 | | 2403 | |Dest=L-NAT-PUB-1 | | 2404 | | | | 2405 |(11)Bind Req | | | 2406 |<-----------------| | | 2407 |Src=R-NAT-PUB-1 | | | 2408 |Dest=L-PRIV-1 | | | 2409 | | | | 2410 |(12)Bind Resp | | | 2411 |----------------->| | | 2412 |Src=L-PRIV-1 | | | 2413 |Dest=L-NAT-PUB-1 | | | 2414 | | | | 2415 | |(13)Bind Resp | | 2416 | |----------------->| | 2417 | |Src=L-NAT-PUB-1 | | 2418 | |Dest=R-NAT-PUB-1 | | 2419 | | | | 2420 | | |(14)Bind Resp | 2421 | | |----------------->| 2422 | | |Src=L-NAT-PUB-1 | 2423 | | |Dest=R-PRIV-1 | 2424 | | | | 2425 | 2427 Figure 20: Single Port/Address-Dependant NAT - Success 2429 In this abbreviated example, Client R has already received a SIP 2430 INVITE request and is starting its connectivity checks with Client L. 2431 Client R generates a connectivity check (1) and sends to client L's 2432 information as presented in the SDP offer. The request arrives at 2433 client L's Port/Address dependent NAT and fails to traverse as there 2434 is no NAT binding. This would then move the connectivity check to a 2435 failed state. In the mean time client L has received the SDP answer 2436 in the SIP request and will also commence connectivity checks. A 2437 check is dispatched (3) to Client R. The check is able to traverse 2438 the NAT due to the association set up in the previously failed 2439 check(1). The full Bind request/response is shown in steps (3)-(8). 2440 As part of a candidate pair, Client R will now successfully be able 2441 to complete the checks, as illustrated in steps (9)-(14). The result 2442 is a successful pair of candidates that can be used without the need 2443 to relay any media. 2445 In conclusion, the only time media needs to be relayed is a result of 2446 clients both behind Address/Port Dependant NAT type. As you can see 2447 from the example in this section, neither side would be able to 2448 complete connectivity checks with the exception of the Relayed 2449 candidates. 2451 6. IPv4-IPv6 Transition 2453 This section describes how IPv6-only SIP user agents can communicate 2454 with IPv4-only SIP user agents. While the techniques discussed in 2455 this draft primarily contain examples of traversing NATs to allow 2456 communications between hosts in private and public networks, they are 2457 by no means limited to such scenarios. The same NAT traversal 2458 techniques can also be used to establish communication in a 2459 heterogeneous network environment -- e.g., communication between an 2460 IPv4 host and an IPv6 host. 2462 6.1. IPv4-IPv6 Transition for SIP Signaling 2464 IPv4-IPv6 translations at the SIP level usually take place at dual- 2465 stack proxies that have both IPv4 and IPv6 DNS entries. Since this 2466 translations do not involve NATs that are placed in the middle of two 2467 SIP entities, they fall outside the scope of this document. A 2468 detailed description of this type of translation can be found in 2469 [I-D.ietf-sipping-v6-transition] 2471 7. Security Considerations 2473 There are no Security Considerations beyond the ones inherited by 2474 reference. 2476 8. IANA Considerations 2478 There are no IANA Considerations. 2480 9. IAB Considerations 2482 There are no IAB considerations. 2484 10. Acknowledgments 2486 The authors would like to thank the members of the IETF SIPPING WG 2487 for their comments and suggestions. Expert review and detailed 2488 contribution including text was provided by Dan Wing who was 2489 supportive throughout. 2491 Detailed comments were provided by Vijay Gurbani, kaiduan xie, Remi 2492 Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins and 2493 Hans Persson. 2495 11. References 2497 11.1. Normative References 2499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2500 Requirement Levels", BCP 14, RFC 2119, March 1997. 2502 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2503 A., Peterson, J., Sparks, R., Handley, M., and E. 2504 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2505 June 2002. 2507 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 2508 Protocol (SIP): Locating SIP Servers", RFC 3263, 2509 June 2002. 2511 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2512 with Session Description Protocol (SDP)", RFC 3264, 2513 June 2002. 2515 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 2516 (SIP) Extension Header Field for Registering Non-Adjacent 2517 Contacts", RFC 3327, December 2002. 2519 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2520 Jacobson, "RTP: A Transport Protocol for Real-Time 2521 Applications", STD 64, RFC 3550, July 2003. 2523 [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the 2524 Session Initiation Protocol (SIP) for Symmetric Response 2525 Routing", RFC 3581, August 2003. 2527 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2528 in Session Description Protocol (SDP)", RFC 3605, 2529 October 2003. 2531 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2532 Description Protocol", RFC 4566, July 2006. 2534 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2535 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2536 RFC 4787, January 2007. 2538 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2539 BCP 131, RFC 4961, July 2007. 2541 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2542 (ICE): A Protocol for Network Address Translator (NAT) 2543 Traversal for Offer/Answer Protocols", RFC 5245, 2544 April 2010. 2546 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2547 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2548 October 2008. 2550 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 2551 Initiated Connections in the Session Initiation Protocol 2552 (SIP)", RFC 5626, October 2009. 2554 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2555 Control Packets on a Single Port", RFC 5761, April 2010. 2557 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 2558 Relays around NAT (TURN): Relay Extensions to Session 2559 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 2561 [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in 2562 the Session Initiation Protocol (SIP)", RFC 5923, 2563 June 2010. 2565 11.2. Informative References 2567 [I-D.cheshire-nat-pmp] 2568 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 2569 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 2571 [I-D.ietf-mmusic-media-path-middleboxes] 2572 Stucker, B. and H. Tschofenig, "Analysis of Middlebox 2573 Interactions for Signaling Protocol Communication along 2574 the Media Path", 2575 draft-ietf-mmusic-media-path-middleboxes-03 (work in 2576 progress), July 2010. 2578 [I-D.ietf-sipping-v6-transition] 2579 Camarillo, G., "IPv6 Transition in the Session Initiation 2580 Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work 2581 in progress), August 2007. 2583 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2584 3", BCP 9, RFC 2026, October 1996. 2586 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 2587 Self-Address Fixing (UNSAF) Across Network Address 2588 Translation", RFC 3424, November 2002. 2590 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 2591 Using Session Traversal Utilities for NAT (STUN)", 2592 RFC 5780, May 2010. 2594 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 2595 A., and M. Bhatia, "Requirements from Session Initiation 2596 Protocol (SIP) Session Border Control (SBC) Deployments", 2597 RFC 5853, April 2010. 2599 [UPnP-IGD] 2600 UPnP Forum, "Universal Plug and Play Internet Gateway 2601 Device v1.0", 2000, 2602 . 2604 Authors' Addresses 2606 Chris Boulton 2607 NS-Technologies 2609 Email: chris@ns-technologies.com 2611 Jonathan Rosenberg 2612 Skype 2614 Email: jdrosen@jdrosen.net 2616 Gonzalo Camarillo 2617 Ericsson 2618 Hirsalantie 11 2619 Jorvas 02420 2620 Finland 2622 Email: Gonzalo.Camarillo@ericsson.com 2624 Francois Audet 2625 Skype 2627 Email: francois.audet@skype.net