3CX PBX Failover with SIP Trunks

[rtstech]

Hi All,

Just want to ask if someone has come across a similar issue like us.

We have two PBX's (Active/Passive) setup and two SIP trunks (Active / Passive) setup. Our SIP provider is Gamma, and we use IP based trunk.

First Issue - Backup from Primary contains SIP trunk information of Primary, therefore when we restore the backup on Secondary it overrides SIP trunk info of secondary. Can't seem to find a way to exclude SIP trunk information from the backup, or automate the modification of the secondary SIP trunk after the restore, any thought?

Second Issue - One of the information apart from SIP trunks info, backup also includes is Primary Public IP for "SIP Trunk > Options > Adnaced > Put Public IP in SIP Header", from what I understand without the Public IP no outbound calls can be made (No IP is mentioned on the invite - If removed).

Will appreciate any help

Thanks
RTS

 

[Evolute IT]

Normally, you would use a register-based trunk so that you can use the same infos on both PBX and when the passive takes over, it registers the trunk and calls come through.

As for the public IP, that setting shouldn't be necessary. Also, is it because the IP is entered there manually? Was it this way when you created the trunk?

 

[Evolute IT]

I just checked and the template does put the public IP automatically with that setting.

@NickD_3CX or @cobaltit any ideas there?

 

[NickD_3CX]

This scenario is something we are aware of, but for the time being there is not a lot we can do.
The information stored in the "Put Public IP in SIP Header" field is "static", meaning that when you restore a backup, the value is also restored.
This is a problem if you restore onto a system where the Public IP is different.

Gamma is one of the very few providers that require this option to be enabled.

The only thing I can say is that in the event that the 2 servers have no NAT, meaning that they have their Public IP on their network card, not a LAN IP, then you can disable this option and it should still work.

Also, if the Active/Passive servers are on the same LAN and will have the same public IP address, this will not matter (but I'm assuming that this is not he case here).

Other that this, for now you will have to just be aware of this and if a failover does occur, to manually change this value on the Passive server, until an improvement is implemented.

 

[cobaltit]

If they are IP-based trunks could you not just have both trunks defined on the primary and then restored to the backup?

 

[NickD_3CX]

If they are IP-based trunks could you not just have both trunks defined on the primary and then restored to the backup?

The problem is that Gamma requires that in this field they see the Public IP of the system making/receiving the calls.


Because the Failover server has a different Public IP, the backup will contain the IP of the Primary.

As I wrote, the only way this will work is if the Active and Passive have no NAT, in which case this option can be disabled, because 3CX will put the Public IP there anyway.

 

[rtstech]

Hi Both,

Thanks for the quick replies.

For the first issue, I will check with Gamma if we can implement a Register based trunk instead.

Regarding the second issue, both PBX's are on different datacenters so have different public IPs. Having both on directly connected public IP will be an issue for us as both have firewalls that do the Natting.

Manually updating the public IP on a failover will defeat the purpose of having automated failover. I know 3CX doesn't recommend modifying the database directly but is this something I guess we can try? or maybe use the API's to modify the value (Not sure we can do this though).

Also, any thought on when we can expect this improvement in the future.

Many Thanks
RTS

 

[NickD_3CX]

The 3CX policy about touching the database is simple: Don't, it voids any support

Also, any thought on when we can expect this improvement in the future.

All I can say for now is that it is on our "to-do" but because the Providers that require this option is the 1%, if that, it is not high priority.
I don't like saying this, but Gamma is not an ideal provider to have when 3CX Failover is in place for this exact reason.

 

[Evolute IT]

All I can say for now is that it is on our "to-do" but because the Providers that require this option is the 1%, if that, it is not high priority.

Why not just add an option "use public IP of PBX" or make this field parameterable, so that we can put something like "$PUBLICIP" and it takes that from the network config. It would be easy and fix this issue.

 

[NickD_3CX]

Why not just add an option "use public IP of PBX" or make this field parameterable, so that we can put something like "$PUBLICIP" and it takes that from the network config. It would be easy and fix this issue.

This is the "improvement" we have in mind, but things like this are sometimes simple to say, not so simple to implement, test and verify.

 

[rtstech]

Thanks, Nick, we will see what we can do regarding this.

Normally, you would use a register-based trunk so that you can use the same infos on both PBX and when the passive takes over, it registers the trunk and calls come through.

Frederick, I presume even with the Register-based we still need to specify a Registrar/Gateway/IP address on both PBX's, so we will end up with the same issue? or with Register-based, we should be able to specify the same IP address on both PBX's.

Thanks

 

[Lee Cramman]

What would happen if you included both Gamma SIP trunks and your dial rules used the priority active, passive?

Did you get anywhere with asking Gamma about register based auth? I ask because we are also with them.

 

[YiannisH_3CX]

Frederick, I presume even with the Register-based we still need to specify a Registrar/Gateway/IP address on both PBX's, so we will end up with the same issue? or with Register-based, we should be able to specify the same IP address on both PBX's.

The Registrar/Gateway/IP address can be the same for both PBX's as that is the address you contact the provider to. What you need for now is a provider that does not require your public IP presented in the Via header. Most providers don't actually.

 

[rtstech]

What would happen if you included both Gamma SIP trunks and your dial rules used the priority active, passive?

@Lee Cramman Brilliant idea, but having issues with outgoing calls to use the secondary trunk, calls for some reason don't failover to the secondary route. Calls simply disconnect after sending invites to the primary trunk for about 30s @NickD_3CX any thought?. I can add another outbound rule and put the secondary trunk above the primary, but this will be overwritten by the backup of the primary and it will go back to the primary trunk as the first priority.

Did you get anywhere with asking Gamma about register based auth? I ask because we are also with them.

Nope, Gamma only supports IP-based auth.

The Registrar/Gateway/IP address can be the same for both PBX's as that is the address you contact the provider to. What you need for now is a provider that does not require your public IP presented in the Via header. Most providers don't actually.

We have two separate SIP trunks (Primary and Secondary) for redundancy. As @Lee Cramman suggested we can set up both SIP trunks IP addresses on both PBX's, with their individual public IP header, but this is leading to another issue with outgoing calls where it doesn't failover to the secondary SIP trunk route.

 

[Lee Cramman]

Then I would ask Gamma if you can have both possible originating PBX IP addresses (active and failover) registered against both SIP trunks (i.e. 2 addresses on each) for failover purposes. I would think they could accommodate this.

It would take IP addressing / auth problems out of the equation.

 

[NickD_3CX]

Calls simply disconnect after sending invites to the primary trunk for about 30s @NickD_3CX any thought?

Nothing ca be done about that. 32 seconds to be precise, is the SIP timeout after which a Server is considered "down". This is one of the big benefits or Register-based Trunks, you immediately know if they are up or down, not need to wait 32s on each call.

 

[rtstech]

Then I would ask Gamma if you can have both possible originating PBX IP addresses (active and failover) registered against both SIP trunks (i.e. 2 addresses on each) for failover purposes. I would think they could accommodate this.

It would take IP addressing / auth problems out of the equation.

This can be done, but this will end up secondary PBX always using the Primary SIP trunk endpoint for outgoing calls, and as far I understand, if there is PBX failover due to Primary SIP trunk failure, secondary PBX won't be able to make outgoing calls.

 

[rtstech]

@NickD_3CX Is there a way I can automate to change the priority of the outbound rules (Not via changing DB off course)? if there is a way then I think all our headaches will be solved. For now alteast..

 

[NickD_3CX]

@NickD_3CX Is there a way I can automate to change the priority of the outbound rules (Not via changing DB off course)? if there is a way then I think all our headaches will be solved. For now alteast..

Sadly no, I wish there were a solution I could offer you, but because this is not the first time this inquiry has come up specifically with Gamma, there is no "good" solution for 3CX Failover + Gamma for the time being.

 

[Lee Cramman]

This can be done, but this will end up secondary PBX always using the Primary SIP trunk endpoint for outgoing calls, and as far I understand, if there is PBX failover due to Primary SIP trunk failure, secondary PBX won't be able to make outgoing calls.

I'm not well versed in failover but would a SIP trunk failure normally result in the entire PBX failing over? I thought it was the SIP server service in 3CX that was monitored for failover (rather than the trunk).