11.1. SIP with NAT or Firewalls
1.1. Problem Description:
1.2. related asterisk configuration settings:
1.3. Different types of NATs and firewalls.
There are several ways UDP might be handled by a specific NAT or firewall implementations, these are categorized into:
1.3.1 Full Cone NAT
A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address.
1.3.2 Restricted Cone:
A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X.
1.3.3 Port Restricted Cone:
A port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers.
Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.
1.3.4 Symmetric Nat:
A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.
You can find out which one you are using by trying a stun client:
e.g.: http://sourceforge.net/projects/stun/
1.4. Different problems in detail:
Most conventional voip protocols (SIP, h323, …) are not programmed with NAT in mind, on itself they only carry call signaling (call setup, teardown,… and use RTP to carry the audio samples.
The signaling usually uses fixed and standardized ports, but the RTP uses random ports to exchange both call legs (incoming and outgoing audio).
Most firewalls/NATs are unable to link the signalling protocol packets with the audio packets and are in some cases unable to tell where to send the audio to.
When making a call, everything will seem to go normal, caller id will get passed, ringing will start, you can pick up and hangup the call, but no audio in one or both directions.
The signaling usually uses fixed and standardized ports, but the RTP uses random ports to exchange both call legs (incoming and outgoing audio).
Most firewalls/NATs are unable to link the signalling protocol packets with the audio packets and are in some cases unable to tell where to send the audio to.
When making a call, everything will seem to go normal, caller id will get passed, ringing will start, you can pick up and hangup the call, but no audio in one or both directions.
1.2. related asterisk configuration settings:
1.2.1.: sip.conf
-> The port used by asterisk for the signaling (default=5060)
-> The ip address on the machine asterisk has to bind to, put 0.0.0.0 to bind to all ports.
-> This is an option that has to be set in the [general] context at sip.conf and has to be set to either an ip or a hostname (pointing to the external ip on your NAT device).
If you want to use a dynamic hostname, you will have to reload the asterisk after every ip change.
It will set the IP address in the sip address to the external ip instead of the internal IP.
You should only set it if asterisk is behind a NAT and trying to communicate with devices outside of the NAT.
-> This is an option has to be set in the [general] context at sip.conf and has to be set to the netmask for the private network asterisk is in, this is only needed when asterisk is behind a NAT and trying to communicate with devices outside of the NAT.
->This option determines the type of setting for users trying to connect to an asterisk server.
All these values have the same behaviour, a combination of the options Route + rfc3581.
Asterisk will send the audio to the port and ip where its receiving the audio from. Instead of relying on the addresses in the SIP and SDP messages.
This will only work if the phone behind nat send and receive audio on the same port and if they send and receive the signaling on the same port. (The signaling port does not have to be the same as the RTP audio port).
This is the default behaviour, is no nat=… line is found for that user, this is the option used.
Asterisk will add an rport to the via header of the SIP messages, as described in rfc3581 (see http://www.faqs.org/rfcs/rfc3581.html), this will allow a client to request that the server send the response back to the source IP address and port where the request came from. The "rport" parameter is analogous to the "received" parameter in the VIA line, except "rport" contains a port number, not the IP address.
This will cause asterisk not to add an rport "rport" in the VIA line of the sip invite header, as introduced in rfc3581. (see http://www.faqs.org/rfcs/rfc3581.html) as some sip ua’s seem to have problems with them. (one of those UAs being the Uniden SIP phone UIP200 – Olle E. Johanson.)
-> This option has a double function, it will keep open the NAT translation binding, and will make sure asterisk doesn’t try to send a call to this phone if its unreachable.
These options will use the default value of 2 seconds.
This will disable the checking of the peer.
This will set the amount of ms between to checks”
1.2.2.: rtp.conf
Takes a numeric value, which is the first port of the port range that can be used by asterisk to send and receive RTP.
Takes a numeric value, which is the last port of the port range that can be used by asterisk to send and receive RTP.
port=
-> The port used by asterisk for the signaling (default=5060)
Bindaddr=
-> The ip address on the machine asterisk has to bind to, put 0.0.0.0 to bind to all ports.
Externip=
-> This is an option that has to be set in the [general] context at sip.conf and has to be set to either an ip or a hostname (pointing to the external ip on your NAT device).
If you want to use a dynamic hostname, you will have to reload the asterisk after every ip change.
e.g: externip=123.123.123.123
It will set the IP address in the sip address to the external ip instead of the internal IP.
You should only set it if asterisk is behind a NAT and trying to communicate with devices outside of the NAT.
Localnet=
-> This is an option has to be set in the [general] context at sip.conf and has to be set to the netmask for the private network asterisk is in, this is only needed when asterisk is behind a NAT and trying to communicate with devices outside of the NAT.
e.g: localnet=192.168.0.0/255.255.255.0
Nat=
->This option determines the type of setting for users trying to connect to an asterisk server.
Possible values:
a) NAT=Yes, true, y, t, 1, on
All these values have the same behaviour, a combination of the options Route + rfc3581.
b) Nat=route:
Asterisk will send the audio to the port and ip where its receiving the audio from. Instead of relying on the addresses in the SIP and SDP messages.
This will only work if the phone behind nat send and receive audio on the same port and if they send and receive the signaling on the same port. (The signaling port does not have to be the same as the RTP audio port).
c) NAT=rfc3581
This is the default behaviour, is no nat=… line is found for that user, this is the option used.
Asterisk will add an rport to the via header of the SIP messages, as described in rfc3581 (see http://www.faqs.org/rfcs/rfc3581.html), this will allow a client to request that the server send the response back to the source IP address and port where the request came from. The "rport" parameter is analogous to the "received" parameter in the VIA line, except "rport" contains a port number, not the IP address.
d) NAT=never
This will cause asterisk not to add an rport "rport" in the VIA line of the sip invite header, as introduced in rfc3581. (see http://www.faqs.org/rfcs/rfc3581.html) as some sip ua’s seem to have problems with them. (one of those UAs being the Uniden SIP phone UIP200 – Olle E. Johanson.)
Qualify=
-> This option has a double function, it will keep open the NAT translation binding, and will make sure asterisk doesn’t try to send a call to this phone if its unreachable.
Possible values:
a) Qualify=yes or qualify=0
These options will use the default value of 2 seconds.
b) Qualify=no
This will disable the checking of the peer.
c) Qualify=”some numeric value"
This will set the amount of ms between to checks”
1.2.2.: rtp.conf
rtpstart=
Takes a numeric value, which is the first port of the port range that can be used by asterisk to send and receive RTP.
rtpend=
Takes a numeric value, which is the last port of the port range that can be used by asterisk to send and receive RTP.
1.3. Different types of NATs and firewalls.
There are several ways UDP might be handled by a specific NAT or firewall implementations, these are categorized into:
1.3.1 Full Cone NAT
A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address.
1.3.2 Restricted Cone:
A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X.
1.3.3 Port Restricted Cone:
A port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers.
Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.
1.3.4 Symmetric Nat:
A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.
You can find out which one you are using by trying a stun client:
e.g.: http://sourceforge.net/projects/stun/
1.4. Different problems in detail:
1.4.1 Asterisk as a SIP server outside nat, clients on the inside of the NAT.
->If the voip phone does not use STUN or another mechanism to detect its public ip (=the public ip of the nat firewall) and thus embeds this ip into the the invite message, then asterisk will try to send its RTP packets to the private ip, and this will be dropped by the routers, resulting in one way audio.
(The caller wont hear a thing).
This happens when nat=never, or nat=no or nat= rfc3581 is added in sip.conf for this calling user, regardless of what nat device is used.
-> If the phone was able to detect its public ip and it sends it correctly in the sip invite header, then asterisk will know what ip to send the rtp to.
But, if a Cone firewall was used, the source port used by the NAT device to send the rtp to asterisk, does not have to be the same as the original rtp source port, and asterisk will send it to the original source port, the NAT device will not be able to know where its supposed to go and will drop the packets.
This will be resolved by setting a nat=route or nat=yes line into sip.conf for that calling user.
If you have only 1 phone behind nat, you could have a look at what range of RTP ports that phone is using and use portforwarding on the firewall, in the direction of public ip to internal network.
If you have multiple phones behind nat, and you can put the range of RTP ports on the phone, you could use non overlapping RTP ranges in each of the phones, with port forwarding for each range to the according phone.
Using a symmetric nat would also solve this problem as well as using a STUN server on the phone (if the phone has it).
-> Without the sip phone registering to Asterisk or the ip of the NAT device in SIP.conf, the asterisk server has no idea where to look for the phone, thus the call will never go through.
(This is the same for all NAT devices).
If host=123.123.123.123 in sip.conf or the phone registers to asterisk, asterisk will be able to send the signaling and the RTP to the NAT device which will forward everything to the phone.
When the phone has STUN support, it will be able to open bindings on the NAT device and will use that ip and those ports (one for signaling, 1 for RTP and one for RTCP) inside its SIP messages in the SDP field.
The STUN would also take care of keeping the bindings alive (will detect the NAT timeout and send keep alive packets.)
If the phone has no STUN support, you will need to register the phone to the server, and have asterisk send keep alive messages with the qualify= line. Make sure asterisk sends the messages faster than the timeout on your NAT device.
Without STUN support, you will also need NAT=yes or NAT=route, and you will have no incoming audio on the natted phone until the asterisk server received audio from that natted phone.
As seen before, a Restricted Cone Nat device will only allow incoming packets to be sent to the phone if that phone first sent something to the public device where the call comes from.
This could be done by having the phone send a REGISTER, or if your phone supports STUN, the phone would send an empty sip message to your asterisk server to open the bindings.
When stun is used, the phone will also know what ports are mapped to it, and include those in the SDP messages sent. (STUN would not have to send RTP to your asterisk server to make the binding, only something to the STUN server).
Without STUN support, you will also need NAT=yes or NAT=route, and you will have no incoming audio on the natted phone until the asterisk server received audio from that natted phone.
Please note that without STUN support, the registrar and proxy server have to be on the same IP. (if you are using only Asterisk without for example SER, this wont be a problem).
-> Even if we registered the phone to Asterisk, Asterisk will not be able to send any audio to the natted phone, unless the phone first sent audio to Asterisk, as only the 5060 port on the NAT device will be mapped to the phone.
if your phone supports STUN, the phone would send an empty sip message to your asterisk server to open the bindings, as well as some RTP to your asterisk servers to open the RTP bindings.
When stun is used, the phone will also know what ports are mapped to it, and include those in the SDP messages sent. (STUN would not have to send RTP to your asterisk server to make the binding, only something to the STUN server).
Without STUN support, you will also need NAT=yes or NAT=route, and you will have no incoming audio on the natted phone until the asterisk server received audio from that natted phone.
1.4.2 Asterisk as a SIP server outside nat, clients / proxies on the outside connecting to Asterisk
1.4.3 Asterisk as a SIP client outside nat, connecting to outside SIP proxies / phones
1.4.4 Asterisk as a SIP client outside nat, connecting to inside SIP proxies
1.4.5 Asterisk as a SIP server behind nat, sip proxies / clients on the inside connecting to Asterisk
1.4.6 Asterisk as a SIP server behind nat, clients on the outside connecting to Asterisk
1.4.7 Asterisk as a SIP client behind nat, connecting to outside SIP Proxies / phones / gateways.
1.4.8 Asterisk as a SIP client behind nat, connecting to inside SIP proxies / phones / gateways.
1.4.9 Asterisk inside a NAT, phone / gateway inside ANOTHER NAT
1) Call coming from behind nat, Asterisk sends audio to a private ip.
->If the voip phone does not use STUN or another mechanism to detect its public ip (=the public ip of the nat firewall) and thus embeds this ip into the the invite message, then asterisk will try to send its RTP packets to the private ip, and this will be dropped by the routers, resulting in one way audio.
(The caller wont hear a thing).
This happens when nat=never, or nat=no or nat= rfc3581 is added in sip.conf for this calling user, regardless of what nat device is used.
2) Call coming from behind nat, Asterisk sends audio to the wrong port.
-> If the phone was able to detect its public ip and it sends it correctly in the sip invite header, then asterisk will know what ip to send the rtp to.
But, if a Cone firewall was used, the source port used by the NAT device to send the rtp to asterisk, does not have to be the same as the original rtp source port, and asterisk will send it to the original source port, the NAT device will not be able to know where its supposed to go and will drop the packets.
This will be resolved by setting a nat=route or nat=yes line into sip.conf for that calling user.
If you have only 1 phone behind nat, you could have a look at what range of RTP ports that phone is using and use portforwarding on the firewall, in the direction of public ip to internal network.
If you have multiple phones behind nat, and you can put the range of RTP ports on the phone, you could use non overlapping RTP ranges in each of the phones, with port forwarding for each range to the according phone.
Using a symmetric nat would also solve this problem as well as using a STUN server on the phone (if the phone has it).
3) Call coming from Asterisk outside the nat with a Full Cone Nat.
-> Without the sip phone registering to Asterisk or the ip of the NAT device in SIP.conf, the asterisk server has no idea where to look for the phone, thus the call will never go through.
(This is the same for all NAT devices).
If host=123.123.123.123 in sip.conf or the phone registers to asterisk, asterisk will be able to send the signaling and the RTP to the NAT device which will forward everything to the phone.
When the phone has STUN support, it will be able to open bindings on the NAT device and will use that ip and those ports (one for signaling, 1 for RTP and one for RTCP) inside its SIP messages in the SDP field.
The STUN would also take care of keeping the bindings alive (will detect the NAT timeout and send keep alive packets.)
If the phone has no STUN support, you will need to register the phone to the server, and have asterisk send keep alive messages with the qualify= line. Make sure asterisk sends the messages faster than the timeout on your NAT device.
Without STUN support, you will also need NAT=yes or NAT=route, and you will have no incoming audio on the natted phone until the asterisk server received audio from that natted phone.
4) call coming from asterisk outside the nat with a Restricted Cone Nat device
As seen before, a Restricted Cone Nat device will only allow incoming packets to be sent to the phone if that phone first sent something to the public device where the call comes from.
This could be done by having the phone send a REGISTER, or if your phone supports STUN, the phone would send an empty sip message to your asterisk server to open the bindings.
When stun is used, the phone will also know what ports are mapped to it, and include those in the SDP messages sent. (STUN would not have to send RTP to your asterisk server to make the binding, only something to the STUN server).
Without STUN support, you will also need NAT=yes or NAT=route, and you will have no incoming audio on the natted phone until the asterisk server received audio from that natted phone.
Please note that without STUN support, the registrar and proxy server have to be on the same IP. (if you are using only Asterisk without for example SER, this wont be a problem).
5) call coming from asterisk outside the nat with a PORT Restricted Cone Nat device
-> Even if we registered the phone to Asterisk, Asterisk will not be able to send any audio to the natted phone, unless the phone first sent audio to Asterisk, as only the 5060 port on the NAT device will be mapped to the phone.
if your phone supports STUN, the phone would send an empty sip message to your asterisk server to open the bindings, as well as some RTP to your asterisk servers to open the RTP bindings.
When stun is used, the phone will also know what ports are mapped to it, and include those in the SDP messages sent. (STUN would not have to send RTP to your asterisk server to make the binding, only something to the STUN server).
Without STUN support, you will also need NAT=yes or NAT=route, and you will have no incoming audio on the natted phone until the asterisk server received audio from that natted phone.
1.4.2 Asterisk as a SIP server outside nat, clients / proxies on the outside connecting to Asterisk
There is no nat in between => no problem
1.4.3 Asterisk as a SIP client outside nat, connecting to outside SIP proxies / phones
No nat is being used between them => no problem.
1.4.4 Asterisk as a SIP client outside nat, connecting to inside SIP proxies
You will need to port forward the ports the proxy uses for signaling on the NAT as well as the ports needed for RTP. (If the proxy also handles RTP).
Problem is similar to the problem in xxx
Problem is similar to the problem in xxx
1.4.5 Asterisk as a SIP server behind nat, sip proxies / clients on the inside connecting to Asterisk
There is no nat in between => no problem
1.4.6 Asterisk as a SIP server behind nat, clients on the outside connecting to Asterisk
Works by doing portforwarding on the NAT, of all RTP ports used by asterisk (defined in RTP.conf) as well as the signaling port used by sip (the port option in sip.conf)
You will also want to configure the externip and localnet options in sip.conf
You will also want to configure the externip and localnet options in sip.conf
1.4.7 Asterisk as a SIP client behind nat, connecting to outside SIP Proxies / phones / gateways.
This might work, depending on the phone / gateway you are trying to reach through the proxy. (you might have to use externip and localnet).
1.4.8 Asterisk as a SIP client behind nat, connecting to inside SIP proxies / phones / gateways.
No nat in between => no problem
1.4.9 Asterisk inside a NAT, phone / gateway inside ANOTHER NAT
In this case, we need a middle man to even find each other, an outbound SIP proxy that handles the SIP transaction and is reachable by all parties. To get media streams from point to point we need another middle man, a media server.
Possible media servers:
On the Asterisk inside the NAT, you will need to have externip and localnet in sip.conf if you want to use a symmetric NAT.
Possible media servers:
- Portaone's RTPProxy (works with SER, symmetric NAT support only)
- AG Projects MediaProxy (works with SER, symmetric NAT support only)
- Second asterisk outside the NAT(works for all nats but needs configuring, - non symmetric NATs will require NAT=route.)
- AG Projects MediaProxy (works with SER, symmetric NAT support only)
- Second asterisk outside the NAT(works for all nats but needs configuring, - non symmetric NATs will require NAT=route.)
On the Asterisk inside the NAT, you will need to have externip and localnet in sip.conf if you want to use a symmetric NAT.