editor
471
edits
VoIP NAT: Difference between revisions
Mention configuring the public address, or using a STUN server to obtain it
(Move the "purpose of the page" to the top) |
(Mention configuring the public address, or using a STUN server to obtain it) |
||
| (10 intermediate revisions by the same user not shown) | |||
|
*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.
*Some phones allow the public IP address to be entered in the configuration (e.g. Grandstream products have a "Use NAT IP" option).
*A STUN server enables a phone to be told its public IP address (e.g. ''stun.aa.net.uk).
*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
==How does SIP work?==
VoIP using SIP has a control channel, which is used for registering with the VoIP server and for initiating outgoing calls and notification of incoming calls. The VoIP server normally listens on UDP port 5060. When a call is being setup and when the call is active, an additional audio channel is used.
When your VoIP phone places a call, a message is sent on a control channel - this will conventionally be to the VoIP server's IP address on port 5060. When the call is answered, the two ends of the link have a conversation to agree on how to do the audio link (and video link too, if supported). The two ends of the link will agree on audio codecs to use (how the audio will be transmitted), and each end tells the other end where to send the audio packets to. The audio travels on a different channel from the control channel (using Real Time Protocol - RTP), and your VoIP phone will send something like "send your audio to this IP address, I'm listening for RTP on (for example) ports 5008 - 5012". Each end agrees, and you have a successful phone call.▼
▲When your VoIP phone places a call, a message is sent on a control channel - this will conventionally be to the VoIP server's IP address on port 5060. Your VoIP phone will use a fixed local SIP port number - this is remembered by the VoIP server because it's where incoming call messages will be sent to. When the call is
An incoming call works the same way. It's important to note that the VoIP server will send control messages to your local SIP port, and your firewall connection tracker may have timed out the connection to the control channel if you haven't re-registered recently, or made an outgoing call recently - you either need to provide firewall rules to accept this control channel traffic, or send SIP Keep-Alives every (say) 120 seconds.
Here's an (edited) SIP trace of an outbound call being setup from 02083xxxxxx to 07973xxxxxx. The phone on public IP address 81.187.xx.xx sends:
INVITE sip:07973xxxxxx@voiceless.aa.net.uk;user=phone SIP/2.0
From: "aaisp" <sip:+442083xxxxxx@voiceless.aa.net.uk>;tag=xidd3faqpi
To: <sip:07973xxxxxx@voiceless.aa.net.uk;user=phone>
Content-Type: application/sdp
o=root 1510857313 1510857313 IN IP4 '''81.187.xx.xx'''
c=IN IP4 '''81.187.xx.xx'''
m=audio '''5010''' RTP/AVP 9 0 8 3 99 112 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
The bold text shows the IP address and port number that the phone is listening on - telling the far end where to send audio.
The server replies:
SIP/2.0 100 Trying
...
SIP/2.0 183 Session progress
From: "aaisp" <sip:+442083xxxxxx@voiceless.aa.net.uk>;tag=xidd3faqpi
To: <sip:07973xxxxxx@voiceless.aa.net.uk;user=phone>;tag=2020111412411300003
Server: FireBrick/1.54.153
Content-Type: application/sdp
o=- 31466 0 IN IP4 '''81.187.30.118'''
c=IN IP4 '''81.187.30.118'''
m=audio '''31466''' RTP/AVP 8 101
a=rtpmap:8 pcma/8000
So again the bold text tells the phone the IP address and port number to send the audio to.
The section below on "Why is SIP a problem" explains how NAT breaks things.
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/
===NAT is evil===
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
There are three 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 ''stun.aa.net.uk'' 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 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.
*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. This is caused by muliple phones using the same local SIP port, and/or the same local RTP port. Each phone should use a different local SIP port, and a different local RTP port or non-overlapping local RTP port ranges.
===What is the solution===
| |||