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. The STUN would also take care of keeping the bindings alive (will detect the NAT timeout and send keep alive packets.) 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. 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. > 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.
#Xlite softphone drops call after few seconds full
Using a symmetric nat would also solve this problem as well as using a STUN server on the phone (if the phone has it).ģ) Call coming from Asterisk outside the nat with a Full Cone Nat. 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. 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. This will be resolved by setting a nat=route or nat=yes line into sip.conf for that calling user. > 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.īut, 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. 2) Call coming from behind nat, Asterisk sends audio to the wrong port.