We are currently running 2 servers with master replication. We recently moved our traffic to DSIP Router to load balance the traffic between the 2 Fusion PBX servers for a failover. Everything was working great. Outbound works fine. Inbound goes straight to voicemail when we call in. We noticed that all phones on our domain are registered on Fusion 1 with the outbound traffic. Then on Fusion 2 with the inbound traffic no phones are registered, and all calls go straight to voicemail. How do get 1 phone to be registered on both fusion1/2?
Inbound Issues in a 2-server load balancing system (master replication)
- Thread starter nocstaff
- Start date
To achieve your desired outcome, you need to do dual registration on the phone settings or via provisioning config. It's possible on any modern phone. However, I'm going to give a heads-up on the next issue you will experience. Once you set up dual registration, the calls will work, but you will have issues with BLF buttons and parks, and so on. A call parked on one server will not be available on the other. BLF buttons work on the main registration only for Polycom and Yealink phones, possibly others too. And forget about call center queue calls. It will be a mess.
You'll also have issues with things like conferencing and queueing. Load balancing just does not work well at all unless you have a very customised setup. This is probably a question for the dsip router guys, eg is it even meant to be able to load balance, I doubt it very much. Certainly, in a 2 node setup, I see no gain. If you have a failure, you need node2 to be able to handle the entire load of node1 anyway. Just leave node2 as a standby.
I have use failover pairs now for years and they work brilliantly. I know it isn't cost effective for massive scaling but when one pair gets full, just create another. It keeps all the eggs out of the one basket too so if you do have a problem with one cluster, it only affects one cluster, also, hardware is cheap.
I have use failover pairs now for years and they work brilliantly. I know it isn't cost effective for massive scaling but when one pair gets full, just create another. It keeps all the eggs out of the one basket too so if you do have a problem with one cluster, it only affects one cluster, also, hardware is cheap.
Just as a PS to this and where it really helped recently in a real situation: I always use different datacenters/providers for the primary and secondary.
We had a recent issue where routing must have gotten bad between our primary and some of our clients, others were just fine. The way I have it configured, in that case, all I needed to do was stop freeswitch on the primary, that initiated a failover to the secondary and all extensions then connected successfully. The routing issue was resolved during the day and starting up the primary freeswitch instance during the night caused all the registrations to switch back to the primary.
We had a recent issue where routing must have gotten bad between our primary and some of our clients, others were just fine. The way I have it configured, in that case, all I needed to do was stop freeswitch on the primary, that initiated a failover to the secondary and all extensions then connected successfully. The routing issue was resolved during the day and starting up the primary freeswitch instance during the night caused all the registrations to switch back to the primary.
