idnits 2.17.1 draft-ietf-sipping-nat-scenarios-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 32) being 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 52 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 58 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 27 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 "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 2002) is 7977 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '13') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2705 (ref. '18') (Obsoleted by RFC 3435) -- Obsolete informational reference (is this intentional?): RFC 3015 (ref. '19') (Obsoleted by RFC 3525) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIPPING WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 R. Mahy 6 Cisco 7 S. Sen 8 Nortel 9 draft-ietf-sipping-nat-scenarios-00.txt 10 June 24, 2002 11 Expires: December 2002 13 NAT and Firewall Scenarios and Solutions for SIP 15 STATUS OF THIS MEMO 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 To view the list Internet-Draft Shadow Directories, see 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The problem of firewall and nat traversal for SIP is a complex one, 39 due, in part, to the large number of different scenarios and the 40 multitude of solutions developed to solve them. In this draft, we 41 enumerate the various scenarios which can arise, and for each, point 42 to some of the existing solutions for that scenario, and present call 43 flows and explanations for how it works. 45 Table of Contents 47 1 Introduction ........................................ 4 48 2 Scenario I: Residence with single NAT ............... 4 49 2.1 Solution I: Configuration ........................... 5 50 2.2 Solution II: Stun in Client ......................... 8 51 2.2.1 Not Symmetric NAT ................................... 9 52 2.2.1.1 Registration ........................................ 9 53 2.2.1.2 Registration: TCP ................................... 9 54 2.2.1.3 Registration: STUN .................................. 10 55 2.2.1.4 Registration: UDP, no STUN .......................... 10 56 2.2.1.5 Initiating a Session ................................ 12 57 2.2.1.6 Receiving an Invitation to a Session ................ 15 58 2.2.1.7 Media Flow .......................................... 16 59 2.2.2 Symmetric NAT ....................................... 18 60 2.2.2.1 Registration ........................................ 20 61 2.2.2.2 Initiating a Session ................................ 21 62 2.2.2.3 Answering an Invitation to a Session ................ 22 63 2.2.2.4 Media Flows ......................................... 25 64 2.3 Solution III: STUN in B2BUA ......................... 26 65 2.3.1 Registration ........................................ 26 66 2.3.2 Initiating a Session ................................ 30 67 2.3.3 Receiving an Invitation to a Session ................ 33 68 2.4 Solution IV: ALG .................................... 34 69 3 Uncooperative Enterprise ............................ 37 70 4 Cooperative Enterprise .............................. 37 71 4.1 Solution I: ALG ..................................... 37 72 4.2 Solution II: MIDCOM Firewall and Proxy .............. 40 73 4.3 Solution III: Internal B2BUAWM ...................... 40 74 5 Outsourced Service: Centrex ......................... 43 75 5.1 Solution I: ALG ..................................... 43 76 5.2 Solution II: External B2BUAWM ....................... 46 77 5.2.1 Signaling Path ...................................... 47 78 5.2.2 Media Path: The Case for RTP (Media) Proxy .......... 49 79 5.3 Solution III: Outsourced MIDCOM ..................... 52 80 5.4 Solution IV: STUN and TURN .......................... 53 81 6 Comparing the Approaches ............................ 54 82 7 Changes since draft-rosenberg-sipping-nat- 83 scenarios-00 ................................................... 56 84 8 Future Work ......................................... 57 85 9 Acknowledgements .................................... 57 86 10 Authors Addresses ................................... 57 87 11 Normative References ................................ 57 88 12 Informative References .............................. 58 90 1 Introduction 92 The problem of firewall and NAT traversal is one that receives a very 93 large amount of attention. It is particularly troublesome for 94 interactive communications, such as those established and managed by 95 SIP [1]. A host of solutions have been proposed and discussed, 96 including the Simple Traversal of UDP Through NAT (STUN) protocol 97 [2], Traversal Using Relay NAT (TURN) [3], SIP ALGs [4] [5] [6], the 98 MIDCOM protocol [7], SDP extensions for NAT [8], SIP extensions for 99 NAT [9], RSIP [10] [11], MGCP controlled firewalls [12], tunnels of 100 various flavors [13], and even an April Fools RFC, RFC 3093 [14], 101 which many people have taken quite seriously. 103 This is further complicated by the variety of scenarios that are 104 frequently discussed, including service providers, enterprise, 105 centrex, residential, nats alone, nats and firewalls, firewalls 106 alone, and so on. 108 All of this is the source of unending confusion. For the novice 109 wishing to understand how to solve the "nat problem", it is a nearly 110 insurmountable hurdle to sort through these drafts and scenarios, to 111 put together a coherent view of the options at hand. 113 This draft is a first attempt to resolve that problem. We enumerate 114 what we believe is a comprehensive set of scenarios that have been 115 discussed, and for each scenario, describe some of the solutions and 116 the drafts that would be needed to make them work. Our solution sets 117 are not complete, as they omit discussion of approaches such as RSIP 118 and VPN. Those are coming in a future revision. We have also omitted 119 a good comparison of the solutions, which will also be present in a 120 future revision. 122 The scenarios that are considered include (1) a user behind a 123 residential NAT/FW using a public service provider's VoIP service 124 (Section 2), (2) a user within an enterprise that wants to use the 125 services of a VoIP provider on the public Internet, but whose 126 enterprise is not supporting the service (Section 3), (3) a user 127 within an enterprise that is deploying VoIP itself, and is not using 128 any VoIP provider (Section 4), and (4) a user within an enterprise 129 that is providing VoIP services, but is doing so by outsourcing the 130 service to a public provider. This is effectively a Centrex approach. 131 (Section 5). 133 2 Scenario I: Residence with single NAT 135 In this scenario, a user has a broadband connection to the Internet, 136 using a cable modem or DSL, for example. In order to provide 137 security, or to run multiple machines, the user has purchased an 138 off-the-shelf "DSL Router" as they are called. These devices, 139 manufactured by companies such as Linksys, Netgear, 2wire, and 140 Netopia, generally include a NAT, simple firewall, DHCP server and 141 client, and a built in ethernet switch of some sort. The firewall 142 generally allows all outgoing traffic, but disallows incoming traffic 143 unless specific port forwarding or a DMZ host has been configured. 144 The NAT treatment of UDP in these boxes varies. The most common types 145 appear to be full-cone and restricted cone. See [15] for a definition 146 of these terms. 148 The user in this scenario wishes to use a communications service from 149 a retail provider, such as net2phone or deltathree, for example. The 150 connection between the user and the provider is through the cable 151 modem or DSL, through the public Internet. The user may have multiple 152 PCs in their home accessing this service, but they are not related in 153 any way. This scenario also includes the case where its not a PC, but 154 a standalone SIP phone. In this case, the provider might be providing 155 some kind of second line VoIP service. 157 This scenario is depicted in Figure 1. 159 2.1 Solution I: Configuration 161 The most simplistic solution for this case is to configure the NAT 162 and the PC or softphone to allow for service. 164 Most residential NATs allow the NAT to be configured with a DMZ host. 165 This is a host that will receive all incoming packets that are not 166 associated with some kind of outgoing connection established 167 previously. The NAT also allows the user to find out the IP address 168 that was assigned to them from their cable modem or DSL provider. 170 The procedure is then simple: 172 1. Determine the IP address assigned to the user by the cable 173 or DSL provider, by looking through the residential NAT 174 configuration. Call this the "public address". 176 2. Determine the IP address assigned to the phone that the 177 user wishes to use. This address is on the home LAN, 178 assigned by the DHCP server running in the residential NAT. 179 Call this the "phone address". 181 3. Enable the DMZ host configuration on the residential NAT. 182 Set the DMZ host to be equal to the phone address. This 183 means that the phone will receive all incoming traffic. 185 +--------+ 186 |Provider| 187 | Proxy | 188 | | 189 +---+----+ 190 | 191 --------+---------- 192 /////// \\\\\\\ 193 /// \\\ 194 || || 195 | Internet | 196 | | 197 | | 198 || || 199 \\\ /// 200 \\\\\\\ /////// 201 ---------+--------- 202 | DSL, Cable 203 +--------+-------+ 204 | Home NAT | 205 +----------------+ 207 +--------+ +----------+ 208 | | | / \ | 209 | PC | /SIP \ 210 | | /Phone \ 211 | | / \ 212 +--------+ ------------ 214 Figure 1: Residence with Single NAT 216 4. Configure the PC softphone or hardphone to use the public 217 address in all SIP and SDP messages it builds. Many VoIP 218 clients can be configured in this way. 220 Thats it! This configuration effectively makes the NAT transparent; 221 all packets in go to the phone without being natted, and the phone 222 has the public address that will get routed to it. 224 Phone Client NAT Provider Provider 225 (1) INVITE Proxy Gateway 226 | srcIP = 10.0.1.1 | | | 227 | srcPort = 5060 | | | 228 | SDP = 1.2.3.4:8876 | | 229 |----------------->| | | 230 | |(2) INVITE | | 231 | | srcIP = 1.2.3.4 | | 232 | | srcPort = 9357 | | 233 | |----------------->| | 234 | | |(3) INVITE | 235 | | |----------------->| 236 | | |(4) 200 OK | 237 | | |<-----------------| 238 | | |Resp. to src IP | 239 | | | and port in via | 240 | |(5) 200 OK | | 241 | | dstIP = 1.2.3.4 | | 242 | | dstPort = 5060 | | 243 | |<-----------------| | 244 |(6) 200 OK | | | 245 | dstIP = 10.0.1.1 | | | 246 | dstPort = 5060 | | | 247 |<-----------------| | | 248 |(7) ACK | | | 249 |----------------->| | | 250 | |(8) ACK | | 251 | |------------------------------------>| 252 | |(9) RTP | | 253 | | destIP = 1.2.3.4 | | 254 | | destPort = 8876 | | 255 | |<------------------------------------| 256 |(10) RTP | | | 257 | destIP = 10.0.1.1 | | 258 | destPort = 8876 | | | 259 |<-----------------| | | 261 Figure 2: Configuration solution 263 A PC to phone call flow for this case is shown in Figure 2. Since the 264 PC client is configured with the IP address on the public side of the 265 NAT (1.2.3.4), that is the address inserted into the SDP of the 266 INVITE (message 1). When the proxy sends the 200 OK response to the 267 PC (message 4), it sends it to the source IP address where the 268 request came from (1.2.3.4), but the port in the Via header (5060). 269 This is received by the NAT. Since there is no mapping for this, the 270 IP address is rewritten to the DMZ host's address (10.0.1.1), and 271 sent there. This is exactly what we want, since the PC is listening 272 on 5060 for the responses. The media from the gateway to the PC works 273 in a similar way (line 9). Its sent from the gateway to the IP 274 address and port in the SDP (1.2.3.4:8876). The NAT receives this. 275 Since there is no binding, the IP address is rewritten to the DMZ 276 host (1.2.3.4) and the RTP packets forwarded there. 278 Receiving calls will work in a similar way. The Contact header in the 279 registrations from the PC client or hard phone will include the 280 public address (1.2.3.4), and therefore incoming calls are routed 281 there. 283 The benefits of this solution are that it works without additional 284 software changes. However, the drawbacks are many. It requires 285 complex configuration which is certainly beyond the capabilities of 286 most users. Secondly, it only works with a single phone at a time 287 talking. If a different phone is used, the configuration would need 288 to change. Third, it will open up the phone to a variety of DoS 289 attacks, since all other kinds of traffic will be let in towards the 290 phone. 292 2.2 Solution II: Stun in Client 294 The second solution for this scenario is to upgrade the client phone 295 or PC application to include support for the STUN protocol [2], and 296 optionally the SDP extensions for NAT [8], SDP extensions for 297 connection oriented media [16], and SIP extensions for NAT [9]. The 298 latter three are all optional, as the solution can work without them. 299 We discuss the pros and cons of having or not having these. This 300 solution also requires the service provider to deploy the stun server 301 described in [2]. 303 The stun protocol allows a client to discover whether it is behind a 304 nat, and what type of nat it is behind. In the case of three of the 305 four nat types described in [2] (all but the symmetric NAT), stun 306 will provide the client with its public IP address. 308 When the client first starts up, the first thing it will do is to use 309 STUN to determine the type of NAT it is behind. This check need only 310 be done on startup; the type of NAT will not generally change unless 311 the user upgrades or replaces their NAT, in which case a boot of the 312 phone or client would be needed. The procedure on startup is the 313 discovery procedure that is described in the stun protocol. This 314 involves messaging exchanges between the stun client and its stun 315 server. The reader is referred to that document for details. 317 Once the type of NAT is discovered, operation from there on depends 318 on the result of the discovery. If the user discovers that they are 319 not behind any NAT or firewall at all, then no special processing is 320 required. If, however, they discover that they are behind a NAT, the 321 processing depends on whether the NAT is symmetric or not. 323 2.2.1 Not Symmetric NAT 325 In this scenario, the client has discovered that it is behind a full 326 cone or restricted cone NAT. This includes the case where there are 327 multiple NATs (its common for cable modem providers to NAT their 328 entire networks, so this NAT might exist in addition to the NAT in 329 the user's home), but the most restrictive type is full cone or 330 restricted cone. 332 2.2.1.1 Registration 334 The first step is for the client to register. Like everything else, 335 there are several approaches. 337 The recommended procedure is to use a persistent TCP connection for 338 the registrations, and to indicate that the connection is to be 339 reused for incoming requests. If, for some reason, TCP is not 340 possible, there are two UDP-based solutions. One is to use STUN, and 341 the other is to use double UDP registrations. 343 2.2.1.2 Registration: TCP 345 TCP is the recommended solution because of binding lifetimes. TCP 346 connections can remain open through a NAT for extended durations 347 without continuous traffic to refresh them. UDP, on the other hand, 348 requires data traffic every minute or so to keep the bindings active. 349 Therefore, if registrations were done over UDP, they would require 350 registration refreshes every minute or less, which has scalability, 351 performance and congestion issues. 353 The trick with registering over TCP is to inform the server that it 354 should reuse the connection established for registration to send 355 requests to the UA. One way to accomplish that is through a "double 356 register" procedure. In this procedure, the UA opens a TCP connection 357 to the server, and then sends a REGISTER request. The Contact header 358 contains an arbitrary URI. If the server implements the rport 359 parameter in the SIP nat extensions [9], the response to the REGISTER 360 request will contain a filled-in rport and received parameter in the 361 top Via. These parameters identify the source side of the TCP 362 connection as seen by the server. The client can then re-register, 363 removing the Contact that was placed in the first registration, and 364 adding a new Contact, formed from the IP address and rport in the top 365 Via of the previous response. Based on the rules for connection reuse 366 in SIP [1], the server will reuse that connection for sending 367 requests to the client. 369 The alternative is to explicitly request for connection reuse. 370 Requirements for such reuse are documented in [17]. It is expected 371 that the mechanism resulting from these requirements will replace the 372 Translate header which was originally proposed in [9]. 374 Persistent TCP connections introduce failover and load balancing 375 issues. If the client cannot be reached except through the specific 376 TCP connection open to the client on a specific proxy, incoming calls 377 must be routed through that proxy. As a result, load balancers will 378 need to take this into account, explicitly routing a request to that 379 proxy, if its still available. Fault tolerant solutions will need to 380 share the TCP connection state to a backup which shares the same IP 381 address. 383 2.2.1.3 Registration: STUN 385 In the event that TCP registrations are not possible, the next best 386 thing is STUN. The flow for using STUN is shown in Figure 3. 388 First, the client uses a STUN query to its provider's STUN server. 389 This will provide it with an IP address and port on which it can 390 receive messages. The client will use the address and port in the 391 STUN response (message 4) to receive incoming SIP messages. In order 392 to do that, it includes this address and port as the Contact header 393 of a REGISTER message that it sends to its provider's proxy (message 394 5). This REGISTER will need to use the rport parameter in the Via 395 header [9] in order for the response to be received by the UA. The UA 396 will then receive incoming requests through the socket used to 397 allocate the binding from the STUN server. 399 The UA will need to refresh the binding learned from STUN by re- 400 sending the STUN query every minute or so. It will also need to 401 listen for incoming SIP messages on this address and port. 402 Fortunately, the stateless nature of the STUN server makes it 403 relatively inexpensive to refresh the STUN binding, compared to a SIP 404 REGISTER request. 406 2.2.1.4 Registration: UDP, no STUN 408 If STUN is not available, the next best solution is to apply the 409 double registration procedure of Section 2.2.1 to UDP. The process is 411 Client NAT Proxy STUN 412 Server 413 |(1) STUN Query | | | 414 |-------------------->| | | 415 | |(2) STUN Query | | 416 | |------------------------------------------>| 417 | |(3) STUN Response | | 418 | | addr = 1.2.3.4:5678 | | 419 | |<------------------------------------------| 420 |(4) STUN Response | | | 421 | addr = 1.2.3.4:5678 | | | 422 |<--------------------| | | 423 |(5) REGISTER | | | 424 | Contact: 1.2.3.4:5678 | | 425 |-------------------->| | | 426 | |(6) REGISTER | | 427 | | Contact: 1.2.3.4:5678 | 428 | |-------------------->| | 429 | |(7) 200 OK | | 430 | |<--------------------| | 431 |(8) 200 OK | | | 432 |<--------------------| | | 434 Figure 3: Register flow, not symmetric NAT 436 the same, but instead of opening a TCP connection, a single UDP 437 socket is used for both registrations, and is then used to receive 438 incoming SIP requests. 440 The drawback is that the registration will need to be frequently 441 refreshed. The rate needs to be often enough to cause the NAT 442 bindings to remain fresh. This could be as frequently as once every 443 30 seconds. That produces a substantial amount of messaging traffic. 444 A 10,000 user system would be generating REGISTER transactions at a 445 rate of 333 per second, far more than the actual call volume rate for 446 that many users. Therefore, this solution is better suited to lower 447 volume systems. 449 The benefit compared to TCP is, like the STUN solution, if the NAT is 450 full-cone, the incoming INVITE need not be delivered to the proxy 451 with which the UA established the binding. 453 Like TCP, the double registration can be avoid through the use of 454 explicit connection sharing. 456 2.2.1.5 Initiating a Session 458 The next operation to consider is how the client makes a call. The 459 flow for this process is shown in Figure 4. We assume the simple case 460 of a single audio stream. In that case, the client will require two 461 IP addresses and ports - one to receive RTP, and the other, to 462 receive RTCP. As a result, it launches two STUN queries (messages 1-4 463 and message 5-8), resulting in two address/port pairs. Unfortunately, 464 the RTP and RTCP ports are no longer adjacent. This will require the 465 SDP in the INVITE constructed by the client to include the address 466 for RTCP as a separate element. An SDP extension for doing this is 467 defined in [8]. If this extension is not supported by the client (or 468 the called party), the result is that RTCP may not be transmitted for 469 the session. This is bad, but not catastrophic, as the call can 470 proceed without it. 472 The client will also need to populate the IP address in the Contact 473 header of the INVITE. This will generally be the same Contact address 474 which was registered from the process in Section 2.2.1. This should 475 always be the value from the Contact header in the response to the 476 REGISTER request. 478 The final component of the INVITE is the support for connection 479 oriented media [16]. Connection oriented media are media that run 480 over transports that have the notion of a connection that needs to be 481 established. Normally, this means TCP. In the case of TCP, if two 482 parties want to communicate, one needs to initiate the connection, 483 and the other needs to receive it. Once established, both sides can 484 send over the connection. To support that, the comedia draft [16] 485 defines a new SDP attribute, the a=direction attribute. This 486 attribute can take on the values of passive, active, or both. Passive 487 means that the participant can only be on the receiving end of the 488 connection. Active means it must be the initiating side. Both means 489 that it can do either. Connection oriented operation can also be 490 applied to RTP over UDP. We call this mode of operation "symmetric 491 RTP". In symmetric RTP, the active side sends an RTP packet to the 492 passive side. When the passive side receives this, it sends RTP 493 packets back to the source address of the RTP packet just received. 494 Thats it. 496 Symmetric RTP has the important property that one side (the active 497 side) does not need to provide an IP address and port to the peer in 498 its SDP, since no packet is sent there. Rather, its sent to the 499 source address of the received RTP packet from the active side. This 500 means that the active side can be behind a symmetric NAT, and still 501 send media directly to its peer without use of some kind of network 502 intermediary. This is good. However, for it to work, the peer needs 503 to support symmetric RTP. So, even though in the case currently under 504 consideration, the client is not behind a symmetric NAT, it should 505 ideally support symmetric RTP just in case its peer is behind a 506 symmetric NAT. 508 Therefore, if the client supports the comedia extension applied to 509 RTP, it should include the a=direction:both attribute in its SDP. If 510 this extension is not supported, things will still work, but the call 511 may be routed through an intermediary if the peer is behind a NAT. 513 The Via header contains an IP address as well. This address will 514 never be used, in fact, except for failure conditions at the proxy. 515 Therefore, the address should contain the same address used in the 516 contact header. The SDP o line also has an IP address, used for 517 identification purposes only. Its value is arbitrary, but should be 518 the contact address also, to prevent leakage of any private addresses 519 outside the network. 521 The outgoing INVITE (message 9) might look like: 523 INVITE sip:user@domain SIP/2.0 524 From: sip:user@school.edu;tag=88asd 525 To: sip:user@domain 526 Call-ID: 98asd6asd60099 527 CSeq: 987769 INVITE 528 Via: SIP/2.0/TCP 1.2.3.4 529 Contact: sip:1.2.3.4:5678 530 Content-Type: application/sdp 531 Content-Length: ... 533 v=0 534 o=aa 2890844526 2890842807 IN IP4 1.2.3.4 535 c=IN IP4 1.2.3.4 536 t=0 0 537 m=audio 5679 RTP/AVP 0 538 a=rtcp:5688 539 a=direction:both 541 The INVITE goes through the NAT, and is received at the proxy 542 (message 10). The proxy forwards it on, and receives a 2xx response. 543 This response is passed through the nat (message 11) and arrives at 544 the client (message 12). 546 The proxy should have record-routed, in order to ensure that the 547 messaging flows through it (as its holding the only signaling 549 Client NAT STUN Proxy 550 Server 551 |(1) STUN Query | | | 552 |src=10.0.1.1:5306 | | | 553 |------------------>| | | 554 | |(2) STUN Query | | 555 | |src=1.2.3.4:5679 | | 556 | |------------------>| | 557 | |(3) STUN Resp. | | 558 | |addr=1.2.3.4:5679 | | 559 | |dst=1.2.3.4:5679 | | 560 | |<------------------| | 561 |(4) STUN Resp. | | | 562 |addr=1.2.3.4:5679 | | | 563 |dst=10.0.1.1:5306 | | | 564 |<------------------| | | 565 |(5) STUN Query | | | 566 |src=10.0.1.1:5307 | | | 567 |------------------>| | | 568 | |(6) STUN Query | | 569 | |src=1.2.3.4:5688 | | 570 | |------------------>| | 571 | |(7) STUN Resp. | | 572 | |addr=1.2.3.4:5688 | | 573 | |dst=1.2.3.4:5688 | | 574 | |<------------------| | 575 |(8) STUN Resp. | | | 576 |addr=1.2.3.4:5688 | | | 577 |dst=10.0.1.1:5307 | | | 578 |<------------------| | | 579 |(9) INVITE | | | 580 |rtp=1.2.3.4:5679 | | | 581 |rtcp=1.2.3.4:5688 | | | 582 |contact=1.2.3.4:5678 | | 583 |------------------>| | | 584 | |(10) INVITE | | 585 | |rtp=1.2.3.4:5679 | | 586 | |rtcp=1.2.3.4:5688 | | 587 | |contact=1.2.3.4:5678 | 588 | |-------------------------------------->| 589 | | | |Proxy forwards 590 | | | | INVITE, 591 | | | |response 592 | | | |comes 593 | |(11) 200 OK | | 594 | |<--------------------------------------| 595 |(12) 200 OK | | | 596 |<------------------| | | 597 |(13) ACK | | | 598 |------------------>| | | 599 | |(14) ACK | | 600 | |-------------------------------------->| 602 Figure 4: Initiating a session, not symmetric NAT 603 connection to the client). As a result, the ACK should be sent over 604 that TCP connection to the proxy (the same for UDP; it would be sent 605 from the same socket, to the same place the REGISTER was sent). 607 If symmetric RTP is being used, the SDP in the response will contain 608 an a=direction attribute, in which case the procedures of [16] would 609 apply. If there is no symmetric RTP in use, the client sends media to 610 the address(es) provided in the 200 OK. The media should be sent from 611 the same socket that is being used to receive (the two learned 612 through STUN), although this is not strictly needed. 614 2.2.1.6 Receiving an Invitation to a Session 616 The call flow for receiving an invitation to a session is shown in 617 Figure 5. The flow resembles the one for the outgoing INVITE in many 618 ways. When the INVITE arrives at the client, it will need to perform 619 two STUN queries for each media stream (messages 3-6 for the RTP 620 address and messages 7-10 for the RTCP address in the case of a 621 single media stream). This is to obtain the addresses to use for 622 receiving media. 624 The client also checks for the comedia a=direction attribute 625 (assuming this extension is supported). If it is, the guidelines in 626 [16] are followed to set the direction attribute in the 200 OK. If it 627 was a=active in the INVITE, this means that the peer is likely behind 628 a symmetric NAT. The direction attribute in the response will then be 629 a=passive. If the client doesn't support comedia, the attribute is 630 ignored and no direction attribute is placed in the response. 632 As with the initiation case, the SDP extensions for RTCP [8] will 633 need to be used to explicitly specify the RTCP address. The same 634 guidlines for selecting the Contact, Via, and o line as described in 635 the initiation case apply here as well. The result is a 200 OK 636 response (assuming the call is accepted, of course), which looks like 637 (message 11): 639 SIP/2.0 200 OK 640 From: sip:user@school.edu;tag=88asd 641 To: sip:user@domain;tag=99as8a 642 Call-ID: 98asd6asd60099 643 CSeq: 987769 INVITE 644 Via: SIP/2.0/TCP 1.9.2.2 645 Via: SIP/2.0/UDP 82.3.4.5 646 Via: SIP/2.0/TCP 1.2.3.4 647 Contact: sip:9.8.7.6:7766 648 Content-Type: application/sdp 649 Content-Length: ... 651 v=0 652 o=aa 2890844526 2890842807 IN IP4 9.8.7.6 653 c=IN IP4 9.8.7.6 654 t=0 0 655 m=audio 9988 RTP/AVP 0 656 a=rtcp:8877 657 a=direction:passive 659 The client will receive the ACK over the same connection it received 660 the INVITE, since its proxy will record route. 662 2.2.1.7 Media Flow 664 Finally, let us consider the actual flow of media in the examples 665 above. The examples had a call placed from user@school, behind a NAT 666 with public IP 1.2.3.4, calling user@domain, behind a NAT with public 667 IP 9.8.7.6. user@school used the comedia extensions, with a direction 668 attribute of both, and user@domain answered with a direction of 669 passive. The result is that user@school will act as active, and send 670 the first RTP (and RTCP) packet. This will flow through its NAT, the 671 NAT of user@domain, and then to user@domain. 673 The flow of the media for this case is shown in Figure 6. The RTCP is 674 not shown, but would work in an identical fashion. 676 This flow will work perfectly for full cone, but will not work as 677 written for restricted cone. Thats because NAT 2, assuming its 678 restricted cone, will not allow the RTP packet from user@school 679 (message 2) in. Thats because user@domain has not yet sent a packet 680 to 1.2.3.4 yet. Therefore, user@domain needs to "prime" its NAT by 681 sending a packet to 1.2.3.4:5679 (it will know this address from the 682 INVITE it received). Thus, it needs to send a packet even though it 683 has indicated it wants to be the passive side of the symmetric RTP 684 connection. The most natural way to accomplish this is to actually 685 have users behind restricted cone or port restricted cones respond to 686 a=direction:both with a=direction:both. In that scenario, as 687 described in [16], both sides send a packet to each other, and one of 688 the "connections" is then used. Having both sides send packets to 689 each other is exactly what is needed to allow operation in restricted 690 cone and port restricted cone nats. 692 The flow for this case (where both sides indicated a=direction:both) 694 Client NAT STUN Proxy 695 Server 696 | |(1) INVITE | | 697 | |<--------------------------------------| 698 |(2) INVITE | | | 699 |<------------------| | | 700 |(3) STUN Query | | | 701 |src=10.1.2.3:1928 | | | 702 |------------------>| | | 703 | |(4) STUN Query | | 704 | |src=9.8.7.6:9988 | | 705 | |------------------>| | 706 | |(5) STUN Resp. | | 707 | |addr=9.8.7.6:9988 | | 708 | |dst=9.8.7.6:9988 | | 709 | |<------------------| | 710 |(6) STUN Resp. | | | 711 |addr=9.8.7.6:9988 | | | 712 |dst=10.1.2.3:1928 | | | 713 |<------------------| | | 714 |(7) STUN Query | | | 715 |src=10.1.2.3:1929 | | | 716 |------------------>| | | 717 | |(8) STUN Query | | 718 | |src=9.8.7.6:8877 | | 719 | |------------------>| | 720 | |(9) STUN Resp. | | 721 | |addr=9.8.7.6:8877 | | 722 | |dst=9.8.7.6:8877 | | 723 | |<------------------| | 724 |(10) STUN Resp. | | | 725 |addr=9.8.7.6:8877 | | | 726 |dst=10.1.2.3:1929 | | | 727 |<------------------| | | 728 |(11) 200 OK | | | 729 |rtp=9.8.7.6:9988 | | | 730 |rtcp=9.8.7.6:8877 | | | 731 |contact=9.8.7.6:7766 | | 732 |------------------>| | | 733 | |(12) 200 OK | | 734 | |rtp=9.8.7.6:9988 | | 735 | |rtcp=9.8.7.6:8877 | | 736 | |contact=9.8.7.6:7766 | 737 | |-------------------------------------->| 738 | | | |200 OK 739 | | | |forwarded 740 | | | |upstream 741 | |(13) ACK | | 742 | |<--------------------------------------| 743 |(14) ACK | | | 744 |<------------------| | | 746 Figure 5: Incoming INVITE, not Symmetric NAT 747 user@school NAT 1 NAT 2 user@domain 748 |(1) RTP | | | 749 |src=10.0.1.1:5306 | | | 750 |dest=9.8.7.6:9988 | | | 751 |------------------>| | | 752 | |(2) RTP | | 753 | |src=1.2.3.4:5679 | | 754 | |dest=9.8.7.6:9988 | | 755 | |------------------>| | 756 | | |(3) RTP | 757 | | |src=1.2.3.4:5679 | 758 | | |dest=10.1.2.3:1928 | 759 | | |------------------>| 760 | | |(4) RTP | 761 | | |src=10.1.2.3:1928 | 762 | | |dest=1.2.3.4:5679 | 763 | | |<------------------| 764 | |(5) RTP | | 765 | |src=1.2.3.4:5679 | | 766 | |dest=1.2.3.4:5679 | | 767 | |<------------------| | 768 |(6) RTP | | | 769 |src=1.2.3.4:5679 | | | 770 |dest=10.0.1.1:5306 | | | 771 |<------------------| | | 773 Figure 6: Media flow for residential case, not symmetric NAT 775 is shown in Figure 7. It is identical to the flow above, but with a 776 reordering of messages. Now, both users send their first packet at 777 the same time, causing the NATs to be "primed". In reality, the 778 packets may not be sent at the same time, so the first few packets 779 from the first sender will be lost until the other user primes their 780 NAT. 782 Its important to realize that with port restricted cone NAT, the 783 priming will only work when the user sends from the same IP address 784 and port they expect to receive from. 786 2.2.2 Symmetric NAT 788 Section 2.2.1 handled the case where the user was in a residence 789 behind a full cone or restricted cone NAT. In this section, we 790 consider the case of a symmetric NAT. 792 user@school NAT 1 NAT 2 user@domain 793 |(1) RTP | | | 794 |src=10.0.1.1:5306 | | | 795 |dest=9.8.7.6:9988 | | | 796 |------------------>| | | 797 | |NAT1 primed | | 798 | |to receive | | 799 | |from 9.8.7.6:9988 | | 800 | | |(2) RTP | 801 | | |src=10.1.2.3:1928 | 802 | | |dest=1.2.3.4:5679 | 803 | | |<------------------| 804 | | |NAT2 primed | 805 | | |to receive | 806 | | |from 1.2.3.4:5679 | 807 | |(3) RTP | | 808 | |src=1.2.3.4:5679 | | 809 | |dest=9.8.7.6:9988 | | 810 | |------------------>| | 811 | |(4) RTP | | 812 | |src=1.2.3.4:5679 | | 813 | |dest=1.2.3.4:5679 | | 814 | |<------------------| | 815 | | |(5) RTP | 816 | | |src=1.2.3.4:5679 | 817 | | |dest=10.1.2.3:1928 | 818 | | |------------------>| 819 |(6) RTP | | | 820 |src=1.2.3.4:5679 | | | 821 |dest=10.0.1.1:5306 | | | 822 |<------------------| | | 824 Figure 7: Media flow for residential case, priming the NAT 826 The operation is much like the non-symmetric case. However, instead 827 of using STUN to determine the addresses, a TURN [3] server is used 828 to obtain addresses. Like STUN, TURN will provide a publically 829 routable IP address and port that can be used. However, unlike STUN, 830 this address and port routes to the TURN server, which forwards the 831 packets on the same socket the TURN request was received on. This 832 allows it to operate through more restrictive symmetric NAT. The cost 833 of this approach is routing of media through the service provider 834 network, which can substantially increase latency and loss, and also 835 increases the cost to the provider. 837 2.2.2.1 Registration 839 The recommended registration mechanism parallels the procedure for 840 STUN as described in Section 2.2.1. TCP is still preferred. If UDP is 841 used, the TURN-based solution is preferred. In that mode, the client 842 will allocate an address from the TURN server, and then include that 843 in the Contact header in the REGISTER. In the case of TURN, it is 844 recommended that a TCP address be allocated from the TURN server. 845 This will avoid the need to constantly refresh the binding, as would 846 be the case for UDP. The problem is worse with TURN, since once the 847 client receives an incoming INVITE, refreshes of the binding would 848 cause packets to be delivered to the proxy, and therefore they would 849 need to be complete REGISTER messages themselves in order to be 850 properly processed. This will result in a serious burden on the proxy 851 server. 853 Client NAT Proxy TURN 854 Server 855 |(1) TURN Allocate | | | 856 |-------------------->| | | 857 | |(2) TURN Allocate | | 858 | |------------------------------------------>| 859 | |(3) TURN Response | | 860 | | addr = 15.1.2.3:5678| | 861 | |<------------------------------------------| 862 |(4) TURN Response | | | 863 | addr = 15.1.2.3:5678| | | 864 |<--------------------| | | 865 |(5) REGISTER | | | 866 | Contact: 15.1.2.3:5678 | | 867 | Translate: 15.1.2.3:5678 | | 868 |-------------------->| | | 869 | |(6) REGISTER | | 870 | | Contact: 15.1.2.3:5678 | 871 | | Translate: 15.1.2.3:5678 | 872 | |-------------------->| | 873 | |(7) 200 OK | | 874 | |<--------------------| | 875 |(8) 200 OK | | | 876 |<--------------------| | | 878 Figure 8: Registration for Symmetric NAT 879 Assuming TCP, the flow for registration is shown in Figure 8. Before 880 message 1 is sent, there is a standard TCP handshake with the TURN 881 server, not shown. Then, the client sends a TURN Allocate request 882 (message 1) to its TURN server. The response (message 4) contains the 883 address allocated to the client, in this case, 15.1.2.3:5678. So, it 884 uses that address in a REGISTER message, also sent using TCP, to its 885 proxy (message 5). 887 2.2.2.2 Initiating a Session 889 The process for initiating a session parallels that for the non- 890 symmetric case in Section 2.2.1. The client will use TURN to allocate 891 two UDP addresses - one for the RTP, and another for the RTCP. The 892 INVITE that is constructed will use the SDP extensions for RTCP [8] 893 to contain the RTCP addresses. The construction of the Via, Contact, 894 and origin lines in the SDP mirrors that for the non-symmetric case. 896 The main difference is in the use of comedia. For the symmetric case, 897 support for the comedia draft [16] is strongly recommended. If the 898 other participant in the call is not behind a NAT, or is behind a 899 full cone for restricted cone NAT, the use of the TURN server as 900 relay can be avoided. This will improve the voice quality and reduce 901 costs to the provider. In order for its usage to be avoided, the 902 client includes an a=direction:active attribute in its SDP. Note that 903 it still includes the addresses it obtained from the TURN server. 904 These will end up being used if the peer doesn't support comedia, or 905 is behind a symmetric or port restricted cone NAT. 907 This usage of a=active differs from the current comedia 908 draft, which says that if a=active is present, you MUSTNOT 909 initiate a connection to it. This is not backwards 910 compatible. The approach described here is. We should work 911 to get this incorporated into comedia to add backwards 912 compatibility. 914 A flow for this case is shown in Figure 9. 916 The resulting INVITE generated might look like: 918 INVITE sip:user@domain SIP/2.0 919 From: sip:user@school.edu;tag=88asd 920 To: sip:user@domain 921 Call-ID: 98asd6asd60099 922 CSeq: 987769 INVITE 923 Via: SIP/2.0/TCP 15.1.2.3 924 Contact: sip:15.1.2.3:5678 925 Content-Type: application/sdp 926 Content-Length: ... 928 v=0 929 o=aa 2890844526 2890842807 IN IP4 15.1.2.3 930 c=IN IP4 15.1.2.3 931 t=0 0 932 m=audio 5679 RTP/AVP 0 933 a=rtcp:5688 934 a=direction:active 936 2.2.2.3 Answering an Invitation to a Session 938 The procedure for answering an INVITE mirrors that for the non- 939 symmetric case described in Section 2.2.1. However, the RTP and RTCP 940 ports are obtained from a TURN server, not a STUN server, and the 941 client should indicate a=direction:active in the response if the 942 INVITE request indicated passive or both (assuming it supports 943 symmetric RTP.) 945 Another difference is the path of the INVITE itself. If TURN was used 946 to allocate the registered address, the incoming INVITE will flow 947 from the proxy, through the TURN server, towards the client. 949 The call flow for this case is shown in Figure 10. Note that the 950 incoming INVITE, its 200 OK, and the ACK, now all flow through the 951 TURN server. The initial INVITE from the proxy to the TURN server 952 (message 1) will actually cause a TCP connection to be first opened 953 from the proxy to the turn server. From this point forward, the 954 client should re-register over this TCP connection (rather than the 955 other one it used to send the initial REGISTER, which goes directly 956 to the proxy), without the Translate header. Using this connection 957 for re-registrations is needed to keep the connection alive. 959 The 200 OK response sent by the client might look like: 961 SIP/2.0 200 OK 962 From: sip:user@school.edu;tag=88asd 963 To: sip:user@domain;tag=99as8a 964 Call-ID: 98asd6asd60099 965 CSeq: 987769 INVITE 966 Via: SIP/2.0/TCP 1.9.2.2 967 Via: SIP/2.0/UDP 82.3.4.5 969 Client NAT TURN Proxy 970 Server 971 |(1) TURN Allocate | | | 972 |src=10.0.1.1:5306 | | | 973 |------------------>| | | 974 | |(2) TURN Allocate | | 975 | |src=15.1.2.3:5679 | | 976 | |------------------>| | 977 | |(3) TURN Resp. | | 978 | |addr=15.1.2.3:5679 | | 979 | |dst=15.1.2.3:5679 | | 980 | |<------------------| | 981 |(4) TURN Resp. | | | 982 |addr=15.1.2.3:5679 | | | 983 |dst=10.0.1.1:5306 | | | 984 |<------------------| | | 985 |(5) TURN Allocate | | | 986 |src=10.0.1.1:5307 | | | 987 |------------------>| | | 988 | |(6) TURN Allocate | | 989 | |src=15.1.2.3:5688 | | 990 | |------------------>| | 991 | |(7) TURN Resp. | | 992 | |addr=15.1.2.3:5688 | | 993 | |dst=15.1.2.3:5688 | | 994 | |<------------------| | 995 |(8) TURN Resp. | | | 996 |addr=15.1.2.3:5688 | | | 997 |dst=10.0.1.1:5307 | | | 998 |<------------------| | | 999 |(9) INVITE | | | 1000 |rtp=15.1.2.3:5679 | | | 1001 |rtcp=15.1.2.3:5688 | | | 1002 |contact=15.1.2.3:5678 | | 1003 |------------------>| | | 1004 | |(10) INVITE | | 1005 | |rtp=15.1.2.3:5679 | | 1006 | |rtcp=15.1.2.3:5688 | | 1007 | |contact=15.1.2.3:5678 | 1008 | |-------------------------------------->| 1009 | | | |Proxy forwards 1010 | | | | INVITE, 1011 | | | |response 1012 | | | |comes 1013 | |(11) 200 OK | | 1014 | |<--------------------------------------| 1015 |(12) 200 OK | | | 1016 |<------------------| | | 1017 |(13) ACK | | | 1018 |------------------>| | | 1019 | |(14) ACK | | 1020 | |-------------------------------------->| 1022 Figure 9: STUN Symmetric, Outgoing INVITE 1024 Client NAT TURN Proxy 1025 Server 1026 | | |(1) INVITE | 1027 | | |<------------------| 1028 | |(2) INVITE | | 1029 | |<------------------| | 1030 |(3) INVITE | | | 1031 |<------------------| | | 1032 |(4) TURN Query | | | 1033 |src=10.1.2.3:1928 | | | 1034 |------------------>| | | 1035 | |(5) TURN Query | | 1036 | |src=15.4.5.6:9988 | | 1037 | |------------------>| | 1038 | |(6) TURN Resp. | | 1039 | |addr=15.4.5.6:9988 | | 1040 | |dst=15.4.5.6:9988 | | 1041 | |<------------------| | 1042 |(7) TURN Resp. | | | 1043 |addr=15.4.5.6:9988 | | | 1044 |dst=10.1.2.3:1928 | | | 1045 |<------------------| | | 1046 |(8) TURN Query | | | 1047 |src=10.1.2.3:1929 | | | 1048 |------------------>| | | 1049 | |(9) TURN Query | | 1050 | |src=15.4.5.6:8877 | | 1051 | |------------------>| | 1052 | |(10) TURN Resp. | | 1053 | |addr=15.4.5.6:8877 | | 1054 | |dst=15.4.5.6:8877 | | 1055 | |<------------------| | 1056 |(11) TURN Resp. | | | 1057 |addr=15.4.5.6:8877 | | | 1058 |dst=10.1.2.3:1929 | | | 1059 |<------------------| | | 1060 |(12) 200 OK | | | 1061 |rtp=15.4.5.6:9988 | | | 1062 |rtcp=15.4.5.6:8877 | | | 1063 |contact=15.4.5.6:7766 | | 1064 |------------------>| | | 1065 | |(13) 200 OK | | 1066 | |rtp=15.4.5.6:9988 | | 1067 | |rtcp=15.4.5.6:8877 | | 1068 | |contact=15.4.5.6:7766 | 1069 | |------------------>| | 1070 | | |(14) 200 OK | 1071 | | |rtp=15.4.5.6:9988 | 1072 | | |rtcp=15.4.5.6:8877 | 1073 | | |contact=15.4.5.6:7766 1074 | | |------------------>| 1075 | | | |200 OK 1076 | | | |forwarded 1077 | | | |upstream 1078 | | |(15) ACK | 1079 | | |<------------------| 1080 | |(16) ACK | | 1081 | |<------------------| | 1082 |(17) ACK | | | 1083 |<------------------| | | 1085 Figure 10: Incoming INVITE, Symmetric NAT 1087 Via: SIP/2.0/TCP 15.1.2.3 1088 Contact: sip:15.4.5.6:7766 1089 Content-Type: application/sdp 1090 Content-Length: ... 1092 v=0 1093 o=aa 2890844526 2890842807 IN IP4 15.4.5.6 1094 c=IN IP4 15.4.5.6 1095 t=0 0 1096 m=audio 9988 RTP/AVP 0 1097 a=rtcp:8877 1098 a=direction:active 1100 2.2.2.4 Media Flows 1102 The media flow scenarios depend on the type of NAT each side is 1103 behind. 1105 Consider the case where the caller is behind a full cone NAT, and the 1106 callee is behind a symmetric NAT. In this case, the SDP in the INVITE 1107 from the caller will have an a=direction:both attribute. The SDP in 1108 the 200 OK from the callee will have a=direction:active. The callee 1109 will send media to the caller, using a socket different than the one 1110 used to allocate the address from the TURN server. The caller sends 1111 media back to the source address where media from the callee came 1112 from. In this case, even though a TURN address was allocated by the 1113 callee, that address is never used, and the binding will expire at 1114 the TURN server. 1116 TODO: flow for this case 1118 Consider the case where the caller is behind a restricted cone NAT, 1119 and the callee is behind a symmetric NAT. The caller includes an 1120 a=direction:active attribute in its INVITE. The callee responds with 1121 an a=direction:passive attribute. The caller will send to the address 1122 provided by the callee in the 200 OK. This address is on the TURN 1123 server. This data is received by the callee, which sends data back. 1124 This is forwarded to the TURN server, and then onwards towards the 1125 caller. Thus, an intermediary is included in this case. 1127 TODO: flow for this case 1128 TODO: not sure all these cases are completely sorted out. 1129 Setting of active/passive for restricted cone requires more 1130 consideration. 1132 2.3 Solution III: STUN in B2BUA 1134 The solution of Section 2.2 assumed that the client would need to be 1135 upgraded to support at least STUN, and additionally several other SIP 1136 extensions. In many cases, this will not be feasible. It is possible 1137 to deploy the STUN solution in an intermediary, typically run as a 1138 piece of software that would be run within the residence. It can run 1139 on the same machine as the client, or on a separate PC. In SIP 1140 terminology, this additional server is a "B2BUA", or Back to back 1141 User Agent. It receives requests from the clients, acts as a STUN 1142 client, obtains addresses for media, modifies the SDP in the INVITEs, 1143 and forwards the requests onwards. Both SIP traffic, and media 1144 traffic, would be routed through it. Unlike the use of an 1145 intermediary in the service provider network (like a TURN server), 1146 the use of an intermediary in the home does not introduce any real 1147 latency or voice quality problems, and there is no cost to the 1148 service provider. There could be cost to the consumer, but we 1149 anticipate that these intermediaries would be given away for free as 1150 part of the service. 1152 We call the B2BUA in the home network that acts as a STUN client a 1153 "STUN Agent", just for the sake of having a simple name. Note that 1154 the STUN agent may also need to implement TURN, in the case that the 1155 agent is behind a symmetric NAT. However, in the flows below, we do 1156 specifically consider this case. The flows from Section 2.2.2 can be 1157 directly applied to the flows below to show this scenario. 1159 The configuration using the STUN Agent is shown in Figure 11. The 1160 clients (PC phones, hardphones) are configured to talk to the STUN 1161 agent as their SIP local outbound proxy server, sending it both 1162 registrations and invitations. 1164 When the STUN agent starts up, it discovers whether there is a NAT or 1165 not, and what type of NAT, using the STUN discovery mechanisms [2]. 1166 In the event that there is no NAT, the STUN agent merely acts as a 1167 stateless proxy, relaying packets in and out. We consider, from here 1168 on, the case where it has discovered that it is behind a full cone or 1169 restricted cone NAT. 1171 2.3.1 Registration 1173 The first step is for the clients to REGISTER. The flow for this 1174 +--------+ 1175 |Provider| 1176 | Proxy | 1177 | | 1178 +---+----+ 1179 | 1180 --------+---------- 1181 /////// \\\\\\\ 1182 /// \\\ 1183 || || 1184 | Internet | 1185 | | 1186 | | 1187 || || 1188 \\\ /// 1189 \\\\\\\ /////// 1190 ---------+--------- 1191 | DSL, Cable 1192 +--------+-------+ 1193 | Home NAT | 1194 +----------------+ 1196 +--------+ 1197 | STUN | 1198 | Agent | 1199 | | 1200 +--------+ 1202 +--------+ +----------+ 1203 | | | / \ | 1204 | PC | /SIP \ 1205 | | /Phone \ 1206 | | / \ 1207 +--------+ ------------ 1209 Figure 11: STUN Agent Configuration 1211 scenario is shown in Figure 12. First, the client sends a REGISTER 1212 (message 1). This is a normal UDP REGISTER, and therefore the Contact 1213 is likely to reflect an IP address within the home network: 1215 Client STUN NAT Proxy STUN 1216 Agent Server 1217 |(1) REGISTER | | | | 1218 |-------------->| | | | 1219 | |(2) STUN Query | | | 1220 | |src=10.0.1.2:10| | | 1221 | |-------------->| | | 1222 | | |(3) STUN Query | | 1223 | | |src=1.2.3.4:5678 | 1224 | | |------------------------------>| 1225 | | |(4) STUN Response | 1226 | | |addr = 1.2.3.4:5678 | 1227 | | |dst=1.2.3.4:5678 | 1228 | | |<------------------------------| 1229 | |(5) STUN Response | | 1230 | |addr = 1.2.3.4:5678 | | 1231 | |dst=10.0.1.2:10| | | 1232 | |<--------------| | | 1233 | |Contact | | | 1234 | |rewritten | | | 1235 | |(6) REGISTER | | | 1236 | |-------------->| | | 1237 | | |(7) REGISTER | | 1238 | | |-------------->| | 1239 | | |(8) 200 OK | | 1240 | | |<--------------| | 1241 | |(9) 200 OK | | | 1242 | |<--------------| | | 1243 |(10) 200 OK | | | | 1244 |<--------------| | | | 1246 Figure 12: STUN Agent Registration 1248 REGISTER sip:provider.com SIP/2.0 1249 Via: SIP/2.0/UDP 10.0.1.1 1250 From: sip:user@provider.com 1251 To: sip:user@provider.com 1252 Call-ID: 99asdasd98hnn 1253 Contact: sip:user@10.0.1.1:5060 1254 CSeq: 88790 REGISTER 1256 Since the client is using a local outbound proxy, this REGISTER is 1257 sent to the STUN agent. The STUN agent recognizes that this is a 1258 registration, and determines that it needs to obtain an IP address 1259 and port to use in the Contact which can route to it. So, it follows 1260 the procedures that the client itself would have followed from 1261 Section 2.2.1. Specifically, it acts as a STUN client, and sends a 1262 Query request (message 2) to the provider.com STUN server. This goes 1263 through the NAT (message 3), and is reflected off of the STUN server 1264 (message 4) providing the STUN agent with a external IP address and 1265 port that routes to it (message 5). This address is inserted as the 1266 Contact header in a rewritten REGISTER message (message 6) that is 1267 sent to the proxy. This outgoing REGISTER might look like: 1269 REGISTER sip:provider.com SIP/2.0 1270 Via: SIP/2.0/UDP 1.2.3.4:5678 1271 From: sip:user@provider.com 1272 To: sip:user@provider.com 1273 Call-ID: 88sdasdlasd0 1274 Contact: sip:user@1.2.3.4:5678 1275 Translate: sip:user@1.2.3.4:5678 1276 CSeq: 88790 REGISTER 1278 This REGISTER is forwarded through the NAT (message 7), and the 200 1279 OK response from the proxy/registar (message 8) is sent through the 1280 NAT to the STUN agent (message 9). From this 200 OK, the STUN agent 1281 knows whether or not the Translate header was used or not. 1283 Its important to note that the STUN query need only be done for the 1284 first REGISTER request. For subsequent ones, the STUN agent can reuse 1285 the same binding. The binding must be refreshed (if it was used), of 1286 course, but a new one need not be selected for each registration. The 1287 Contact header in each registration from a different client would 1288 have to contain a unique user name in order to disambiguate the 1289 incoming requests from the proxy. 1291 The final step is for the STUN agent to respond to the REGISTER 1292 received from the client. The response contains the original Contact 1293 sent in the REGISTER. The STUN agent also remembers this contact, 1294 effectively acting as a registrar itself. This contact will be used 1295 for incoming INVITE requests. The response sent to the client might 1296 look like: 1298 SIP/2.0 200 OK 1299 Via: SIP/2.0/UDP 10.0.1.1 1300 From: sip:user@provider.com 1301 To: sip:user@provider.com 1302 Call-ID: 99asdasd98hnn 1303 Contact: sip:user@10.0.1.1:5060 1304 Expires:3600 1305 CSeq: 88790 REGISTER 1307 In this way, when the STUN agent receives an incoming INVITE with a 1308 request URI of sip:user@1.2.3.4:5678, it knows to rewrite it to 1309 sip:user@10.0.1.1:5060 and proxy the request there. 1311 2.3.2 Initiating a Session 1313 The call flow for initiating a session is shown in Figure 13. The 1314 client formulates a normal INVITE (message 1), without SIP extensions 1315 for NAT [9] or SDP extensions for RTCP [8]. It it is sent to the STUN 1316 Agent as a local outbound proxy. This INVITE might look like: 1318 INVITE sip:user@school.edu SIP/2.0 1319 Via: SIP/2.0/UDP 10.0.1.1 1320 From: sip:user@provider.com 1321 To: sip:user@school.edu 1322 Call-ID: 99asdas88shnn 1323 Contact: sip:user@10.0.1.1:5060 1324 Content-Type: application/sdp 1325 Content-Length: ... 1327 v=0 1328 o=aa 2890844526 2890842807 IN IP4 10.0.1.1 1329 c=IN IP4 10.0.1.1 1330 t=0 0 1331 m=audio 9988 RTP/AVP 0 1333 The STUN Agent needs to do several things. First, it must rewrite the 1334 Contact header to reference the signaling address bound to 1335 sip:user@10.0.1.1:5060 from the previous registration process (in 1336 this case, sip:user@1.2.3.4:5678). Secondly, it rewrites the SDP to 1337 include addresses learned from STUN, in much the same way the client 1338 learned them in Section 2.2.1 (messages 2-5 and message 6-9). It also 1339 adds its own Via address to the outgoing INVITE (message 10), which 1340 might look like: 1342 INVITE sip:user@school.edu SIP/2.0 1343 Via: SIP/2.0/TCP 1.2.3.4:5678 1344 Via: SIP/2.0/UDP 10.0.1.1 1345 From: sip:user@provider.com 1346 To: sip:user@school.edu 1347 Call-ID: 99asdas88shnn 1348 Contact: sip:user@1.2.3.4 1349 Content-Type: application/sdp 1350 Content-Length: ... 1352 v=0 1353 o=aa 2890844526 2890842807 IN IP4 1.2.3.4 1354 c=IN IP4 1.2.3.4 1355 t=0 0 1356 m=audio 5679 RTP/AVP 0 1357 a=rtcp:5688 1358 a=direction:both 1360 There is a subtle error here, in that 1.2.3.4:5678 is the 1361 UDP address learnt from STUN. This can't be used in the Via 1362 header sent over a TCP connection. 1364 The 200 OK to this INVITE will be received by the STUN Agent (message 1365 13). This 200 OK need not be rewritten if it does not contain a 1366 direction or rtcp attribute. In that case, media flows out from the 1367 client directly towards the address in the 2xx, and media flows in 1368 first through the intermediary, and then towards the client. Let us 1369 consider the case where the 200 OK does include an a=rtcp attribute: 1371 SIP/2.0 200 OK 1372 Via: SIP/2.0/TCP 1.2.3.4:5678 1373 Via: SIP/2.0/UDP 10.0.1.1 1374 From: sip:user@provider.com 1375 To: sip:user@school.edu;tag=909asd 1376 Call-ID: 99asdas88shnn 1377 Contact: sip:user@56.66.77.88 1378 Content-Type: application/sdp 1379 Content-Length: ... 1381 v=0 1382 o=aa 2890844526 2890842807 IN 56.66.77.88 1383 c=IN IP4 56.66.77.88 1384 t=0 0 1385 m=audio 56496 RTP/AVP 0 1387 Client STUN Agent NAT STUN Proxy 1388 Server 1389 |(1) INVITE | | | | 1390 |rtp=10.0.1.1:7460 | | | 1391 |-------------->| | | | 1392 | |(2) STUN Query | | | 1393 | |src=10.0.1.2:5306 | | 1394 | |-------------->| | | 1395 | | |(3) STUN Query | | 1396 | | |src=1.2.3.4:5679 | 1397 | | |-------------->| | 1398 | | |(4) STUN Resp. | | 1399 | | |addr=1.2.3.4:5679 | 1400 | | |dst=1.2.3.4:5679 | 1401 | | |<--------------| | 1402 | |(5) STUN Resp. | | | 1403 | |addr=1.2.3.4:5679 | | 1404 | |dst=10.0.1.2:5306 | | 1405 | |<--------------| | | 1406 | |(6) STUN Query | | | 1407 | |src=10.0.1.2:5307 | | 1408 | |-------------->| | | 1409 | | |(7) STUN Query | | 1410 | | |src=1.2.3.4:5688 | 1411 | | |-------------->| | 1412 | | |(8) STUN Resp. | | 1413 | | |addr=1.2.3.4:5688 | 1414 | | |dst=1.2.3.4:5688 | 1415 | | |<--------------| | 1416 | |(9) STUN Resp. | | | 1417 | |addr=1.2.3.4:5688 | | 1418 | |dst=10.0.1.2:5307 | | 1419 | |<--------------| | | 1420 | |(10) INVITE | | | 1421 | |rtp=1.2.3.4:5679 | | 1422 | |rtcp=1.2.3.4:5688 | | 1423 | |contact=1.2.3.4:5678 | | 1424 | |-------------->| | | 1425 | | |(11) INVITE | | 1426 | | |rtp=1.2.3.4:5679 | 1427 | | |rtcp=1.2.3.4:5688 | 1428 | | |contact=1.2.3.4:5678 | 1429 | | |------------------------------>|Proxy 1430 | | | | |forwards 1431 | | | | |INVITE, 1432 | | | | |response 1433 | | | | |comes 1434 | | |(12) 200 OK | | 1435 | | |<------------------------------| 1436 | |(13) 200 OK | | | 1437 | |<--------------| | | 1438 |(14) 200 OK | | | | 1439 |<--------------| | | | 1440 |(15) ACK | | | | 1441 |-------------->| | | | 1442 | |(16) ACK | | | 1443 | |-------------->| | | 1444 | | |(17) ACK | | 1445 | | |------------------------------>| 1447 Figure 13: Initiating a session with a STUN Agent 1448 a=rtcp:36485 1450 Since the client doesn't support the RTCP extensions for SDP, the 1451 STUN Agent needs to allocate a port pair on the host which it can 1452 rewrite into this 200 OK before forwarding. No STUN requests are 1453 needed to allocate this port pair; its local on the STUN Agent. The 1454 forwarded 200 OK might look like: 1456 SIP/2.0 200 OK 1457 Via: SIP/2.0/UDP 10.0.1.1 1458 From: sip:user@provider.com 1459 To: sip:user@school.edu;tag=909asd 1460 Call-ID: 99asdas88shnn 1461 Contact: sip:user@56.66.77.88 1462 Content-Type: application/sdp 1463 Content-Length: ... 1465 v=0 1466 o=aa 2890844526 2890842807 IN 56.66.77.88 1467 c=IN IP4 10.0.1.2 1468 t=0 0 1469 m=audio 4372 RTP/AVP 0 1471 The media flow for this case is shown in Figure 14. As the flow 1472 shows, both RTP and RTCP in and out flow through the STUN Agent. In 1473 the case of outgoing RTP and RTCP, the media is sent on the sockets 1474 used to send the STUN queries, and addressed to the addresses and 1475 ports from the 200 OK. For incoming RTP and RTCP, its received on the 1476 sockets used for the stun queries, and from there, forwarded out to 1477 the address in the original INVITE from the client. Notice how the 1478 STUN Agent can guarantee that media sent to and from the client has 1479 adjacent RTP and RTCP ports. 1481 2.3.3 Receiving an Invitation to a Session 1483 The call flow for handling an incoming INVITE is shown in Figure 15. 1484 As expected, this is a mirror image of the outgoing INVITE case 13. 1485 We have simplified this flow, however, and assumed that the incoming 1486 INVITE (message 2) did not require the usage of SDP attributes for 1487 RTCP or connection oriented media. As a result, the INVITE can be 1488 passed directly to the client (message 3). The 200 OK returned by the 1489 client (message 4) contains an SDP media address that needs to be 1490 rewritten by the agent. 1492 Media from the caller to the callee will flow first through the STUN 1493 Agent. From there it is forwarded to the callee (using adjacent 1494 RTP/RTCP ports on this leg). However, media from the callee flows 1495 directly to the caller at the address specified in the incoming 1496 INVITE. 1498 2.4 Solution IV: ALG 1500 Another solution for the residential case is to throw away your NAT, 1501 and buy one with an embedded ALG inside. This will allow SIP to work 1502 transparently through it without any additional infrastructure on the 1503 service provider or residence side. It will not require any changes 1504 to the clients either. 1506 The primary drawback to this approach is its impracticality. At the 1507 time of writing, there is only one residential NAT product available 1508 with SIP support. This product is not from a maintstream vendor, and 1509 at the time of writing, it is still missing features that are 1510 generally baseline requirements for such a device. Whilst this will 1511 certainly be corrected in a future product release, its symptomatic 1512 of the bigger problem - the manufacturer of a residential NAT cannot, 1513 and won't, be the expert in all application protocols that would need 1514 ALG support. Similarly, a vendor that specializes in a NAT supporting 1515 a particular ALG, won't be the expert in other general purpose NAT 1516 features, or in other protocols. 1518 Protocols also evolve, so that even if SIP support were added today, 1519 its not clear that this would support the extensions being developed 1520 tomorrow. 1522 A further problem is that there is a large, installed based of 1523 residential NATs that are not SIP aware. It is unlikely that users 1524 would be willing to pay money to buy a new box to support a 1525 particular application. Most users would expect that the provider 1526 would simply "make it work". Asking the user to purchase a new, SIP 1527 enabled ALG is putting the responsibility for making it work into the 1528 wrong hands. This is coupled with the fact that consumers are 1529 generally ignorant of technology, and would not be able to identify 1530 and purchase a NAT that had SIP "ALG" support in it. Certainly, most 1531 providers in existence today are not willing to wait for this massive 1532 upgrade to happen. They need a way to provide service now. Providers 1533 are motivated to change or upgrade equipment that they control (their 1534 own servers, the client software, hardphones) in order to provide 1535 service, but users are not generally motivated to change equipment 1536 for a new application. Therefore, we believe that waiting for SIP ALG 1538 user@provider.com STUN Agent NAT user@school.edu 1539 |(1) RTP | | | 1540 |src=10.0.1.1:9988 | | 1541 |dst=10.0.1.2:4372 | | 1542 |-------------->| | | 1543 | |(2) RTP | | 1544 | |src=10.0.1.2:5306 | 1545 | |dst=56.66.77.88:56496 | 1546 | |-------------->| | 1547 | | |(3) RTP | 1548 | | |src=1.2.3.4:5679 1549 | | |dst=56.66.77.88:56496 1550 | | |-------------->| 1551 |(4) RTCP | | | 1552 |src=10.0.1.1:9989 | | 1553 |dst=10.0.1.2:4373 | | 1554 |-------------->| | | 1555 | |(5) RTCP | | 1556 | |src=10.0.1.2:5307 | 1557 | |dst=56.66.77.88:36485 | 1558 | |-------------->| | 1559 | | |(6) RTCP | 1560 | | |src=1.2.3.4:5688 1561 | | |dst=56.66.77.88:36485 1562 | | |-------------->| 1563 | | |(7) RTP | 1564 | | |src=56.66.77.88:56496 1565 | | |dst=1.2.3.4:5679 1566 | | |<--------------| 1567 | |(8) RTP | | 1568 | |src=56.66.77.88:56496 | 1569 | |dst=10.0.1.2:4372 | 1570 | |<--------------| | 1571 |(9) RTP | | | 1572 |src=10.0.1.2:4372 | | 1573 |dst=10.0.1.1:9988 | | 1574 |<--------------| | | 1575 | | |(10) RTCP | 1576 | | |src=56.66.77.88:36485 1577 | | |dst=1.2.3.4:5688 1578 | | |<--------------| 1579 | |(11) RTCP | | 1580 | |src=56.66.77.88:36485 | 1581 | |dst=10.0.1.2:5307 | 1582 | |<--------------| | 1583 |(12) RTCP | | | 1584 |src=10.0.1.2:4373 | | 1585 |dst=10.0.1.1:9989 | | 1586 |<--------------| | | 1588 Figure 14: Media flow for STUN Agent 1590 Client STUN Agent NAT STUN Proxy 1591 Server 1592 | | |(1) INVITE | | 1593 | | |<------------------------------| 1594 | |(2) INVITE | | | 1595 | |<--------------| | | 1596 |(3) INVITE | | | | 1597 |<--------------| | | | 1598 |(4) 200 OK | | | | 1599 |rtp=10.0.1.1:7612 | | | 1600 |-------------->| | | | 1601 | |(5) STUN Query | | | 1602 | |src=10.1.2.3:1928 | | 1603 | |-------------->| | | 1604 | | |(6) STUN Query | | 1605 | | |src=9.8.7.6:9988 | 1606 | | |-------------->| | 1607 | | |(7) STUN Resp. | | 1608 | | |addr=9.8.7.6:9988 | 1609 | | |dst=9.8.7.6:9988 | 1610 | | |<--------------| | 1611 | |(8) STUN Resp. | | | 1612 | |addr=9.8.7.6:9988 | | 1613 | |dst=10.1.2.3:1928 | | 1614 | |<--------------| | | 1615 | |(9) STUN Query | | | 1616 | |src=10.1.2.3:1929 | | 1617 | |-------------->| | | 1618 | | |(10) STUN Query | 1619 | | |src=9.8.7.6:8877 | 1620 | | |-------------->| | 1621 | | |(11) STUN Resp. | 1622 | | |addr=9.8.7.6:8877 | 1623 | | |dst=9.8.7.6:8877 | 1624 | | |<--------------| | 1625 | |(12) STUN Resp. | | 1626 | |addr=9.8.7.6:8877 | | 1627 | |dst=10.1.2.3:1929 | | 1628 | |<--------------| | | 1629 | |(13) 200 OK | | | 1630 | |rtp=9.8.7.6:9988 | | 1631 | |rtcp=9.8.7.6:8877 | | 1632 | |contact=9.8.7.6:7766 | | 1633 | |-------------->| | | 1634 | | |(14) 200 OK | | 1635 | | |rtp=9.8.7.6:9988 | 1636 | | |rtcp=9.8.7.6:8877 | 1637 | | |contact=9.8.7.6:7766 | 1638 | | |------------------------------>| 1639 | | | | |200 OK 1640 | | | | |forwarded 1641 | | | | |upstream 1642 | | |(15) ACK | | 1643 | | |<------------------------------| 1644 | |(16) ACK | | | 1645 | |<--------------| | | 1646 |(17) ACK | | | | 1647 |<--------------| | | | 1649 Figure 15: Incoming INVITE, STUN Agent 1651 support in residential NATs is an untenable proposition from a 1652 business perspective. 1654 3 Uncooperative Enterprise 1656 The "uncooperative enterprise" case arises when there are users 1657 within an enterprise that wish to access service from a provider on 1658 the public Internet. However, the enterprise uses a firewall or NAT. 1659 The enterprise has not deployed VoIP, and has not added any explicit 1660 configuration to support SIP, nor is there desire to do so. 1662 This case is actually identical to the residential case for the most 1663 part. Nearly all of the solutions for that environment can be used 1664 here, but there are some differences. 1666 First, the configuration trick of Section 2.1 does not work. That 1667 trick required that the user of the VoIP application had 1668 administrative control over the NAT. This is true in the residential 1669 case, but not in the enterprise case. 1671 Secondly, enterprise NATs often include firewall functionality and 1672 are more restrictive than the general NAT. At the extreme, they may 1673 even block all UDP traffic in and out. In these cases, there are few 1674 elegant or good solutions. The only workable approaches are the 1675 tunneling and VPN solutions. However, these are risky since they can 1676 introduce security weaknesses into the enterprise, and go against the 1677 enterprise policy that the firewall/NAT is trying to enforce in the 1678 first place. 1680 If the enterprise firewall/NAT is not any more restrictive than the 1681 typical residential NAT (will allow outgoing UDP and TCP), the 1682 residential solutions all work fine. 1684 4 Cooperative Enterprise 1686 In this scenario, there is an enterprise which wishes to deploy SIP 1687 services. There is no public provider involved at all; the enterprise 1688 takes full control. In this case, the enterprise firewall 1689 administrators do have the ability to manipulate the configuration of 1690 the firewall/NAT if neeeded, or to add and deploy additional elements 1691 inside of the network. 1693 4.1 Solution I: ALG 1695 With this solution, the enterprise upgrades their firewall, or 1696 purchases a new firewall, to run software with an integrated SIP ALG. 1697 The NAT/Firewall examines each SIP request, and modifies the Contact, 1698 session description, and Vias as appropriate. Note that this approach 1699 does not work if the SIP messages are hop-by-hop encrypted (using for 1700 example TLS) unless the NAT/Firewall also acts as a SIP proxy server. 1702 Call flows for SIP ALGs have been documented in [6]. 1704 In addition, the enterprise deploys proxies internal to the 1705 enterprise. The NAT is configured with a static mapping or "conduit" 1706 for each of these internal SIP servers from public IP addresses 1707 (typically on the well-know SIP port--5060) to their internal IP 1708 addresses. The Enterprise can then advertise these public addresses 1709 in DNS A or SRV records. This configuration is shown in Figure 16. 1711 ---------- 1712 //// \\\\ 1713 || Public || 1714 | Internet | 1715 | | 1716 || || 1717 \\\\ //// 1718 ---------- 1719 | | 1720 | | 1721 1.2.3.4:5060 | | 1.2.3.5:5060 1722 +-----=-=------+ 1723 | = = | 1724 | = = | Enterprise NAT 1725 | = = | 1726 +-----=-----=--+ 1727 | \ 1728 | | 1729 +----+ +----+ 1730 | | | | 1731 | | | | 1732 +----+ +----+ 1733 Proxy 1 Proxy 2 1734 10.1.1.1 10.1.1.2 1735 :5060 :5060 1737 Figure 16: Enterprise ALG Configuration 1738 Registration is performed entirely inside the enterprise network. SIP 1739 UAs inside the network can communicate with each other directly. SIP 1740 UAs wishing to communicate with the outside world need to go through 1741 the enterprise SIP proxy. 1743 When initiating a session outside the enterprise, the NAT/FW rewrites 1744 portions of the SIP INVITE and offered session description to contain 1745 public IP addresses. The NAT/Firewall also assigns a pairs of public 1746 ports for RTP and RTCP as needed, maps these to the private addresses 1747 and ports included in the original session description, and allows 1748 incoming traffic to these ports from the public internet. 1750 For example, the following INVITE might be rewritten as shown in the 1751 next example. 1753 INVITE sip:user@domain SIP/2.0 1754 From: sip:user@work.com;tag=88asd 1755 To: sip:user@domain 1756 Call-ID: 98asd6asd60099 1757 CSeq: 987769 INVITE 1758 Via: SIP/2.0/UDP 10.1.1.5 1759 Via: SIP/2.0/UDP proxy1.work.com;maddr=10.1.1.1 1760 Record-Route: proxy1.work.com 1761 Contact: sip:10.1.1.5:5060 1762 Content-Type: application/sdp 1763 Content-Length: ... 1765 v=0 1766 o=aa 2890844526 2890842807 IN IP4 10.1.1.5 1767 c=IN IP4 10.1.1.5 1768 t=0 0 1769 m=audio 17832 RTP/AVP 0 1771 The same example INVITE shown rewritten. 1773 INVITE sip:user@domain SIP/2.0 1774 From: sip:user@work.com;tag=88asd 1775 To: sip:user@domain 1776 Call-ID: 98asd6asd60099 1777 CSeq: 987769 INVITE 1778 Via: SIP/2.0/UDP 10.1.1.5 1779 Via: SIP/2.0/UDP proxy1.work.com;maddr=1.2.3.4:5060 1780 Record-Route: proxy1.work.com 1781 Contact: sip:1.2.3.6:7843 1782 Content-Type: application/sdp 1783 Content-Length: ... 1785 v=0 1786 o=aa 2890844526 2890842807 IN IP4 10.1.1.5 1787 c=IN IP4 1.2.3.4 1788 t=0 0 1789 m=audio 5678 RTP/AVP 0 1791 Likwise, when receiving sessions, the NAT/FW rewrites the answered 1792 session description. Note that the NAT/FW should be prepared to 1793 rewrite an offer in a 200, and an answer in an ACK. 1795 4.2 Solution II: MIDCOM Firewall and Proxy 1797 In this approach, the enterprise purchases a firewall/NAT which uses 1798 some type of firewall control protocol such as the protocol being 1799 developed in the MIDCOM Working Group. A SIP proxy inside the network 1800 performs the stateful inspection and ALG rewriting logic that was 1801 imbedded in the firewall in scenario 5.1. The proxy then opens and 1802 closes pinholes in the firewall or creates and destroys NAT mappings 1803 as needed to allow SIP and session media to flow through the 1804 middlebox. This approach is being discussed in depth in the MIDCOM 1805 WG, so we will not elaborate here. 1807 4.3 Solution III: Internal B2BUAWM 1809 In this solution, the enterprise does not need to change their NAT or 1810 firewall to get one with ALG support. Instead, they add an additional 1811 element inside the enterprise, which we call a "Back to Back User 1812 Agent With Media" or B2BUAWM. This element terminates all media and 1813 all SIP traffic in and out of the enterprise. As a result, the 1814 administrator of the firewall can configure the firewall to allow all 1815 traffic in and out from the B2BUAWM. Similarly, if NAT is used, a 1816 static mapping of a single public address to the private address of 1817 the B2BUAWM can be configured (i.e., using basic NAT, not NAPT), or, 1818 a range of ports can be allocated to the B2BUAWM. The media relay 1819 component of the B2BUAWM can also be physically separated, using a 1820 control protocol, like MGCP [18] or MEGACO [19], between them. 1822 Effectively, the B2BUAWM acts as a "DMZ host" for the SIP and media 1823 traffic. 1825 In the example of Figure 17, an enterprise NAT is configured to map 1826 ports 4000 through 4009 from 1.2.3.4 (the public address of the NAT) 1827 ------------- 1828 ///// \\\\\ 1829 // \\ 1830 | Public Internet | 1831 | | 1832 | | 1833 \\ // 1834 \\\\\ ///// 1835 ------------- 1837 1.2.3.4 1838 +------::---=-=-=-=-=------+ 1839 | SIP :: = = = = = RTP | 1840 | 5060 :: = = = = = 4000-| NAT 1841 | :: = = = = = 4009 | 1842 +------::---=-=-=-=-=------+ 1843 10.1.1.1 :: = = = = = 1844 :: = = = = = 1845 :: = = = = = 1846 :: = = = = = 1847 +---------------+ 1848 10.1.1.2 | | 1849 | B2BUA w/Media | 1850 | | 1851 +---------------+ 1852 / : : | : \ 1853 / : : | : \ 1854 / : : | : \ 1855 +----+ +----+ +----+ 1856 | | | | | | 1857 | | | | | | 1858 +----+ +----+ +----+ 1860 UA 1 UA 2 UA 3 1861 10.1.1.5 10.1.1.6 10.1.1.7 1863 Figure 17: B2BUAWM for the Enterprise 1865 to 10.1.1.2 (the private address of the media relay). The NAT is 1866 likewise configured to forward public SIP traffic on port 5060 to the 1867 B2BUA. 1869 The B2BUA will rewrite all Contact and Via headers to appear as if 1870 they are coming from the public or private address of the B2BUA. This 1871 process is pretty much identical to the process that a SIP ALG inside 1872 of a NAT would use. 1874 Proxy/ 1875 UA B2BUA NAT Far UA 1876 | | | | 1877 | | | | 1878 | | | | 1879 |--INVITE------->| | | 1880 | c=10.1.1.7 |---INVITE-------->|---------------->| 1881 | m=audio 8238 | c=1.2.3.4 | | 1882 | | m=audio 4002 | 200 OK | 1883 | | | c=6.7.8.9 | 1884 | | | m=audio 17242 | 1885 | |<-----------------|<----------------| 1886 |<-200 OK--------| | | 1887 | c=10.1.1.2 | | | 1888 | m=audio 4002 | | | 1889 | | | | 1890 |--ACK---------->| | | 1891 | |----ACK---------->|---------------->| 1892 | | | | 1893 | | | | 1894 |==RTP / RTCP===>|====RTP / RTCP===>|==RTP / RTCP====>| 1895 | src=10.1.1.7 | src=10.1.1.2 | src=1.2.3.4 | 1896 | dst=10.1.1.2 | dst=6.7.8.9 | dst=6.7.8.9 | 1897 | :4002/3 | :17242/3 | :17242/3 | 1898 | | | | 1899 |<=RTP / RTCP====|<===RTP / RTCP====|<=RTP / RTCP=====| 1900 | src=10.1.1.2 | src=6.7.8.9 | src=6.7.8.9 | 1901 | dst=10.1.1.7 | dst=10.1.1.2 | dst=1.2.3.4 | 1902 | :8238/9 | :4002/3 | :4002/3 | 1903 | | | | 1904 | | | | 1905 |--BYE---------->|----------------->|---------------->| 1906 |----------------|------------------|<-200 OK---------| 1908 Figure 18: Enterprise with B2BUAWM: Outgoing Invite 1910 The B2BUA will allocate pairs of RTP/RTCP ports from its statically 1911 mapped pool, and rewrite the session description and each message, so 1912 that private addresses are translated to public addresses and vice 1913 versa. Figure 18 shows the call flow for an outgoing INVITE, and 1914 Figure 19 shows the call flow for an incoming INVITE. 1916 Proxy/ 1917 UA B2BUA NAT Far UA 1919 | |<-----------------|<-INVITE---------| 1920 |<-INVITE--------| | c=6.7.8.9 | 1921 | c=10.1.1.2 | | m=audio 17242 | 1922 | m=audio 4002 | | | 1923 | | | | 1924 |--200 OK------->| | | 1925 | c=10.1.1.7 |---200 OK-------->|---------------->| 1926 | m=audio 8238 | c=1.2.3.4 | | 1927 | | m=audio 4002 | | 1928 | | | | 1929 | |<-----------------|<-ACK------------| 1930 |<-ACK-----------| | | 1931 | | | | 1932 | | | | 1933 |==RTP / RTCP===>|====RTP / RTCP===>|==RTP / RTCP====>| 1934 | src=10.1.1.7 | src=10.1.1.2 | src=1.2.3.4 | 1935 | dst=10.1.1.2 | dst=6.7.8.9 | dst=6.7.8.9 | 1936 | :4002/3 | :17242/3 | :17242/3 | 1937 | | | | 1938 |<=RTP / RTCP====|<===RTP / RTCP====|<=RTP / RTCP=====| 1939 | src=10.1.1.2 | src=6.7.8.9 | src=6.7.8.9 | 1940 | dst=10.1.1.7 | dst=10.1.1.2 | dst=1.2.3.4 | 1941 | :8238/9 | :4002/3 | :4002/3 | 1942 | | | | 1944 Figure 19: Enterprise with B2BUAWM: Incoming Invite 1946 5 Outsourced Service: Centrex 1948 In the outsourced service scenario (also known as Centrex), the 1949 enterprise wishes to deploy the SIP service, but does so by 1950 outsourcing it to a provider in the public Internet. 1952 5.1 Solution I: ALG 1954 In this solution, the enterprise upgrades their firewall/NAT to 1955 include SIP ALG support. Unlike the cooperative enterprise case 1956 above, there is no need to deploy any proxies or additional elements 1957 inside the network (that is the point of Centrex). Clients within the 1958 enterprise register directly with the proxies owned and provided by 1959 the Centrex provider. This means that the ALG needs to rewrite 1960 REGISTER messages, in addition to INVITE/200/ACK messages. This is in 1961 contrast to an ALG deployed to support a cooperative enterprise. In 1962 that scenario, registrations are confined to the enterprise and never 1963 traverse the firewall/NAT. 1965 This configuration is shown in Figure 20. The enterprise only has 1966 clients. These clients are configured with the IP address of the 1967 proxy in the provider's network that they will be using. The 1968 enterprise configures its DNS so that SRV lookups on its domain names 1969 for SIP service (i.e., _sip._udp.enterprise.com) route to the 1970 provider's proxies. 1972 A call flow for a registration, followed by an incoming call, is 1973 shown in Figure 21. 1975 When the clients start up, they send REGISTER requests to this proxy 1976 (message 1). The ALG is responsible for rewriting the Contact in the 1977 registrations. The bindings allocated for the Contact headers are set 1978 with a long lifetime, generally equal to the lifetime of the Expires 1979 header in the request (this lifetime could be modified by a different 1980 expiration in the response). 1982 So, for example, the REGISTER sent by a client (message 1) might look 1983 like: 1985 REGISTER sip:enterprise.com SIP/2.0 1986 From: sip:user12@enterprise.com 1987 To: sip:user12@enterprise.com 1988 Contact: sip:user12@10.0.1.1:5060 1989 CSeq: 86590 REGISTER 1990 Via: SIP/2.0/UDP 10.0.1.1 1991 Call-ID: 9adjasd88 1993 The ALG would rewrite this, and the resulting registration (message 1994 2) might look like: 1996 REGISTER sip:enterprise.com SIP/2.0 1997 From: sip:user12@enterprise.com 1998 To: sip:user12@enterprise.com 1999 ................................................... 2000 . . 2001 . +------+ Centrex . 2002 . | | Provider . 2003 . +------+ | Proxy Farm . 2004 . | | | . 2005 . | | | . 2006 . | |-+ . 2007 . +------+ . 2008 . . 2009 . . 2010 .Provider | . 2011 ........................|.......................... 2012 | 2013 |Provider Access (Internet, 2014 +---------+ private connection) 2015 |Enterpris| 2016 ..................|. FW/NAT |..................... 2017 . | w/ ALG | Enterprise . 2018 . +---------+ . 2019 . . 2020 . . 2021 . . 2022 . . 2023 . . 2024 . . 2025 . . 2026 . /\ /\ . 2027 . /\ / \ /\ / \ . 2028 . / \ / \ / \ / \ . 2029 . / \ /Client\ / \ /Client\ . 2030 . /Client\ ---------- /Client\ ---------- . 2031 . ---------- ---------- . 2032 .................................................. 2034 Figure 20: Centrex ALG Configuration 2036 Contact: sip:user12@1.2.3.4:8875 2037 CSeq: 86590 REGISTER 2038 Via: SIP/2.0/UDP 1.2.3.4:8875 2039 Call-ID: 9adjasd88 2040 Client Enterprise Proxy 2041 NAT 2042 |(1) REGISTER | | 2043 |contact=10.0.1.1 | | 2044 |-------------------->| | 2045 | |(2) REGISTER | 2046 | |contact=1.2.3.4:8875 | 2047 | |-------------------->| 2048 | |(3) 200 OK | 2049 | |<--------------------| 2050 |(4) 200 OK | | 2051 |<--------------------| | 2052 | | |Call received 2053 | |(5) INVITE | 2054 | |sip:user12@1.2.3.4:8875 2055 | |<--------------------| 2056 |(6) INVITE | | 2057 |sip:user12@10.0.1.1 | | 2058 |<--------------------| | 2059 |(7) 200 OK | | 2060 |-------------------->| | 2061 | |(8) 200 OK | 2062 | |-------------------->| 2063 | |(9) ACK | 2064 | |<--------------------| 2065 |(10) ACK | | 2066 |<--------------------| | 2068 Figure 21: Incoming Call, Centrex ALG 2070 The ALG would remember the association (1.2.3.4:8875, 10.0.1.1:5060) 2071 for one hour (the default registration expiration). This REGISTER 2072 would arrive at the provider proxy, and the registration stored 2073 there. 2075 When an INVITE arrives at the provider proxy for 2076 sip:user12@enterprise.com, the proxy translates this to 2077 sip:user12@1.2.3.4:8875 (message 5), and forwards the INVITE. This 2078 arrives at the ALG. The ALG rewrites the request URI to the 2079 translated address, sip:user12@10.0.1.1, and forwards it to the 2080 client (message 6). The ALG will also need to rewrite the SDP and 2081 Contact in the 2xx (message 7). 2083 5.2 Solution II: External B2BUAWM 2084 In this solution, the service provider uses a "Back to Back User 2085 Agent with Media" instead of a proxy. This can be viewed as an 2086 integration of the proxy and the TURN server into an application 2087 specific solution. 2089 With this solution, there is no need for the enterprise to deploy an 2090 ALG. 2092 There are two main components of the solution - one addressing the 2093 control/signaling path issues, and the other, the media path. The 2094 signaling path component consists of a stateful Signaling Proxy 2095 server exhibiting some distinct behavior to be discussed later. The 2096 media path component consists of a Media Proxy server. In the context 2097 of SIP and RTP, the signaling path component will be a SIP Proxy 2098 server called Back-to-Back-User-Agent (BBUA) and the media path 2099 component is an RTP Proxy, as shown in Figure 22. The signaling and 2100 media proxies interact using some control protocol, which is 2101 transparent to the end users. 2103 5.2.1 Signaling Path 2105 The following prerequisites must be met in order for the solution to 2106 work: 2108 o The solution described here, relies on the principle that 2109 connections from within the Enterprise are allowed out and 2110 that the corresponding responses to those connections are 2111 allowed back in (as in case of Traditional NAT's). This 2112 enables the end points inside the enterprise to maintain a 2113 connection to the Signaling server via a "keep-alive" 2114 mechanism. 2116 o All signaling messages must travel via the Signaling Proxy. 2117 The SIP Signaling Proxy server with whom the UA registered 2118 must be the one through which all incoming (outgoing) calls 2119 are routed to (from) the UA. 2121 o The SIP Signaling Proxy server must be one hop away from the 2122 UA. 2124 o The destination port of the requests at the Signaling Proxy 2125 server is the same as the source port of the corresponding 2126 responses. 2128 In the example configuration shown in Figure 22, the signaling path 2129 is established when the SIP UA's register with the corresponding 2130 Proxy/Register (Signaling server). The SIP REGISTER message contains 2132 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2133 Service Provider 2135 +-------+ +-------+ 2136 | SIP | | SIP | 2137 | Proxy |+ + + + + + + + +| Proxy | 2138 | X' | | Y' | 2139 | |\ | | 2140 +-------+ \ +-------+ 2141 + \+---------+ + 2142 + | | + 2143 + |RTP Proxy| + 2144 + ^ ^ ^ | |^ ^ ^ + 2145 + ^ +---------+ ^ + 2146 . . . + . . ^ . . . . . . . . . . . . . . ^ . + . . . 2147 + ^ ^ + 2148 + ^ ^ + 2149 +---------+ +---------+ 2150 ........|Symmetric|........... .........|Symmetric|........ 2151 . | NAT/FW | . . | NAT/FW | . 2152 . +---------+ . . +---------+ . 2153 . + ^ . . ^ + . 2154 . + ^ . . ^ + . 2155 . + ^ . . ^ + . 2156 . + ^ . . ^ + . 2157 . +-------+ . . +-------+ . 2158 . | SIP UA| . . | SIP UA| . 2159 . | X | . . | Y | . 2160 . +-------+ . . +-------+ . 2161 .............................. ............................ 2163 Enterprise Enterprise 2165 ++++ Control path for media 2166 ^^^^ Media path 2167 ---- Control path between 2168 Signaling and Media Proxies 2170 Figure 22: B2BUAWM Configuration 2172 an extension tag carried in the Proxy-Require header, indicating to 2173 the Proxy that the client is behind a NAT (Note: the client or the 2174 Proxy does not care about the type of NAT, as the same solution 2175 applies to all types). This packet is NAT-ed by the Enterprise NAT 2176 with a new source IP address and port. If the Proxy supports the 2177 extension tag, it creates an association between the IP address and 2178 port from which the packet arrived and the actual address of the 2179 user. The response to the Registration message is sent to this IP 2180 address and port (not to the Contact address in the REGISTER). 2182 Once the signaling path is established, this can be used to send 2183 subsequent requests and responses to the user using the above 2184 association stored at the Proxy, i.e., the request is sent (as above) 2185 to the address/port assigned by the NAT instead of to the actual 2186 address of the user. All requests and responses must be routed via 2187 this Signaling Proxy. All requests from the user should carry the 2188 Proxy-require header with the special tag indicating that it is 2189 behind NAT/FW. 2191 The signaling path is always kept open through the NAT using a keep- 2192 alive mechanism. This can be done using REGISTER refreshes as 2193 proposed in [9]. One disadvantage of using the REGISTER method for 2194 this purpose is it forces frequent (at least once every minute), 2195 unnecessary involvement on the part of the Registrar. In this 2196 solution, "keep-alive" is achieved by periodically sending a new 2197 lightweight SIP method from the UA to the Server designed 2198 specifically for this purpose. The new SIP method is called PING and 2199 contains the following mandatory SIP headers: From, To, Via, Proxy- 2200 require, Contact, Call-id, Cseq. The Proxy Server responds to the 2201 PING method with a 200 OK final response. The timeout values in 2202 Firewalls and NAT's are observed to be between 1 to 3 mins and the 2203 "keep-alive" frequency must be higher than this. This keep-alive 2204 mechanism must continue during the call. 2206 The public IP address/port allocated by the NAT is returned to the 2207 Client in the Contact header of 200 OK sent by the Proxy server. This 2208 allows the UA to perform NAT/FW failure detection by - (a) not 2209 receiving 200 OK over a prolonged period of time, and (b) detecting 2210 that the NAT IP address has changed in a received 200 OK. The second 2211 event can serve as an indication that the UA needs to re-register 2212 with the Proxy server to maintain the signaling path open. The NAT 2213 address/port, although sent to the registered UA, is never carried in 2214 SIP messages towards the remote callee. This provides certain amount 2215 of security through IP address hiding. 2217 5.2.2 Media Path: The Case for RTP (Media) Proxy 2219 RTP Proxy, as the name suggests, terminates an RTP session on one 2220 side and originates the same session on the other. The UA always 2221 sends (and receives) media to (and from) an assigned address and port 2222 of the RTP proxy. The RTP Proxy can perform NAPT function both on the 2223 source and destination address/port of packets. For a solution using 2224 an RTP Proxy to work, the requirement is that any media stream 2225 traversing the NAT from the private side (e.g., Enterprise) must 2226 always go through the RTP Proxy (and any intra-Enterprise traffic 2227 should be able to bypass the RTP Proxy). Since incoming packets are 2228 received from the same address and port as the outgoing packets are 2229 sent to, a Symmetric NAT will always allow the packets from the RTP 2230 proxy inside the Enterprise for the duration of the session. This 2231 implies that a Full Cone NAT (or any restricted version of it) will 2232 also allow flows to and from the RTP Proxy. This principle can be 2233 generalized to be applicable to any type of application session, not 2234 just RTP/RTCP sessions. 2236 The following are the prerequisites for this solution to work: 2238 o Any media stream that traverses the NAT from private side to 2239 the public will pass through the RTP Proxy. 2241 o The addresses and ports in the RTP Proxy are assigned either 2242 during the call set-up or before it. 2244 o The RTP Proxy should know where to send the received media. 2245 For example, if it is acting as a bridge between two private 2246 endpoints X and Y (X and Y are behind different NAT's), this 2247 implies that the Proxy should be aware of the X's external 2248 address/port before (or at least, as soon as) it starts 2249 receiving media from Y, and vice-versa. 2251 o The send and receive ports of the media in the UA's are 2252 configured to be the same. 2254 Reverting back to our example configuration in Figure 22, let us 2255 illustrate using a call flow, how resource allocation in the RTP 2256 Proxy will take place when UA X wants to establish a SIP session with 2257 UA Y (only relevant parts of the call flow is shown). It is assumed 2258 that the signaling paths between the UA's and the Proxy are already 2259 established by the method described in Section 5.2.1. Please refer to 2260 Figure 23 for the address/port allocations at various devices and the 2261 call flow. 2263 1. UA X sends a SIP INVITE message towards UA Y through the 2264 Proxy X' specifying that it wishes to receive media at 2265 (private) IP address, PXA and port, px, i.e., PXA:px. 2267 2. Proxy X' instructs the RTP Proxy to reserve a pair of IP 2268 address/port, one representing each end of the connection. 2269 To UA Y, the remote end of the connection is perceived to 2270 be A:px*, whereas to UA X, this is perceived to be A:py*. 2272 Legends:- 2273 <><> : bi-directional flow 2274 ---- : signaling 2275 ==== : media 2276 px, px', py*, px*, py', py : ports 2277 PXA, NX, A, NY, PYA : IP addresses 2279 PXA NX A NY PYA 2280 +-----+ +-----+ +--------+ +-----+ +-----+ 2281 | | | | | | | | | | 2282 | px|<><><| px'|<><><>py* px*|<><>|py' |<><>|py | 2283 | | | | | | | | | | 2284 +-----+ +-----+ +--------+ +-----+ +-----+ 2286 UA X NAT Proxy RTP Proxy NAT UA Y 2287 X' 2289 | 1.INVITE | | | | | 2290 |---------->|------>| | | | 2291 | | |------->| | | 2292 | | | 2.Create | | 2293 | | | port bind | | 2294 | | |<-------| | | 2295 | | | |3.INVITE | | 2296 | | |------------------>|-------->| 2297 | | | | | | 2298 |<----------|<------|<------------------|<--------| 2299 | 5. 200 OK | | |4.200 OK | | 2300 | | | | | | 2301 |==========>|===============>| | | 2302 | | 6.RTP | |<=========|<========| 2303 | | | | 6.RTP | | 2304 | | | | | | 2305 |---------->|------>|------------------>|-------->| 2306 |7. ACK | | | | | 2307 | | | | | | 2308 |<=========>|<==============>|<========>|<=======>| 2309 RTP 2311 Figure 23: Call Flow for B2BUAWM 2313 Note 1: Due to the presence of the NAT's, the source IP 2314 address/port of the media packets from the UA's are yet 2315 unknown to the RTP Proxy. Note 2: Consecutive port binds 2316 are also created for RTCP sessions corresponding to RTP. 2318 3. Proxy X' forwards the INVITE towards UA Y (perhaps through 2319 Proxy Y') specifying that Y should send media to the RTP 2320 Proxy at A:px* (by modifying the SDP). 2322 4. UA Y responds with a 200 OK specifying that it wishes to 2323 receive media at (private) IP address, PYA and port, py, 2324 i.e., PYA:py. 2326 5. When Proxy X' receives the 200 OK, it changes these IP 2327 address and port parameters in SDP specifying X should 2328 transmit media to the RTP Proxy at A:py*, and forwards the 2329 200 OK towards UA X (Note: Proxy X' actually forwards the 2330 message to the external NAT-ed address/port of UA X). 2332 6. When UA X receives the 200 OK, it starts transmitting media 2333 (e.g., background noise) towards the RTP Proxy. When the 2334 first of these NAT- ed RTP packets reach the RTP Proxy, the 2335 Proxy remembers the source address/port (say, NX, px') of 2336 that packet as the external representation for the media 2337 end point of UA X. Any media received from Y to X should be 2338 sent to this address/port. 2340 Similarly, when the first RTP packet is received from UA Y, 2341 the RTP Proxy notes down the source IP address/port (say, 2342 NY:py'), which will be used as the destination address to 2343 transmit media received from X to Y. 2345 7. Finally, UA X responds with an ACK message and the call 2346 set-up is complete. 2348 Note that, since all signaling is routed via the Proxy, which can 2349 determine whether both the UA's are in the same domain, all intra- 2350 Enterprise calls (behind the same NAT) can avoid the trip to the RTP 2351 Proxy. This is one of the key advantages of the Proxy mediating the 2352 address/port of the endpoints of a call. 2354 Once the media path is established through the NAT, keep-alive 2355 messages in the form of periodic RTP packets are sent to keep the 2356 connection alive when the users are in mute (i.e., when no speech 2357 packets are transmitted). 2359 There needs to be some control interaction between the SIP and the 2360 RTP Proxies to establish the end-to-end sessions. The protocol can be 2361 one of the device control protocols such as MGCP, Megaco etc. 2363 5.3 Solution III: Outsourced MIDCOM 2364 In this scenario, the enterprise upgrades its firewall/NAT to a 2365 midcom-enabled one. The centrex provider uses a proxy which can 2366 control the firewall/NAT, opening and closing pinholes as needed. 2367 This scenario avoids the need for a SIP specific ALG. Indeed, if the 2368 enterprise uses other outsourced services, each provider can have a 2369 control connection to the firewall/NAT to ensure that it works for 2370 that particular application. This is one of the benefits of MIDCOM. 2372 This configuration (for a single centrex provider) is shown in Figure 2373 24. It is similar to the ALG configuration 20, but there is a control 2374 relationship between the proxies in the provider network (which act 2375 as midcom agents [7]), and the firewall/NAT in the enterprise (which 2376 is the middlebox). 2378 For this solution to work, the firewall/NAT needs a static rule which 2379 allows all outgoing traffic on UDP port 5060 to the proxies in the 2380 provider network. This rule can be configured, or the proxies in the 2381 provider network can create it when they first connect to the 2382 firewall/NAT. 2384 The basic call flow for a registration and incoming INVITE is shown 2385 in Figure 25. The enterprise is using a MIDCOM FW/NAT. The enterprise 2386 has a single public address, 1.2.3.4, which routes to the FW/NAT. 2387 When the REGISTER arrives at the proxy (message 2), the proxy 2388 performs a bind request (message 3), asking for the Contact address, 2389 10.0.1.7:5060, to be translated. The FW/NAT returns with a mapped 2390 address, 1.2.3.4:7765, and this is stored by the proxy to use as the 2391 destination IP/port for sending requests to sip:user@10.0.1.7. 2393 When an incoming INVITE arrives at the proxy (message 7), the R-URI 2394 is looked up, and translated to sip:10.0.1.7, but with a destination 2395 address of 1.2.3.4:7765, which is where the request is sent. This 2396 passes through the NAT, translated to 10.0.1.7:5060, and arrives at 2397 the client (message 9). The 200 OK contains an RTP address of 2398 10.0.1.7:8866. When this is received by the proxy (11), it performs 2399 another bind request to the FW/NAT, asking for a pair of addresses on 2400 consecutive ports. The bind response indicates that 1.2.3.4:6544 and 2401 1.2.3.4:6545 will be mapped to 10.0.1.7:8866 and 10.0.1.7:8867 2402 respectively. The proxy rewrites the SDP in the response, and 2403 forwards that upstream. 2405 5.4 Solution IV: STUN and TURN 2407 The operation of a STUN or TURN solution in the centrex case is 2408 identical to the residential case described in Section 2.2. If the 2409 enterprise uses a firewall/NAT which allows for full-cone operation 2410 ................................................... 2411 . . 2412 . +------+ Centrex . 2413 . | | Provider . 2414 . +------+ | Proxy Farm . 2415 . | | | . 2416 . | | | . 2417 . | |-+ . 2418 . +------+ . 2419 . x . 2420 . x . 2421 .Provider x | . 2422 .................x......|.......................... 2423 x | 2424 MIDCOM x |Provider Access (Internet, 2425 Control x +---------+ private connection) 2426 xx|Enterpris| 2427 ..................|. FW/NAT |..................... 2428 . | MIDCOM | Enterprise . 2429 . +---------+ . 2430 . . 2431 . . 2432 . . 2433 . . 2434 . . 2435 . . 2436 . . 2437 . /\ /\ . 2438 . /\ / \ /\ / \ . 2439 . / \ / \ / \ / \ . 2440 . / \ /Client\ / \ /Client\ . 2441 . /Client\ ---------- /Client\ ---------- . 2442 . ---------- ---------- . 2443 .................................................. 2445 Figure 24: Centrex MIDCOM Configuration 2447 of UDP, then STUN will get used, and the centrex provider needs to 2448 only deploy STUN servers. If, however, a more restrictive 2449 firewall/NAT, such as symmetric, is used, the centrex provider must 2450 deploy TURN servers as well. 2452 6 Comparing the Approaches 2453 Client MIDCOM FW Provider UAC 2454 Proxy 2455 |(1) REGISTER | | | 2456 |m:10.0.1.7 | | | 2457 |--------------->| | | 2458 | |(2) REGISTER | | 2459 | |m:10.0.1.7 | | 2460 | |--------------->| | 2461 | |(3) BIND_REQ | | 2462 | |10.0.1.7:5060 | | 2463 | |<---------------| | 2464 | |(4) BIND_RESP | | 2465 | |1.2.3.4:7765 | | 2466 | |--------------->| | 2467 | |(5) 200 OK | | 2468 | |<---------------| | 2469 |(6) 200 OK | | | 2470 |<---------------| | | 2471 | | |(7) INVITE | 2472 | | |sip:user@enterprise 2473 | | |<---------------| 2474 | |(8) INVITE | | 2475 | |sip:user@10.0.1.7 | 2476 | |dst=1.2.3.4:7765| | 2477 | |<---------------| | 2478 |(9) INVITE | | | 2479 |<---------------| | | 2480 |(10) 200 OK | | | 2481 |m=10.0.1.7 | | | 2482 |rtp=10.0.1.7:8866 | | 2483 |--------------->| | | 2484 | |(11) 200 OK | | 2485 | |m=10.0.1.7 | | 2486 | |rtp=10.0.1.7:8866 | 2487 | |--------------->| | 2488 | |(12) BIND_REQ2 | | 2489 | |10.0.1.7:8866 | | 2490 | |<---------------| | 2491 | |(13) BIND_RESP | | 2492 | |1.2.3.4:6544 | | 2493 | |--------------->| | 2494 | | |(14) 200 OK | 2495 | | |--------------->| 2496 | | |(15) ACK | 2497 | | |<---------------| 2498 | |(16) ACK | | 2499 | |<---------------| | 2500 |(17) ACK | | | 2501 |<---------------| | | 2503 Figure 25: Centrex MIDCOM Solution, Incoming INVITE 2504 In order to compare the various solutions, it is necessary to 2505 establish criteria by which they will be compared. The following 2506 criteria are considered: 2508 Upgrades Required: Which elements does the solution require to 2509 change? The fewer, the better. 2511 Network Traffic: Does the solution generate additional message 2512 traffic that otherwise would not occur if there was no NAT? 2513 The less, the better. 2515 Voice Quality: Does the solution impact voice quality? Does it 2516 increase latency or increase the probability of packet 2517 loss? THe less the impact, the better. 2519 Provider Cost: Does the solution incur substantial incremental 2520 cost for the provider? The less the better. 2522 Enterprise Cost: For solutions that target the enterprise, does 2523 it introduce additional cost for the enterprise? The less, 2524 the better. 2526 User Cost: For solutions that require the end user or the user 2527 agent to change, does it introduce cost to the user? The 2528 less, the better. 2530 Specificity: Does the solution work under very specific 2531 conditions? Or, can it work across a wide variety of 2532 scenarios and NAT types? The less specific, the better. 2534 Application Focus: Is the solution SIP specific, or is it 2535 reusable for other applications? The less specific, the 2536 better. 2538 Loss of Robustness: Does the solution take away robustness from 2539 the system, or make it more expensive to implement the same 2540 amount of robustness in the absence of NAT? The less the 2541 loss of robustness, the better. 2543 Loss of Scale: Does the solution make it harder to scale up to 2544 support a large number of users? The less the loss of 2545 scale, the better. 2547 7 Changes since draft-rosenberg-sipping-nat-scenarios-00 2549 o Added more discussion on registration approaches. Updated 2550 (partially) to reflect removal of translate header in favor of 2551 connection sharing. 2553 o Reference updates. 2555 o Added evaluation criteria. 2557 8 Future Work 2559 o Update for the latest drafts. 2561 o Include a subsection at the end of each scenario, weighing the 2562 pros/cons of each solution based on the criteria. 2564 o Expand the scope of the solution set to include a broader set 2565 of solutions. 2567 o More details on many of the call flows. 2569 o Alignment with UNSAF in terms of criteria and evaluation. 2571 9 Acknowledgements 2573 The authors would like to thank Mary Barnes for her comments on this 2574 draft. 2576 10 Authors Addresses 2578 Jonathan Rosenberg 2579 dynamicsoft 2580 72 Eagle Rock Avenue 2581 First Floor 2582 East Hanover, NJ 07936 2583 email: jdrosen@dynamicsoft.com 2585 Rohan Mahy 2586 Cisco Systems 2587 170 West Tasman Dr, MS: SJC-21/3 2588 Phone: +1 408 526 8570 2589 Email: rohan@cisco.com 2591 Sanjoy Sen 2592 Nortel Networks 2593 sanjoy@nortelnetworks.com 2595 11 Normative References 2596 12 Informative References 2598 [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation 2599 protocol," Internet Draft, Internet Engineering Task Force, Feb. 2600 2002. Work in progress. 2602 [2] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, "STUN - 2603 simple traversal of UDP through NATs," Internet Draft, Internet 2604 Engineering Task Force, Apr. 2002. Work in progress. 2606 [3] J. Rosenberg, "Traversal using relay NAT (TURN)," Internet Draft, 2607 Internet Engineering Task Force, Nov. 2001. Work in progress. 2609 [4] B. Biggs, "A SIP application level gateway for network address 2610 translation," Internet Draft, Internet Engineering Task Force, Mar. 2611 2000. Work in progress. 2613 [5] C. Martin and A. Johnston, "SIP through NAT enabled firewall call 2614 flows," Internet Draft, Internet Engineering Task Force, Feb. 2001. 2615 Work in progress. 2617 [6] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through 2618 firewalls and NATs," Internet Draft, Internet Engineering Task Force, 2619 Feb. 2000. Work in progress. 2621 [7] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan, 2622 "Middlebox communication architecture and framework," Internet Draft, 2623 Internet Engineering Task Force, Mar. 2002. Work in progress. 2625 [8] C. Huitema, "RTCP attribute in SDP," Internet Draft, Internet 2626 Engineering Task Force, Feb. 2002. Work in progress. 2628 [9] J. Rosenberg, J. Weinberger, and H. Schulzrinne, "SIP extensions 2629 for NAT traversal," Internet Draft, Internet Engineering Task Force, 2630 Nov. 2001. Work in progress. 2632 [10] M. Borella, D. Grabelsky, J. Lo, and K. Taniguchi, "Realm 2633 specific IP: protocol specification," RFC 3103, Internet Engineering 2634 Task Force, Oct. 2001. 2636 [11] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm 2637 specific IP: framework," RFC 3102, Internet Engineering Task Force, 2638 Oct. 2001. 2640 [12] F. Thernelius, "SIP firewall solution," Internet Draft, Internet 2641 Engineering Task Force, July 2000. Work in progress. 2643 [13] S. Kent and R. Atkinson, "IP encapsulating security payload 2644 (ESP)," RFC 2406, Internet Engineering Task Force, Nov. 1998. 2646 [14] M. Gaynor and S. Bradner, "Firewall enhancement protocol (FEP)," 2647 RFC 3093, Internet Engineering Task Force, Apr. 2001. 2649 [15] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, "STUN - 2650 simple traversal of UDP through NATs," Internet Draft, Internet 2651 Engineering Task Force, Mar. 2002. Work in progress. 2653 [16] D. Yon, "Connection-oriented media transport in SDP," Internet 2654 Draft, Internet Engineering Task Force, May 2002. Work in progress. 2656 [17] R. Mahy, "Requirements for connection reuse in the session 2657 initiation protocol (SIP)," Internet Draft, Internet Engineering Task 2658 Force, June 2002. Work in progress. 2660 [18] M. Arango, A. Dugan, I. Elliott, C. Huitema, and S. Pickett, 2661 "Media gateway control protocol (MGCP) version 1.0," RFC 2705, 2662 Internet Engineering Task Force, Oct. 1999. 2664 [19] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, and J. 2665 Segers, "Megaco protocol version 1.0," RFC 3015, Internet Engineering 2666 Task Force, Nov. 2000. 2668 Full Copyright Statement 2670 Copyright (c) The Internet Society (2002). All Rights Reserved. 2672 This document and translations of it may be copied and furnished to 2673 others, and derivative works that comment on or otherwise explain it 2674 or assist in its implementation may be prepared, copied, published 2675 and distributed, in whole or in part, without restriction of any 2676 kind, provided that the above copyright notice and this paragraph are 2677 included on all such copies and derivative works. However, this 2678 document itself may not be modified in any way, such as by removing 2679 the copyright notice or references to the Internet Society or other 2680 Internet organizations, except as needed for the purpose of 2681 developing Internet standards in which case the procedures for 2682 copyrights defined in the Internet Standards process must be 2683 followed, or as required to translate it into languages other than 2684 English. 2686 The limited permissions granted above are perpetual and will not be 2687 revoked by the Internet Society or its successors or assigns. 2689 This document and the information contained herein is provided on an 2690 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2691 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2692 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2693 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2694 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2696 The IETF has been notified of intellectual property rights claimed in 2697 regard to some or all of the specification contained in this 2698 document. For more information consult the online list of claimed 2699 rights.