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 advanced. 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. A VoIP Providers network called N2Net, relies 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.