NAT Traversal for VoIP and Internet Communications using STUN, TURN & ICE
Increased penetration of broadband Internet is driving the adoption of voice
over Internet Protocol (VoIP) both for consumer and business markets, and
VoIP is now on its way to becoming the main mode of multimedia
communications in the coming years. High quality multimedia communications
along with rich presence, universal mobility and availability, and low cost
are some of the benefits VoIP brings to end-users. For operators, it
promises new revenues from new and converged services, service bundling,
increased customer loyalty, and lower capital and operation expenses (capex/opex)
by building and running a single IP-based network for all communications
Ironically, the main driving force behind VoIP adoption also poses one of
the biggest challenges - VoIP calls do not work well in many broadband
situations. In short, the problem is as follows:
- More than 90% of PCs or end-devices access the broadband service
using private IP addresses. These private IP addresses get mapped into
real Internet addresses using a mechanism called Network Address
Translation (NAT), which is implemented in all broadband access devices
(also called broadband routers) and sometimes again in the service
- Most users have one or more packet-filtering firewalls to protect
them from hacker attacks or malicious users on the Internet. Firewall
features are implemented in most broadband routers these days and also
in operating systems such as Windows XP and Vista.
- Most VoIP solutions in the market do not work well through NATs and
firewalls - callers may sometimes fail to connect to each other or the
quality and performance may be unacceptable.
In this white-paper we investigate the root-causes and challenges for the
NAT/firewall traversal problem for VoIP, summarize recent work and progress
made by standards-bodies and the industry on NAT traversal, and finally,
present a comprehensive solution to this problem comprising a client-side
SDK and a scalable carrier-grade server.
The NAT and Firewall Traversal Problem for VoIP
users connect to the Internet using broadband routers from various vendors,
such as Belkin, D-Link, LinkSys and NetGear. Users connect using wireless
hotspots at Internet cafes or hotels, which also use routers from vendors,
such as NetGear and SonicWall. Also, business users connect to the Internet
using firewall products such as Cisco PIX, Juniper NetScreen, and CheckPoint
FW1. Businesses sometimes also set up web-proxies such as Squid or Microsoft
ISA for accessing the Web by their employees. Now suppose all the users
behind all of these NAT and firewall devices/solutions want to make VoIP
calls between each other. Will all of these calls work using traditional
VoIP technologies? The answer is no. Most VoIP calls will not work through
these NATs and firewalls. This is referred to as the NAT and firewall
traversal problem - or simply the NAT traversal problem.
Recently, there have been a lot of mobile phone products with Wi-Fi VoIP
features (single-mode Wi-Fi or dual mode cellular plus Wi-Fi). According to
Infonetics Research, the number of Wi-Fi phones will double or triple each
year until 2009 reaching a worldwide market of $3.7 billion . Now
suppose a lot of users have these Wi-Fi phones, and they move around with
these phones to use them from wherever they are - at homes, Internet cafes
and offices. They will not only face the same NAT traversal problem, but
worse, their connections and thus their network configurations, may change
frequently. This further emphasizes the NAT traversal problem as it will
severely limit user capability to communicate.
The NAT/Firewall Traversal ChallengeHomes and businesses are increasingly installing intermediary devices
between their computers and their Internet connections. These devices -
usually routers - provide a number of capabilities, with the most common
being that of a NAT (Network Address Translation) and/or a firewall.
NAT traversal is complicated by many contributing factors:
- NATs break VoIP protocols
The idea of a NAT is to allow several devices to share a single public
IP address. Figure (2a) shows how a router connects several hosts using
private IP addresses to the Internet using a single public IP address.
The router allows these hosts to access the public Internet by modifying
each IP packet to and from these computers by using a two-way mapping
between private IP addresses and transport ports to the router's public
IP address and transport ports. The rewriting of addresses by the NAT is
usually performed using a lookup table, where mappings between internal
address/port pairs and external address/port pairs are stored.
This technique facilitates sharing a single public IP address among many
hosts that use private IP addresses. However, this technique imposes a
few problems for VoIP calls. Figure (2b) shows the problem when Carol
makes a VoIP call using SIP from behind her NAT device. To establish the
call, Carol needs to share the IP address and a UDP transport port where
she will receive voice data. However when Carol uses the private IP
address and local UDP port to receive voice for the SIP call, voice
packets from the remote party connected to public Internet will never
reach Carol because private IP addresses are not routable in the public
Internet. Another property of NATs is that the port mapping is kept only
if there is traffic in both directions. For example, if Carol is in a
call with Ellen, and for a while only Ellen talks (i.e. Carol does not
send any packets to Ellen), then Carol's NAT may close, which
effectively terminates the call.
- Firewalls do not allow uninvited packets and close inactive
The main purpose of a firewall is to protect an internal network from
unauthorized access by entities on external networks. Firewalls normally
allow incoming traffic from external hosts only if the session was
initiated from the internal network. Therefore, incoming calls, coming
from applications on un-trusted external sources, are filtered out by
the firewall, and the application fails to establish connection between
the end users. Firewalls are not only present in most routers, but are
also available in most modern operating systems (e.g. Windows firewall
in Windows XP).
Figure (2c) shows the problem as described above. The firewall allows
media from Ellen to reach Carol, because Carol initiated the call.
However, the incoming call from Dave could not pass through the
firewall, as no data packets were sent to Dave from Carol. Therefore,
the call between Carol and Dave fails to establish. A firewall can,
however, be configured in any number of ways, such as only allowing TCP
traffic out to the public Internet and preventing the use of UDP.
- Cascaded NATs
NAT configuration may be cascaded. This issue is similar to the first
problem, except that it has one more level of complexity. In this
scenario, one router is connected to the Internet using public IP
addresses, and provides a private IP address to a second set of routers.
Each of the second set of routers may itself provide separate private IP
addresses to one or more hosts. For VoIP, the challenge here is for any
host connecting to any of these routers may call each other, or it may
also call any other host in the public Internet (or behind yet another
router in another location).
- UPnP gateways expect application control
Sometimes residential routers expect application control using the UPnP
protocol to access the Internet. If UPnP is enabled on a router, which
is the default case for many Asian countries such as Japan and Korea,
the VoIP application needs to speak with the device to enable sending
and receiving of data from the Internet.
- Enterprise firewalls block UDP and sometimes enforce
Most businesses or enterprises use strong firewall rules where UDP is
usually blocked. Thus all communications need to use TCP transport. In
some the cases only Internet communications that these businesses allow
is browsing the Internet through some web-proxies (such as Squid or
Microsoft ISA). In such environments, VoIP calls cannot use UDP, and
therefore need to use TCP transport or HTTP-tunnelling.
While NATs/firewalls play a very important role in securing and enhancing
the usability of an internal network, they impose a significant problem in
setting up VoIP calls between end users. Application developers cannot make
assumptions about how traffic would pass into or out of these private
NAT Traversal Solution Requirements
We have seen how NAT/firewalls present a challenge to VoIP call completion.
There are different kinds of NATs/firewalls in use, each of
which may be set up differently, making VoIP calls difficult to complete.
A typical solution to the problem described above is that a VoIP application
will require a range of specific port numbers to be left open in the
firewall. This approach introduces a severe security risk because an
intruder, with knowledge of these open ports, can create malicious software
to take advantage of the fact that the firewall is letting traffic in
through the open ports. Leaving ports open defeats the purpose of installing
a firewall in the first place.
Another problem with opening ports is that manual configuration is required
by end-users or network administrators. Home users often lack the necessary
technical knowledge to correctly make this adjustment, or may even be unable
to do so if their ISP controls their firewall product, as is the case with
certain cable and DSL service providers. For internal users, their network
administrator may also be unable, or more likely unwilling, to open the
required ports that the VoIP applications need to function properly. Either
way, users are required to take extra steps to enable end user
communications and, more often than not, will give up in frustration. Some
key features that are expected from a NAT traversal solution include:
- Guaranteed call completion with maximized peer-to-peer calls: The
solution must ensure 100% call completion rate between users, regardless
of the NAT/firewall types used. Moreover, it needs to maximize
peer-to-peer calls in order to reduce load on relay servers.
- Security: The NAT traversal solution must not compromise the
security settings of the NAT/firewall.
- Ease of integration with existing products or services: It is vital
for the NAT traversal solution to be easily integrated with existing
VoIP products or services, with minimal amount of work and time.
- Standard compliance and interoperability: The solution must
interoperate with equipment from different vendors. Therefore, the
solution must be based on some standards to ensure successful
communication between devices with different settings.
- Service scalability: The solution needs to be scalable so that it
can be used for a large number of participants.
- Optimized call completion time: The solution needs to make sure that
the calls are established in a reasonable amount of time.
Solving the NAT Traversal Problem
To solve the NAT traversal problem, the industry has attempted a few
- Application Level Gateway (ALG): An ALG acts as a protocol-aware
firewall, monitoring traffic and permitting traffic flows for specific
applications. This solution, however, does not ensure security or
authenticity, and is difficult to deploy.
- Session Border Controller (SBC): An SBC addresses some of the
problems that ALGs fail to resolve. However, this solution is not
scalable for large numbers of concurrent calls. Moreover, it introduces
additional delay and packet loss with the ultimate consequence of
inferior end-user experience. Since SBCs use proprietary methods for NAT
traversal, they do not work with SBCs from other vendors and/or third
- IETF STUN, TURN and ICE: The IETF (Internet Engineering Task Force)
has devised a suite of protocols, namely STUN (Session Traversal Using
NAT), TURN (Traversal Using Relay NAT), and ICE (Interactive
Connectivity Establishment), to address the limitations of the
currently available NAT traversal solutions. STUN allows the
applications discover the public IP address and port mappings that the
applications can use to communicate with its peer. TURN, on the other
hand, allocates a public IP/port on a globally reachable server and uses
it to relay media between communicating parties. ICE is a framework that
defines how to use the STUN and TURN protocols to solve the NAT
traversal problem, by choosing the best possible interconnection method
between two users. Since ICE incorporates STUN and TURN methods,
sometimes ICE is also used to refer to the complete STUN, TURN, and ICE
already received widespread support and adoption. Leading vendors including
Microsoft, Cisco, Nortel, Lucent Alcatel, Huawei, Avaya, Juniper, Tanberg,
Tekelec, Nokia, and Sony Ericsson have adopted ICE for NAT traversal.
CableLabs, the technology consortium of cable system operators who are also
the largest VoIP operators in USA, has also incorporated ICE support into
the CableLabs IMS specification for next-generation communications
How ICE Methodology Works
In this section we assume that calls are established and controlled with
SIP ; however, call completion can work with any appropriate rendezvous
a call starts by sending a SIP INVITE message with an SDP describing on
which IP address(es) and port(s) the application can receive audio and/or
video packets. These addresses and ports are known as candidates. Candidates
are obtained from the AnyFirewall Engine and are inserted into the SDP of a
SIP INVITE message, which is sent to the callee.
Specifically, a candidate is an IP address and port by which one peer can
communicate with another for the purpose of sending media. A candidate can
include a peer's public IP address, an IP address of a NAT device that it is
behind, or an IP address of a relay server that forwards traffic to/from the
There are 3 types of candidates:
- Local candidate: a local IP address of the client.
- Reflexive or STUN candidates: an IP address of the client's NAT
(assuming they are only behind a single NAT). These are determined from
another entity, and then communicated back to the client.
- Relay or TURN candidate: an address on a relay server that has been
allocated for use by the client.
Traffic can always be sent successfully using relay candidates, unless a
firewall blocks all traffic from the client, in which case no legitimate
firewall traversal technique can ever work. The problem with using relay
candidates, however, is that they require server resources, and relayed
traffic introduces delays in the traffic stream.
We now describe how ICE methodology works for SIP-based calls.
- Caller gathers transport candidates
The caller determines its server reflexive
and relay candidates for a connection. The client sends an ALLOCATE
request to the server, which instructs the server to allocate an IP/port
on the server (the relay candidate). Upon successfully allocating the
relaying address for the client, the server returns the caller's IP/port
as seen by the server (the client's server reflexive candidate). The
reflexive candidate contains the public address that the client is
using, which is usually the address of a NAT that the client is behind.
Due to the way NAT works, other peers will be able to contact the client
on the address defined by this discovered relay candidate.
- Caller sends a SIP INVITE
After gathering the candidates, the caller encodes them in the call
setup message (e.g. a SIP INVITE) and sends
the message to the called party.
- Callee gathers transport candidates
Upon receiving the SIP INVITE, the called party also gathers its
candidates in the same manner as the caller in step 1.
- Callee sends SIP 1xx response
In response to the SIP INVITE, the callee sends its ICE
candidates within the SDP of a SIP provisional response, such as a SIP
183 (Session Progress), to the caller. The message should be sent
reliably (i.e. with retransmission), and should not be considered
successfully sent until either a 200 OK is received in acknowledgement,
or a connectivity check from the caller is received by the callee, as is
described in the next section.
- Both conducts ICE checks
Once the callee has sent its ICE candidates, and once the caller
receives them, they each start performing ICE connectivity checks. At
this point, both parties know about their peer's potential candidates.
Each possible pair of local and remote candidates is formed, creating a
number of candidate pairs. A connectivity check is done by sending STUN
messages from the local candidate to the remote candidate for each pair,
starting with the highest priority (i.e. most preferred) candidate pair
first. Both parties exchange STUN messages in this way to determine the
best possible candidate pair that they can use to communicate. Once a
valid (i.e. successful) message has been sent both ways on a single
candidate pair, the connectivity check may stop and media can be
sent/received using that candidate pair.
- Callee sends SIP 180 ringing
A 180 RINGING message is sent to the caller after the
connectivity checks are completed, signalling that the callee's phone
has begun ringing. Ringing the callee's phone happens now, after
signalling is complete, so that there is no delay in receiving audio
once the phone is picked up.
- Callee sends SIP 200 OK to invite
If the user accepts the call, the callee sends a final response
to the caller (200 OK).
- Caller sends SIP re-invite
If the candidates chosen differ from the original connection
candidate put into the media and connection lines of the SDP of the SIP
message (i.e. the candidate chosen differs from the one thought to have
worked), then a new SIP INVITE message is sent to the callee with the
agreed upon candidates in the m/c line of the enclosed SDP message
- Callee sends SIP 200 OK to re-invite
If a re-invite is sent, then it must be acknowledged, which is
done with a SIP 200 OK message.
- Caller sends SIP ACK
A final acknowledgement is sent from the caller to the callee
indicating the completion of the call setup.
11. Voice/video media transfer successful
Now that the call has been established, both caller and callee can send
media to/from their successful candidate addresses. (Usually using RTP
Eyeball AnyFirewall Technology
Eyeball has developed AnyFirewall Technology to ensure seamless traversal of
media across different NATs, firewalls, UPnP gateways, & web proxies. This
comprises of two products:
- AnyFirewall Engine (AFE) - the industry's leading firewall and
traversal SDK offering the most comprehensive implementation of STUN,
TURN and ICE.
- AnyFirewall Server (AFS) - a
carrier-grade STUN and TURN server
ready for licensing and mass deployment.
Here are a few highlights about Eyeball's NAT traversal solution:
- Developed using industry standard protocols: IETF standards of
STUN-bis10, TURN-04, ICE-18, ICE-TCP,
nat-behaviour-discovery-01 and UPNP.
- 100% call completion: In addition to implementing ICE for
NAT/Firewall traversal, UPnP and HTTP Proxy tunneling are provided to
ensure 100% call completion.
- High peer-to-peer call completion rate: More than 95% of calls are
completed peer-to-peer in UDP-enabled networks.
- Small SDK footprint: The standard footprint is less than 300kB, but
smaller footprints are available for embedded devices and other
environments where available memory is limited.
- Multiple platforms: AFE is available on Windows, Linux, MacOS, with
other platform support available upon request.
- Easy to integrate: The AFE socket API is based on the standard
Berkeley socket API, which is used in most operating systems. This
allows AFE to be integrated quickly into existing products.
- Complete solution: The AnyFirewall Server (a standards-based
STUN/TURN relay server) and the AnyFirewall Engine (a standards-based
ICE client) provide a complete solution for NAT traversal.
- Service scalability: A single AnyFirewall Server supports more than
10,000 concurrent calls, with more calls supported by simply adding
- Product maturity: Eyeball has been a leader in NAT traversal
solutions for over 5 years. Our products are field tested by millions of
end-users all over the world.
Eyeball AnyFirewall Engine
AnyFirewall Engine provides a feature-rich NAT traversal SDK for
application developers and device makers. Here are a few technical
- Most comprehensive implementation of STUN, TURN, and ICE, plus
optional features such as UPnP gateways and HTTP tunneling through
- Automatic selection of transport modes (UDP or TCP), and transparent
translation of UDP to TCP when using TCP relaying.
- Supports symmetric RTP and smart keep-alives for signalling and media
- Multiparty calls with hybrid UDP, TCP and HTTP streams.
- Traversal for voice, video, instant-messages and file-transfer.
- Minimized call completion time by pre-fetching and caching
- Simple C/C++ API familiar to TCP/IP socket programmers.
- Works with 3rd party SIP/XMPP stacks & voice/video engines.
- PC and embedded system support including Microsoft Windows, Linux,
and Windows Mobile.
The rich set of APIs offered by AFE enable developers to write VoIP or
other peer to peer applications without the concern of firewall traversal
problems. AFE integrates with third party application
protocol stacks and media engines as well.
Eyeball AnyFirewall Server
The AnyFirewall Server is a carrier-grade server for NAT/Firewall discovery,
signalling and media relay based on STUN and TURN IETF drafts. Here are some
of the features of the AnyFirewall Server.
- The first standards-based NAT and firewall traversal server for
VoIP. It incorporates STUN, TURN, supports HTTP tunneling as a fallback
and supports traversal of media and signalling including voice, video, IM
- Provides scalable firewall traversal for large deployments by
completing most calls use peer-to-peer media transport, using load
balancing based on DNS SRV lookup and supporting more than 10,000
concurrent calls per CPU.
- Interoperable with third party clients and end-points, and SIP
servers from Cisco, Huawei, Nortel, Tekelec and Ubiquity.
- Supports wiretapping of calls by forcing relay usage for certain
using (for CALEA requirements).
- Ready for deployment in IMS infrastructure (stand-alone server or
integrated into CSCF).
- Runs on standard Linux systems (Standard PC or carrier-grade
- Easy to set up using either text-based configuration; interactive
command line interface; or web-based provisioning, monitoring, and usage
AnyFirewall Engine and the AnyFirewall Server, together,
provide a comprehensive solution meeting all the requirements for solving
the NAT/Firewall Traversal problem.
VoIP Call Example Using the AnyFirewall Technology
Eyeball AnyFirewall Engine uses the concept of channels to simplify
application programming. Each channel is accessed via a set of functions similar to the
socket API. Like sockets, each channel represents an endpoint for sending
and receiving data. However, channels hide the underlying complexity
required for the firewall traversal process, such as the STUN, TURN, and ICE
functionality. To make adding the functionality of AFE to an existing
application easy, calls to the socket API are replaced with similar AFE API
calls. For example, to send and receive data using AFE, an application calls
the Send() or Recv() on a channel, instead of using the send() and recv()
functions of the socket. Furthermore, AFE provides the Select() function for
channels, which models the behavior of the socket API function, select().
API calls that take place on the caller
and callee user agents in order to establish a call. Once a call is completed, the usual Send(), Recv(), and
Select() functions are used, as in standard socket API
Conclusion NAT devices and firewalls are major barriers to widespread adoption of VoIP,
and IETF work STUN, TURN, and ICE provide an excellent methodology to
address this issue. Unfortunately, ICE is a very complex methodology.
Internet engineering experts at IETF have taken more than 6 years to develop
it. Real implementation requires considerable insight and experience to get
it right. Eyeball has invested many years to develop its technology, and its
NAT traversal technology has been field-tested for more than 5 years. If you
want to integrate ICE in your products and services, and are working with
time-to-market and development cost constraints, getting the NAT traversal
solution from technology experts at Eyeball may be your best option.
Otherwise you may risk going into a prolonged cycle of development which may
cause your project to go out of budget and delay your product launch.
Eyeball provides comprehensive and award-winning NAT-traversal solutions
comprising two products: (a) AnyFirewall Engine - a feature-rich NAT
traversal SDK incorporating ICE, and (b) AnyFirewall Server - a
carrier-grade STUN and TURN server. VoIP application developers, device
makers, and service providers can now integrate and deploy these solutions
into their products in order to guarantee VoIP and video call completion
across NATs, firewalls, and web proxies.