Your SlideShare is downloading. ×
Practical Far-End NAT Traversal for VoIP Whitepaper PDF
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Practical Far-End NAT Traversal for VoIP Whitepaper PDF

2,862
views

Published on


0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,862
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
91
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. | WHITE PAPER | Practical Far-End NAT Traversal for VoIP March 2006
  • 2. Practical Far-End NAT Traversal for VoIP Contents Introduction .............................................................................................................................. 3 . Packet Admission Policy Problems ................................................................................................ 3 Packet Admission Policy Modes ........................................................................................... 3 Pinhole Timeout Thresholds .................................................................................................... 4 Signaling Asymmetry .............................................................................................................. 4 Client-Side Signaling Asymmetry ......................................................................................... 4 Server-Side Signaling Asymmetry ......................................................................................... 5 Outbound Calls and 2-Way Media ........................................................................................... 5 REGISTER Packet and Inbound Calls ......................................................................................... 6 Network and Port Translation Problems ........................................................................................ 7 NAT Port Contention and Port Rotation ................................................................................... 8 NAT and Media ...................................................................................................................... 9 Common Attempts to Solve the Problems ....................................................................................11 Using TCP ............................................................................................................................11 . UPnP ....................................................................................................................................11 STUN ...................................................................................................................................12 . TURN ...................................................................................................................................13 . Signaling/Media Proxy Combination ........................................................................................14 ICE ......................................................................................................................................14 . Using an External B2BUA/MP ......................................................................................................15 Summary ..................................................................................................................................18 . Acronyms .................................................................................................................................19 . About Ditech Networks . .............................................................................................................19 Copyright © 2007 Ditech Networks 2/20
  • 3. Practical Far-End NAT Traversal for VoIP Introduction The goal of far-end NAT traversal is to allow inbound and outbound VoIP calls to succeed in the highest possible number of cases, even when one or both call parties on the call are behind one or more address-translation-enabled firewalls. No requirements on the subscriber-premise’s hardware, software, or firewall should be permitted – the subscriber’s experience should be to simply plug in a properly configured VoIP phone and start making calls. This paper discusses the issues that must be considered and the solutions required to achieve this goal. We begin by examining the effects of firewalls in their role as packet admission controlling points, and then look into the more complicated issues arising from Network Address Translation (NAT) and Port Address Translation (PAT). Packet Admission Policy Problems Before discussing the issues of NAT and PAT, administrators must understand that network firewalls create many of VoIP’s problems with their packet admission policies. This is because firewalls are the gatekeeper of the UDP protocol which is required by VoIP. By default, firewalls are typically configured to behave in one or more of the following modes, listed in order of restrictiveness. Packet Admission Policy Modes 1. Allow all User Datagram Protocol (UDP) datagrams to come in through the firewall (Open). 2. Allow only certain hosts to send UDP inbound. 3. Allow certain hosts to send UDP inbound only from certain ports, and only to certain inside hosts on certain ports. 4. Allow all external hosts to send inbound UDP to any inside host, provided that the same type of traffic has recently been emitted outbound from any inside host/port. This is called a Full Cone NAT. 5. Allow an external host to send inbound UDP from any port to an inside host, provided that the same type of traffic has recently been emitted outbound from any inside host/port to that external host. This is called a Restricted Cone NAT. 6. Allow an external host and only that specific external host to send inbound UDP using the same port pair to an inside host. This is called a Port-restricted Cone or Symmetric NAT. Note that there is also a further difference between a Port-restricted Cone and Symmetric NAT which relates to the use of different global-port to local host-port bindings for traffic exchanges between a single internal host to different external hosts. 7. Allow an external host to send inbound UDP to an inside host, provided that the same type of traffic (host/port) has recently been emitted outbound to a port at the external host that is lower than 1024. This is a more restrictive variant of Port-restricted Cone or Symmetric NAT. 8. Behave as a proxy server that only allows inbound UDP traffic from special configurations on the clients. 9. Deny all inbound UDP traffic and responses (Closed). The concept of CPE-less NAT/Firewall traversal rests on the premise that UDP responses from at least one server on the outside network must be allowed to pass through. Different vendors use different terminology to describe Modes 4 through 7 in their firewall configurations. The most common names include Stateful Inspection, Adaptive Security Algorithm, Stateful UDP “Connection” Cache, and Reflexive UDP Admission. Copyright © 2007 Ditech Networks /20
  • 4. Practical Far-End NAT Traversal for VoIP We will use the term Reflexive UDP Admission to describe firewalls that allow an external host to respond symmetri- cally within a given period of time. We will also call this temporary admission of responses a pinhole. Most firewalls support Reflexive UDP Admission by default, but firewall vendors usually do not disclose which type among the above modes that the default behavior for UDP admission falls into. Pinhole Timeout Thresholds Additionally, most firewall vendors do not disclose the length of the inactivity period after which a dynamic pinhole is closed. In our observations, multiple inbound packets are usually accepted for 30 seconds to 10 minutes after an outbound packet has been sent. However, some firewalls may arbitrarily close the pinholes, which halts the external entity’s ability to send inbound calls. Signaling Asymmetry Signaling asymmetry occurs when a client at an IP and port address declares a different IP address or port in the Via and/or Contact headers that are different from the IP address or port actually used to emit that SIP signal. For example, consider the scenario where there is an external Session Initiation Protocol (SIP) proxy server (Px) located at 204.31.1.11 listening on UDP port 5060. A SIP client (C1) located at 192.159.1.11 behind a non-NAT firewall sends a UDP signal from the randomly assigned ephemeral port 12345 to the Px port located at 5060. The client has the option to choose a port to listen to for responses and future requests. If, in the SIP signaling packet, the client declares a Via: information and Contact: information of 192.159.1.11:12345 (the same as its actual address and port), there will be no problems for firewalls configured to behave according to Modes 1 through 4 as previously mentioned. However, this general rule may be subject to the problems described below. Client-Side Signaling Asymmetry Client-side signaling asymmetry occurs when a client declares a different contact port in the Via. In this scenario, if a client declares a Via: port that is different from the source port used to send out the initial outbound signal (most likely a REGISTER), then firewalls that are configured to be more restrictive than Mode 3 will not allow such response packets to reach the client at the declared port. For example, if a client (C1) located at 192.159.1.11:12345 sends a REGISTER to the SIP proxy at 204.31.1.11:5060 with a declared Via: 192.159.1.11:5060, then the expectation is for the server to send the response to a port other than the initial ephemeral port. Figure 1 displays a schematic of a successful client-side signaling asymmetry. Figure 1: : Client-Side Signaling Asymmetry (Successful) Copyright © 2007 Ditech Networks /20
  • 5. Practical Far-End NAT Traversal for VoIP If the server responds back to port 5060, it will not pass through the firewall. Figure 2 displays a schematic of an unsuccessful client-side signaling asymmetry. Figure 2 : : Client-Side Signaling Asymmetry (Unsuccessful) Server-Side Signaling Asymmetry There are several ways a SIP proxy server (Px) can send responses back to the client (C1). Let’s revisit the initial outbound signal from the above example. The client located at IP address 192.159.1.11 and port 12345 now declares in the Via: 192.159.1.11:12345 to the SIP proxy located at 204.3.1.11:5060. The external server may respond in the following ways: • Respond using a different IP address: allowed only by Mode 1. 192.159.1.11:12345 - 204.31.1.12:5060 • Respond using a different source port: allowed only by Modes 1 and 2 192.159.1.11:12345 - 204.31.1.11:54321 • Respond symmetrically: allowed by Mode 4 and other more lenient modes 192.159.1.11:12345 - 204.31.1.11:5060 A port-restricted or symmetric firewall (Mode 4) further mandates that Px must signal C1 using a source port of 5060. Some firewalls feature configurable switches called port triggering or established udp, which allow an administrator to open multiple pinholes on firewalls as a workaround to the above signaling asymmetry. However, such options are not practical, as the user who has the phone behind the firewall may not have administrative control over the fire- wall. Therefore, to assure successful traversal across firewalls that support dynamic UDP admission, it is recommended that both the inside and outside entities use the same port to send and receive a certain type of traffic. Outbound Calls and 2-Way Media A typical outbound SIP call involves a caller signaling a proxy with an INVITE. The proxy then relays the INVITE to the callee. The Session Description Protocol (SDP) information within the INVITE message tells the callee where to send the media. When the call is accepted, the callee sends a 200 OK message with SDP information that tells the caller where to send the media. Copyright © 2007 Ditech Networks /20
  • 6. Practical Far-End NAT Traversal for VoIP If the outbound caller does not send the first media stream of the call, the caller will only be able to hear media from the callee if he/she is behind a firewall using Modes 1 through 3. This is because a restricted cone NAT will not allow a host (the callee) – to whom the caller has not recently sent a packet – to send any UDP inbound across the firewall. For the call to be successful when the caller is behind a firewall using Modes 1 through 6, both the caller and callee should send media on the same port as they declare in the SDP that they will be listening for media. Figure 3 below displays an example of this process. In this figure, the caller located at 192.159.1.11:16384 sends out an INVITE to the callee with SDP information informing the callee where to send media. The callee responds by sending a 200 OK with its own SDP information, after which a call is established between the caller’s port at 16384 and the callee’s port at 8000. Figure 3 : : Outbound Calls and 2-Way Media In this example, media is exchanged symmetrically between the caller and callee. This satisfies the packet admission requirements of the more restrictive firewalls, as long as the firewalls themselves are configured to support Reflexive UDP Admission. If, at any time during the call, the caller behind the firewall stops sending media outbound for a sufficient amount of time, there is no guarantee that the firewall will continue to admit incoming Real Time Protocol (RTP) media streams. This also applies to Real Time Control Protocol (RTCP) packets. It is likely that the firewall will not admit an inbound RTCP packet unless an outbound RTCP packet has been emitted from the caller to the callee. If sufficient time has elapsed before the next RTCP exchange, there is a possibility that the pinhole for incoming RTCP will be closed, and the external callee sending the RTCP packet may get a message from the firewall that the Internet Control Message Protocol (ICMP) destination is unreachable. REGISTER Packet and Inbound Calls Most SIP deployments are set up in such a way that SIP phones send a REGISTER packet out to a Registrar Proxy upon startup. The register signal, when authenticated and accepted by the Registrar Proxy, informs the caller where the callee can be reached for future incoming requests. This coincidentally opens up a pinhole across the firewall for incoming requests to be delivered to the client. Copyright © 2007 Ditech Networks /20
  • 7. Practical Far-End NAT Traversal for VoIP As discussed earlier, the firewall may close the pinhole when a period of inactivity has passed. Common measures taken to keep the firewall pinhole open include the following: • Configuring the SIP Proxy to send dummy keep-alive packets to the client. • Configuring the SIP clients to send dummy keep-alive packets to the SIP proxy. • Configuring the SIP clients to re-register with the SIP proxy approximately every 30 seconds. Unfortunately, dummy packets may be ineffective in the NAT cases to be discussed later in this paper, and increasing the frequency of re-registration often carries the penalty of overwhelming the proxy registration database. Network and Port Translation Problems Network Address Translation (NAT) adds further complications to SIP. This is because SIP signaling relies on the IP addresses and port numbers contained in the signaling message payload, and this payload can be improperly translated by NAT enabled firewalls. Figure 4 below displays an example of NAT introduced complications. In this example the inside client (C1) sends a SIP request packet to an outside SIP proxy (Px) via a NAT (Nx). Note that in this paper, we limit our discussion of NAT to the most complex (and most common) situation, where the firewall exhibits dynamic UDP admission and where no static NAT or PAT forwarding is enabled. Figure 4 : : NAT Complications If the SIP proxy (Px) were to follow the embedded Via in responding to the original SIP message, the packet would have been sent to 192.168.1.100, which is unreachable on the Internet. If the SIP proxy (Px) were to send a response according to the same UDP source address, it is likely that the response message will reach the client. Copyright © 2007 Ditech Networks 7/20
  • 8. Practical Far-End NAT Traversal for VoIP However, here lies the conflict when the packet sent by the client is a REGISTER message. Figure 5 below displays the conflict. Figure 5 : : REGISTER Message - Conflict According to the SIP specification, the proxy should enter into its registrar table that client C1 is reachable at 192.168.1.100, port 5060. Obviously, this address will not be reachable. For practical reasons, it should have entered 192.159.1.11:1024 instead, as long as the client signals symmetrically (listens on port 5060). Unfortunately, by doing this, the proxy deviates from the SIP specification. NAT Port Contention and Port Rotation Most NAT firewalls are deployed in Port Address Protocol (PAT) mode by default, where many internal clients share the same global (external) IP address of the firewall. Consider the case where two SIP clients (C1 and C2) are located in the internal network and send REGISTER messages to the same SIP proxy (Px) outside. Client C1 is at 192.168.1.100 and client C2 is at 192.168.1.101. Figure 6 below displays a schematic of this configuration. Figure 6 : : NAT Port Contention/Rotation Copyright © 2007 Ditech Networks /20
  • 9. Practical Far-End NAT Traversal for VoIP If the NAT does not translate ports by default, the first client (C1) is likely to get a source port on the global IP address that is identical to the original source port of 5060. If there is a second host on the inside using a source port of 5060 to talk to the SIP proxy at Px, the firewall will assign it a random ephemeral port (such as 192.159.11:1024). However, there is a phenomenon similar to musical chairs that is likely to happen. If the first translation slot for 192.168.1.100 ever expires and a packet is sent from C2 at address 192.168.1.101:5060, then C2 will likely get the translation slot of 192.159.1.1:5060, and C1 will get a new translation slot of 192.159.1.11:1025. So what happens to incoming calls to C1? If the SIP proxy (Px) “remembers” C1 is at 192.159.1.1:5060 based on the initial registration, then an incoming INVITE will be sent to the wrong phone and C2 will likely start ringing, or even reject the call because the INVITE would carry a request URI of 192.168.1.100:5060, and not 192.168.1.101:5060. NAT and Media Let’s examine the problem with SDP and media. Consider the case where a caller behind a firewall calls a callee outside the firewall. In this scenario, the caller is located behind the firewall at 192.159.1.11:16384. Figure 7 below displays a schematic of this configuration. Figure 7 : : NAT and Media Since the callee receives the INVITE from the proxy, the callee will not have any idea what the firewall global IP address of the caller would be, not to mention the correct port to send to. The SDP information contained inside the INVITE message simply cannot be used. A caller behind a NAT firewall may be able to learn what its translated global IP address is ahead of time. In this outbound case, the initial INVITE contains the correct IP address. Consider the case where the user behind a NAT 192.159.1.11 already knows ahead of time what the translated address will be, and configures the phone to send SDP information to contain the global IP (Figure 8 on page 10). Copyright © 2007 Ditech Networks /20
  • 10. Practical Far-End NAT Traversal for VoIP Figure 8 : : NAT and Media - Second Example The INVITE requests the callee to send media to 192.159.1.11:16384, and the caller starts listening on port 16384 for incoming media. NAT firewalls (with the exception of Full Cone NATs) disallow the callee’s media packets coming inbound. This is also an issue with port translation. For example, when the caller sends media via a NAT to a callee, the UDP state created in the NAT may have a port that differs from the UDP port used by the caller. The SDP information embedded in the outbound INVITE has a UDP port declared. This is the port from which the caller will send media if it sends and receives RTP media symmetrically. However, unless the firewall is guaranteed not to perform any port translation, it is unlikely that an incoming stream from the callee to the NAT port (in our example, port number 16384) will be translated and sent inbound to callee port 16384. If the NAT type is more restrictive than a Full Cone, the question becomes what the caller should send across the firewall to create the UDP state entry (or pinhole) on the firewall, such that incoming media will reach port 16384. If the caller knows ahead of time that the callee is not behind a NAT, and its SDP can be trusted, then the caller can send media as soon as a 200 OK is received (see Figure 9 on page 11). Copyright © 2007 Ditech Networks 10/20
  • 11. Practical Far-End NAT Traversal for VoIP Figure 9 : : Caller Aware Callee Not Behind NAT If the external callee were to disregard the caller’s SDP declared in the INVITE, but send media symmetrically to the caller once it has received a media packet from the caller, then 2-way media should be established. However, we have not seen a SIP phone in production that is capable of this. Furthermore, in the case where both caller and callee are behind their respective firewalls, both the caller and callee will be in limbo, waiting for each other to be the first to send media. Common Attempts to Solve the Problems The following section describes the common measures used to achieve CPE-less far-end NAT traversal for SIP. With the exception of Transmission Control Protocol (TCP) signaling and UPnP, the methods described take advantage of signaling and media symmetry on almost all newer phones, and Reflexive UDP Admission on most firewalls in their actual deployed configuration. Using TCP Using TCP for signaling and configuring the proxy (where possible) to ignore mismatching Via and Contact headers caused by NATs to a certain extent can work. However, to ensure that inbound calls can reach clients behind firewalls, persistent TCP connections must be made with the proxy, which dramatically reduces scalability and creates a significant amount of network overhead. Furthermore, most NAT firewalls have TCP idle timeouts, mandating the use of keep-alive packets across the TCP connection. Note that TCP only addresses signaling, because RTP and RTCP are still transmitted in UDP. UPnP Universal Plug and Play (UPnP) clients try to signal the NAT firewall to pre-allocate numerous UDP ports to allow both incoming signal and media. In practice, there is often confusion in the allocation of these ports when more than one client tries to open the same range of UDP ports. Since a large percentage of firewalls are not configured to have UPnP enabled, one cannot rely on UPnP to work, especially when users may not know whether the firewall they are behind is actually UPnP compatible. Copyright © 2007 Ditech Networks 11/20
  • 12. Practical Far-End NAT Traversal for VoIP STUN Some IP phone vendors are implementing Simple Traversal of UDP through NAT (STUN), which is in IETF Draft stage (RFC 3489). STUN is a protocol that lets the phone query an external server to validate its external IP address/port. Unfortunately, STUN does not work in the common corporate firewall example of a symmetric NAT. In this example below (see Figure 10), the caller sends a single STUN query to get its RTP port (abridged for the sake of simplicity), which is translated from 16384 to 1024. Figure 10 : : STUN Port Translation When making an outbound call, the caller (C1) sends an INVITE to (C2) using the IP address and port information it received from the STUN queries (Figure 11). Figure 11 : : STUN Port Usage However, when the time comes for the caller to send media to the callee, the NAT assigns a new port allocation. This may be due to the fact that the firewall chooses a different binding for a different host (STUN server vs. callee), or it is a different binding due to a different destination port (3478 vs. 8000 in this example). Copyright © 2007 Ditech Networks 12/20
  • 13. Practical Far-End NAT Traversal for VoIP Figure 12 below, displays a schematic of this example. When the callee tries to send media to port 1024 on the firewall based on the SDP information, it gets blocked. Figure 12 : : Blocked Media Furthermore, there is no telling whether the external host will send media symmetrically. Many media servers for voicemail, IVR, and conference do not send and receive media on the same port. This creates a media asymmetry for which even Port-restricted Cone firewalls will not work. Newer phones often execute a STUN “test” to notify the user what type of NAT firewall the phone is behind. However, since NAT bindings can change or expire without warning, a STUN-enabled phone behind a NAT firewall should regularly reconfirm its global address and ports with the STUN servers, and preferably right before it sends a request signal. Unfortunately, this carries the penalty of adding load to the network. In rare cases, a Restricted Cone NAT may exhibit the behavior of a Symmetric NAT. These symptoms are observable when a phone frequently re-registers from different global source ports. This may be due to the inadvertent clearing of the “translation table” for configuration changes that mandate the restarting of the firewall, crashes, or simply a failure to follow the translation timeouts based on inactivity. In general, STUN can work well, but only when the following configuration exists: • The STUN client is behind a NAT that is less restrictive than a Port-restricted Cone, and • The signaling proxy signals symmetrically, and • The endpoint, if located on the external network, emits/receives RTP symmetrically, or the other endpoint is a STUN client. TURN A significant supplement to STUN that utilizes an externally-hosted Media Proxy to deal with symmetric NATs is Traversal Using Relay NAT (TURN). The goal of TURN is to enable calls to pass through symmetric NATs. Copyright © 2007 Ditech Networks 1/20
  • 14. Practical Far-End NAT Traversal for VoIP Endpoints could be equipped with the intelligence to negotiate with the TURN server to allocate and send media to a globally-routable media relay. Instead of sending media based on SDP information, it relays media for each call symmetrically, using the same source port on which it listens for incoming media. A major criticism of this approach is the amount of bandwidth wastage and latency induced by routing all media to a central rendezvous location, and subsequently, to the other party. Calls between two neighboring endpoints often find their media routed out the firewall and back unnecessarily. Signaling/Media Proxy Combination TURN requires intelligence built into the endpoints to signal a TURN server. An alternative approach is to have an external Media Proxy that operates in conjunction with a Registrar/Signaling Proxy that modifies SDP as call signals pass through. This approach does not require endpoints to have the intelligence to perform any global address discovery or pre-call signaling with a TURN server. As long as the endpoints send and receive media symmetrically and the NATs involved support reflexive UDP admission, there should be no trouble getting calls through. However, this approach suffers the same drawback as the STUN/TURN combination in terms of bandwidth efficiency and scalability, and the SIP proxy often performs unnecessary re-routing of media between clients that are not behind firewalls or NATs. ICE Interactive Connectivity Establishment (ICE) is a method that tries to build intelligence into endpoints so that they can perform route discovery, path optimization, and even verify media flow before a call is deemed to be established. Prior to sending an INVITE, the caller performs a sequence of steps to characterize the firewall that it is behind: • Obtains addresses of all usable interfaces (local, VPN) • Checks the results from STUN • If needed, negotiates a port with the TURN server Afterwards, the caller sends a list of available IP addresses/ports in the INVITE to the proxy. As soon as the callee gets the INVITE, it follows a similar set of steps as did the caller. Next, it attempts to send STUN queries to the caller to see if it is possible to directly send media to any of the IP addresses it presented in the INVITE. Finally, the callee picks the address of highest preference in the INVITE to which the callee can confidently send media. This approach is compatible with most known firewalls that support UDP. In addition to working with all types of NATs that support reflexive UDP admission, it also works with the very restrictive firewalls that are deliberately configured to only allow internal hosts to converse using UDP with one or two hosts on the outside. However, for ICE to work properly, both caller and callee must support ICE, and there should readily be a STUN and TURN server available. For this reason, it should be deployed only in a homogeneous, controlled environment. Furthermore, it is likely that the call setup will be delayed because of the steps involved in media path discovery by both the caller and callee. Finally, with the end points advertising their own internal IP addresses, ICE may not meet the topology hiding requirements of security-focused environments. Copyright © 2007 Ditech Networks 1/20
  • 15. Practical Far-End NAT Traversal for VoIP Using an External B2BUA/MP The approaches discussed thus far in this paper can only solve selected problems some of the time. Furthermore, they often require additional intelligence on the endpoints, which may not always be available. Fortunately, an approach has been discovered that works in virtually all situations that does not require any additional customer-premise equipment, software, or firewall configuration. The result of applying this approach is that VoIP signaling and media streams can be made to traverse an arbitrary number of (possibly nested) NAT, PAT, and firewall devices, using any standards-compliant endpoint. This approach has the added benefit that in almost all cases, no additional media workload or latency is introduced, since the media still travel directly from caller to callee, and vice versa. This approach involves the use of a Session Border Controller (SBC) that contains a SIP Back-to-Back User Agent with an embedded Media Proxy (B2BUA/MP). The B2BUA/MP is located in the service provider’s network, from where it can see and reach the global IP addresses and port numbers of all call participants. The endpoints in a call are set up to either register through the B2BUA/MP, or to use it as their outbound proxy (as per IETF RFC 3261). The job of the B2BUA/MP is to accept call signaling and media streams from endpoints located behind NAT devices, and to “sanitize” those streams so that they can be sent further out onto the global Internet. It is not necessary for both endpoints to be behind the same B2BUA/MP. Indeed, one endpoint can be behind one and the other endpoint behind another, or one endpoint can be behind one while the other uses some other means to deal with its own NAT problems. One of the major advantages of this approach is that it does not require any special device or configuration to be present at both ends of a call. The following example (Figure 13 below) shows how a B2BUA, configured as the outbound proxy of the client, can function as a far-end NAT traversal device. Figure 13 : : B2BUA as a NAT Traversal Device The registrar proxy now has the user location information of C1 at the B2BUA. When properly implemented, the B2BUA does not have to keep a statically provisioned database of users, nor does the proxy need to be statically configured with user locations pointing at the B2BUA. Copyright © 2007 Ditech Networks 1/20
  • 16. Practical Far-End NAT Traversal for VoIP To ensure that user C1 is always reachable in case of inbound calls, the B2BUA uses various types of SIP signals to encourage the client C1 to regularly send SIP traffic to the B2BUA. This flow of SIP signals at regular intervals helps maintain the pinhole at the firewall. In case of an unexpected pinhole closure or change in UDP state brought about by firewall anomalies, this “heartbeat” traffic serves to inform the B2BUA of the client’s new global location. To prevent the proxy from being overwhelmed by this heartbeat traffic, the signals are not passed to the proxy unnecessarily. As an additional measure to deal with clients that do not obey the request by the B2BUA to send outbound messages, the B2BUA initiates SIP messages to clients periodically to verify their respective locations. When properly implemented, all the signals mentioned above should be generic SIP signals that should not cause any problems to any SIP endpoints. The B2BUA always uses the same port to communicate with the client, which makes it compatible with symmetric NATs. Unlike UPnP, where the client opens multiple ports across the firewall for multiple external hosts, there is no requirement for the client to open additional pinholes across the firewall. When a call is initiated, the B2BUA modifies the signals, informing both the caller and callee to send their media to pre-allocated ports on a Media Proxy, often configured to run on the same machine as the B2BUA. At regular intervals, the B2BUA uses standards-compliant SIP signals to verify that both caller and callee are still on the call. In the most challenging scenario, both caller and callee are each behind their own symmetric NATs. Since the Media Proxy is engaged at the start of the call, both parties receive media from each other, provided that each side has sent at least one RTP packet. If no further action is taken to optimize the call, the behavior of the B2BUA is similar to the Signaling/Media Proxy combination mentioned earlier in this document, having the same drawbacks of media latency and bandwidth wastage. Unless one party on the call is behind a symmetric NAT with frequent port translation changes, it is possible to re-direct the media during the middle of a call, where the caller sends the media to the correct port on the firewall that hides the callee, and vice versa. It is also possible for the B2BUA to use standards-compliant SIP signals to characterize the type of NAT firewall in front of each party on the call. This is done by inspecting the characteristics of the media flow after each of those NAT-characterized signals has been sent. This technique is called Media Path Optimization (MPO). Figure 14 on page 17 displays a schematic of the process for the B2BUA/MP. Copyright © 2007 Ditech Networks 1/20
  • 17. Practical Far-End NAT Traversal for VoIP Figure 14 : : B2BUA/MP Process Figure 14 displays the following steps in the B2BUA/MP process: 1. Assuming callee C2 has registered, caller C1 sends an INVITE. 2. The SIP proxy server (Px) locates C2 at the B2BUA. 3. The B2BUA sends an INVITE to C2’s firewall. Note that the signaling process that establishes the call has been omitted here. 4. The initial media flow has both the caller and callee sending media to the media proxy. 5. The B2BUA now starts NAT characterization of the firewalls on both sides. 6. The B2BUA sends signals to both endpoints, telling them to send the media to specific ports on the other party’s firewall. 7. The B2BUA successfully removes itself from the media path, but it still maintains control of call signaling. The key differentiator of a port-translating symmetric NAT from other NAT types is that a different global-to-local port-mapping is used if the same internal host sends a packet with the same source address and port, but to a different destination host or destination port. By observing the changes in media behavior with every SIP signal sent to each party on the call, the Media Proxy can determine whether a client is behind a port-translating symmetric NAT. If either party is behind such a NAT, the Media Proxy must continue to proxy the media for the call. Fortunately, the percentage of symmetric NATs deployed remains relatively small, especially in Small Office/Home Office (SOHO) environments. Aside from NAT characterization, SIP signals generated by the B2BUA media path optimization sequence also help to determine whether both clients on the call are tolerant of media redirection. Copyright © 2007 Ditech Networks 17/20
  • 18. Practical Far-End NAT Traversal for VoIP Since NAT characterization is performed after the call has been set up and media is being received by both parties, extreme care must be taken to avoid loss of media during the procedure. The Media Proxy should not disengage itself until a certain time has elapsed after media path optimization has completed, and both clients are sending media to the other party’s respective global address and port. If the Media Proxy ever detects an undesirable behavior on the part of the client or firewall, SIP signals should be generated by the B2BUA to inform the clients to revert back to the original media path. Additionally, there are other issues to be considered when media path optimization is executed. The B2BUA cannot simply attempt to globally optimize all calls. Some user agents do not react properly to media redirecting and will not send media to the redirected destination. There is also the issue of whether to have the parties who are apparently behind the same NAPT address send media to the respective ports on the NAT global address, or whether they should send media locally to each other. A significant percentage of NATs will not relay “hairpin media” using their global IP addresses. That is, two hosts on the internal side of the NAT may not talk to each other by using the global IP address of the NAT. On the other hand, redirecting the RTP flow to each party’s local address may not work well in the case where there is one party behind a second level of cascaded NAT calling a party located in a different cascading level. Such cases mandate disabling media path optimization for certain global addresses, or using slave media rendezvous points strategically located to minimize bandwidth wastage. In addition to resolving the NAT traversal issues, an SBC with a B2BUA can provide other benefits that are often critical to the VoIP network, such as: • Topology hiding • Protecting service from DOS attacks • Enforcing QoS policies • Ensuring end-to-end interoperability • Billing • Per-session troubleshooting • Lawful intercept Summary Most providers of IP telephony services believe that the experience of a user should mirror the ease of use and ubiquitous availability of the Public Switched Telephone Network (PSTN). Indeed, in many cases, the economics of providing service require that things “simply work” so that customer support expenses are kept to a minimum. Given the complexity of today’s NAT and firewall protected networks – both in residential and enterprise environments – this kind of ubiquitous reliability for VoIP can only be successfully provided with some help from a NAT traversal system. Again, driven mostly by economics, such a system must not require any special hardware or software on the users’ premises, and must not require either the service provider or the user to have any special knowledge of the topology of the network (or how its NAT and firewall components are to be configured). The goal of a NAT traversal system for real-world deployment must therefore be to solve users’ NAT and firewall problems remotely, and from the service provider’s network. Copyright © 2007 Ditech Networks 1/20
  • 19. Practical Far-End NAT Traversal for VoIP Many solutions involving remotely-located NAT helper appliances such as STUN, TURN, ICE, and UPnP have been pro- posed, but each can reasonably be deployed only in a subset of situations that is too small to be of practical use for a ubiquitous service. On the other hand, the Back-to-Back User Agent approach with its embedded Media Proxy works in virtually all situations, and meets the goal of not requiring any special and/or complex user premise installation. Acronyms B2BUA/MP Back-to-Back User Agent and Media Proxy ICE Interactive Connectivity Establishment ICMP Internet Control Message Protocol IP Internet Protocol NAT Network Address Translation PAT Port Address Translation PSTN Public Switched Telephone Network RTCP Real Time Control Protocol RTP Real Time Protocol SDP Session Description Protocol SIP Session Initiation Protocol TCP Transmission Control Protocol UDP User Datagram Protocol VOIP Voice over IP About Ditech Networks Ditech Networks is a global telecommunications equipment supplier for communications networks. Ditech Networks’ voice processing products serve the needs of mobile and wire-line operators for circuit- and packet-based networks. Ditech products include high-capacity voice enhancement and echo canceller solutions that utilize advanced software and digital signal processor (DSP) technology. This combination of software and hardware allows Ditech Networks to deliver Voice Quality Assurance (VQA™) technology, a robust and cost-effective solution for voice enhancement that includes both noise reduction and echo cancellation to provide improved sound quality on calls made over wireless networks. Ditech Networks’ VoIP products combine VQA technology with packet voice processing and security capabilities to enable carriers to deploy end-to-end VoIP services across network security boundaries without requiring network re-architecting. Ditech (Nasdaq: DITC) is headquartered in Mountain View, California, USA. Copyright © 2007 Ditech Networks 1/20
  • 20. Practical Far-End NAT Traversal for VoIP Corporate Headquarters US Sales – West Brazil Sales Office Middle East/Africa Sales Office Ditech Networks Ditech Networks Ditech Networks 825 East Middlefield Rd. Alameda Araguaia, 933 21 El-Fawakeh St., 3rd Floor Mountain View, CA 94043 Alphaville Dokki, Giza 12311 USA Barueri, SP 06455-000 Egypt 1-800-234-0884 (Toll Free) Brazil +20 2 336-5100 (Phone) 1-650-623-1300 (Direct) +55 (11) 4208-6266 (Main) +20 2 761-8964 (Fax) 1-650-564-9599 (Fax) +55 (21) 3521-5543 (Sales) MEA-Sales@ditechnetworks.com NA-Sales@ditechnetworks.com Brazil-Sales@ditechnetworks.com South-America-Sales@ditechnetworks.com Spain Sales Office US Sales Office – East and Central Ditech Networks Ditech Networks China Sales Office Torres Quevedo, 1 – (P.T.M.) 8360 Greensboro Dr. Ditech Networks 28760 Tres Cantos – Madrid McLean, VA 22102 Unit 3010, No. 500 Spain USA Xiangyang South Road +34 (91) 803 74 44 (Main) 1-800-234-0884 (Toll Free) Xuhui District +34 (91) 829 26 90 (Sales) 1-650-623-1300 (Direct) Shanghai 200031 Spain-Sales@ditechnetworks.com 1-650-564-9599 (Fax) PRC Europe-Sales@ditechnetworks.com NA-Sales@ditechnetworks.com +86 (21) 5456 0305 (Phone) China-Sales@ditechnetworks.com Canada Sales Office Ditech Networks South-East Asia Sales Office 2275 Lakeshore Blvd West, Suite 500 Ditech Networks Toronto, ON M8V 3Y3 Lippo Plaza 3rd Floor Canada Jl. Jend. Sudirman Kav. 25 1-416-255-7776 (Phone) Jakarta 12920 NA-Sales@ditechnetworks.com Indonesia +62 (21) 5291 3780 (Phone) +62 (21) 522 1977 (Fax) Mexico Sales Office SE-Asia-Sales@ditechnetworks.com Ditech Networks Torcuato Tasso 245-6o. Piso Col. Polanco South Asia Sales Office México, D.F. C.P. 11570 Ditech Networks México No. 8/11, Sarvapriya Vihar +52 (55) 5254-5422 (Main) New Delhi – 110016 +52 (55) 5350-8679 (Sales) India Mexico-Sales@ditechnetworks.com +91 9810372555 (Phone) South-Asia-Sales@ditechnetworks.com Copyright © 2007 Ditech Networks. All rights reserved. VQA is a trademark of Ditech Networks. All other brands are the property of their respective owners. 20/20 Specifications may change without notice. This document was last revised 02/07.