Backup Cell Modem

Has anyone ever set up FreePBX with a backup cell modem in the event the primary network connection fails? I know if I plug in a secondary network connection, it should show up in System Admin > Network Settings. But if I only want it used in the event of a failure of the primary network connection, is there any way to automate that in FreePBX?

FreePBX/Asterisk is terrible for failover configuration, especially if you want to automate it.

I would look at an SD-WAN service that would provide you the same external IP across both internet connections to automate that process upstream from the PBX if it’s that business critical.

without thinking of freepbx: It is a native function of asterisk to check weather or not a trunk is online.
See trunk-config in freepbx:

This field may include a script-name such as “”
The script must be owned by user asterisk and must chmod +x
In my case it enables trunk-id #4 (which may be your cell-trunk)
…and your outbound-routes shall use this trunk in the second line
The skript is intended to run, once the current trunk looses connection

#path: /var/lib/asterisk/agi-bin/
EMAIL=what ever you like@some domain
fwconsole trunks --enable=4
fwconsole reload
#/usr/sbin/asterisk -rx “reload”
SIPTRUNKS=$(/usr/sbin/asterisk -rx ‘pjsip show registrations’)
IAXTRUNKS=$(/usr/sbin/asterisk -rx ‘iax2 show peers’)
MESSAGE=“A trunk failure forced a reload on $HOST and activated the cell-trunk”
MESSAGE=“$MESSAGE\nCurrent Trunk Status:”
echo -e “$MESSAGE” | mail -s “Trunk Failure” “$EMAIL”

I have no idea, how to disable trunk id 4 again automatically, once the landline trunk is available again, because I’m not a friend of cronjobs running every x secs.
If anyone has an idea, please return.

1 Like

I would use a router that supports two WAN inputs with automatic failover. Program it to use your fixed internet connection unless that fails then switch to the input for the cellular modem’s ethernet out.

TP-Link makes this:

You would still have to deal with the IP address changing and have an inbound SIP provider that can recognize two routes for the incoming numbers and handle the failover.

I assume you are registering , not using IP routing, then I would suggest

tail -F /var/log/asterisk/full | while :; do read LINE; [[ LINE ~= [identifiable trunk re-registering string] ]] && [disable the temp trunk and anytging elseneeded ];done

the regex matches the log line then ‘do something’ if not it justs wait for the next line

Thanks all! I’m glad to see I have options here!

@kenn10 I actually have a couple of spare routers lying around that support this type of functionality. For some reason I’m shying away from this idea only because I don’t want to add another piece of hardware in the mix just for the phone system (I don’t want to back up the whole internet with a cell modem - just the phones). It adds a level of topology complexity, but does take FreePBX and any of its potential quirks out of the equation. A WAN connection port goes down, and FreePBX doesn’t know or worry about it. I like it.

With that said, though, @guenni23 and @dicko this is more along the lines of what I was originally thinking. I’m always concerned about doing too much outside the GUI only because I fear a backup/restore situation or an upgrade could mess with it, things need to be documented, documentation needs to kept up to date… But seeing a “native” option to monitor the trunk and run a script is pretty awesome. I’m ehem less concerned about cron jobs. I’ll admit I have a problem. Hi I’m Kyle, and I use an excessive amount of cron jobs. But kidding aside, it can be something that runs every 5 or 10 minutes. I want the failover to be quick, but the switch back can take it’s time.

Oh and @dobrosavljevic , we currently have an SD-WAN solution in place with a provider that’s… not going well. We’re in the process of switching providers as a result, and I’m looking for a way to eliminate someone else managing our phone system’s WAN backup because of the bad experience we’ve been having. I know this is probably a very reliable and tried and true method at this point, and we’ve just had bad luck. But if I can come up with a solution that we can manage internally, not pay someone to do for us, that’s our preferred method at this time (ha, I mean that should be obvious, we just switched to FreePBX for our 300 phones!). Outside of UniFi’s “Site Magic” SD-WAN (sort of) solution, there’s not too many self managed SD-WAN solutions that I can find - and wrap my brain around!

Again, thank you folks for the ideas. These certainly will help me moving forward.

By default the ‘full’ log will note registration and deregistrations synchronously whereas cron is only asynchronously granular to the minute, it takes a failed call to trigger the failed trunk script so but IP based trunks would need active monitoring with something like sipsak to ‘know’ it’s state.

Watching a log file won’t disrupt the system and if it properly restores the trunks’ states then FreePBX need not even be involved.

I wrote myself a somewhat small (124 lines) script that runs every 5 minutes and checks connectivity to cloudflare DNS (2606:4700:4700::1111) and google DNS (2001:4860:4860::8888). If ping fails to google dns, it will recheck after 30s. If it fails again it will check ping to cloudflare DNS and if that fails also it will switch the interface by disabling ipv6 on the currently used interface and enabling ipv6 on the backup interface (or vice versa). Then it waits a few seconds and updates the v6 dynamic dns hostname to the new host.

Works very well. I made it v6-only to avoid any NAT trouble. External phones register against the v6-only dynamic hostname which also comes with the advantage of having less attack surface because if you don’t know the hostname you cant accidently find the IP where PJSIP is running on because the address space is way to big.

I guess there are a gazillion ways to solve this, but this is what I came up with because our primary internet was flaky for some time. The secondary internet is not cellular but I guess that would not make a difference if it were.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.