OK, OK. Now I think I see what is going on here. The local network stuff is only usable for when the External Address/Host details are set. It basically says “if request is from local network to a place not in local network then use the external details”. Since you have neither external details setup AND you have the ISP’s network set as a local network, it would never use the external details even if they were set. It would believe things need to stay local.
Here is what I would do. First, get rid of Chan_SIP for the trunk. Second, setup a Chan_PJSIP transport that listens on 10.221.11.10. Third, setup a Chan_PJSIP trunk that uses the transport for the voice IP. Now you will have this trunk listening on the 10.221.11.10 IP and using the 10.221.11.10 IP to source requests from over that trunk.
See right now requests are hitting the other IP which Asterisk is then using for all requests because it just won’t randomly select another IP to use for things. So even when it routes over the correct interface (eth0) to the ISP, it’s going to use the office LAN IP for its SIP message details because that’s where the SIP message sourced from.
It probably won’t affect you but I just wanted to suggest you not use 172.32.x.x internally, if that’s what you are doing. It’s publicly-routable IP space owned by T-Mobile. Use rfc1918 ranges.
The local network stuff is only usable for when the External Address/Host details are set. It basically says “if request is from local network to a place not in local network then use the external details”. Since you have neither external details setup AND you have the ISP’s network set as a local network, it would never use the external details even if they were set. It would believe things need to stay local.
I understand this.
Is there a way to achieve this using the Chain_SIP?
It probably won’t affect you but I just wanted to suggest you not use 172.32.x.x internally, if that’s what you are doing. It’s publicly-routable IP space owned by T-Mobile. Use rfc1918 ranges.
That is one of the IPs I changed for the purposes of this thread. Like @BlazeStudios I did not notice my mistake. So this is not a problem on my implementation.
Apologies for the delay. Apparently there is a limit to how many messages a new user can send on his first day.
Not really. Chan_SIP is pretty much dead. It hasn’t had active support or development for almost 6 years. Anything done with it recently has been by community members. You’re better off with Chan_PJSIP.
