VoIP NAT

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
• Disable Stun settings on the VoIP phone (or try enabling it - stun.aa.net.uk can be used)

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.

• The technicolor broadband routers we 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.

Why is NAT a problem with SIP?

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.

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 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. The answer is for the call server to 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 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.

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.