Selecting a scalable NAT Traversal Solution

The NAT traversal problem as described in the next few paragraphs is still a real issue for most people unless the decide to deploy devices over a VLAN or deploy ALGs (Applicatio Layer gateways) as their NAT traversing solution at each location.

 "In the Cloud" Network Address Translation (NAT) or SBC are being used by most Tier 2 service providers as the most cost effective way to get around the problem of not having enough IP addresses. NAT traversal refers to an algorithm to the common problem in TCP/IP networking of establishing connections between hosts in private TCP/IP networks which use NAT devices. Many techniques exist, but no technique works in every situation since NAT behavior is not standardized.

NAT traversal is a challenge that all Service Providers looking to deliver public IP-based voice and multimedia services must solve. The challenge is to provide secure connection to subscribers behind NAT devices and Firewalls.

In order to determine the NAT mapped public IP:port there are two possible methods:

• The first is to ask the NAT. A client can ask the NAT how it would map a particular IP:port through a protocol called Universal Plug and Play (UPnP). This is a solution that is being pushed by Microsoft. One problem with UPnP is that it will not work in the case of cascading NATs.
• The second is to ask someone outside the NAT. The best way for a client to determine its external IP:port is to ask a server sitting outside the NAT on the public Internet how it sees the source of a packet coming from this client.

Simple Traversal of UDP Through NATs (STUN) is a protocol for setting up a server outside the NAT. Unfortunately STUN will not work in the case of symmetric NATs, since the IP address of the NAT probe is different than that of the endpoint. In the case of a symmetric NAT, the client must send out RTP to, and receive RTP back from the same IP address. If an endpoint supports Connection Oriented Media, then the problem of symmetric NAT traversal is solved.

Traversal Using Relay NATs (TURN) complements STUN and places the probe in the signaling and media path. The probe in essence terminates the media for both ends so that vis-à-vis the client the same probe that detected its address:port pair in the first place is also the probe that is sending the client media so the symmetric problem is taken care of. But, QoS and Security requirements at the entrance to the network limit using a TURN like approach since relevant SIP session information is not exposed in the TURN protocol.
 

Finally, the additional complexity in the client associated with both STUN and TURN has led to the fact that to date only a handful of vendors have integrated these capabilities in their clients (User Agents).

One solution for NAT Transversal and the most successful method that solve all types of NATs is to have an RTP Relay in the middle of the RTP flow between endpoints. There would be a server in the middle of the SIP flow (herein called a NAT Proxy) that would manipulate the SDP in such a way as to instruct the endpoints to send RTP to the Relay instead of directly to each other.

Our solution for this problem is a NAT Proxy NATPass^TM designed to be a simple solution for VoIP service providers to deploy. It is optimized to release RTP stream to endpoint SIP devices whenever is possible. When RTP stream is not release to end points it continues to flow through the NAT Proxy together with signaling, causing additional bandwidth utilization. NATPass^TM is a well proven solution, which was designed to work as an intermediary between end point devices such as SIP phone devices and SIP Proxies without consuming much bandwidth. RTP stream released to end points is also beneficial because voice traffic can be flowing between two devices using the shortest available route. The other feature of NATPass^TM is the ability to rectify SIP protocol bugs that appear in other vendor devices and software. NATPass^TM is a pure software solution, which provides unlimited scalability at the lowest cost. 

Maritza

Credits: The Technical Concepts at the beginning of this article were para phrased or copied from the White Paper NAT Traversal in SIP from David Schwartz & Baruch Sterman, Ph.D