I have a SIP communication scenario between two asterisk servers, on the main server I have a trunk and on the other I have an extension to which I register this trunk. It turns out that the outgoing IP of these servers are different, for example: on my trunk on the main server, I put the IP 200.9.221.x as “host”, but on the second server, this is not the valid outgoing IP, both are behind a NAT and the calls are going mute.
Trunk configuration:
username=1191
type=friend
secret=password
qualify=yes
nat=yes
insecure=very
host= destination IP
fromuser=1191
fromdomain= destination IP
disallow=all
context=from-pstn
canreinvite=no
authuser=1191
allow=g729&ilbc&gsm&alaw&ulaw
Question: Is there a way to solve the problem of mute calls when establishing a SIP communication between two servers that operate behind a NAT?
Yes. But there is insufficient information to determine more than that you are a using a deprecated channel driver and ancient cook book configurations for it, which use deprecated names and option values.
For a start, please explain “It turns out that the outgoing IP of these servers are different!”. Also please describe the location of the network translations and give the private network numbers for the relevant networks.
Note, if this is a private trunk, and you control both ends, there should be no valid reason for specifying insecure. If the trunks are symmetric, doing so will have completely nullified the authentication.
Also, is this one way audio, or is the audio broken in both directions? What rules does the/do the router(s) have for forwarding media?
PJSIP, the non-deprecated driver, has more support for NAT, and the normal way of handling a private trunk in a complex arrangement would be over a VPN.
The internal IP is 192.168.254.69/24, the outgoing IP is 177.53.x.x.
Server 2:
The internal IP is 192.168.0.20/16, the outgoing IP for the internet is in the following range 187.x.x.x and the IP that we use to register the trunk is in the following range: 189.x.x.x. That is, the outgoing and incoming IPs of server 2 are different. When the incoming and outgoing IP was the same, that is, both 189.x.x.x, it worked normally, but changes were made to our firewall and the valid outgoing IP was changed, after the calls started to be silent.
There is currently a NAT rule for everything destined for IP 189.58.x.x on port 5060 to be redirected to the internal IP of server 2, 192.168.0.20. And the src nat rule makes everything from the 192.168.0.0/16 network out through IP 187.84.x.
