idnits 2.17.1 draft-ietf-sipping-nat-scenarios-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2686. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2710. 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 Copyright Line does not match the current year == Line 2625 has weird spacing: '...ication along...' -- 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 (September 17, 2008) is 5701 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) == Unused Reference: 'RFC2766' is defined on line 2542, but no explicit reference was found in the text == Unused Reference: 'RFC3388' is defined on line 2558, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sip-gruu' is defined on line 2596, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 3388 (Obsoleted by RFC 5888) == Outdated reference: A later version (-14) exists of draft-ietf-sip-connect-reuse-11 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-09 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-15 == Outdated reference: A later version (-09) exists of draft-ietf-sipping-sbc-funcs-06 == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-media-path-middleboxes-01 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group C. Boulton, Ed. 3 Internet-Draft Avaya 4 Intended status: BCP J. Rosenberg 5 Expires: March 21, 2009 Cisco Systems 6 G. Camarillo 7 Ericsson 8 F. Audet 9 Nortel 10 September 17, 2008 12 Best Current Practices for NAT Traversal for Client-Server SIP 13 draft-ietf-sipping-nat-scenarios-09 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 21, 2009. 40 Abstract 42 Traversal of the Session Initiation Protocol (SIP) and the sessions 43 it establishes through Network Address Translators (NATs) is a 44 complex problem. Currently there are many deployment scenarios and 45 traversal mechanisms for media traffic. This document aims to 46 provide concrete recommendations and a unified method for NAT 47 traversal as well as documenting corresponding flows. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Solution Technology Outline Description . . . . . . . . . . . 7 55 4.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 8 56 4.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 8 57 4.1.2. Client Initiated Connections . . . . . . . . . . . . . 9 58 4.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 9 59 4.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 10 60 4.2.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 4.2.3. ICE/STUN/TURN . . . . . . . . . . . . . . . . . . . . 10 62 5. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 12 63 5.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 12 64 5.1.1. Registration (Registrar/Edge Proxy Co-Located) . . . . 12 65 5.1.2. Registration(Registrar/Edge Proxy not Co-Located) . . 16 66 5.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 19 67 5.1.4. Receiving an Invitation to a Session . . . . . . . . . 22 68 5.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 26 69 5.2.1. Endpoint Independent NAT . . . . . . . . . . . . . . . 27 70 5.2.2. Address and Port Dependant NAT . . . . . . . . . . . . 46 71 6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 54 72 6.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 54 73 6.2. IPv4-IPv6 Transition for Media . . . . . . . . . . . . . . 55 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 56 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 76 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 57 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 79 11.1. Normative References . . . . . . . . . . . . . . . . . . . 57 80 11.2. Informative References . . . . . . . . . . . . . . . . . . 59 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 82 Intellectual Property and Copyright Statements . . . . . . . . . . 61 84 1. Introduction 86 NAT (Network Address Translators) traversal has long been identified 87 as a complex problem when considered in the context of the Session 88 Initiation Protocol (SIP)[RFC3261] and it's associated media such as 89 Real Time Protocol (RTP)[RFC3550]. The problem is exacerbated by the 90 variety of NATs that are available in the market place today and the 91 large number of potential deployment scenarios. Details of different 92 NATs behavior can be found in 'NAT Behavioral Requirements for 93 Unicast UDP' [RFC4787]. 95 The IETF has been active on many specifications for the traversal of 96 NATs, including STUN[I-D.ietf-behave-rfc3489bis], 97 ICE[I-D.ietf-mmusic-ice], symmetric response[RFC3581], symmetric 98 RTP[RFC4961], TURN[I-D.ietf-behave-turn], SIP 99 Outbound[I-D.ietf-sip-outbound], SDP attribute for RTCP[RFC3605], and 100 others. These each represent a part of the solution, but none of 101 them gives the overall context for how the NATs traversal problem is 102 decomposed and solved through this collection of specifications. 103 This document serves to meet that need. 105 This document provides a definitive set of 'Best Common Practices' to 106 demonstrate the traversal of SIP and its associated media through NAT 107 devices. The document does not propose any new functionality but 108 does draw on existing solutions for both core SIP signaling and media 109 traversal (as defined in Section 4). 111 The best practices described in this document are for traditional 112 "client- server"-style SIP. It seems likely that other groups using 113 SIP, for example P2PSIP, will recommend these same practices between 114 a P2PSIP client and a P2PSIP peer, but will recommend different 115 practices for use between peers in a peer-to-peer network. 117 The draft is split into distinct sections as follows: 118 1. A clear definition of the problem statement. 119 2. Description of proposed solutions for both SIP protocol signaling 120 and media signaling. 121 3. A set of basic and advanced flow scenarios. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Problem Statement 131 The traversal of SIP through NATs can be split into two categories 132 that both require attention - The core SIP signaling and associated 133 media traversal. This document assumes NATs that do not contain SIP- 134 aware Application Layer Gateways (ALG). Some NATs that are available 135 today contain such behavior that which makes much of the issues 136 discussed in the document not applicable. It should also be noted 137 that Session Border Controllers (SBC) doing 'hosted NAT traversal' 138 also makes many of the discussions in this document moot. More 139 information can be obtained from [I-D.ietf-sipping-sbc-funcs] and 140 [I-D.ietf-mmusic-media-path-middleboxes]. 142 The core SIP signaling has a number of issues when traversing through 143 NATs. 145 Normal SIP response routing over UDP causes the response to be 146 delivered to the source IP address specified in the topmost Via 147 header, or the "received" parameter of the topmost Via header. The 148 port is extracted from the SIP 'Via' header to complete the IP 149 address/port combination for returning the SIP response. While the 150 destination for the response is correct, the port contained in the 151 SIP 'Via' header represents the listening port of the originating 152 client and not the port representing the open pin hole on the NAT. 153 This results in responses being sent back to the NAT but to a port 154 that is likely not open for SIP traffic. The SIP response will then 155 be dropped at the NAT. This is illustrated in Figure 1 which depicts 156 a SIP response being returned to port 5060. 158 Private NAT Public 159 Network | Network 160 | 161 | 162 -------- SIP Request |open port 10923 -------- 163 | |-------------------->--->-----------------------| | 164 | | | | | 165 | Client | |port 5060 SIP Response | Proxy | 166 | | x<------------------------| | 167 | | | | | 168 -------- | -------- 169 | 170 | 171 | 173 Figure 1: Failed Response 175 Secondly, there are two cases where new requests re-use existing 176 connections. The first is when using a reliable, connection 177 orientated transport protocol such as TCP, SIP has an inherent 178 mechanism that results in SIP responses reusing the connection that 179 was created/used for the corresponding transactional request. The 180 SIP protocol does not provide a mechanism that allows new requests 181 generated in the reverse direction of the originating client to use, 182 for example, the existing TCP connection created between the client 183 and the server during registration. This results in the registered 184 contact address not being bound to the "connection" in the case of 185 TCP. Requests are then blocked at the NAT, as illustrated in 186 Figure 2. The second case is when unreliable transport protocols 187 such as UDP where external NAT mappings need to be re-used to reach a 188 SIP entity on the private side of the network. 190 Private NAT Public 191 Network | Network 192 | 193 | 194 -------- (UAC 8023) REGISTER/Response (UAS 5060) -------- 195 | |-------------------->---<-----------------------| | 196 | | | | | 197 | Client | |5060 INVITE (UAC 8015)| Proxy | 198 | | x<------------------------| | 199 | | | | | 200 -------- | -------- 201 | 202 | 203 | 205 Figure 2: Failed Request 207 In Figure 2 the original REGISTER request is sent from the client on 208 port 8023 and received on port 5060, establishing a connection and 209 opening a pin-hole in the NAT. The generation of a new request from 210 the proxy results in a request destined for the registered entity 211 (Contact IP address) which is not reachable from the public network. 212 This results in the new SIP request attempting to create a connection 213 to a private network address. This problem would be solved if the 214 original connection was re-used. While this problem has been 215 discussed in the context of connection orientated protocols such as 216 TCP, the problem exists for SIP signaling using any transport 217 protocol. The impact of connection reuse of connection orientated 218 transports (TCP, TLS, etc) is discussed in more detail in the 219 connection reuse specification[I-D.ietf-sip-connect-reuse]. The 220 approach proposed for this problem in Section 4 of this document is 221 relevant for all SIP signaling in conjunction with connection reuse, 222 regardless of the transport protocol. 224 NAT policy can dictate that connections should be closed after a 225 period of inactivity. This period of inactivity may vary from a 226 number seconds to hours. SIP signaling can not be relied upon to 227 keep alive connections for the following two reasons. Firstly, SIP 228 entities can sometimes have no signaling traffic for long periods of 229 time which has the potential to exceed the inactivity timer, and this 230 can lead to problems where endpoints are not available to receive 231 incoming requests as the connection has been closed. Secondly, if a 232 low inactivity timer is specified, SIP signaling is not appropriate 233 as a keep-alive mechanism as it has the potential to add a large 234 amount of traffic to the network which uses up valuable resource and 235 also requires processing at a SIP stack, which is also a waste of 236 processing resources. 238 Media associated with SIP calls also has problems traversing NAT. 239 RTP [RFC3550] runs over UDP and is one of the most common media 240 transport types used in SIP signaling. Negotiation of RTP occurs 241 with a SIP session establishment using the Session Description 242 Protocol(SDP) [RFC4566] and a SIP offer/answer exchange[RFC3264]. 243 During a SIP offer/answer exchange an IP address and port combination 244 are specified by each client in a session as a means of receiving 245 media such as RTP. The problem arises when a client advertises its 246 address to receive media and it exists in a private network that is 247 not accessible from outside the NAT. Figure 3 illustrates this 248 problem. 250 NAT Public Network NAT 251 | | 252 | | 253 | | 254 -------- | SIP Signaling Session | -------- 255 | |----------------------->---<--------------------| | 256 | | | | | | 257 | Client | | | | Client | 258 | A |>=====>RTP>==Unknown Address==>X | | B | 259 | | | X<==Unknown Address==| | 348 | Client |<---------------------------------send response| Client | 349 | A | | | B | 350 | | | | | 351 -------- | -------- 352 | 353 | 354 | 356 Figure 4: Symmetric Response 358 The outgoing request from Client A opens a pin hole in the NAT. 360 Client B would normally respond to the port available in the SIP Via 361 header, as illustrated in Figure 1. Client B honors the 'rport' 362 parameter in the SIP Via header and routes the response to port from 363 which it was sent. The exact functionality for this method of 364 response traversal is called 'Symmetric Response' and the details are 365 documented in RFC 3581 [RFC3581]. Additional requirements are 366 imposed on SIP entities in RFC 3581 [RFC3581] such as listening and 367 sending SIP requests/responses from the same port. 369 4.1.2. Client Initiated Connections 371 The second problem with SIP signaling, as defined in Section 3 and 372 illustrated in Figure 2, is to allow incoming requests to be properly 373 routed. 375 Guidelines for devices such as User Agents that can only generate 376 outbound connections through NATs are documented in 'Managing Client 377 Initiated Connections in the Session Initiation 378 Protocol(SIP)'[I-D.ietf-sip-outbound]. The document provides 379 techniques that use a unique User Agent instance identifier 380 (instance-id) in association with a flow identifier (reg-id). The 381 combination of the two identifiers provides a key to a particular 382 connection (both UDP and TCP) that is stored in association with 383 registration bindings. On receiving an incoming request to a SIP 384 Address-Of-Record (AOR), a proxy/registrar routes to the associated 385 flow created by the registration and thus a route through NATs. It 386 also provides a keepalive mechanism for clients to keep NATs bindings 387 alive. This is achieved by multiplexing a ping/pong mechanism over 388 the SIP signaling connection (STUN for UDP and CRLF/operating system 389 keepalive for reliable transports like TCP). Usage of 390 [I-D.ietf-sip-outbound] is RECOMMENDED. This mechanism is not 391 transport specific and should be used for any transport protocol. 393 Even if the SIP Outbound draft is not used, clients generating SIP 394 requests SHOULD use the same IP address and port (i.e., socket) for 395 both transmission and receipt of SIP messages. Doing so allows for 396 the vast majority of industry provided solutions to properly 397 function. Deployments should also consider the mechanism described 398 in the Connection Reuse[I-D.ietf-sip-connect-reuse] specification for 399 routing bi-directional messages securely between trusted SIP Proxy 400 servers. 402 4.2. Media Traversal 404 The issues of media traversal through NATs is not straight forward 405 and requires the combination of a number of traversal methodologies. 406 The technologies outlined in the remainder of this section provide 407 the required solution set. 409 4.2.1. Symmetric RTP/RTCP 411 The primary problem identified in Section 3 of this document is that 412 internal IP address/port combinations can not be reached from the 413 public side of NATs. In the case of media such as RTP, this will 414 result in no audio traversing NATs (as illustrated in Figure 3). To 415 overcome this problem, a technique called 'Symmetric RTP/ 416 RTCP'[RFC4961] can be used. This involves a SIP endpoint both 417 sending and receiving RTP/RTCP traffic from the same IP address/port 418 combination. 'Symmetric RTP/RTCP' SHOULD only be used for traversal 419 of RTP through NATs when one of the participants in a media session 420 definitively knows that it is on the public network and is using a 421 'latching' technique as described in 422 [I-D.ietf-mmusic-media-path-middleboxes]. Symmetric RTP/RTCP is 423 important for everything that might want to traverse a NAT or speak 424 with an endpoint that is behind a NAT - even if the remote endpoint 425 is an SBC performing 'hosted NAT traversal'. 427 4.2.2. RTCP 429 Normal practice when selecting a port for defining RTP Control 430 Protocol (RTCP) [RFC3550] is for consecutive order numbering (i.e 431 select an incremented port for RTCP from that used for RTP). This 432 assumption causes RTCP traffic to break when traversing certain types 433 of NATs due to blocked ports. To combat this problem a specific 434 address and port need to be specified in the SDP rather than relying 435 on such assumptions. RFC 3605 [RFC3605] defines an SDP attribute 436 that is included to explicitly specify transport connection 437 information for RTCP so a separate, explicit NAT binding can be set 438 up for the purpose. The address details can be obtained using any 439 appropriate method including those detailed in this section (e.g. 440 STUN, TURN, ICE). 442 The use of RFC 3605 [RFC3605] MUST be supported. An alternative 443 mechanism defined in [I-D.ietf-avt-rtp-and-rtcp-mux] specifies 444 'muxing' both RTP and RTCP on the same IP/PORT combination. Using 445 this technique eliminates the problem but is still immature. 447 4.2.3. ICE/STUN/TURN 449 ICE, STUN and TURN are a suite of 3 inter-related protocols that 450 combine to provide a complete media traversal solution for NATs. The 451 following sections provide details of each component part. 453 4.2.3.1. STUN 455 Session Traversal Utilities for NAT or STUN is defined in RFC 3489bis 456 [I-D.ietf-behave-rfc3489bis]. STUN is a lightweight tool kit and 457 protocol that provides details of the external IP address/port 458 combination used by the NAT device to represent the internal entity 459 on the public facing side of NATs. On learning of such an external 460 representation, a client can use it accordingly as the connection 461 address in SDP to provide NAT traversal. Using terminology defined 462 in the draft 'NAT Behavioral Requirements for Unicast UDP' [RFC4787], 463 STUN does work with 'Endpoint Independent Mapping' but does not work 464 with either 'Address Dependent Mapping' or 'Address and Port 465 Dependent Mapping' type NATs. Using STUN with either of the previous 466 two NATs mappings to probe for the external IP address/port 467 representation will provide a different result to that required for 468 traversal by an alternative SIP entity. The IP address/port 469 combination deduced for the STUN server would be blocked for incoming 470 packets from an alterative SIP entity. 472 As mentioned in Section 4.1.2, STUN is also used as a client-to- 473 server keep-alive mechanism to refresh NAT bindings. 475 4.2.3.2. TURN 477 As described in the Section 4.2.3.1, the STUN protocol does not work 478 for UDP traversal through certain identified NAT mappings. 479 'Traversal Using Relays around NAT' is a usage of the STUN protocol 480 for deriving (from a TURN server) an address that will be used to 481 relay packets towards a client. TURN provides an external address 482 (globally routable) at a STUN server that will act as a media relay 483 which attempts to allow traffic to reach the associated internal 484 address. The full details of the TURN specification are defined in 485 [I-D.ietf-behave-turn]. A TURN service will almost always provide 486 media traffic to a SIP entity but it is RECOMMENDED that this method 487 would only be used as a last resort and not as a general mechanism 488 for NAT traversal. This is because using TURN has high performance 489 costs when relaying media traffic and can lead to unwanted latency. 491 4.2.3.3. ICE 493 Interactive Connectivity Establishment (ICE) is the RECOMMENDED 494 method for traversal of existing NATs if Symmetric RTP is not 495 appropriate. ICE is a methodology for using existing technologies 496 such as STUN, TURN and any other UNSAF[RFC3424] compliant protocol to 497 provide a unified solution. This is achieved by obtaining as many 498 representative IP address/port combinations as possible using 499 technologies such as STUN/TURN (*note - an ICE endpoint can also use 500 non-IETF mechanisms (e.g., NAT-PMP, UPnP IGD) to learn public IP 501 addresses and ports, and populate a=candidate lines with that 502 information). Once the addresses are accumulated, they are all 503 included in the SDP exchange in a new media attribute called 504 'candidate'. Each 'candidate' SDP attribute entry has detailed 505 connection information including a media address, priority and 506 transport protocol. The appropriate IP address/port combinations are 507 used in the order specified by the priority. A client compliant to 508 the ICE specification will then locally run STUN servers on all 509 addresses being advertised using ICE. Each instance will undertake 510 connectivity checks to ensure that a client can successfully receive 511 media on the advertised address. Only connections that pass the 512 relevant connectivity checks are used for media exchange. The full 513 details of the ICE methodology are contained in 514 [I-D.ietf-mmusic-ice]. 516 5. NAT Traversal Scenarios 518 This section of the document includes detailed NAT traversal 519 scenarios for both SIP signaling and the associated media. 520 Signalling NAT traversal is achieved using [I-D.ietf-sip-outbound]. 522 5.1. Basic NAT SIP Signaling Traversal 524 The following sub-sections concentrate on SIP signaling traversal of 525 NATs. The scenarios include traversal for both reliable and un- 526 reliable transport protocols. 528 5.1.1. Registration (Registrar/Edge Proxy Co-Located) 530 The set of scenarios in this section document basic signaling 531 traversal of a SIP REGISTER method through NATs. 533 5.1.1.1. UDP 534 Registrar/ 535 Bob NAT Edge Proxy 536 | | | 537 |(1) REGISTER | | 538 |----------------->| | 539 | | | 540 | |(1) REGISTER | 541 | |----------------->| 542 | | | 543 |*************************************| 544 | Create Outbound Connection Tuple | 545 |*************************************| 546 | | | 547 | |(2) 200 OK | 548 | |<-----------------| 549 | | | 550 |(2) 200 OK | | 551 |<-----------------| | 552 | | | 554 Figure 5: UDP Registration 556 In this example the client sends a SIP REGISTER request through a 557 NAT. The client will include an 'rport' parameter as described in 558 Section 4.1.1 of this document for allowing traversal of UDP 559 responses. The original request as illustrated in (1) in Figure 5 is 560 a standard REGISTER message: 562 Message 1: 564 REGISTER sip:example.com SIP/2.0 565 Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7 566 Max-Forwards: 70 567 From: Bob ;tag=7F94778B653B 568 To: Bob 569 Call-ID: 16CB75F21C70 570 CSeq: 1 REGISTER 571 Supported: path, outbound 572 Contact: ;reg-id=1 573 ;+sip.instance="" 574 Content-Length: 0 576 This SIP transaction now generates a SIP 200 OK response, as depicted 577 in (2) from Figure 5: 579 Message 2: 581 SIP/2.0 200 OK 582 Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7; 583 received=172.16.3.4 584 From: Bob ;tag=7F94778B653B 585 To: Bob ;tag=6AF99445E44A 586 Call-ID: 16CB75F21C70 587 CSeq: 1 REGISTER 588 Supported: path, outbound 589 Require: outbound 590 Contact: ;reg-id=1;expires=3600 591 ;+sip.instance="" 592 Content-Length: 0 594 The response will be sent to the address appearing in the 'received' 595 parameter of the SIP 'Via' header (address 172.16.3.4). The response 596 will not be sent to the port deduced from the SIP 'Via' header, as 597 per standard SIP operation but will be sent to the value that has 598 been stamped in the 'rport' parameter of the SIP 'Via' header (port 599 8050). For the response to successfully traverse the NAT, all of the 600 conventions defined in RFC 3581 [RFC3581] MUST be obeyed. Make note 601 of both the 'reg-id' and 'sip.instance' contact header parameters. 602 They are used to establish an Outbound connection tuple as defined in 603 [I-D.ietf-sip-outbound]. The connection tuple creation is clearly 604 shown in Figure 5. This ensures that any inbound request that causes 605 a registration lookup will result in the re-use of the connection 606 path established by the registration. This exonerates the need to 607 manipulate contact header URIs to represent a globally routable 608 address as perceived on the public side of a NAT. 610 5.1.1.2. Connection Oriented Transport 611 Registrar/ 612 Bob NAT Edge Proxy 613 | | | 614 |(1) REGISTER | | 615 |----------------->| | 616 | | | 617 | |(1) REGISTER | 618 | |----------------->| 619 | | | 620 |*************************************| 621 | Create Outbound Connection Tuple | 622 |*************************************| 623 | | | 624 | |(2) 200 OK | 625 | |<-----------------| 626 | | | 627 |(2) 200 OK | | 628 |<-----------------| | 629 | | | 631 Figure 6 633 Traversal of SIP REGISTER requests/responses using a reliable, 634 connection orientated protocol such as TCP does not require any 635 additional core SIP signaling extensions, beyond the procedures 636 defined in [I-D.ietf-sip-outbound]. SIP responses will re-use the 637 connection created for the initial REGISTER request, (1) from 638 Figure 6: 640 Message 1: 642 REGISTER sip:example.com SIP/2.0 643 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 644 Max-Forwards: 70 645 From: Bob ;tag=7F94778B653B 646 To: Bob 647 Call-ID: 16CB75F21C70 648 CSeq: 1 REGISTER 649 Supported: path, outbound 650 Contact: ;reg-id=1 651 ;+sip.instance="" 652 Content-Length: 0 654 Message 2: 656 SIP/2.0 200 OK 657 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 658 From: Bob ;tag=7F94778B653B 659 To: Bob ;tag=6AF99445E44A 660 Call-ID: 16CB75F21C70 661 CSeq: 1 REGISTER 662 Supported: path, outbound 663 Require: outbound 664 Contact: ;reg-id=1;expires=3600 665 ;+sip.instance="" 666 Content-Length: 0 668 This example was included to show the inclusion of the +sip.instance 669 Contact header parameter as defined in the SIP Outbound specification 670 [I-D.ietf-sip-outbound]. This creates an association tuple as 671 described in the previous example for future inbound requests 672 directed at the newly created registration binding with the only 673 difference that the association is with a TCP connection, not a UDP 674 pin hole binding. 676 5.1.2. Registration(Registrar/Edge Proxy not Co-Located) 678 This section demonstrates traversal mechanisms when the Registrar 679 component is not co-located with the edge proxy element. The 680 procedures described in this section are identical, regardless of 681 transport protocol and so only one example will be documented in the 682 form of TCP. 684 Bob NAT Edge Proxy Registrar 685 | | | | 686 |(1) REGISTER | | | 687 |----------------->| | | 688 | | | | 689 | |(1) REGISTER | | 690 | |----------------->| | 691 | | | | 692 | | |(2) REGISTER | 693 | | |----------------->| 694 | | | | 695 |********************************************************| 696 | Create Outbound Connection Tuple | 697 |********************************************************| 698 | | | | 699 | | |(3) 200 OK | 700 | | |<-----------------| 701 | |(4)200 OK | | 702 | |<-----------------| | 703 | | | | 704 |(4)200 OK | | | 705 |<-----------------| | | 706 | | | | 708 Figure 7: Registration(Registrar/Proxy not Co-Located) 710 This scenario builds on the previous example contained in 711 Section 5.1.1.2. The primary difference being that the REGISTER 712 request is routed onwards from a Proxy Server to a separated 713 Registrar. The important message to note is (1) in Figure 7. The 714 Edge proxy, on receiving a REGISTER request that contains a 715 'sip.instance' media feature tag, forms a unique flow identifier 716 token as discussed in [I-D.ietf-sip-outbound]. At this point, the 717 proxy server routes the SIP REGISTER message to the Registrar. The 718 proxy will create the connection tuple as described in SIP Outbound 719 at the same moment as the co-located example, but for subsequent 720 messages to arrive at the Proxy, the proxy needs to indicate its need 721 to remain in the SIP signaling path. To achieve this the proxy 722 inserts to REGISTER message (2) a SIP PATH extension header, as 723 defined in RFC 3327 [RFC3327]. The previously created flow 724 association token is inserted in a position within the Path header 725 where it can easily be retrieved at a later point when receiving 726 messages to be routed to the registration binding (in this case the 727 user part of the SIP URI). The REGISTER message of (1) includes a 728 SIP Route header for the edge proxy. 730 Message 1: 732 REGISTER sip:example.com SIP/2.0 733 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 734 Max-Forwards: 70 735 From: Bob ;tag=7F94778B653B 736 To: Bob 737 Call-ID: 16CB75F21C70 738 CSeq: 1 REGISTER 739 Supported: path, outbound 740 Route: 741 Contact: ;reg-id=1 742 ;+sip.instance="" 743 Content-Length: 0 745 When proxied in (2) looks as follows: 747 Message 2: 749 REGISTER sip:example.com SIP/2.0 750 Via: SIP/2.0/TCP ep1.example.com;branch=z9hG4bKnuiqisi 751 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 752 Max-Forwards: 69 753 From: Bob ;tag=7F94778B653B 754 To: Bob 755 Call-ID: 16CB75F21C70 756 CSeq: 1 REGISTER 757 Supported: path, outbound 758 Contact: ;reg-id=1 759 ;+sip.instance="" 760 Path: 761 Content-Length: 0 763 This REGISTER request results in the Path header being stored along 764 with the AOR and it's associated binding at the Registrar. The URI 765 contained in the Path header will be inserted as a pre-loaded SIP 766 'Route' header into any request that arrives at the Registrar and is 767 directed towards the associated AOR binding. This all but guarantees 768 that all requests for the new registration will be forwarded to the 769 Edge Proxy. In our example, the user part of the SIP 'Path' header 770 URI that was inserted by the Edge Proxy contains the unique token 771 identifying the flow to the client. On receiving subsequent 772 requests, the edge proxy will examine the user part of the pre-loaded 773 SIP 'route' header and extract the unique flow token for use in its 774 connection tuple comparison, as defined in the SIP Outbound 775 specification [I-D.ietf-sip-outbound]. An example which builds on 776 this scenario (showing an inbound request to the AOR) is detailed in 777 Section 5.1.4.2 of this document. 779 5.1.3. Initiating a Session 781 This section covers basic SIP signaling when initiating a call from 782 behind a NAT. 784 5.1.3.1. UDP 786 Initiating a call using UDP (the Edge Proxy and Authoritative Proxy 787 funcationality are co-located). 789 Edge Proxy/ 790 Bob NAT Auth. Proxy Alice 791 | | | | 792 |(1) INVITE | | | 793 |----------------->| | | 794 | | | | 795 | |(1) INVITE | | 796 | |----------------->| | 797 | | | | 798 | | |(2) INVITE | 799 | | |---------------->| 800 | | | | 801 | | |(3)180 RINGING | 802 | | |<----------------| 803 | | | | 804 | |(4)180 RINGING | | 805 | |<-----------------| | 806 | | | | 807 |(4)180 RINGING | | | 808 |<-----------------| | | 809 | | | | 810 | | |(5)200 OK | 811 | | |<----------------| 812 | | | | 813 | |(6)200 OK | | 814 | |<-----------------| | 815 | | | | 816 |(6)200 OK | | | 817 |<-----------------| | | 818 | | | | 819 |(7)ACK | | | 820 |----------------->| | | 821 | | | | 822 | |(7)ACK | | 823 | |----------------->| | 824 | | | | 825 | | |(8) ACK | 826 | | |---------------->| 827 | | | | 829 Figure 8: Initiating a Session - UDP 831 The initiating client generates an INVITE request that is to be sent 832 through the NAT to a Proxy server. The INVITE message is represented 833 in Figure 8 by (1) and is as follows: 835 Message 1: 837 INVITE sip:alice@a.example SIP/2.0 838 Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7 839 Max-Forwards: 70 840 From: Bob ;tag=ldw22z 841 To: Alice 842 Call-ID: 95KGsk2V/Eis9LcpBYy3 843 CSeq: 1 INVITE 844 Supported: outbound 845 Route: 846 Contact: 847 Content-Type: application/sdp 848 Content-Length: ... 850 [SDP not shown] 852 There are a number of points to note with this message: 853 1. Firstly, as with the registration example in Section 5.1.1.1, 854 responses to this request will not automatically pass back 855 through a NAT and so the SIP 'Via' header 'rport' is included as 856 described in the 'Symmetric response' Section 4.1.1 and defined 857 in RFC 3581 [RFC3581]. 858 2. Secondly, the contact inserted contains to ensure that all new 859 requests will be sent to the same flow. Alternatively, a GRUU 860 might have been used. See 4.3/[I-D.ietf-sip-outbound]. 862 In (2), the proxy inserts itself in the Via, adds the rport port 863 number in the previous Via header, adds the received parameter in the 864 previous Via, removes the Route header, and inserts a Record-Route 865 with a token. 867 Message 2: 869 INVITE sip:alice@172.16.1.4 SIP/2.0 870 Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi 871 Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7; 872 received=172.16.3.4 873 Max-Forwards: 69 874 From: Bob ;tag=ldw22z 875 To: Alice 876 Call-ID: 95KGsk2V/Eis9LcpBYy3 877 CSeq: 1 INVITE 878 Supported: outbound 879 Record-Route: 880 Contact: 881 Content-Type: application/sdp 882 Content-Length: ... 884 [SDP not shown] 886 5.1.3.2. Connection-oriented Transport 888 When using a reliable transport such as TCP the call flow and 889 procedures for traversing a NAT are almost identical to those 890 described in Section 5.1.3.1. The primary difference when using 891 reliable transport protocols is that Symmetric response[RFC3581] are 892 not required for SIP responses to traverse a NAT. RFC 3261[RFC3261] 893 defines procedures for SIP response messages to be sent back on the 894 same connection on which the request arrived. See section 9.5/ 895 [I-D.ietf-sip-outbound] for an example call flow of an outgoing call. 897 5.1.4. Receiving an Invitation to a Session 899 This section details scenarios where a client behind a NAT receives 900 an inbound request through a NAT. These scenarios build on the 901 previous registration scenario from Section 5.1.1 and Section 5.1.2 902 in this document. 904 5.1.4.1. Registrar/Proxy Co-located 906 The SIP signaling on the interior of the network (behind the user's 907 proxy) is not impacted directly by the transport protocol and so only 908 one example scenario is necessary. The example uses UDP and follows 909 on from the registration installed in the example from 910 Section 5.1.1.1. 912 Edge Proxy 913 Bob NAT Auth. Proxy Alice 914 | | | | 915 |*******************************************************| 916 | Registration Binding Installed in | 917 | section 5.1.1.1 | 918 |*******************************************************| 919 | | | | 920 | | |(1)INVITE | 921 | | |<----------------| 922 | | | | 923 | |(2)INVITE | | 924 | |<-----------------| | 925 | | | | 926 |(2)INVITE | | | 927 |<-----------------| | | 928 | | | | 929 | | | | 930 Figure 9: Receiving an Invitation to a Session 932 An INVITE request arrives at the Authoritative Proxy with a 933 destination pointing to the AOR of that inserted in Section 5.1.1.1. 934 The message is illustrated by (1) in Figure 9 and looks as follows: 936 INVITE sip:bob@example.com SIP/2.0 937 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d 938 Max-Forwards: 70 939 From: External Alice ;tag=02935 940 To: Bob 941 Call-ID: klmvCxVWGp6MxJp2T2mb 942 CSeq: 1 INVITE 943 Contact: 944 Content-Type: application/sdp 945 Content-Length: .. 947 [SDP not shown] 949 The INVITE request matches the registration binding previously 950 installed at the Registrar and the INVITE request-URI is re-written 951 to the selected onward address. The proxy then examines the request 952 URI of the INVITE and compares with its list of current open flows. 953 It uses the incoming AOR to commence the check for associated open 954 connections/mappings. Once matched, the proxy checks to see if the 955 unique instance identifier (+sip.instance) associated with the 956 binding equals the same instance identifier associated with the flow. 957 The request is then dispatched on the appropriate flow. This is 958 message (2) from Figure 9 and is as follows: 960 INVITE sip:bob@192.168.1.2 SIP/2.0 961 Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4kmlds893jhsd 962 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d 963 Max-Forwards: 69 964 From: Alice ;tag=02935 965 To: client bob 966 Call-ID: klmvCxVWGp6MxJp2T2mb 967 CSeq: 1 INVITE 968 Contact: 969 Content-Type: application/sdp 970 Content-Length: .. 972 [SDP not shown] 974 It is a standard SIP INVITE request with no additional functionality. 976 The major difference being that this request will not be forwarded to 977 the address specified in the Request-URI, as standard SIP rules would 978 enforce but will be sent on the flow associated with the registration 979 binding (look-up procedures in RFC 3263 [RFC3263] are overridden). 980 This then allows the original connection/mapping from the initial 981 registration process to be re-used. 983 5.1.4.2. Edge Proxy/Authoritative Proxy Not Co-located 985 The core SIP signaling associated with this call flow is not impacted 986 directly by the transport protocol and so only one example scenario 987 is necessary. The example uses UDP and follows on from the 988 registration installed in the example from Section 5.1.2. 990 Bob NAT Edge Proxy Auth. Proxy Alice 991 | | | | | 992 |***********************************************************| 993 | Registration Binding Installed in | 994 | section 5.1.2 | 995 |***********************************************************| 996 | | | | | 997 | | | |(1)INVITE | 998 | | | |<-------------| 999 | | | | | 1000 | | |(2)INVITE | | 1001 | | |<-------------| | 1002 | | | | | 1003 | |(3)INVITE | | | 1004 | |<-------------| | | 1005 | | | | | 1006 |(3)INVITE | | | | 1007 |<-------------| | | | 1008 | | | | | 1009 | | | | | 1011 Figure 10: Registrar/Proxy Not Co-located 1013 An INVITE request arrives at the Authoritative Proxy with a 1014 destination pointing to the AOR of that inserted in Section 5.1.2. 1015 The message is illustrated by (1) in Figure 10 and looks as follows: 1017 INVITE sip:bob@example.com SIP/2.0 1018 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d 1019 Max-Forwards: 70 1020 From: Alice ;tag=02935 1021 To: Bob 1022 Call-ID: klmvCxVWGp6MxJp2T2mb 1023 CSeq: 1 INVITE 1024 Contact: 1025 Content-Type: application/sdp 1026 Content-Length: .. 1028 [SDP not shown] 1030 The INVITE request matches the registration binding previously 1031 installed at the Registrar and the INVITE request-URI is re-written 1032 to the selected onward address. The Registrar also identifies that a 1033 SIP PATH header was associated with the registration and pushes it 1034 into the INVITE request in the form of a pre-loaded SIP Route header. 1035 It then forwards the request on to the proxy identified in the SIP 1036 Route header as shown in (2) from Figure 10: 1038 INVITE sip:bob@client.example.com SIP/2.0 1039 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc 1040 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d 1041 Route: 1042 Max-Forwards: 69 1043 From: Alice ;tag=02935 1044 To: Bob 1045 Call-ID: klmvCxVWGp6MxJp2T2mb 1046 CSeq: 1 INVITE 1047 Contact: 1048 Content-Type: application/sdp 1049 Content-Length: .. 1051 [SDP not shown] 1053 The request then arrives at the outbound proxy for the client. The 1054 proxy examines the request URI of the INVITE in conjunction with the 1055 flow token that it previously inserted into the user part of the PATH 1056 header SIP URI (which now appears in the user part of the Route 1057 header in the incoming INVITE). The proxy locates the appropriate 1058 flow and sends the message to the client, as shown in (3) from 1059 Figure 10: 1061 INVITE sip:bob@192.168.1.2 SIP/2.0 1062 Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4nsi30dncmnl 1063 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc 1064 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d 1065 Record-Route: 1066 Max-Forwards: 68 1067 From: Alice ;tag=02935 1068 To: bob 1069 Call-ID: klmvCxVWGp6MxJp2T2mb 1070 CSeq: 1 INVITE 1071 Contact: 1072 Content-Type: application/sdp 1073 Content-Length: .. 1075 [SDP not shown] 1077 It is a standard SIP INVITE request with no additional functionality 1078 at the originator. The major difference being that this request will 1079 not follow the address specified in the Request-URI when it reaches 1080 the outbound proxy, as standard SIP rules would enforce but will be 1081 sent on the flow associated with the registration binding as 1082 indicated in the Route header(look-up procedures in RFC 3263 1083 [RFC3263] are overridden). This then allows the original connection/ 1084 mapping from the initial registration to the outbound proxy to be re- 1085 used. 1087 5.2. Basic NAT Media Traversal 1089 This section provides example scenarios to demonstrate basic media 1090 traversal using the techniques outlined earlier in this document. 1092 In the flow diagrams STUN messages have been annotated for simplicity 1093 as follows: 1094 o The "Src" attribute represents the source transport address of the 1095 message. 1096 o The "Dest" attribute represents the destination transport address 1097 of the message. 1098 o The "Map" attribute represents the server reflexive (XOR-MAPPED- 1099 ADDRESS STUN attribute) transport address. 1100 o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN 1101 attribute) transport address. 1103 The meaning of each STUN attribute is extensively explained in the 1104 core STUN[I-D.ietf-behave-rfc3489bis] and TURN [I-D.ietf-behave-turn] 1105 drafts. 1107 A number of ICE SDP attributes have also been included in some of the 1108 examples. Detailed information on individual attributes can be 1109 obtained from the core ICE specification[I-D.ietf-mmusic-ice]. 1111 The examples also contain a mechanism for representing transport 1112 addresses. It would be confusing to include representations of 1113 network addresses in the call flows and make them hard to follow. 1114 For this reason network addresses will be represented using the 1115 following annotation. The first component will contain the 1116 representation of the client responsible for the address. For 1117 example in the majority of the examples "L" (left client), "R" (right 1118 client), NAT-PUB" (NAT public), PRIV (Private), and "STUN-PUB" (STUN 1119 Public) are used. To allow for multiple addresses from the same 1120 network element, each representation can also be followed by a 1121 number. These can also be used in combination. For example "L-NAT- 1122 PUB-1" would represent a public network address of the left hand side 1123 NAT while "R-NAT-PUB-1" would represent a public network address of 1124 the right hand side of the NAT. "L-PRIV-1" would represent a private 1125 network address of the left hand side of the NAT while "R-PRIV-1" 1126 represents a private address of the right hand side of the NAT. 1128 It should also be noted that during the examples it might be 1129 appropriate to signify an explicit part of a transport address. This 1130 is achieved by adding either the '.address' or '.port' tag on the end 1131 of the representation. For example, 'L-PRIV-1.address' and 'L-PRIV- 1132 1.port'. 1134 The use of '$' signifies variable parts in example SIP messages. 1136 5.2.1. Endpoint Independent NAT 1138 This section demonstrates an example of a client both initiating and 1139 receiving calls behind an 'Endpoint independent' NAT. An example is 1140 included for both STUN and ICE with ICE being the RECOMMENDED 1141 mechanism for media traversal. 1143 5.2.1.1. STUN Solution 1145 It is possible to traverse media through an 'Endpoint Independent NAT 1146 using STUN. The remainder of this section provides simplified 1147 examples of the 'Binding Discovery' STUN as defined in 1148 [I-D.ietf-behave-rfc3489bis]. The STUN messages have been simplified 1149 and do not include 'Shared Secret' requests used to obtain the 1150 temporary username and password. 1152 5.2.1.1.1. Initiating Session 1154 The following example demonstrates media traversal through a NAT with 1155 'Address-Independent' properties using the STUN 'Binding Discovery' 1156 usage. It is assumed in this example that the STUN client and SIP 1157 Client are co-located on the same physical machine. Note that some 1158 SIP signaling messages have been left out for simplicity. 1160 Client NAT STUN [..] 1161 Server 1162 | | | | 1163 |(1) BIND Req | | | 1164 |Src=L-PRIV-1 | | | 1165 |Dest=STUN-PUB | | | 1166 |----------------->| | | 1167 | | | | 1168 | |(2) BIND Req | | 1169 | |Src=NAT-PUB-1 | | 1170 | |Dest=STUN-PUB | | 1171 | |----------------->| | 1172 | | | | 1173 | |(3) BIND Resp | | 1174 | |<-----------------| | 1175 | |Src=STUN-PUB | | 1176 | |Dest=NAT-PUB-1 | | 1177 | |Map=NAT-PUB-1 | | 1178 | | | | 1179 |(4) BIND Resp | | | 1180 |<-----------------| | | 1181 |Src=STUN-PUB | | | 1182 |Dest=L-PRIV-1 | | | 1183 |Map=NAT-PUB-1 | | | 1184 | | | | 1185 |(5) BIND Req | | | 1186 |Src=L-PRIV-2 | | | 1187 |Dest=STUN-PUB | | | 1188 |----------------->| | | 1189 | | | | 1190 | |(6) BIND Req | | 1191 | |Src=NAT-PUB-2 | | 1192 | |Dest=STUN-PUB | | 1193 | |----------------->| | 1194 | | | | 1195 | |(7) BIND Resp | | 1196 | |<-----------------| | 1197 | |Src=STUN-PUB | | 1198 | |Dest=NAT-PUB-2 | | 1199 | |Map=NAT-PUB-2 | | 1200 | | | | 1201 |(8) BIND Resp | | | 1202 |<-----------------| | | 1203 |Src=STUN-PUB | | | 1204 |Dest=L-PRIV-2 | | | 1205 |Map=NAT-PUB-2 | | | 1206 | | | | 1207 |(9)SIP INVITE | | | 1208 |----------------->| | | 1209 | | | | 1210 | |(10)SIP INVITE | | 1211 | |------------------------------------>| 1212 | | | | 1213 | | |(11)SIP 200 OK | 1214 | |<------------------------------------| 1215 | | | | 1216 |(12)SIP 200 OK | | | 1217 |<-----------------| | | 1218 | | | | 1219 |========================================================| 1220 |>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>| 1221 |========================================================| 1222 | | 1223 |========================================================| 1224 |<<<<<<<<<<<>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>| 1229 |========================================================| 1230 | | 1231 |========================================================| 1232 |<<<<<<<<<<<| | | 1237 | | | | 1238 | |(14) SIP ACK | | 1239 | |------------------------------------>| 1240 | | | | 1242 Figure 11: Endpoint Independent NAT - Initiating 1244 o On deciding to initiate a SIP voice session the client starts a 1245 local STUN client on the interface and port that is to be used for 1246 media (send/receive). The STUN client generates a standard 1247 'Binding Discovery' request as indicated in (1) from Figure 11 1248 which also highlights the source address and port for which the 1249 client device wishes to obtain a mapping. The 'Binding Discovery' 1250 request is sent through the NAT towards the public internet and 1251 STUN server. 1252 o Message (2) traverses the NAT and breaks out onto the public 1253 internet towards the public STUN server. Note that the source 1254 address of the 'Binding Discovery' request now represents the 1255 public address and port from the public side of the NAT. 1256 o The STUN server receives the request and processes it 1257 appropriately. This results in a successful 'Binding Discovery' 1258 response being generated and returned (3). The message contains 1259 details of the XOR mapped public address (contained in the STUN 1260 XOR-MAPPED-ADDRESS attribute) which is to be used by the 1261 originating client to receive media (see 'Map=NAT-PUB-1' from 1262 (3)). 1263 o The 'Binding Discovery' response traverses back through the NAT 1264 using the path created by the 'Binding Discovery' request and 1265 presents the new XOR mapped address to the client (4). At this 1266 point the process is repeated to obtain a second XOR-mapped 1267 address (as shown in (5)-(8)) for a second local address (Address 1268 has changed from "L-PRIV-1" to "L-PRIV-2") for an RTCP port. 1269 o The client now constructs a SIP INVITE message(9). Note that 1270 traversal of SIP is not covered in this example and is discussed 1271 in Section 5.1. The INVITE request will use the addresses it has 1272 obtained in the previous STUN transactions to populate the SDP of 1273 the SIP INVITE as shown below: 1275 v=0 1276 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address 1277 c=IN IP4 $NAT-PUB-1.address 1278 t=0 0 1279 m=audio $NAT-PUB-1.port RTP/AVP 0 1280 a=rtcp:$NAT-PUB-2.port 1282 o Note that the XOR-mapped address obtained from the 'Binding 1283 Discovery' transactions are inserted as the connection address for 1284 the SDP (c=$NAT-PUB-1.address). The Primary port for RTP is also 1285 inserted in the SDP (m=audio $NAT-PUB-1.port RTP/AVP 0). Finally, 1286 the port gained from the additional 'Binding Discovery' is placed 1287 in the RTCP attribute (as discussed in Section 4.2.2) for 1288 traversal of RTCP (a=rtcp:$NAT-PUB-2.port). 1289 o The SIP signaling then traverses the NAT and sets up the SIP 1290 session (9-12). Note that the left client transmits media as soon 1291 as the 200 OK to the INVITE arrives at the client (12). Up until 1292 this point the incoming media and RTCP to the left hand client 1293 will not pass through the NAT as no outbound association has been 1294 created with the far end client. Two way media communication has 1295 now been established. 1297 5.2.1.1.2. Receiving Session Invitation 1299 Receiving a session for an 'Endpoint Independent' NAT using the STUN 1300 'Binding Discovery' usage is very similar to the example outlined in 1301 Section 5.2.1.1.1. Figure 12 illustrates the associated flow of 1302 messages. 1304 Client NAT STUN [..] 1305 Server 1306 | | | (1)SIP INVITE | 1307 | |<------------------------------------| 1308 | | | | 1309 |(2) SIP INVITE | | | 1310 |<-----------------| | | 1311 | | | | 1312 |(3) BIND Req | | | 1313 |Src=L-PRIV-1 | | | 1314 |Dest=STUN-PUB | | | 1315 |----------------->| | | 1316 | | | | 1317 | |(4) BIND Req | | 1318 | |Src=NAT-PUB-1 | | 1319 | |Dest=STUN-PUB | | 1320 | |----------------->| | 1321 | | | | 1322 | |(5) BIND Resp | | 1323 | |<-----------------| | 1324 | |Src=STUN-PUB | | 1325 | |Dest=NAT-PUB-1 | | 1326 | |Map=NAT-PUB-1 | | 1327 | | | | 1328 |(6) BIND Resp | | | 1329 |<-----------------| | | 1330 |Src=STUN-PUB | | | 1331 |Dest=L-PRIV-1 | | | 1332 |Map=NAT-PUB-1 | | | 1333 | | | | 1334 |(7) BIND Req | | | 1335 |Src=L-PRIV-2 | | | 1336 |Dest=STUN-PUB | | | 1337 |----------------->| | | 1338 | | | | 1339 | |(8) BIND Req | | 1340 | |Src=NAT-PUB-2 | | 1341 | |Dest=STUN-PUB | | 1342 | |----------------->| | 1343 | | | | 1344 | |(9) BIND Resp | | 1345 | |<-----------------| | 1346 | |Src=STUN-PUB | | 1347 | |Dest=NAT-PUB-2 | | 1348 | |Map=NAT-PUB-2 | | 1349 | | | | 1350 |(10) BIND Resp | | | 1351 |<-----------------| | | 1352 |Src=STUN-PUB | | | 1353 |Dest=L-PRIV-2 | | | 1354 |Map=NAT-PUB-2 | | | 1355 | | | | 1356 |(11)SIP 200 OK | | | 1357 |----------------->| | | 1358 | |(12)SIP 200 OK | | 1359 | |------------------------------------>| 1360 | | | | 1361 |========================================================| 1362 |>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>| 1363 |========================================================| 1364 | | | | 1365 |========================================================| 1366 |<<<<<<<<<<<<>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>| 1371 |========================================================| 1372 | | | | 1373 |========================================================| 1374 |<<<<<<<<<<<<| | | | 1461 | | | | | 1462 | |(2) Alloc Req | | | 1463 | |Src=L-NAT-PUB-1 | | | 1464 | |Dest=TURN-PUB-1 | | | 1465 | |--------------->| | | 1466 | | | | | 1467 | |(3) Alloc Resp | | | 1468 | |<---------------| | | 1469 | |Src=TURN-PUB-1 | | | 1470 | |Dest=L-NAT-PUB-1| | | 1471 | |Map=L-NAT-PUB-1 | | | 1472 | |Rel=TURN-PUB-2 | | | 1473 | | | | | 1474 |(4) Alloc Resp | | | | 1475 |<---------------| | | | 1476 |Src=TURN-PUB-1 | | | | 1477 |Dest=L-PRIV-1 | | | | 1478 |Map=L-NAT-PUB-1 | | | | 1479 |Rel=TURN-PUB-2 | | | | 1480 | | | | | 1481 |(5) Alloc Req | | | | 1482 |Src=L-PRIV-2 | | | | 1483 |Dest=TURN-PUB-1 | | | | 1484 |--------------->| | | | 1485 | | | | | 1486 | |(6) Alloc Req | | | 1487 | |Src=L-NAT-PUB-2 | | | 1488 | |Dest=TURN-PUB-1 | | | 1489 | |--------------->| | | 1490 | | | | | 1491 | |(7) Alloc Resp | | | 1492 | |<---------------| | | 1493 | |Src=TURN-PUB-1 | | | 1494 | |Dest=NAT-PUB-2 | | | 1495 | |Map=NAT-PUB-2 | | | 1496 | |Rel=TURN-PUB-3 | | | 1497 | | | | | 1498 |(8) Alloc Resp | | | | 1499 |<---------------| | | | 1500 |Src=TURN-PUB-1 | | | | 1501 |Dest=L-PRIV-2 | | | | 1502 |Map=L-NAT-PUB-2 | | | | 1503 |Rel=TURN-PUB-3 | | | | 1504 | | | | | 1505 |(9) SIP INVITE | | | | 1506 |------------------------------------------------->| | 1507 | | | | | 1508 | | | |(10) SIP INVITE | 1509 | | | |--------------->| 1510 | | | | | 1511 | | | |(11) Alloc Req | 1512 | | | |<---------------| 1513 | | | |Src=R-PRIV-1 | 1514 | | | |Dest=TURN-PUB-1 | 1515 | | | | | 1516 | | |(12) Alloc Req | | 1517 | | |<---------------| | 1518 | | |Src=R-NAT-PUB-1 | | 1519 | | |Dest=TURN-PUB-1 | | 1520 | | | | | 1521 | | |(13) Alloc Res | | 1522 | | |--------------->| | 1523 | | |Src=TURN-PUB-1 | | 1524 | | |Dest=R-NAT-PUB-1| | 1525 | | |Map=R-NAT-PUB-1 | | 1526 | | |Rel=TURN-PUB-4 | | 1527 | | | | | 1528 | | | |(14) Alloc Res | 1529 | | | |--------------->| 1530 | | | |Src=TURN-PUB-1 | 1531 | | | |Dest=R-PRIV-1 | 1532 | | | |Map=R-NAT-PUB-1 | 1533 | | | |Rel=TURN-PUB-4 | 1534 | | | | | 1535 | | | |(15) Alloc Req | 1536 | | | |<---------------| 1537 | | | |Src=R-PRIV-2 | 1538 | | | |Dest=TURN-PUB-1 | 1539 | | | | | 1540 | | |(16) Alloc Req | | 1541 | | |<---------------| | 1542 | | |Src=R-NAT-PUB-2 | | 1543 | | |Dest=TURN-PUB-1 | | 1544 | | | | | 1545 | | |(17) Alloc Res | | 1546 | | |--------------->| | 1547 | | |Src=TURN-PUB-1 | | 1548 | | |Dest=R-NAT-PUB-2| | 1549 | | |Map=R-NAT-PUB-2 | | 1550 | | |Rel=TURN-PUB-5 | | 1551 | | | | | 1552 | | | |(18) Alloc Res | 1553 | | | |--------------->| 1554 | | | |Src=TURN-PUB-1 | 1555 | | | |Dest=R-PRIV-2 | 1556 | | | |Map=R-NAT-PUB-2 | 1557 | | | |Rel=TURN-PUB-5 | 1558 | | | | | 1559 | | | |(19) SIP 200 OK | 1560 | |<-------------------------------------------------| 1561 | | | | | 1562 |(20) SIP 200 OK | | | | 1563 |<---------------| | | | 1564 | | | | | 1565 |(21) SIP ACK | | | | 1566 |------------------------------------------------->| | 1567 | | | | | 1568 | | | |(22) SIP ACK | 1569 | | | |--------------->| 1570 | | | | | 1571 |(23) Bind Req | | | | 1572 |------------------------>x | | | 1573 |Src=L-PRIV-1 | | | | 1574 |Dest=R-PRIV-1 | | | | 1575 | | | | | 1576 |(24) Bind Req | | | | 1577 |--------------->| | | | 1578 |Src=L-PRIV-1 | | | | 1579 |Dest=R-NAT-PUB-1| | | | 1580 | | | | | 1581 | |(25) Bind Req | | | 1582 | |-------------------------------->| | 1583 | |Src=L-NAT-PUB-1 | | | 1584 | |Dest=R-NAT-PUB-1| | | 1585 | | | | | 1586 | | | |(26) Bind Req | 1587 | | | |--------------->| 1588 | | | |Src=L-NAT-PUB-1 | 1589 | | | |Dest=R-PRIV-1 | 1590 | | | | | 1591 | | | |(27) Bind Res | 1592 | | | |<---------------| 1593 | | | |Src=R-PRIV-1 | 1594 | | | |Dest=L-NAT-PUB-1| 1595 | | | |Map=L-NAT-PUB-1 | 1596 | | | | | 1597 | | |(28) Bind Res | | 1598 | |<--------------------------------| | 1599 | | |Src=R-NAT-PUB-1 | | 1600 | | |Dest=L-NAT-PUB-1| | 1601 | | |Map=L-NAT-PUB-1 | | 1602 | | | | | 1603 |(29) Bind Res | | | | 1604 |<---------------| | | | 1605 |Src=R-NAT-PUB-1 | | | | 1606 |Dest=L-PRIV-1 | | | | 1607 |Map=L-NAT-PUB-1 | | | | 1608 | | | | | 1609 |===================================================================| 1610 |>>>>>>>>>>>>>>>>>>Outgoing RTP sent from L-PRIV-1 >>>>>>>>>>>>>>>>>| 1611 |===================================================================| 1612 | | | | | 1613 | | | |(30) Bind Req | 1614 | | | x<-----------------------| 1615 | | | |Src=R-PRIV-1 | 1616 | | | |Dest=L-PRIV-1 | 1617 | | | | | 1618 | | | |(31) Bind Req | 1619 | | | |<---------------| 1620 | | | |Src=R-PRIV-1 | 1621 | | | |Dest=L-NAT-PUB-1| 1622 | | | | | 1623 | | |(32) Bind Req | | 1624 | |<--------------------------------| | 1625 | | |Src=R-NAT-PUB-1 | | 1626 | | |Dest=L-NAT-PUB-1| | 1627 | | | | | 1628 |(33) Bind Req | | | | 1629 |<---------------| | | | 1630 |Src=R-NAT-PUB-1 | | | | 1631 |Dest=L-PRIV-1 | | | | 1632 | | | | | 1633 |(34) Bind Res | | | | 1634 |--------------->| | | | 1635 |Src=L-PRIV-1 | | | | 1636 |Dest=R-NAT-PUB-1| | | | 1637 |Map=R-NAT-PUB-1 | | | | 1638 | | | | | 1639 | |(35) Bind Res | | | 1640 | |-------------------------------->| | 1641 | |Src=L-NAT-PUB-1 | | | 1642 | |Dest=R-NAT-PUB-1| | | 1643 | |Map=R-NAT-PUB-1 | | | 1644 | | | | | 1645 | | | |(36) Bind Res | 1646 | | | |--------------->| 1647 | | | |Src=L-NAT-PUB-1 | 1648 | | | |Dest=R-PRIV-1 | 1649 | | | |Map=R-NAT-PUB-1 | 1650 | | | | | 1651 |===================================================================| 1652 |<<<<<<<<<<<<<<<<<| | | | 1656 |Src=L-PRIV-1 | | | | 1657 |Dest=R-NAT-PUB-1| | | | 1658 |USE-CANDIDATE | | | | 1659 | | | | | 1660 | |(38) Bind Req | | | 1661 | |-------------------------------->| | 1662 | |Src=L-NAT-PUB-1 | | | 1663 | |Dest=R-NAT-PUB-1| | | 1664 | |USE-CANDIDATE | | | 1665 | | | | | 1666 | | | |(39) Bind Req | 1667 | | | |--------------->| 1668 | | | |Src=L-NAT-PUB-1 | 1669 | | | |Dest=R-PRIV-1 | 1670 | | | |USE-CANDIDATE | 1671 | | | | | 1672 | | | |(40) Bind Res | 1673 | | | |<---------------| 1674 | | | |Src=R-PRIV-1 | 1675 | | | |Dest=L-NAT-PUB-1| 1676 | | | |Map=L-NAT-PUB-1 | 1677 | | | | | 1678 | | |(41) Bind Res | | 1679 | |<--------------------------------| | 1680 | | |Src=R-NAT-PUB-1 | | 1681 | | |Dest=L-NAT-PUB-1| | 1682 | | |Map=L-NAT-PUB-1 | | 1683 | | | | | 1684 |(42) Bind Res | | | | 1685 |<---------------| | | | 1686 |Src=R-NAT-PUB-1 | | | | 1687 |Dest=L-PRIV-1 | | | | 1688 |Map=L-NAT-PUB-1 | | | | 1689 | | | | | 1690 |(43) Bind Req | | | | 1691 |--------------->| | | | 1692 |Src=L-PRIV-2 | | | | 1693 |Dest=R-NAT-PUB-2| | | | 1694 | | | | | 1695 | |(44) Bind Req | | | 1696 | |-------------------------------->| | 1697 | |Src=L-NAT-PUB-2 | | | 1698 | |Dest=R-NAT-PUB-2| | | 1699 | | | | | 1700 | | | |(45) Bind Req | 1701 | | | |--------------->| 1702 | | | |Src=L-NAT-PUB-2 | 1703 | | | |Dest=R-PRIV-2 | 1704 | | | | | 1705 | | | |(46) Bind Res | 1706 | | | |<---------------| 1707 | | | |Src=R-PRIV-2 | 1708 | | | |Dest=L-NAT-PUB-2| 1709 | | | |Map=L-NAT-PUB-2 | 1710 | | | | | 1711 | | |(47) Bind Res | | 1712 | |<--------------------------------| | 1713 | | |Src=R-NAT-PUB-2 | | 1714 | | |Dest=L-NAT-PUB-2| | 1715 | | |Map=L-NAT-PUB-2 | | 1716 | | | | | 1717 |(48) Bind Res | | | | 1718 |<---------------| | | | 1719 |Src=R-NAT-PUB-2 | | | | 1720 |Dest=L-PRIV-2 | | | | 1721 |Map=L-NAT-PUB-2 | | | | 1722 | | | | | 1723 |===================================================================| 1724 |>>>>>>>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2 >>>>>>>>>>>>>>>>| 1725 |===================================================================| 1726 | | | | | 1727 | | | |(49) Bind Req | 1728 | | | |<---------------| 1729 | | | |Src=R-PRIV-2 | 1730 | | | |Dest=L-NAT-PUB-2| 1731 | | | | | 1732 | | |(50) Bind Req | | 1733 | |<--------------------------------| | 1734 | | |Src=R-NAT-PUB-2 | | 1735 | | |Dest=L-NAT-PUB-2| | 1736 | | | | | 1737 |(51) Bind Req | | | | 1738 |<---------------| | | | 1739 |Src=R-NAT-PUB-2 | | | | 1740 |Dest=L-PRIV-2 | | | | 1741 | | | | | 1742 |(52) Bind Res | | | | 1743 |--------------->| | | | 1744 |Src=L-PRIV-2 | | | | 1745 |Dest=R-NAT-PUB-2| | | | 1746 |Map=R-NAT-PUB-2 | | | | 1747 | | | | | 1748 | |(53) Bind Res | | | 1749 | |-------------------------------->| | 1750 | |Src=L-NAT-PUB-2 | | | 1751 | |Dest=R-NAT-PUB-2| | | 1752 | |Map=R-NAT-PUB-2 | | | 1753 | | | | | 1754 | | | |(54) Bind Res | 1755 | | | |--------------->| 1756 | | | |Src=L-NAT-PUB-2 | 1757 | | | |Dest=R-PRIV-2 | 1758 | | | |Map=R-NAT-PUB-2 | 1759 | | | | | 1760 |===================================================================| 1761 |<<<<<<<<<<<<<<<<<| | | | 1765 |Src=L-PRIV-2 | | | | 1766 |Dest=R-NAT-PUB-2| | | | 1767 |USE-CANDIDATE | | | | 1768 | | | | | 1769 | |(56) Bind Req | | | 1770 | |-------------------------------->| | 1771 | |Src=L-NAT-PUB-2 | | | 1772 | |Dest=R-NAT-PUB-2| | | 1773 | |USE-CANDIDATE | | | 1774 | | | | | 1775 | | | |(57) Bind Req | 1776 | | | |--------------->| 1777 | | | |Src=L-NAT-PUB-2 | 1778 | | | |Dest=R-PRIV-2 | 1779 | | | |USE-CANDIDATE | 1780 | | | | | 1781 | | | |(58) Bind Res | 1782 | | | |<---------------| 1783 | | | |Src=R-PRIV-2 | 1784 | | | |Dest=L-NAT-PUB-2| 1785 | | | |Map=L-NAT-PUB-2 | 1786 | | | | | 1787 | | |(59) Bind Res | | 1788 | |<--------------------------------| | 1789 | | |Src=R-NAT-PUB-2 | | 1790 | | |Dest=L-NAT-PUB-2| | 1791 | | |Map=L-NAT-PUB-2 | | 1792 | | | | | 1793 |(60) Bind Res | | | | 1794 |<---------------| | | | 1795 |Src=R-NAT-PUB-2 | | | | 1796 |Dest=L-PRIV-2 | | | | 1797 |Map=L-NAT-PUB-2 | | | | 1798 | | | | | 1799 | | | | | 1800 |(61) SIP INVITE | | | | 1801 |------------------------------------------------->| | 1802 | | | | | 1803 | | | |(62) SIP INVITE | 1804 | | | |--------------->| 1805 | | | | | 1806 | | | |(63) SIP 200 OK | 1807 | |<-------------------------------------------------| 1808 | | | | | 1809 |(64) SIP 200 OK | | | | 1810 |<---------------| | | | 1811 | | | | | 1812 |(65) SIP ACK | | | | 1813 |------------------------------------------------->| | 1814 | | | | | 1815 | | | |(66) SIP ACK | 1816 | | | |--------------->| 1817 | | | | | 1818 Figure 13: Endpoint Independent NAT with ICE 1820 o On deciding to initiate a SIP voice session the SIP client 'L' 1821 starts a local STUN client. The STUN client generates a TURN 1822 Allocate request as indicated in (1) from Figure 13 which also 1823 highlights the source address and port combination for which the 1824 client device wishes to obtain a mapping. The Allocate request is 1825 sent through the NAT towards the public internet. 1826 o The Allocate message (2) traverses the NAT to the public internet 1827 towards the public TURN server. Note that the source address of 1828 the Allocate request now represents the public address and port 1829 from the public side of the NAT (L-NAT-PUB-1). 1830 o The TURN server receives the Allocate request and processes it 1831 appropriately. This results in a successful Allocate response 1832 being generated and returned (3). The message contains details of 1833 the server reflexive address which is to be used by the 1834 originating client to receive media (see 'Map=L-NAT-PUB-1') from 1835 (3)). It also contains an appropriate TURN-relayed address that 1836 can be used at the STUN server (see 'Rel=TURN-PUB-2'). 1837 o The Allocate response traverses back through the NAT using the 1838 binding created by the initial Allocate request and presents the 1839 new mapped address to the client (4). The process is repeated and 1840 a second STUN derived set of address' are obtained, as illustrated 1841 in (5)-(8) in Figure 13. At this point the User Agent behind the 1842 NAT has pairs of derived external server reflexive and relayed 1843 representations. The client would be free to gather any number of 1844 external representations using any UNSAF[RFC3424] compliant 1845 protocol. 1846 o The client now constructs a SIP INVITE message (9). The INVITE 1847 request will use the addresses it has obtained in the previous 1848 STUN/TURN interactions to populate the SDP of the SIP INVITE. 1849 This should be carried out in accordance with the semantics 1850 defined in the ICE specification[I-D.ietf-mmusic-ice], as shown 1851 below in Figure 14: 1853 v=0 1854 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1 1855 c=IN IP4 $L-PRIV-1.address 1856 t=0 0 1857 a=ice-pwd:$LPASS 1858 a=ice-ufrag:$LUNAME 1859 m=audio $L-PRIV-1.port RTP/AVP 0 1860 a=rtpmap:0 PCMU/8000 1861 a=rtcp:$L-PRIV-2.port 1862 a=candidate:$L1 1 UDP 2130706431 $L-PRIV-1.address $L-PRIV-1.port 1863 typ host 1864 a=candidate:$L1 2 UDP 2130706430 $L-PRIV-2.address $L-PRIV-2.port 1865 typ host 1866 a=candidate:$L2 1 UDP 1694498815 $L-NAT-PUB-1.address $L-NAT-PUB-1.port 1867 typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port 1868 a=candidate:$L2 2 UDP 1694498814 $L-NAT-PUB-2.address $L-NAT-PUB-2.port 1869 typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port 1870 a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-2.port 1871 typ relay raddr $L-PRIV-1.address rport $L-PRIV-1.port 1872 a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-3.port 1873 typ relay raddr $L-PRIV-1.address rport $L-PRIV-2.port 1875 Figure 14: ICE SDP Offer 1877 o The SDP has been constructed to include all the available 1878 candidates that have been assembled. The first set of candidates 1879 (as identified by Foundation $L1) contain two local addresses that 1880 have the highest priority. They are also encoded into the 1881 connection (c=) and media (m=) lines of the SDP. The second set 1882 of candidates, as identified by Foundation $L2, contains the two 1883 server reflexive addresses obtained from the STUN server for both 1884 RTP and RTCP traffic (identified by candidate-id $L2). This entry 1885 has been given a priority lower than the pair $L1 by the client. 1886 The third and final set of candidates represents the relayed 1887 addresses (as identified by $L3) obtained from the STUN server. 1888 This pair has the lowest priority and will be used as a last 1889 resort if both $L1 or $L2 fail. 1890 o The SIP signaling then traverses the NAT and sets up the SIP 1891 session (9)-(10). On advertising a candidate address, the client 1892 should have a local STUN server running on each advertised 1893 candidate address. This is for the purpose of responding to 1894 incoming STUN connectivity checks. 1895 o On receiving the SIP INVITE request (10) client 'R' also starts 1896 local STUN servers on appropriate address/port combinations and 1897 gathers potential candidate addresses to be encoded into the SDP 1898 (as the originating client did). Steps (11-18) involve client 'R' 1899 carrying out the same steps as client 'L'. This involves 1900 obtaining local, server reflexive and relayed addresses. Client 1901 'R' is now ready to generate an appropriate answer in the SIP 200 1902 OK message (19). The example answer follows in Figure 14: 1904 v=0 1905 o=test 3890844516 3890842803 IN IP4 $R-PRIV-1 1906 c=IN IP4 $R-PRIV-1.address 1907 t=0 0 1908 a=ice-pwd:$RPASS 1909 m=audio $R-PRIV-1.port RTP/AVP 0 1910 a=rtpmap:0 PCMU/8000 1911 a=rtcp:$R-PRIV-2.port 1912 a=candidate:$L1 1 UDP 2130706431 $R-PRIV-1.address $R-PRIV-1.port 1913 typ host 1914 a=candidate:$L1 2 UDP 2130706430 $R-PRIV-2.address $R-PRIV-2.port 1915 typ host 1916 a=candidate:$L2 1 UDP 1694498815 $R-NAT-PUB-1.address $R-NAT-PUB-1.port 1917 typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port 1918 a=candidate:$L2 2 UDP 1694498814 $R-NAT-PUB-2.address $R-NAT-PUB-2.port 1919 typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port 1920 a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-4.port 1921 typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port 1922 a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-5.port 1923 typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port 1925 Figure 15: ICE SDP Answer 1927 o The two clients have now exchanged SDP using offer/answer and can 1928 now continue with the ICE processing - User Agent 'L' assuming the 1929 role controlling agent, as specified by ICE. The clients are now 1930 required to form their Candidate check lists to determine which 1931 will be used for the media streams. In this example User Agent 1932 'L's 'Foundation 1' is paired with User Agent 'R's 'Foundation 1', 1933 User Agent 'L's 'Foundation 2' is paired with User Agent 'R's 1934 'Foundation 2', and finally User Agent 'L's 'Foundation 3' is 1935 paired with User Agent 'R's 'Foundation 3'. User Agents 'L' and 1936 'R' now have a complete candidate check list. Both clients now 1937 use the algorithm provided in ICE to determine candidate pair 1938 priorities and sort into a list of decreasing priorities. In this 1939 example, both User Agent 'L' and 'R' will have lists that firstly 1940 specifies the host address (Foundation $L1), then the server 1941 reflexive address (Foundation $L2) and lastly the relayed address 1942 (Foundation $L3). All candidate pairs have an associate state as 1943 specified in ICE. At this stage, all of the candidate pairs for 1944 User Agents 'L' and 'R' are initialized to the 'Frozen' state. 1945 The User Agents then scan the list and move the candidates to the 1946 'Waiting' state. At this point both clients will periodically, 1947 starting with the highest candidate pair priority, work their way 1948 down the list issuing STUN checks from the local candidate to the 1949 remote candidate (of the candidate pair). As a STUN Check is 1950 attempted from each local candidate in the list, the candidate 1951 pair state transitions to 'In-Progress'. As illustrated in (23), 1952 client 'L' constructs a STUN connectivity check in an attempt to 1953 validate the remote candidate address received in the SDP of the 1954 200 OK (20) for the highest priority in the check list. As a 1955 private address was specified in the active address in the SDP, 1956 the STUN connectivity check fails to reach its destination causing 1957 a STUN failure. Client 'L' transitions the state for this 1958 candidate pair to 'Failed'. In the mean time, Client 'L' is 1959 attempting a STUN connectivity check for the second candidate pair 1960 in the returned SDP with the second highest priority (24). As can 1961 be seen from messages (24) to (29), the STUN Bind request is 1962 successful and returns a positive outcome for the connectivity 1963 check. Client 'L' is now free to send media to the peer using the 1964 candidate pair. Immediately after sending its 200 Okay, Client 1965 'R' also carries out the same set of binding requests. It firstly 1966 (in parallel) tries to contact the active address contained in the 1967 SDP (30) which results in failure. 1968 o In the mean time, a successful response to a STUN connectivity 1969 check by User Agent 'R' (27) results in a tentative check in the 1970 reverse direction - this is illustrated by messages (31) to (36). 1971 Once this check has succeeded, User Agent 'R' can transition the 1972 state of the appropriate candidate to 'Succeeded', and media can 1973 be sent (RTP). The previously (31-36) described check confirm on 1974 both sides (User Agent 'L' and 'R') that connectivity can be 1975 achieved using the appropriate candidate pair. User Agent 'L', as 1976 the controlling client now sends another connectivity check for 1977 the candidate pair, this time including the 'USE-CANDIDATE' 1978 attribute as specified in ICE to signal the chosen candidate. 1979 This exchange is illustrated in messages (37) to (42). 1980 o As part of the process in this example, both 'L' and 'R' will now 1981 complete the same connectivity checks for part 2 of the component 1982 named for the favored 'Foundation' selected for use with RTCP. 1983 The connectivity checks for part '2' of the candidate component 1984 are shown in 'L'(43-48) and 'R'(49-54). Once this has succeeded, 1985 User Agent 'L' as the controlling client sends another 1986 connectivity check for the candidate pair. This time the 'USE- 1987 CANDIDATE' attribute is again specified to signal the chosen 1988 candidate for component '2'. 1989 o The candidates have now been fully verified (and selected) and as 1990 they are the highest priority, an updated offer (61-62) is now 1991 sent from the offerer (client 'L') to the answerer (client 'R') 1992 representing the new active candidates. The new offer would look 1993 as follows: 1995 v=0 1996 o=test 2890844526 2890842808 IN IP4 $L-PRIV-1 1997 c=IN IP4 $L-NAT-PUB-1.address 1998 t=0 0 1999 a=ice-pwd:$LPASS 2000 a=ice-ufrag:$LUNAME 2001 m=audio $L-NAT-PUB-1.port RTP/AVP 0 2002 a=rtpmap:0 PCMU/8000 2003 a=rtcp:$L-NAT-PUB-2.port 2004 a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port 2005 typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port 2006 a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port 2007 typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port 2009 Figure 16: ICE SDP Updated Offer 2011 o The resulting answer (63-64) for 'R' would look as follows: 2013 v=0 2014 o=test 3890844516 3890842804 IN IP4 $R-PRIV-1 2015 c=IN IP4 $R-PRIV-1.address 2016 t=0 0 2017 a=ice-pwd:$RPASS 2018 a=ice-ufrag:$RUNAME 2019 m=audio $R-PRIV-1.port RTP/AVP 0 2020 a=rtpmap:0 PCMU/8000 2021 a=rtcp:$R-PRIV-2.port 2022 a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port 2023 typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port 2024 a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port 2025 typ srflx raddr $R-PRIV-1.address rport $R-PRIV-2.port 2027 Figure 17: ICE SDP Updated Answer 2029 5.2.2. Address and Port Dependant NAT 2031 5.2.2.1. STUN Failure 2033 This section highlights that while using STUN techniques is the 2034 preferred mechanism for traversal of NAT, it does not solve every 2035 case. The use of basic STUN on its own will not guarantee traversal 2036 through every NAT type, hence the recommendation that ICE is the 2037 preferred option. 2039 Client PORT/ADDRESS-Dependant STUN [..] 2040 NAT Server 2041 | | | | 2042 |(1) BIND Req | | | 2043 |Src=L-PRIV-1 | | | 2044 |Dest=STUN-PUB | | | 2045 |----------------->| | | 2046 | | | | 2047 | |(2) BIND Req | | 2048 | |Src=NAT-PUB-1 | | 2049 | |Dest=STUN-PUB | | 2050 | |----------------->| | 2051 | | | | 2052 | |(3) BIND Resp | | 2053 | |<-----------------| | 2054 | |Src=STUN-PUB | | 2055 | |Dest=NAT-PUB-1 | | 2056 | |Map=NAT-PUB-1 | | 2057 | | | | 2058 |(4) BIND Resp | | | 2059 |<-----------------| | | 2060 |Src=STUN-PUB | | | 2061 |Dest=L-PRIV-1 | | | 2062 |Map=NAT-PUB-1 | | | 2063 | | | | 2064 |(5)SIP INVITE | | | 2065 |------------------------------------------------------->| 2066 | | | | 2067 | | |(6)SIP 200 OK | 2068 | |<------------------------------------| 2069 | | | | 2070 |(7)SIP 200 OK | | | 2071 |<-----------------| | | 2072 | | | | 2073 |========================================================| 2074 |>>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>| 2075 |========================================================| 2076 | | | | 2077 | x=====================================| 2078 | xIncoming Media sent to L-PRIV-1<<<<<<| 2079 | x=====================================| 2080 | | | | 2081 |(8)SIP ACK | | | 2082 |----------------->| | | 2083 | |(9) SIP ACK | | 2084 | |------------------------------------>| 2085 | | | | 2086 Figure 18: Port/Address-Dependant NAT with STUN - Failure 2088 The example in Figure 18 is conveyed in the context of a client 2089 behind the 'Port/Address-Dependant' NAT initiating a call. It should 2090 be noted that the same problem applies when a client receives a SIP 2091 invitation and is behind a Port/Address-Dependant NAT. 2092 o In Figure 18 the client behind the NAT obtains a server reflexive 2093 representation using standard STUN mechanisms (1)-(4) that have 2094 been used in previous examples in this document (e.g 2095 Section 5.2.1.1.1). 2096 o The external mapped address (server reflexive) obtained is also 2097 used in the outgoing SDP contained in the SIP INVITE request(5). 2098 o In this example the client is still able to send media to the 2099 external client. The problem occurs when the client outside the 2100 NAT tries to use the reflexive address supplied in the outgoing 2101 INVITE request to traverse media back through the 'Port/Address 2102 Dependent' NAT. 2103 o A 'Port/Address-Dependant' NAT has differing rules from the 2104 'Endpoint Independent' type of NAT (as defined in RFC4787 2105 [RFC4787]). For any internal IP address and port combination, 2106 data sent to a different external destination does not provide the 2107 same public mapping at the NAT. In Figure 18 the STUN query 2108 produced a valid external mapping for receiving media. This 2109 mapping, however, can only be used in the context of the original 2110 STUN request that was sent to the STUN server. Any packets that 2111 attempt to use the mapped address, that do not originate from the 2112 STUN server IP address and optionally port, will be dropped at the 2113 NAT. Figure 18 shows the media being dropped at the NAT after (7) 2114 and before (8). This then leads to one way audio. 2116 5.2.2.2. TURN Solution 2118 As identified in Section Section 5.2.2.1, STUN provides a useful tool 2119 for the traversal of the majority of NATs but fails with Port/Address 2120 Dependent NAT. The TURN extensions [I-D.ietf-behave-turn] address 2121 this scenario. TURN extends STUN to allow a client to request a 2122 relayed address at the TURN server rather than a reflexive 2123 representation. This then introduces a media relay in the path for 2124 NAT traversal (as described in Section 4.2.3.2). The following 2125 example explains how TURN solves the previous failure when using STUN 2126 to traverse a 'Port/ Address Dependent' type NAT. 2128 L Port/Address-Dependant STUN [..] 2129 NAT Server 2130 | | | | 2131 |(1) Alloc Req | | | 2132 |Src=L-PRIV-1 | | | 2133 |Dest=STUN-PUB-1 | | | 2134 |----------------->| | | 2135 | | | | 2136 | |(2) Alloc Req | | 2137 | |Src=NAT-PUB-1 | | 2138 | |Dest=STUN-PUB-1 | | 2139 | |----------------->| | 2140 | | | | 2141 | |(3) Alloc Resp | | 2142 | |<-----------------| | 2143 | |Src=STUN-PUB-1 | | 2144 | |Dest=NAT-PUB-1 | | 2145 | |Map=NAT-PUB-1 | | 2146 | |Rel=STUN-PUB-2 | | 2147 | | | | 2148 |(4) Alloc Resp | | | 2149 |<-----------------| | | 2150 |Src=STUN-PUB-1 | | | 2151 |Dest=L-PRIV-1 | | | 2152 |Map=NAT-PUB-1 | | | 2153 |Rel=STUN-PUB-2 | | | 2154 | | | | 2155 |(5) Alloc Req | | | 2156 |Src=L-PRIV-2 | | | 2157 |Dest=STUN-PUB-1 | | | 2158 |----------------->| | | 2159 | | | | 2160 | |(6) Alloc Req | | 2161 | |Src=NAT-PUB-2 | | 2162 | |Dest=STUN-PUB-1 | | 2163 | |----------------->| | 2164 | | | | 2165 | |(7) Alloc Resp | | 2166 | |<-----------------| | 2167 | |Src=STUN-PUB-1 | | 2168 | |Dest=NAT-PUB-2 | | 2169 | |Map=NAT-PUB-2 | | 2170 | |Rel=STUN-PUB-3 | | 2171 | | | | 2172 |(8) Alloc Resp | | | 2173 |<-----------------| | | 2174 |Src=STUN-PUB-1 | | | 2175 |Dest=L-PRIV-2 | | | 2176 |Map=NAT-PUB-2 | | | 2177 |Rel=STUN-PUB-3 | | | 2178 | | | | 2179 |(9)SIP INVITE | | | 2180 |----------------->| | | 2181 | | | | 2182 | |(10)SIP INVITE | | 2183 | |------------------------------------>| 2184 | | | | 2185 | | |(11)SIP 200 OK | 2186 | |<------------------------------------| 2187 | | | | 2188 |(12)SIP 200 OK | | | 2189 |<-----------------| | | 2190 | | | | 2191 |========================================================| 2192 |>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>| 2193 |========================================================| 2194 | | | | 2195 | | |==================| 2196 | | |<<| 2206 | | |<<<| | | 2215 | | | | 2216 | |(14) SIP ACK | | 2217 | |------------------------------------>| 2218 | | | | 2220 Figure 19: Port/Address-Dependant NAT with TURN - Success 2222 o In this example, client 'L' issues a TURN allocate request(1) to 2223 obtained a relay address at the STUN server. The request 2224 traverses through the 'Port/Address-Dependant' NAT and reaches the 2225 STUN server (2). The STUN server generates an Allocate response 2226 (3) that contains both a server reflexive address (Map=NAT-PUB-1) 2227 of the client and also a relayed address (Rel=STUN-PUB-2). The 2228 relayed address maps to an address mapping on the STUN server 2229 which is bound to the public pin hole that has been opened on the 2230 NAT by the Allocate request. This results in any traffic sent to 2231 the TURN server relayed address (Rel=STUN-PUB-2) being forwarded 2232 to the external representation of the pin hole created by the 2233 Allocate request(NAT-PUB-1). 2234 o The TURN derived address (STUN-PUB-2) arrives back at the 2235 originating client (4) in an Allocate response. This address can 2236 then be used in the SDP for the outgoing SIP INVITE request as 2237 shown in the following example (note that the example also 2238 includes client 'L' obtaining a second relay address for use in 2239 the RTCP attribute (5-8)): 2241 v=0 2242 o=test 2890844342 2890842164 IN IP4 $L-PRIV-1 2243 c=IN IP4 $STUN-PUB-2.address 2244 t=0 0 2245 m=audio $STUN-PUB-2.port RTP/AVP 0 2246 a=rtcp:$STUN-PUB-3.port 2248 o On receiving the INVITE request, the UAS is able to stream media 2249 and RTCP to the relay address (STUN-PUB-2 and STUN-PUB-3) at the 2250 STUN server. As shown in Figure 19 (between messages (12) and 2251 (13), the media from the UAS is directed to the relayed address at 2252 the STUN server. The STUN server then forwards the traffic to the 2253 open pin holes in the Port/Address-Dependant NAT (NAT-PUB-1 and 2254 NAT-PUB-2). The media traffic is then able to traverse the 'Port/ 2255 Address-Dependant' NAT and arrives back at client 'L'. 2256 o TURN on its own will work for 'Port/Address-Dependent' and other 2257 types of NAT mentioned in this specification but should only be 2258 used as a last resort. The relaying of media through an external 2259 entity is not an efficient mechanism for NAT traversal and comes 2260 at a high processing cost. 2262 5.2.2.3. ICE Solution 2264 The previous two examples have highlighted the problem with using 2265 core STUN for all forms of NAT traversal and a solution using TURN 2266 for the Address/Port-Dependent NAT case. The RECOMMENDED mechanism 2267 for traversing all varieties of NAT is using ICE, as detailed in 2268 Section 4.2.3.3. ICE makes use of core STUN, TURN and any other 2269 UNSAF[RFC3424] compliant protocol to provide a list of prioritized 2270 addresses that can be used for media traffic. Detailed examples of 2271 ICE can be found in Section 5.2.1.2.1. These examples are associated 2272 with an 'Endpoint-Independent' type NAT but can be applied to any NAT 2273 type variation, including 'Address/Port-Dependant' type NAT. The ICE 2274 procedures carried out are the same. For a list of candidate 2275 addresses, a client will choose where to send media dependant on the 2276 results of the STUN connectivity checks and associated priority 2277 (highest priority wins). It should be noted that the inclusion of a 2278 NAT displaying Address/Port-Dependent properties does not 2279 automatically result in relayed media. In fact, ICE processing will 2280 avoid use of media relay with the exception of two clients which both 2281 happen to be behind a NAT using Address/Port-Dependent 2282 characteristics. The connectivity checks and associated selection 2283 algorithm enable traversal in this case. Figure 20 and following 2284 description provide a guide as to how this is achieved using the ICE 2285 connectivity checks. This is an abbreviated example that assumes 2286 successful SIP offer/answer exchange and illustrates the connectivity 2287 check flow. 2289 L Port/Address-Dependent Endpoint-Independent R 2290 L-NAT R-NAT 2291 |========================================================| 2292 | SIP OFFER/ANSWER EXCHANGE | 2293 |========================================================| 2294 | | | | 2295 | | |(1)Bind Req | 2296 | | |<-----------------| 2297 | | |Src=R=PRIV-1 | 2298 | | |Dest=L-NAT-PUB-1 | 2299 | | | | 2300 | |(2)Bind Req | | 2301 | x<-----------------| | 2302 | |Src=R-NAT-PUB-1 | | 2303 | |Dest=L-NAT-PUB-1 | | 2304 | | | | 2305 |(3)Bind Req | | | 2306 |----------------->| | | 2307 |Src=L-PRIV-1 | | | 2308 |Dest=R-NAT-PUB-1 | | | 2309 | | | | 2310 | |(4)Bind Req | | 2311 | |----------------->| | 2312 | |Src=L-NAT-PUB-1 | | 2313 | |Dest=R-NAT-PUB-1 | | 2314 | | | | 2315 | | |(5)Bind Req | 2316 | | |----------------->| 2317 | | |Src=L-NAT-PUB-1 | 2318 | | |Dest=R-PRIV-1 | 2319 | | | | 2320 | | |(6)Bind Resp | 2321 | | |<-----------------| 2322 | | |Src=R-PRIV-1 | 2323 | | |Dest=L-NAT-PUB-1 | 2324 | | | | 2325 | |(7)Bind Resp | | 2326 | |<-----------------| | 2327 | |Src=R-NAT-PUB-1 | | 2328 | |Dest=L-NAT-PUB-1 | | 2329 | | | | 2330 |(8)Bind Resp | | | 2331 |<-----------------| | | 2332 |Src=R-NAT-PUB-1 | | | 2333 |Dest=L-PRIV-1 | | | 2334 | | | | 2335 | | |(9)Bind Req | 2336 | | |<-----------------| 2337 | | |Src=R-Priv-1 | 2338 | | |Dest=L-NAT-PUB-1 | 2339 | |(10)Bind Req | | 2340 | |<-----------------| | 2341 | |Src=R-NAT-PUB-1 | | 2342 | |Dest=L-NAT-PUB-1 | | 2343 | | | | 2344 |(11)Bind Req | | | 2345 |<-----------------| | | 2346 |Src=R-NAT-PUB-1 | | | 2347 |Dest=L-PRIV-1 | | | 2348 | | | | 2349 |(12)Bind Resp | | | 2350 |----------------->| | | 2351 |Src=L-PRIV-1 | | | 2352 |Dest=L-NAT-PUB-1 | | | 2353 | | | | 2354 | |(13)Bind Resp | | 2355 | |----------------->| | 2356 | |Src=L-NAT-PUB-1 | | 2357 | |Dest=R-NAT-PUB-1 | | 2358 | | | | 2359 | | |(14)Bind Resp | 2360 | | |----------------->| 2361 | | |Src=L-NAT-PUB-1 | 2362 | | |Dest=R-PRIV-1 | 2363 | | | | 2364 | 2365 Figure 20: Single Port/Address-Dependant NAT - Success 2367 In this abbreviated example, Client R has already received a SIP 2368 INVITE request and is starting its connectivity checks with Client L. 2369 Client R generates a connectivity check (1) and sends to client L's 2370 information as presented in the SDP offer. The request arrives at 2371 client L's Port/Address dependent NAT and fails to traverse as there 2372 is no NAT binding. This would then move the connectivity check to a 2373 failed state. In the mean time client L has received the SDP answer 2374 in the SIP request and will also commence connectivity checks. A 2375 check is dispatched (3) to Client R. The check is able to traverse 2376 the NAT due to the association set up in the previously failed 2377 check(1). The full Bind request/response is shown in steps (3)-(8). 2378 As part of a candidate pair, Client R will now successfully be able 2379 to complete the checks, as illustrated in steps (9)-(14). The result 2380 is a successful pair of candidates that can be used without the need 2381 to relay any media. 2383 In conclusion, the only time media needs to be relayed is a result of 2384 clients both behind Address/Port Dependant NAT type. As you can see 2385 from the example in this section, neither side would be able to 2386 complete connectivity checks with the exception of the Relayed 2387 candidates. 2389 6. IPv4-IPv6 Transition 2391 This section describes how IPv6-only SIP user agents can communicate 2392 with IPv4-only SIP user agents. While the techniques discussed in 2393 this draft primarily contain examples of traversing NATs to allow 2394 communications between hosts in private and public networks, they are 2395 by no means limited to such scenarios. The same NAT traversal 2396 techniques can also be used to establish communication in a 2397 heterogeneous network environment -- e.g., communication between an 2398 IPv4 host and an IPv6 host. 2400 6.1. IPv4-IPv6 Transition for SIP Signaling 2402 IPv4-IPv6 translations at the SIP level usually take place at dual- 2403 stack proxies that have both IPv4 and IPv6 DNS entries. Since this 2404 translations do not involve NATs that are placed in the middle of two 2405 SIP entities, they fall outside the scope of this document. A 2406 detailed description of this type of translation can be found in 2407 [I-D.ietf-sipping-v6-transition] 2409 6.2. IPv4-IPv6 Transition for Media 2411 Figure 21 shows a network of IPv6 SIP user agents that has a relay 2412 with a pool of public IPv4 addresses. The IPv6 SIP user agents of 2413 this IPv6 network need to communicate with users on the IPv4 2414 Internet. To do so, the IPv6 SIP user agents use TURN to obtain a 2415 set of public IPv4 address and port pairs from the relay (for RTP and 2416 RTCP). The mechanism that an IPv6 SIP user agent follows to obtain 2417 public IPv4 address and port pairs from a relay using TURN is the 2418 same as the one followed by a user agent with a private IPv4 address 2419 to obtain public IPv4 address and port pairs. The example below 2420 explains how a UA in an IPv6-only network can use ICE 2421 [I-D.ietf-mmusic-ice] to communicate with a SIP Phone in an IPv4-only 2422 network. Note that no server reflective addresses are used in this 2423 example. 2425 +----------+ 2426 | / \ | 2427 /SIP \ 2428 /Phone \ 2429 / \ 2430 ------------ 2431 | | 2432 | | 2433 192.0.2.2:25000 | | 192.0.2.2:25123 2434 RTP RTCP 2435 +-------------+ 2436 | TURN Server | 2437 +-------------+ 2438 IPv4 Network | | 2439 +---------+ 2440 | | 2441 ----------------------| NAT |--------------------- 2442 | | 2443 +---------+ 2444 IPv6 Network | | 2445 | | 2446 | | 2447 [2001:DB8::1]:30000 RTP RTCP [2001:DB8::1]:30001 2448 +----------+ 2449 | IPv6 SIP | 2450 | UA | 2451 +----------+ 2453 Figure 21: IPv6-IPv4 transition scenario 2455 The IPv6 UA obtains a TURN-derived IPv4 address and port pair for its 2456 RTP port and another one for its RTCP port by issuing 2 TURN Allocate 2457 requests. The TURN server generates responses containing relayed 2458 IPv4 addressee and port pairs for both RTP and RTCP ports. These 2459 IPv4 addresses and port pairs map to the IPv6 source addressee and 2460 port pairs. The result of any UDP packets sent to the IPv4 address 2461 and port pairs provided by the TURN server (i.e., 192.0.2.2:25000 for 2462 RTP and 192.0.2.2:25123 for RTCP) with be redirected to the IPv6 IP 2463 address and port pairs of the SIP UA (i.e., [2001:DB8::1]:30000 for 2464 RTP and [2001:DB8::1]:30001 for RTCP). 2466 When the UA builds the original Offer, it includes 2 candidates: one 2467 for the host IPv6 address and another for the relay IPv4 address. 2468 When computing the priority for the candidate, we will use a type 2469 preference of 126 for the host address candidate, and of 0 for the 2470 relay address candidate, a local preference of 65535 for both 2471 candidates, and a component ID of 1 for RTP and 2 for RTCP for both 2472 candidates. This will generate a priority of 2130706431 for the host 2473 address, and of 16777215 for the relay address. The default 2474 candidate is the relay address candidate. The Offer will look as 2475 follows. 2477 v=0 2478 o=test 2890844342 2890842164 IN IP6 2001:DB8::1 2479 c=IN IP4 192.0.2.2 2480 t=0 0 2481 a=ice-pwd:asd88fgpdd777uzjYhagZg 2482 a=ice-ufrag:8hhY 2483 m=audio 25000 RTP/AVP 0 2484 a=rtcp:25123 2485 a=candidate:1 1 UDP 2130706431 [2001:DB8::1] 30000 typ host 2486 a=candidate:1 2 UDP 2130706430 [2001:DB8::1] 30001 typ host 2487 a=candidate:2 1 UDP 16777215 192.0.2.2 25000 typ relay 2488 raddr [2001:DB8::1] rport 30000 2489 a=candidate:2 2 UDP 16777214 192.0.2.2 25123 typ relay 2490 raddr [2001:DB8::1] rport 30001 2492 The Offer is sent in an INVITE request which gets routed to the IPv4- 2493 only UA, which will choose the IPv4 candidate as per normal ICE 2494 procedures. 2496 7. Security Considerations 2498 There are no Security Considerations beyond the ones inherited by 2499 reference. 2501 8. IANA Considerations 2503 There are no IANA Considerations. 2505 9. IAB Considerations 2507 There are no IAB considerations. 2509 10. Acknowledgments 2511 The authors would like to thank the members of the IETF SIPPING WG 2512 for their comments and suggestions. Expert review and contribution 2513 was provided by Francois Audet. 2515 Detailed comments were provided by Vijay Gurbani, kaiduan xie, Remi 2516 Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Dan Wing, Spencer 2517 Dawkins and Hans Persson. 2519 11. References 2521 11.1. Normative References 2523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2524 Requirement Levels", BCP 14, RFC 2119, March 1997. 2526 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2527 A., Peterson, J., Sparks, R., Handley, M., and E. 2528 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2529 June 2002. 2531 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 2532 Protocol (SIP): Locating SIP Servers", RFC 3263, 2533 June 2002. 2535 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2536 Jacobson, "RTP: A Transport Protocol for Real-Time 2537 Applications", STD 64, RFC 3550, July 2003. 2539 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2540 Description Protocol", RFC 4566, July 2006. 2542 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 2543 Translation - Protocol Translation (NAT-PT)", RFC 2766, 2544 February 2000. 2546 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2547 with Session Description Protocol (SDP)", RFC 3264, 2548 June 2002. 2550 [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the 2551 Session Initiation Protocol (SIP) for Symmetric Response 2552 Routing", RFC 3581, August 2003. 2554 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 2555 (SIP) Extension Header Field for Registering Non-Adjacent 2556 Contacts", RFC 3327, December 2002. 2558 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 2559 Schulzrinne, "Grouping of Media Lines in the Session 2560 Description Protocol (SDP)", RFC 3388, December 2002. 2562 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2563 in Session Description Protocol (SDP)", RFC 3605, 2564 October 2003. 2566 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2567 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2568 RFC 4787, January 2007. 2570 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 2571 BCP 131, RFC 4961, July 2007. 2573 [I-D.ietf-sip-connect-reuse] 2574 Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in 2575 the Session Initiation Protocol (SIP)", 2576 draft-ietf-sip-connect-reuse-11 (work in progress), 2577 July 2008. 2579 [I-D.ietf-behave-rfc3489bis] 2580 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2581 "Session Traversal Utilities for (NAT) (STUN)", 2582 draft-ietf-behave-rfc3489bis-18 (work in progress), 2583 July 2008. 2585 [I-D.ietf-behave-turn] 2586 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 2587 Relays around NAT (TURN): Relay Extensions to Session 2588 Traversal Utilities for NAT (STUN)", 2589 draft-ietf-behave-turn-09 (work in progress), July 2008. 2591 [I-D.ietf-sip-outbound] 2592 Jennings, C. and R. Mahy, "Managing Client Initiated 2593 Connections in the Session Initiation Protocol (SIP)", 2594 draft-ietf-sip-outbound-15 (work in progress), June 2008. 2596 [I-D.ietf-sip-gruu] 2597 Rosenberg, J., "Obtaining and Using Globally Routable User 2598 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 2599 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 2600 October 2007. 2602 [I-D.ietf-mmusic-ice] 2603 Rosenberg, J., "Interactive Connectivity Establishment 2604 (ICE): A Protocol for Network Address Translator (NAT) 2605 Traversal for Offer/Answer Protocols", 2606 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 2608 [I-D.ietf-avt-rtp-and-rtcp-mux] 2609 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2610 Control Packets on a Single Port", 2611 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 2612 August 2007. 2614 11.2. Informative References 2616 [I-D.ietf-sipping-sbc-funcs] 2617 Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen, 2618 A., and M. Bhatia, "Requirements from SIP (Session 2619 Initiation Protocol) Session Border Control Deployments", 2620 draft-ietf-sipping-sbc-funcs-06 (work in progress), 2621 June 2008. 2623 [I-D.ietf-mmusic-media-path-middleboxes] 2624 Stucker, B. and H. Tschofenig, "Analysis of Middlebox 2625 Interactions for Signaling Protocol Communication along 2626 the Media Path", 2627 draft-ietf-mmusic-media-path-middleboxes-01 (work in 2628 progress), July 2008. 2630 [I-D.ietf-sipping-v6-transition] 2631 Camarillo, G., "IPv6 Transition in the Session Initiation 2632 Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work 2633 in progress), August 2007. 2635 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 2636 Self-Address Fixing (UNSAF) Across Network Address 2637 Translation", RFC 3424, November 2002. 2639 Authors' Addresses 2641 Chris Boulton 2642 Avaya 2643 Eastern Business Park 2644 St Mellons 2645 Cardiff, South Wales CF3 5EA 2647 Email: cboulton@avaya.com 2649 Jonathan Rosenberg 2650 Cisco Systems 2651 600 Lanidex Plaza 2652 Parsippany, NJ 07054 2654 Email: jdrosen@cisco.com 2656 Gonzalo Camarillo 2657 Ericsson 2658 Hirsalantie 11 2659 Jorvas 02420 2660 Finland 2662 Email: Gonzalo.Camarillo@ericsson.com 2664 Francois Audet 2665 Nortel 2666 4655 Great America Parkway 2667 Santa Clara CA 95054 2668 US 2670 Email: audet@nortel.com 2672 Full Copyright Statement 2674 Copyright (C) The IETF Trust (2008). 2676 This document is subject to the rights, licenses and restrictions 2677 contained in BCP 78, and except as set forth therein, the authors 2678 retain all their rights. 2680 This document and the information contained herein are provided on an 2681 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2682 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2683 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2684 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2685 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2686 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2688 Intellectual Property 2690 The IETF takes no position regarding the validity or scope of any 2691 Intellectual Property Rights or other rights that might be claimed to 2692 pertain to the implementation or use of the technology described in 2693 this document or the extent to which any license under such rights 2694 might or might not be available; nor does it represent that it has 2695 made any independent effort to identify any such rights. Information 2696 on the procedures with respect to rights in RFC documents can be 2697 found in BCP 78 and BCP 79. 2699 Copies of IPR disclosures made to the IETF Secretariat and any 2700 assurances of licenses to be made available, or the result of an 2701 attempt made to obtain a general license or permission for the use of 2702 such proprietary rights by implementers or users of this 2703 specification can be obtained from the IETF on-line IPR repository at 2704 http://www.ietf.org/ipr. 2706 The IETF invites any interested party to bring to its attention any 2707 copyrights, patents or patent applications, or other proprietary 2708 rights that may cover technology that may be required to implement 2709 this standard. Please address the information to the IETF at 2710 ietf-ipr@ietf.org.