aa.net.uk Broadband - Broadband you can work with

Skip to Navigation / Skip to Content

Knowledge base SIP and NAT

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 mutliple 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" (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", 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" 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.