VoIP NAT: Difference between revisions

Revision as of 15:25, 14 November 2020

You have probably been directed to this page because you are having trouble with Voice over IP services (using SIP) when using a router or firewall which does some sort of Network Address Translation (NAT). This page tries to explain some of the issues, and why it is often a problem.

NAT is not officially supported, but generally can be made to work. Due to the nature of NAT, and the numerous implementation and 'fixes' and 'bodges' in routers, it can be tricky to get working. Lots of the phones that we've tested do just work without the need for an ALG, Stun, Port Forwarding etc., but other network equipment (i.e. the router) may get in the way.

We'd always suggest using public IP addresses for VoIP devices.

The Technicolor broadband routers we used to supply with Home::1 provide a full SIP/NAT ALG which means they work such that neither the phone nor our call server know NAT is in use. This appears to be a well implemented ALG and just works.
Using a FireBrick FB2700 providing NAT has no ALG and does simple dynamic port forwarding of outgoing UDP connections with a default timeout of over 2 minutes. This also just works as the call server recognises the NAT and sends one minute keep-alive packets to hold the NAT session open, as well as sending symmetric RTP response packets.
Other cases where testing has been done have usually required one or other approach, and in some cases required "NAT assist" to be disabled on phones or routers to allow the correct operation.
SIP and NAT requires the call server, NAT device and phone to all play nicely and can still mean problems. There are a few specific cases we have tested and found reliable, but we cannot guarantee it will work in all cases or without some specific configuration settings

NAT Tips

If you do want to use NAT, then here are some tips if you are struggling:

Disable UPnP on routers
Disable SIP ALG on the router (or try enabling) See Disable SIP ALG
If the VoIP phone has a config setting to enter your external/public IP address, then enter the address of your router's WAN port
Disable Stun settings on the VoIP phone, or try enabling it - stun.aa.net.uk can be used as the server name
Enter firewall rules on the router to allow UDP traffic from our VoIP servers to your VoIP phone. See VoIP Firewall

If you have 2 similar VoIP phones behind a router using NAT, you will have to change the port settings on one phone. The local SIP port (often 5060) and the local RTP port(s) can't be the same on the 2 phones - if they are the same, you'll get weirdness on incoming calls.

If NAT works, then well done, but if not we cannot guarantee to be able to make it work. We can provide broadband lines with constant quality monitoring and public IPs that can be used for VoIP - even multiple lines through different back-haul suppliers for extra resilience. Do speak to us.

NAT is not officially supported, but generally can be made to work.

How does SIP work?

VoIP using SIP has a control channel, which is used for registering with the VoIP server and for initiating outgoing calls and notification of incoming calls. The VoIP server normally listens on UDP port 5060. When a call is being setup and when the call is active, an additional audio channel is used.

When your VoIP phone places a call, a message is sent on a control channel - this will conventionally be to the VoIP server's IP address on port 5060. Your VoIP phone will use a fixed local SIP port number - this is remembered by the VoIP server because it's where incoming call messages will be sent to. When the call is being setup, the two ends of the link have a conversation to agree on how to do the audio link (and video link too, if supported). The two ends of the link will agree on audio codecs to use (how the audio will be transmitted), and each end tells the other end where to send the audio packets to. The audio travels on a different channel from the control channel (using Real Time Protocol - RTP), and your VoIP phone will send something like "send your audio to this IP address, I'm listening for RTP on (for example) port 5012". Each end agrees, and you have a successful phone call.

An incoming call works the same way. It's important to note that the VoIP server will send control messages to your local SIP port, and your firewall connection tracker may have timed out the connection to the control channel if you haven't re-registered recently, or made an outgoing call recently - you either need to provide firewall rules to accept this control channel traffic, or send SIP Keep-Alives every (say) 120 seconds.

Here's an (edited) SIP trace of an outbound call being setup from 02083xxxxxx to 07973xxxxxx. The phone on public IP address 81.187.xx.xx sends:

INVITE sip:07973xxxxxx@voiceless.aa.net.uk;user=phone SIP/2.0
From: "aaisp" <sip:+442083xxxxxx@voiceless.aa.net.uk>;tag=xidd3faqpi
To: <sip:07973xxxxxx@voiceless.aa.net.uk;user=phone>
Content-Type: application/sdp

o=root 1510857313 1510857313 IN IP4 81.187.xx.xx
c=IN IP4 81.187.xx.xx
m=audio 5010 RTP/AVP 9 0 8 3 99 112 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

The bold text shows the IP address and port number that the phone is listening on - telling the far end where to send audio.

The server replies:

SIP/2.0 100 Trying
...
SIP/2.0 183 Session progress 
From: "aaisp" <sip:+442083xxxxxx@voiceless.aa.net.uk>;tag=xidd3faqpi
To: <sip:07973xxxxxx@voiceless.aa.net.uk;user=phone>;tag=2020111412411300003
Server: FireBrick/1.54.153
Content-Type: application/sdp

o=- 31466 0 IN IP4 81.187.30.118
c=IN IP4 81.187.30.118
m=audio 31466 RTP/AVP 8 101
a=rtpmap:8 pcma/8000

So again the bold text tells the phone the IP address and port number to send the audio to.

The section below on "Why is SIP a problem" explains how NAT breaks things.

Why is NAT a problem with SIP?

SIP services we supply

The VoIP services we supply are designed to operate using internet protocol (IP) in the way it was designed - this means that your equipment has an IP address to which we can send packets, and when we send packets to its IP address - they get there. This is pretty fundamental to the way the service works. If you have something in the way that breaks that logic, whether it is something in the ISP you are using or something in the router or firewall you are using, then that could stop the service working. That is not our fault. We do not claim to support SIP over any sort of NAT in any way whatsoever. If you want to know why, read on.

Broadband/internet services we supply

We supply a broadband/internet service which can have fixed real IP addresses for your equipment, both legacy IP (IPv4) and current IP (IPv6). At present there is no reason for you to use any sort of NAT on your broadband service from us. Even when we are no longer able to provide legacy IP addresses for all your machines (which will happen) we are able to provide as many IPv6 addresses as you need.

If you choose to use NAT on your broadband/internet service, then that is up to you - but don't blame us if some things (like SIP) don't work well. It is your choice.

Routers and firewalls we supply

We supply various equipment. Usually it is equipment made by third parties, such as ZyXEL, Billion, etc. They will often include features such a NAT in the equipment, which you can use. NAT is not something that has a defined standard to which it works - it is a bodge, and so the quality of the NAT features in such equipment is not something we can guarantee. We supply them as is in that respect, and you are welcome to ask the manufacturers for details of what they do with NAT before you purchase (but don't expect a detailed reply). Our recommendation is, as always, not to use NAT at all. Using any sort of NAT, whatever the manufactuters claim, is likely to cause problems with some protocols, especially SIP.

We also supply FireBrick firewall/routers. These do allow basic IP and TCP/IDP port mapping if you want, and as such can provide basic NAT features. In the case of the FireBrick there are specifically no ALGs (Application Layer Gateways) and any NAT or mapping is purely at the TCP/UDP level. You can configure timeouts for sessions in the configuration for FireBricks which can help. Again, our recommendation is, as always, not to use NAT at all. If your VoIP devices have fixed IP addresses then firewall rules on a FireBrick are simple to set up to allow correct SIP operation.

NAT is evil

We could go on about the evils of NAT - but suffice to say that it is a bodge. It breaks the fundamental design principles of IP. It came about almost by accident as a way of handling multiple devices when people moved from using one PC with a modem to a small network in their home. It served a vaguely useful purpose in that respect allowing some internet connection sharing which works for some things (web pages, email, etc.). However, it has a lot of problems. Many devices that do NAT also have ALGs (Application Level Gateways) which assist the NAT by tinkering with the packets as they go through in complex ways where the devices understands the higher level protocol. There are devices that do a reasonal job at this even with NAT. Even so, expecting this to work is pot luck as NAT and especially NAT ALGs are not built to any standard or even well documented. They work in some cases and not others.

Why is SIP a problem

Consider a simple access to a web site - your machine (behind NAT) makes a connection to a web server and requests a page which is sent in that connection. The connection (using TCP) can be NATted easily allowing two way data flow and allowing the web page to be received.

However, telephony is different. For a start the process is broken in two - signalling and media. This means the "connection" to establish a call is different to the actual audio that makes up the call. When the signalling sets up the call it says where to send the audio (see the above SIP trace) - except it will be saying (for example) "send it to 192.168.1.124" (i.e. a NATted address). That won't work because that is a private IP address and not reachable from the Internet.

There are three answers to this problem:

Tell the phone what its externally visible (public) IP address is. Some phones allow you to enter this in the configuration. If not, you can use a STUN server - which tells the phone what its externally visible IP address is, and attempts to tell the phone about the firewall it's behind. You can use stun.aa.net.uk as the STUN server.
Rely on the modem/router having an Application Layer Gateway (ALG) which will rewrite the packet to change the private IP address to the modem/router's externally visible IP address. And which does it properly - the challenge is that it's often very difficult to see what the ALG has done to the packet (need to be able to look at packets going down the phone line).
The call server can break the SIP specification and wait for the audio to come from the device and send its audio back to the same place - i.e. allow the phone to make an outgoing connection for the audio first. The SIP standard does not work like that, and indeed there is no requirement for the phone behind NAT to expect its audio to come back to the same IP and port from which is sends it. Of course many phones do this as it happens, and they might work in such cases, but some do not and they don't work. You have no way to tell when buying a phone, or upgrading its software. It is quite valid for the phone to stop working with your NAT and still meet the standard for SIP. Of course, as a user you have no control over how the call server works.

The other big problem is telephone calls are both ways - you don't just make calls but you receive them. This means the phone registers where it is. I.e. it sends a message saying "I can be reached on 192.168.1.124", which won't work. Now, again, some call servers will break the SIP standard, ignore the actual stated connection details and assume calls can be sent to the IP and port from which the registration came. This may work as long as the session that did the registration is still active on the NAT device. The device will have a timeout. It could be seconds, minutes, hours - no way to tell on most NAT devices. So that means incoming calls work some of the time (within X seconds of the last periodic registration message). Now, some call servers will send a dummy message every few seconds to keep the session active. Some phones may do that. They are both guessing what the NAT device does with timeouts, and may guess right. This is, of course, non standard for phone and call server to do. It's all very well for the phone to be listening on, for example, port 5060 for control messages ("incoming call") and ports 5008 - 5012 for audio - but if the firewall doesn't know about these listening ports the call isn't going to succeed. The best solution is to have firewall rules which allow VoIP packets from the AAISP VoIP servers - see VoIP Firewall

Of course, the NAT device may have an ALG which changes the SIP messages sent, and so changes the "I can be reached on 192.168.1.124" to be something sensible. A good ALG can mean the call server and phone do not need to break the rules at all. But the NAT device may well not understand all SIP messages or all syntax variations, so may work with some phones and with some call servers, and may even work only some of the time. No way to tell.

The fact that you may need non standard operation of the call server, NAT router, and VoIP phone in order to get SIP over NAT to work, and the exact non standard workings of all three is unlikely to be documented at all by any of the suppliers, makes it a bit of a gamble. Generally, anyone getting SIP working over NAT is rather lucky, and the situation will probably stop for no good reason one day because of a change on one of those three devices.

It is not uncommon for various levels of brokenness:-

Not working at all
Setting up calls but one way audio
Making calls but not receiving them
Able to receive calls only some of the time
Working perfectly some of the time, and not others
Stopping working one day with no apparent reason
Working when there is only one phone behind NAT but not when more than one

What is the solution

The solution is simple - using IP properly with no NAT. Thankfully IPv6 allows this to be the case for the long term. IPv4 allows it, but IPv4 addresses have run out, and so this is increasingly difficult with IPv4. More phones are starting to support IPv6, we have them listed on our wiki. Similarly few ISPs support IPv6, we do! A problem with VoIP on IPv6 is when you want to talk to a phone that is using IPv4. In this case we act as a proxy and so an IPv6 phone can talk to an IPv4 phone.

Once you have all SIP phones on IPv6 (even if the rest of your network is IPv4 and NAT!) is will just work. You can easily firewall these. You can easily have a separate subnet for the phones even, as IPv6 subnets are readily available.

In the long run IPv6 will be the answer to NAT in many areas, and especially SIP/NAT issues.

You need help?

Customers calling with SIP/NAT issues really will not get a lot of sympathy - at every stage we are recommending not doing SIP and NAT. It can (and does) take many hours to debug the issues people have with SIP and NAT, and then may simply mean it cannot be made to work.

Unless you are contacting us for help sorting IPv6 non NAT SIP as a solution to this, our staff will refer you to this web site for any SIP/NAT issues. If you really want help with them, beyond saying "SIP and NAT usually does not work, sorry", then we have an hourly rate and even then cannot guarantee we can solve your issues. The answer is to do it properly without NAT.

@@ Line 89: / Line 89: @@
 Consider a simple access to a web site - your machine (behind NAT) makes a connection to a web server and requests a page which is sent in that connection. The connection (using TCP) can be NATted easily allowing two way data flow and allowing the web page to be received.
-However, telephony is different. For a start the process is broken in two - signalling and media. This means the "connection" to establish a call is different to the actual audio that makes up the call. When the signally sets up the call it says where to send the audio - except it will be saying "send it to 192.168.1.124" (i.e. a NATted address). That won't work because that is a private IP address and not reachable from the Internet.
+However, telephony is different. For a start the process is broken in two - signalling and media. This means the "connection" to establish a call is different to the actual audio that makes up the call. When the signalling sets up the call it says where to send the audio (see the above SIP trace) - except it will be saying (for example) "send it to 192.168.1.124" (i.e. a NATted address). That won't work because that is a private IP address and not reachable from the Internet.
-There are two answers to this problem:
+There are three answers to this problem:
 # Tell the phone what its externally visible (public) IP address is.  Some phones allow you to enter this in the configuration.  If not, you can use a STUN server - which tells the phone what its externally visible IP address is, and attempts to tell the phone about the firewall it's behind.  You can use ''stun.aa.net.uk'' as the STUN server.
+# Rely on the modem/router having an Application Layer Gateway (ALG) which will rewrite the packet to change the private IP address to the modem/router's externally visible IP address.  And which does it properly - the challenge is that it's often very difficult to see what the ALG has done to the packet (need to be able to look at packets going down the phone line).
-# The call server can break the SIP specification and wait for the audio to come from the device and send its audio back to the same place - i.e. allow the phone to make an outgoing connection for the audio first. The SIP standard does not work like that, and indeed there is no requirement for the phone behind NAT to expect its audio to come back to the same IP and port from which is sends it. Of course many phones do this as it happens, and they might work in such cases, but some do not and they don't work. You have no way to tell when buying a phone, or upgrading its software. It is quite valid for the phone to stop working with your NAT and still meet the standard for SIP.
+# The call server can break the SIP specification and wait for the audio to come from the device and send its audio back to the same place - i.e. allow the phone to make an outgoing connection for the audio first. The SIP standard does not work like that, and indeed there is no requirement for the phone behind NAT to expect its audio to come back to the same IP and port from which is sends it. Of course many phones do this as it happens, and they might work in such cases, but some do not and they don't work. You have no way to tell when buying a phone, or upgrading its software. It is quite valid for the phone to stop working with your NAT and still meet the standard for SIP.  Of course, as a user you have no control over how the call server works.
 The other big problem is telephone calls are both ways - you don't just make calls but you receive them. This means the phone registers where it is. I.e. it sends a message saying "I can be reached on 192.168.1.124", which won't work. Now, again, some call servers will break the SIP standard, ignore the actual stated connection details and assume calls can be sent to the IP and port from which the registration came. This may work as long as the session that did the registration is still active on the NAT device. The device will have a timeout. It could be seconds, minutes, hours - no way to tell on most NAT devices. So that means incoming calls work some of the time (within X seconds of the last periodic registration message). Now, some call servers will send a dummy message every few seconds to keep the session active. Some phones may do that. They are both guessing what the NAT device does with timeouts, and may guess right. This is, of course, non standard for phone and call server to do.  It's all very well for the phone to be listening on, for example, port 5060 for control messages ("incoming call") and ports 5008 - 5012 for audio - but if the firewall doesn't know about these listening ports the call isn't going to succeed.  The best solution is to have firewall rules which allow VoIP packets from the AAISP VoIP servers - see [[VoIP Firewall]]