Multiple FreeSWITCH Servers

[mutt]

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 (10.0.0.1)
Alice registers to 101@phoneswitch.local (10.0.0.2)
Mary registers to 102@phoneswitch.local (10.0.0.3)


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
sofia/internal/100@10.0.0.1|sofia/internal/100@10.0.0.2|sofia/internal/100@10.0.0.3

or something like that..

Ideas?

 

[abraham]

My experience is it will goto voicemail, or whatever the unregistered user setting is set to. As 101 also resides as an extension on 10.0.0.1, 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 10.0.0.1 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.

 

[abraham]

BTW, look at this thread ( i read this afterwards).... will also achieve the same result for what you want.
http://www.pbxforums.com/threads/experimenting-with-a-full-load-sharing-cluster.867/unread

 

[mutt]

Thank you. I've been making some slow progress. This thread is helpful. Thank you.

 

[DigitalDaz]

I'd suggest you drop this idea before you waste too much time on it, its not going to work, you cannot balance between FS servers.

 

[mutt]

It's working pretty good right now - fs_path did most of the work. I'll post some notes when I'm done.

 

[DigitalDaz]

Try things like call parking, queuing, attended transfer etc.

 

[mutt]

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.

 

[DigitalDaz]

Look at the other script knocking about here for Kamailio, it does per domain load balancing so you should be good, these issues shouldn't arise.

 

[mutt]

Thanks - I appreciate the help. Been lurking for a while.

 

[phonesimon]

Try things like call parking, queuing, attended transfer etc.

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?

 

[DigitalDaz]

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....

BLF

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?

 

[phonesimon]

Time for some new open-source VoIP projects to come along.

 

[mutt]

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.

 

[DigitalDaz]

@mutt Active/passive pairs work great and are very easy to get going even cross datacenter, this is exactly how I run in production

 

[Andrew Pickett]

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.

 

[markjcrane]

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.

 

[MTR]

Look at the other script knocking about here for Kamailio, it does per domain load balancing so you should be good, these issues shouldn't arise.

Does the per domain LB work?