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