Updated July 2018
When dealing with VoIP traffic on today’s networks it is inevitable that you will run across an issue involving NAT and SIP. It is helpful to understand what NAT (Network Address Translation) does before you see why this causes a problem with SIP (Session Initiation Protocol).
The NAT Process
When your computer makes a request for a resource out on the public internet, that request will have a source address consistent with the local LAN addressing scheme. That’s not an issue until the public resource tries to use that information to send data back to you.
That local network address will not be publicly routable due to the fact that the LAN is using a private IP addressing scheme (typically 192.168.x.x or 10.0.x.x.). NAT attempts to fix this by replacing the local source IP address with an IP address which is routable on the public internet, hence the “translation.” NAT is translating a private IP to a public IP.
For protocols that do not embed address information into the payload of the data packet, NAT works just fine. That’s not what SIP does.
The SIP Issue
Let’s look at a SIP INVITE request from a phone on a local network:
As you can see from all the underlined IP addresses, the local IP address frequently appears in the payload of the SIP message. The NAT device on this network is going to replace the local source IP address with a publicly routable source address, but only for the IP header on this packet.
When the provider’s VoIP equipment sees this packet, it may be OK and route a response back as needed. The problem arises is in the second half of the payload – at the SDP (Session Description Protocol).
The two VoIP devices will use the SDP information in the INVITE and OK SIP methods to negotiate a path over which the audio stream will travel. Take a look at the second from the last underlined IP address. That’s telling the provider’s VoIP equipment where to send the audio for this call, which is problematic. The provider’s VoIP equipment cannot route the private 192.168.1.179 address across the internet which means this call, if left as is, will result in ‘no audio’ or ‘one way audio.’ This is a common complaint when NAT is causing problems on a VoIP network.
Overcoming the SIP/NAT Issue
IP phone systems today are pretty smart. Most have a provision which lets them know they are behind a NAT device. The phone system will actually replace all the instances of local (private) address with the public address of the NAT device before sending the packet to the NAT device to be forwarded on to the VoIP Providers network.
Another option used to address SIP/NAT issues is to implement what is called a SIP aware firewall/router. This feature of a firewall / router is commonly referred to as a SIP ALG (Application Layer Gateway). These devices are able to rewrite SIP packets with the correct IP address information as the traffic flows through them. Some SIP ALG’s can be problematic, but with the right tweaking, can be made to do exactly what you want. At N2Net, we rely on the Edgewater Networks Edgemarc device to deal with NAT issues in complex client infrastructures. Example deployment using the Edgemarc devices will be a topic of later blog posts.
Partner with Voice and Data Experts
As a full service voice and data provider, N2Net engineers are experienced in dealing with complex NAT issues with VoIP. In addition, N2Net manages its own VoIP network and can guarantee your speed as well as call quality on VoIP applications utilizing dedicated connections. To learn more about how you can N2Net specialist today.
