Our solution for this problem is a NAT Proxy NATPass™ designed to be a simple solution for VoIP service providers to deploy. It is optimized to release the RTP stream to endpoint SIP devices whenever is possible. When the RTP stream is not released to endpoints it continues to flow through the NAT Proxy together with signaling, causing additional bandwidth utilization. NATPass™ is a well-proven solution, which was designed to work as an intermediary between endpoint devices such as SIP phone devices and SIP Proxies without consuming much bandwidth. RTP stream released to endpoints is also beneficial because voice traffic can be flowing between two devices using the shortest available route. The other feature of NATPass™ is the ability to rectify SIP protocol bugs that appear in other vendor devices and software. NATPassTM is a pure software solution, which provides unlimited scalability at the lowest cost.
NATPass – IPTECHVIEW integrates a Scalable Far-End Cloud NAT Traversal for SIP Telephony
Selecting a Scalable Cloud NAT Traversal Solution
The NAT traversal problem as described in the next few paragraphs is still a real issue for many remote phone installations unless the company also deploys either a private VPN link (VLAN) or deploy an SBC (Session Border Controler). or an ALGs (Application Layer gateways) as their NAT traversing solution at each location.
IPTECHVIEW’S approach of “In the Cloud” FAR-END NAT TRAVERSAL or CLOUD SBC is the solution 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 that 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 a 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 asymmetric 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 an 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.
