Have two ISPS - ISP1 and ISP2 and two SIP providers - SIP1 and SIP 2. Due to restrictions in the policy, SIP2 provider needs to use ISP2 exclusively for it’s SIP related communication. Both ISPs terminate into a single firewall and I managed to get the network routing worked out so that it flows the way it should (FreePBX has only one interface but using Policy based routing all the SIP traffic for SIP B is going to ISP2 and everything else is going out ISP1). The problem that you are already saying in your head is that the sip registration for SIP B will never work as the “external” IP address that FreePBX has will only allow one to be specified globally - not per trunk.
After pouring over the internet and realizing that this is a known limitation (as discussed here), I still continued to look. I came across this from the Wiki in the “What Does That Stuff in the PEER Details Mean?” that states “nat=yes
"yes” tells Asterisk that the system you are communicating with is or may be behind a NAT, and that Asterisk should ignore the IPAddress in the from line and instead use the IP address that the packets actually come from." and it got me wondering…in my case, is that saying that nat=yes on SIP B provider’s PBX would overcome this limitation or not being able to specify a different external address? I also wanted to ask before I get too excited if that concept is common in PBXs as I dont think SIP B provider is running Asterisk.
Secondly, the more I think about this the more it seems like a fairly straight forward problem and answer to allow a specific address per trunk. I know Chan SIP is mature and all the cool kids are trying to get PJSIP going, but is anyone aware if PJSIP has the ability to specify distinct ip addresses per trunk?
Thanks for the advice on this. I did get this to work without proxying, but all magic into making this works really is attributed to the SIP provider. It seems they are indeed ignoring the sip header ip address as the sip packet has the external address for ISP1 but they are replying to the pre-defined PBX address of ISP2 or just using the ip address the packets are actually coming from the ip address for ISP2. Either way it is good as both SIP providers are working independently over each ISP.
As SBC’s (Session Border Controllers) get smarter the carriers can make decisions like this. My guess is the SBC first probes the header IP then if no response gives the source IP a try. That is an option in the Acme Packet SBC.
The logic behind it is called TURN and stands tor Traversal Using Relay NAT and works with it’s brother ICE Interactive Connectivity Establishment to solve the tough NAT issues you described.
Pretty soon this stuff is going to be so easy I will be out of a job. That’s OK more time with the grandkids. Glad you had a succesful outcome.
I want to do the same.
So all you did was add a static route on your CentOS box and force traffic to ISP2 through a certain WAN interface, and let ISP2 know what IP address to send packets back to. So ISP2 is sending packets back to your second external IP, instead of sending it to the IP in the SIP header, which uses whatever is in the external IP field in SIP settings.