editor
466
edits
VoIP NAT: Difference between revisions
Expand on "Why is SIP a problem", it probably needs a couple more volumes...
(Move the "purpose of the page" to the top) |
(Expand on "Why is SIP a problem", it probably needs a couple more volumes...) |
||
|
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
There are two answers to this problem:
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.▼
# 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 its behind. You can use stun.aa.net.uk as the STUN server.
# 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 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. 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.
| |||