Jump to: navigation, search


488 bytes added, 16:25, 14 November 2020
Add explanation to the NAT 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 signallysignalling 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" (i.e. a NATted address). That won't work because that is a private IP address and not reachable from the Internet.
There are twothree 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 '''' 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", 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]]

Navigation menu