Jump to content

This is the support site for Andrews & Arnold Ltd, a UK Internet provider. Information on these pages is generally for our customers but may be useful to others, enjoy!

VoIP NAT: Difference between revisions

244 bytes added ,  8 November 2020
Explain why opening firewall ports is "a good thing" (TM)
m (Minor tidy)
(Explain why opening firewall ports is "a good thing" (TM))
# 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. 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.
editor
466

edits