Implemented Redundant SBC Support

[cobaltit]

I'd like to see support for redundant SBCs. So this would be two SBCs devices at the customer premise and both IP's entered into the provisioning tab of the extension. This would cause the 2nd (backup) SBC to be provisioned as SIP Server 2/Outbound Proxy Server 2 in the account (or as a second account, not sure which is better).

 

[BrenttG]

@BrenttG - the problem with DNS is that you are stuck living with the TTL, so if you put an SBC's fqdn and handle in DNS, the phones will still honor the TTL and you will have a delay.

Excuse me? You would have both IPs attached to the same record, full time, they will randomly balance between them, and if one drops off, they will just use the alternate ip they already know. Do an nslookup against microsoft.com and see what i mean. The call will drop if in progress when the SBC goes down, but the phone will swap over to the other one quite quickly, we have tested it here in office.

 

[Evolute IT]

For those interested, we use corosync/pacemaker stack with virtual IP. More details will follow in due time.

Will this come with a dropdown selector for the Phone Provisioning tab? So we don't have to know the IP.

 

[dandenson]

@BrenttG "You would have both IPs attached to the same record, full time, they will randomly balance between them "
You are exploiting a specific behavior in a specific phone. DNS spec doesn't handle this so it's purely up to the implementation. Many devices will do a query, take the top IP from the list and hold that until the TTL expires, then query again and accept which ever IP shows up at the top. The DNS server is sorting it's replies for all clients so could very well hand a client the same IP multiple times if it's got other queries in between.

Of coarse you can set your TTL to very low if you are hosting DNS locally to be more 'standard' but that is outside the scope of the PBX.

Doing this via corosync/pacemaker simply removes 'outside tricks' from the equation and doesn't rely on vendor specific behavior in DNS resolvers.

 

[BrenttG]

You obviously have not heard of RFC 1794, section 2, C
https://tools.ietf.org/html/rfc1794

 

[dandenson]

I have in fact, but that doesn't mean the client will roll through those responses after seeing a failure, and most simply don't. Try to get your web browser to do this for example, or even a 'ping' utility on any OS. DNS servers will show a round-robin sorted list of entries but clients can do with those as they please and most don't even cache anything but the top entry.

Most of us are with 3CX for a supported out of the box solution. DNS has a ton of shortcomings for failover and clients behaving the way you want is one of the main problems and it separates a critical part of the system into a separate kit.

This is a solution to a problem that is unsupportable by 3CX, and is really only supportable by the person who implemented it which means this increases business risk rather than decreases it like you would expect redundancy to do.

If you are a busy 3CX shop and you have a solid training and documentation program you can certainly make this work, but this solution really isn't for the masses.

We need a 3CX supported solution and they are working on it, that solution also happens to be far more system agnostic than the DNS solution.

 

[BrenttG]

Browsers have respected it for many years, and any desk phones that are built from Linux kernels that are not as old as dirt will also, but i digress there is no point to continue this argument further, you clearly only want it your way or the highway.

1. Any company dealing 3CX needs to have properly trained staff, 3CX strives to ensure this.
2. Any shop dealing in 3CX needs at least one network engineer on staff to handle that aspect of the system.
3. Any network engineer who has difficulty working with DNS in this manner, is not a network engineer.
4. Your argument that its unsupportable by 3cx is superfluous, its basic DNS, come on now your acting like were working with something archaic like RS485.

3CX is an amazing system, but you cant expect the web interface to do all the networking for you, it already handles most of it though which is props to them.

I don't see a point for me to reply further.

 

[Nick W]

Delighted that there is an implementation of failover! Nice work.

 

[dandenson]

DNS is not for HA. This is tried and true knowledge. Don't steer people towards bad practices.

I'm glad 3CX is looking at a proper HA solution in corosync and pacemaker.