Multiple FreeSWITCH Servers


New Member
If I deploy n+1 FusionPBX servers - for arguments sake, we'll say 3 all using a shared Postgres database (*not for core*)

There is a DNS round robin called "phoneswitch.local".

Bob registers as 100@phoneswitch.local (
Alice registers to 101@phoneswitch.local (
Mary registers to 102@phoneswitch.local (

If Bob dials 101, is the expected behaviour that Alice will ring?
If no - what is the best practice to create that situation?

I've seen reference to mod_xml_curl, I was thinking of defining a route like

or something like that..

Last edited:
My experience is it will goto voicemail, or whatever the unregistered user setting is set to. As 101 also resides as an extension on, but its unregistered there. DB replication is only DB replication, and Fusion is not presence aware. I have also seen an invite may be sent out from towards alice, but if she is behind a NAT, then it will likely never ring.

You should do a lookup on the alternative server if the user is registered there and send a 302 if it is.


New Member
Yup, not so good. Gah.. frustrating. I want to be able to just add nodes in case the system gets too busy to spread it around. At this point I don't need queing, just A -> B connectivity. I should probably just scrap this and run OpenSIPS.


Staff member
It works if you share the core db... I had it working using the notes provided in my thread, but no one else can seem to believe or reproduce the success?
Testing in the past just showed advanced but everyday usage cases failing. If I remember rightly, your thread was pretty much a subset of what was already being taught in the FusionPBX advanced class. Sometime ago, the lead developer also said that Freeswitch code would need to be modified in order for true load balancing to work.

There are many of us have travelled this road and though we had limited success, we all reached a point where we came to a halt with a problem that was unresolveable.

I will just throw one guessed example into the pot that may again illustrate things....


Freeswitch is well known for being poor when it comes to BLF performance. The mailing list has examples scattered around where, as servers get busier, blf is getting more and more delayed. I have seen at least one case myself of a guy complaining blf was taking a full minute to be updated rendering it completely useless. That was on a single server. Now imagine replicating that DB to multiple servers across a WAN, what would it be like then?


New Member
I think it depends on function, certainly. Like straight up routing is pretty easy to cluster. If I was to route to voicemail servers, I would probably do active/active. Same with IVRs.. things like queuing, parking, conferencing, etc.. tend to have to have an active/standby mode.

My approach for those applications would be to have a dedicated domain, with a pair in active/standby. There are many ways of doing this sort of thing, but FreeSWITCH does have some limitations.

I should really spend time on getting good at Kamailio.. it seems to be the fix to most of these pitfalls.
Yes - Just like to put it out there i have a pair spread accross AWS and Digital Ocean. They cost nothing to run and hold 175 domains with 10 - 20 users in each. AWS is the prime server. Its been running now for 2 years without a single outage in the AWS Dubin region. The secondary has been built in Digital Ocean. We have never had to failover to the DO server. We have had 1 planned outage that lasted 2 hours in DO out of business hours. TO be honest im not sure what would work quicker. Restoring from an AWS snapshot or the DNSsvr records kicking in. I love to play but when it comes to production choose who and what you host on with personal impartiality and hard facts.


Active Member
Staff member
Multiple Servers is a large topic with a wide array of choices that you can spend a lot of time learning. I have been doing this for many years and have not stopped improving and refining how to setup multiple servers. I'm sure others are having a similar experience with this topic.
Last edited: