(if you are using only Asterisk without for example SER, this wont be a problem). Please note that without STUN support, the registrar and proxy server have to be on the same IP. (STUN would not have to send RTP to your asterisk server to make the binding, only something to the STUN server). When stun is used, the phone will also know what ports are mapped to it, and include those in the SDP messages sent. 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.
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.Ĥ) call coming from asterisk outside the nat with a Restricted Cone Nat deviceĪs 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. Make sure asterisk sends the messages faster than the timeout on your NAT device. 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.
#ZOIPER NO AUDIO 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.
0 kommentar(er)
