And I am pretty damn sure what asterisk uses for routing, you need either ‘externip=18.104.22.168’ or ‘externhost=your.dns.server’
‘externip=22.214.171.124’ will not be “resolved” by dns, "externhost=a.b.c’ will be, but if you use externhost, it is not asterisk that can do that, it is your network setup, you will need a ‘helper’ (dynamic dns)
I guess I don’t completely understand. Are you talking about the SIP Settings - External Address value?
I haven’t set that value for over four years and I don’t have a problem receiving calls or dialing out. From my understanding when I register with VOIP.MS that link basically becomes a controller channel where-as my PBX open ports to VOIP.MS for making and receiving calls. My firewall doesn’t forward any ports back to the PBX. I don’t have any extensions outside my PBX local network so maybe that’s why I’m not having an issue.
I guess I am not sure why asterisk would do any sort of IP routing as that’s not really the function of asterisk.
Pretty sure it uses that value to overwrite the LAN IP of the asterisk host in a SIP packet before sending it on to an external host, as the LAN IP would be unusable by the external host that’s talking to my asterisk box.
PS: Also pretty sure it’s used with individual extensions that connect to the phone system that are on the external side of the NAT.
I don’t configure individual asterisk settings files manually, I let the FreePBX GUI do that most of the time and in the GUI that setting is under Settings -> Asterisk SIP Settings -> General SIP settings tab -> External Address. This is also a required field that needs to be the valid external IP address of your internet connection.
Absolutely correct, Asterisk doesn’t do any routing decisions, it simple sends the call to what you have defined as the route to use. If the route can’t complete, the call will fail. It is up to you to define a route that CAN complete, it will honor either externip or externhost as defined. They are mutually exclusive.
Did you consider this is a question about when the Internet connection dies and failover over to the secondary Internet connection? So this is going to require configuring two IPs and networks on the SBC and then that means the routing on the SBC needs to be updated to not route requests over the primary Internet when it is down and then send requests over the primary when it comes back up.
I’m not sure where you are getting that from? If the SBC is only programmed with WAN IPs then the PBX still needs to go from the LAN to the WAN to connect to the SBC, there’s going to be NAT still at the router for this. Even then, you can put the SBC on the LAN as well (so three networks now on it) and you still need to convert the WAN to LAN to talk to the PBX.
There’s NAT involved in this no matter how you slice it.
I’ve looked into SBC’s before, however it has been a while. I believe the conclusion that I came to was that it was also a trade off. We liked features of a pfSense or USG firewalls that we were putting in and any SBC that we saw wasn’t really measuring up when it came to features that we would be using if we replaced those firewalls with an SBC.
It has been a while that I’ve looked into those and maybe it warrants another look.
But maybe I need to consider running the SBC in parallel to the firewall. That would require multiple WAN static IPs for both connections but theoretically it would be doable.
Do you know if an SBC can handle multiple WAN connections and if it has automatic WAN fail over in case of a single WAN failure? I guess I should do that legwork on my own and check out Sangoma’s SBCs and their features.
The reason there would be no NAT here is because the SBC will act as a sort of bridge. The trunks terminate on the SBC and then there is another trunk between the SBC and the PBX. Theoretically this would work but the problem is that implementing an SBC would still be a trade off between the firewall’s features that you would have implemented and whatever the SBC is capable of doing for everything else but the SBC portion.
You are still going to have to translate the WAN IP to the LAN IP, that the definition of Network Address Translation. The SBC needs to be on the LAN to talk to the PBX so it needs to go from the public to private and vice versa. This is going to be because the SBC needs to listen on the WAN and the LAN IPs for SIP traffic. So it will receive incoming requests on the WAN IP and have to route them to the LAN IP of the PBX. Same goes with the PBX, the PBX is going to send requests to the LAN IP of the SBC and the SBC needs to translate that to the WAN IP it’s going to use.
The SBC still needs to know what external IPs are needed for the signalling and media. The same issue you are running into now.
In the absence of a permanently enabled external URL that resolves to one or more of your servers IP addresses, a Session Border controller (SBC) won’t help you , If you indeed have that URL you will need a SIP proxy to redirect calls to your available PBX and you will need that to SBC to be resolvable outside your LAN or wait for DNS to propagate throughout the internet.
In that case I guess I am misunderstanding what an SBC does and how it works.
My assumption was that it would terminate and handle SIP traffic directly for both endpoints (the trunk provider and the PBX) instead of rewriting IP addresses in packets that come in and out of it (which is distinctly what NAT does).
Well, you setup the SBC and need to give it an IP. You give it a WAN IP. You can now connect the SBC to Vitelity. Now you need to connect the PBX to the SBC, the PBX is on the LAN it doesn’t have a WAN IP the SBC does. So if you create a trunk to it, the PBX needs to go out the Internet to hit that WAN IP. The only option at that point is to have the SBC listening on the LAN as well so the PBX can talk to it. So now you need to translate WAN to LAN traffic in the SBC.
Go a step further, you have two WAN IPs for two Internet connections. You still need to translate the LAN (PBX) traffic to use whatever WAN IP/route for the Internet. So again, you’re still translating the signalling and media from LAN to WAN.
An SBC is great when you have multiple SIP connections you still need to deal with Internet connections like everything else.
I totally didn’t understand how an SBC works. I really thought it was actually replacing the firewall and handling NATing for normal data traffic as well as its SBC functionality.
Yea, I don’t know how an SBC would help in this case really as it would need to be able to handle two WAN connections as well.
The NATing wouldn’t be as much a problem if there was a way to configure a third interface (on top of the two WAN interfaces) on a LAN subnet. But it doesn’t sound like an SBC is capable of handling two separate WAN interfaces with automatic WAN failover and a third LAN interface for connectivity from the LAN side.
So yea, you are correct, an SBC wouldn’t really solve my problem here.
This being said without actual research. The real question is are you willing to spend the $$$$$. I never said that this scenario wasn’t possible, I was pointing out what needed to be done to make it happen. There are SBCs out there for this but they ain’t free.
Kamalio is effectively an SBC (otherwise read a SIP proxy, same concept different words), and it is free , and you can easily wrap it up in dsiprouter ( a gooey) , nonetheless it always needs internet availability ($5 a month on DO or Vultr) you can cluster as many as you want, they will all get to any of your internet available PBI