Remote Extension - IP Change during call (Wan Failover)

Good Day,

Working on a solution to a technical issue on a property I manage. This potential issue came up on another post on MikroTik Forum looking for a solution to part of this overall issue. Essentially wondering if FreePBX can be enabled to allow remote extensions WAN IP to change during call which would result from WAN failover on extension side. FreePBX hosted in cloud.

Long story short, we’re installing an elevator on a remote property that doesn’t have serviceable POTS any longer. I setup a Cloud FreePBX server years ago with Twilio SIP. Working great for years without issues. Now our elevator has a POTS phone in the cabin and to pass elevator inspections, the phone has to run for 24+ hours. Installing giant UPS on all our network equipment and radio tower isn’t an option, and power can be dicey during the winter. The hardware solution is a Grandstream ATA with a MikroTik LTE modem with dual ethernet. Fails over from ETH2 to LTE once the main network drops after a couple hours on UPS. Very little wattage on elevator phone UPS which should allow for a day or so power.

Have you tried deploying SRV records?

The call changing WAN address while the call is in progress is going to be really hard to do, especially since that’s what a MITM network attack could look like.

I’m pretty sure that this kind of network interaction is going to be prohibited by most network stacks.

Can you set up the MikroTik as a VPN client connecting to VPN server running on the FreePBX machine, with the ATA accessing the PBX through the VPN? Also, the client would need to aggressively (quickly) reopen the VPN after the failover. Then, Asterisk would see only a few seconds interruption in the RTP (not enough to drop the call) with no IP changes at all.

1 Like

Is cellular not an option for you? A hacky solution for passing a safety inspection seems like it would make the inspector’s eyebrows go up.

If you decide to go ahead with this, I don’t think the PBX side is your issue, it’s the client side. The client needs to detect that it has changed IP addresses and then issue a re-INVITE with new media addresses. SIP as a protocol supports this; I can’t think of any specific reason it wouldn’t work in Asterisk; but the issue is having a client that can do this, and it’s likely your Grandstream ATA cannot.

Even with aggressive network-change detection, there would be some time of silence during the renegotiation. What are your tolerances?

1 Like

@billsimon is correct that changing IPs is possible if the client is aware of the change. I “roam” from wifi to mobile and back during and a call quite often, but that is on a cell phone, so the client is aware of the IP change.

If a straight up POTS or cellular isn’t doable, then @Stewart1’s VPN option was going to be my suggestion.

1 Like

Are you sure that uninterrupted fail-over of a call-in-progress is a requirement for this inspection?? Even POTS lines can have interruptions, especially if those lines are on the same poles as the power lines…and you’d never have uninterrupted fail-over of a POTS call in this scenario, even with two POTS lines available. So, I don’t know that, specifically, call-in-progress fail-over would be an inspection requirement. Merely having the dual-WAN to ensure that a “dial tone” is always available would put you on par with POTS.

Not sure where in the world you are, but I’ve encountered similar issues meeting “old world” inspection requirements like this here in the USA. Since such regulations are typically issued at the local level, the exact requirements (and just how “outdated” they are) are going to vary wildly from place to place beyond the Federal minimums. In some cases, we’ve had to specifically request a variance from the municipality in question, if they haven’t modernized such requirements. They’ll all have to modernize this eventually…even the major PSTN providers are killing off their POTS lines for SIP-based equivalents, much to the chagrin of those inspectors and their 1980’s limitations. :smirk:

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