Migrate to new public IPs

Hi guys,

I’ve got a handful of FreePBX servers that need to be migrated to a new set of static public IPs on a different network (same upstream router, though). I need to minimize downtime - zero if possible.

What’s the best way to go about this?

My first thought is to run on both IPs until the DNS changes propagate. Is that feasible? How would I go about doing that? Can it be done with FreePBX, or do I need to do it at the Linux/asterisk level?



1 Like

This is quite tough. I believe that you would have to set up two pjsip transports on different ports, because Asterisk needs to know its external address to send in SIP headers and SDP.

The lazy approach is to set the DNS TTL to e.g. one minute (30 seconds is theoretical minimum) and set the phones registration expiry to e.g. two minutes. Wait for this to propagate, then do the cutover. You’ll have about five minutes of downtime. You can then increase TTL and/or expiry as desired.

If you have a system that can’t tolerate any downtime, you really should have a live spare or even load balance between two or more servers. Unfortunately, this is even tougher.

Assuming you are in US or Canada, cutting over a system starting at e.g. 4 AM Eastern on a Sunday would be a very small disruption. If the trunking provider supports it, route failed calls to an announcement advising the caller to try again after an hour.

Does your VSP support SRV as one of it’s routing choices?

if so , do you have control of your ‘Name service’ (generally that would be DNS ) to so configure those necessary SRV records?

Do you have ‘external’ extensions?

if so , can they also register to SRV (most can, Polycom, Yealink, Grandstream to my knowledge are in that set) ?

If AOK to all the above then there is probably a “wise virgin” solution if you have precognition of your new IP’s.

I need to update that post.

Those instructions use the original term.skyetel.com address and that one does not have SRV records. They updated instructions for them are to use na.skyetel.com which does have SRV records.

Indeed, they credit your post in their new authority, but the concept is solid and should work with any VSP’s that are so SRV capable.

I do have DNS control, and can set up SRV records as soon as I get the new IPs from my hosting provider. My concern is that while I can specify the TTL, intermediate nameservers can choose to ignore that value.

Plus, unless I’m missing something, that post doesn’t address how to make a single asterisk instance listen on multiple IPs. I’m not concerned in the least about the route from asterisk to the VSP, but I am concerned about the routes to/from the phones.

I have come across docs that indicate that PJSIP can be configured to bind to a specific IP. FreePBX is currently configured for “both” chan_sip and chan_pjsip.

If all your endpoints accept SRV records properly, TTL is not an issue because if the higher priority address (old IP) doesn’t work, the device will automatically try the other.

Alternatively, your endpoints may allow configuring primary and backup servers.

Are your PBXes on a public IP, or are they NATted? If the former, it should not be hard to set up two pjsip transports, each with its one public IP. With NAT, it’s more complicated.

Do your trunks use registration, or IP auth?

What is your application? For an ordinary business, it should be no big deal to be down for an hour in the wee morning hours on a weekend day. If it’s something seriously important e.g. an accidental poisoning hotline, you should have at least two servers always working anyhow.

I have a little niggle that chan_pjsip seems not easily to be configured to disallow IP address based communication. You can use URI or SRV routes for both trunks and extensions if they all support that.

Good point, although in this case I’d think setting the higher priority to the new IP would make more sense.

All IPs are public, no NAT. Trunks are IP auth, so we’ll need to update the VSPs.

I suspect that wee-morning downtime will be acceptable, but I didn’t engineer this solution originally, and have been asked to make it as seamless as possible.

This seems to indicate that you can specify the transport on each interface:


Yes, you can specify as you say but unless you have a working BGP solution, then IP based auth is not a good way to go and you can’t presently “unspecify” such transport ( especially in your case :slight_smile: )

Perhaps your VSP offers a ‘failover’ destination ? Perhaps your phones also?

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