Redundancy with SIP trunks and srv record on Allworx 6x

[vtjballeng]

We have an allworx 6x and a router with multiple failover options because our local primary connection is junk (thanks comcast). We've tried various options for sip trunks but have stayed with bandwidth.com as our primary for years. The downside is that bandwidth.com uses ip based authentication.

To combat these issues, we created an srv record which rolls between our 3 wan connections based on priority for inbound calls. This seems to be working well. We have registered 3 ips with bandwidth.com for outbound calls which also seems to be working well. The issue seems to fall on the allworx 6x public ip address setting in Home > Network > Configuration. The allworx is set as a lan host as it sits behind our router which is our firewall. The router needs to sit in front of the allworx to handle the wan failovers. We can only set the public ip address setting in the Allworx 6x to one fixed, numerical ip address which must match our actual ip address to properly receive 2 way audio. In the event of a failover, the router, srv records and bandwidth automatically handle a new ip but the Allworx 6x box doesn't and must be manually changed. This manual change requires recognition/diagnosis of the issues, resolution and a reboot which add up to enough time to break our redundancy planning.

So, any ideas on how to make this work and build in redundancy with our Allworx 6x?

[brandondube]

Did you ever find a solution to this issue or did you change systems? I am looking at the same issue for a client where I can get the whole network working well on a failover connection but the allworx seems to have no dynamic option.

[vtjballeng]

No. It was a damn mess. We've tried various ways over the years. We got a Cisco ASA5505 with everything needed for sip-rewriting etc. We also have a Cradlepoint MBR1400. Everthing fell on it's face between the Allworx and bandwidth though, not because of the routing equipment. We could get the failover to work in all situations except incoming voice on an outgoing call. The solution failed on two points. 1. Bandwidth didn't properly handle SRV records and so wouldn't fail over correctly to secondary ips. 2. Allworx offered no dynamic pointer option in the settings, just a fixed IP.

Here was our testing matrix:
https://docs.google.com/spreadsheets/d/1iAf_2prFTJK9JwoFCMbCGovunT19nnGUtqwU9A6ngfU/edit?usp=sharing

It was a few years ago now and we let our firmware subscription on the Allworx lapse and haven't looked to see if bandwidth added proper srv record handling. We also considered flowroute but never acted on it. We just put so much time into it and our business isn't phone centric so we haven't revisited the problem since. If you do find a solution, we'd love to hear how you did it.

[DrRob]

I'm sorry I don't have a resolution for you. However, I'm in a similar position and we've essentially agreed to make it a manual Allworx WAN IP setting change in the event of a failover.

What's different about our situation is that our provider does not validate based on IP.

We were looking at creating SRV records to make sure the remote endpoints are able to find the server without trouble in the event the Allworx WAN IP address changes. Could you share how you were structuring your SRV records to attempt your automatic failover? I'm making a large assumption that you had remote endpoints as well, so the SRV records had dual purpose in helping with IP based validation and for your endpoints. Are there any other configuration changes that I should be aware of, either for the manual or automatic fail over?

[vtjballeng]

I'm sorry I don't have a resolution for you. However, I'm in a similar position and we've essentially agreed to make it a manual Allworx WAN IP setting change in the event of a failover.

What's different about our situation is that our provider does not validate based on IP.

We were looking at creating SRV records to make sure the remote endpoints are able to find the server without trouble in the event the Allworx WAN IP address changes. Could you share how you were structuring your SRV records to attempt your automatic failover? I'm making a large assumption that you had remote endpoints as well, so the SRV records had dual purpose in helping with IP based validation and for your endpoints. Are there any other configuration changes that I should be aware of, either for the manual or automatic fail over?

We use godaddy and we set up srv records with tcp and udp entries. We gave them appropriate weighting and priority with the correct port such that the call would roll from our first fqdn pointer to the next. Then we set up with our sip trunk provider to point to those srv records. This all worked fine and the srv records were being pointed to correctly during failover testing. Though our Allworx 6x had a fixed pointer, our Cisco box could re-write the IP. Unfortunately this didn't work during a failover due to glitches on the bandwidth side.

Leaving the public ip address field blank in the allworx is a theoretical solution but. Bandwidth couldn't deal with the sip messaging structure when no public ip address is set in the allworx (inbound voice did not work on outgoing calls). So we were stuck. Here was our testing matrix with a Cradlepoint mbr1400 https://docs.google.com/spreadsheets/d/ ... sp=sharing . We had similar issues on the Cisco ASA5500. Bandwidth can only handle an srv record depth of 2.

If you manually change the ip address in the allworx to match your srv failover ip, it works ok but it is self-defeating imo.

[vtjballeng]

For anyone who cares, we moved to flowroute for dramatically better call handling, failover handling, & lower cost. We are now flexibible on the # of trunks (flowroute automatically scales up or down).

We removed the Public IP setting in the Allworx and our SRV record is functional with flowroute. While we still aren't able to sustain calls during a failover or failback event, we are now able to make and receive calls on our primary or secondary WAN connections based on which is active at the time.