SIP trunk failover strategies

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.

Pretty sure that’s the one.

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.

I found another thread

Since you’re doing IP Auth it seems you’ll need to port forward and have the external IP set…I’m “registering” to a SIP provider so this setting doesn’t do anything for me [the best I can tell].


have you considered using SBCs instead of your router firewall. they can handle failover with the asterisk behind them

bonus no nat

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.

Any specific recommendations for hardware?

I guess my dream solution would be, now that I am thinking about it, if there was a way to implement an SBC as a package on a pfSense installation. I did some Googling and found a recent thread saying that’s not a thing though:

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).

I guess that rules out an SBC as a potential solution then as well.

As I said before, I feel so close to the solution and yet so far!

Again, an SBC is effectively a SIP proxy, and that can only work outside your LAN in the Internet address space

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.

1 Like

It will do all you want, but it needs to exist in the routable ip address space

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

i think your solution won’t be cheap but any of the solutions from major brands like audiocodes, acme packet, genband, metaswitch perimeta etc are regularly used for exactly what you are describing / lan, wan, device failover with multiple sip trunks and PSTN backups.

bonus on top of NAT traversal they also do SIP normalization and QoS

im guessing they are not common in tiny deployment like 10-15 ext since they aren’t priced for that segment

I am not necessarily looking for a completely free solution but enterprise pricing also wouldn’t make any sense for the typical deployment that we implement and need to support.