Download Practical Far-End NAT Traversal for VoIP Whitepaper PDF

|
Practical Far-End
NAT Traversal for VoIP
March 2006
WHITE PAPER
|
Practical Far-End NAT Traversal for VoIP
Contents
Introduction. .............................................................................................................................. 3
Packet Admission Policy Problems................................................................................................ 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
Packet Admission Policy Modes........................................................................................... 3
/20
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
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 symmetrically 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.
Copyright © 2007 Ditech Networks
Figure 1: : Client-Side Signaling Asymmetry (Successful)
/20
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 firewall. 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
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
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
/20
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
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
Practical Far-End NAT Traversal for VoIP
Figure 8 : :NATandMedia-SecondExample
TheINVITErequeststhecalleetosendmediato192.159.1.11:16384,andthecallerstartslisteningonport16384for
incomingmedia.
NATfirewalls(withtheexceptionofFullConeNATs)disallowthecallee’smediapacketscominginbound.Thisisalso
anissuewithporttranslation.Forexample,whenthecallersendsmediaviaaNATtoacallee,theUDPstatecreated
intheNATmayhaveaportthatdiffersfromtheUDPportusedbythecaller.
TheSDPinformationembeddedintheoutboundINVITEhasaUDPportdeclared.Thisistheportfromwhichthe
callerwillsendmediaifitsendsandreceivesRTPmediasymmetrically.However,unlessthefirewallisguaranteed
nottoperformanyporttranslation,itisunlikelythatanincomingstreamfromthecalleetotheNATport(inour
example,portnumber16384)willbetranslatedandsentinboundtocalleeport16384.
IftheNATtypeismorerestrictivethanaFullCone,thequestionbecomeswhatthecallershouldsendacrossthe
firewalltocreatetheUDPstateentry(orpinhole)onthefirewall,suchthatincomingmediawillreachport16384.
IfthecallerknowsaheadoftimethatthecalleeisnotbehindaNAT,anditsSDPcanbetrusted,thenthecallercan
sendmediaassoonasa200OKisreceived(seeFigure 9onpage11).
Copyright © 2007 Ditech Networks
10/20
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
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
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
13/20
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
14/20
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
15/20
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
16/20
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
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
18/20
Practical Far-End NAT Traversal for VoIP
Many solutions involving remotely-located NAT helper appliances such as STUN, TURN, ICE, and UPnP have been proposed, 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
19/20
Practical Far-End NAT Traversal for VoIP
Corporate Headquarters
US Sales – West
Brazil Sales Office
Middle East/Africa Sales Office
Ditech Networks
825 East Middlefield Rd.
Mountain View, CA 94043
USA
1-800-234-0884 (Toll Free)
1-650-623-1300 (Direct)
1-650-564-9599 (Fax)
[email protected]
Ditech Networks
Alameda Araguaia, 933
Alphaville
Barueri, SP 06455-000
Brazil
+55 (11) 4208-6266 (Main)
+55 (21) 3521-5543 (Sales)
[email protected]
[email protected]
Ditech Networks
21 El-Fawakeh St., 3rd Floor
Dokki, Giza 12311
Egypt
+20 2 336-5100 (Phone)
+20 2 761-8964 (Fax)
[email protected]
US Sales Office – East and Central
Ditech Networks
8360 Greensboro Dr.
McLean, VA 22102
USA
1-800-234-0884 (Toll Free)
1-650-623-1300 (Direct)
1-650-564-9599 (Fax)
[email protected]
China Sales Office
Ditech Networks
Unit 3010, No. 500
Xiangyang South Road
Xuhui District
Shanghai 200031
PRC
+86 (21) 5456 0305 (Phone)
[email protected]
Spain Sales Office
Ditech Networks
Torres Quevedo, 1 – (P.T.M.)
28760 Tres Cantos – Madrid
Spain
+34 (91) 803 74 44 (Main)
+34 (91) 829 26 90 (Sales)
[email protected]
[email protected]
Canada Sales Office
Ditech Networks
2275 Lakeshore Blvd West, Suite 500
Toronto, ON M8V 3Y3
Canada
1-416-255-7776 (Phone)
[email protected]
Mexico Sales Office
Ditech Networks
Torcuato Tasso 245-6o. Piso
Col. Polanco
México, D.F. C.P. 11570
México
+52 (55) 5254-5422 (Main)
+52 (55) 5350-8679 (Sales)
[email protected]
South-East Asia Sales Office
Ditech Networks
Lippo Plaza 3rd Floor
Jl. Jend. Sudirman Kav. 25
Jakarta 12920
Indonesia
+62 (21) 5291 3780 (Phone)
+62 (21) 522 1977 (Fax)
[email protected]
South Asia Sales Office
Ditech Networks
No. 8/11, Sarvapriya Vihar
New Delhi – 110016
India
+91 9810372555 (Phone)
[email protected]
Copyright © 2007 Ditech Networks. All rights reserved. VQA is a trademark of Ditech Networks. All other brands are the property of their respective owners.
Specifications may change without notice. This document was last revised 02/07.
20/20