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.

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.








-> 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.





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.

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.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