[Freeswitch-users] FreeSWITCH HA + Loadbalancing

David Knell dave at 3c.co.uk
Fri Aug 28 14:01:53 PDT 2009

Hi Raimund,

One FreeSWITCH box will be quite enough to handle the call volumes that
you're talking about, and it ought to be much more stable than the
Asterisk solution which you've outlined below.

It's probably best to forget about live failover without calls dropping
- this isn't something that's supported, and there'd be a lot of work to
do to develop code to keep two boxed in sync.  Once you get used to a
stable solution - i.e. something which doesn't crash - then live
failover, HA, etc., will seem somewhat irrelevant.

I recently did some work on an FS-based call center solution - drop me a
note if I could be of any help with yours.

Cheers --


> Hello List,
> I have read the current thread about scalability and I would need some  
> advice about a callcenter setup:
> First where I come from:
> I have lot's of problems with an asterisk solution. I have regular  
> crash's and lock-ups, with downgrading and other stuff i got it  
> somewhat stable, but have nevertheless regular hickups. I am desperate  
> and want to get rid of asterisk and I hope that freeSwitch will  
> provide me with a more stable solution.
> Our Setup (really nothing special):
> * 1 Asterisk box, New IBM Hardware (3 month old), 2 HE rack server, 3  
> GIG of RAM, Xircom analog switch connected to mobile stations for 4  
> different providers, Digium 4port cards TP400<something>
> * 8 queues
> * ~60 agents (which logon, logoff, pause, unpause), not more than 40  
> concurrently online
> * ~ 7K - 9K calls (well, CDR entries) a day (not that much for a bpx)
> * Music on Hold in the call-queues
> * No special announcement
> * Transfers between calls in queues and different agents as well as  
> non agents (i mention this because we have transfer related chrashes  
> in asterisk)
> The current Problems:
> * Lockups with different causes (ranging from calls not terminated to  
> heavy thread locking through the AMI interface)
> * Crashes and library aborts (pthread, libc, crashes related to music  
> on hold, app_queue, transfers)
> We used Asterisk: 1.4.23, 1.4.24, 1.4.26rc3, 1.4.26rc5, 1.4.26 and are  
> now back to (stock debian) as anything beyond that is for  
> whatever reason highly unstable for our szenario. Maybe we should have  
> been segmenting the box into one asterisk dedicted to talking to the  
> hardware, one especial for queue/sip handling, i do not know. (all  
> issues are well documented in issues.asterisk.org, but it seems to be  
> very, very difficult to get to the bottom of them as they exist since  
> 1.4.23 as it seems and are open until know and not fixable since month.)
> Now, I really would appreciate some success-stories on how you guys  
> managed to get a stable pbx system with freeSWITCH in regard of HA and  
> scalability:
> * How to segment freeSWITCH? Or is it stable enough to handle all in  
> one for such a szenario as outlined above?
> * What would be the best strategie for High Availability / Failover?
> 	-> I read in the WIKI (featurelist) that Livemigration of calls from  
> one box to another should be possible?
> 	-> I was thinking about using memcached for storing all state  
> information so another freeswitch box can takeover calls from the  
> first box if it dies, is this possible? If so, how?
> 	-> Is there anotherway to somehow configure freeSWITCH that in the  
> event of a crash i do not loose the current established calls?
> Basically I just want a stable PBX where I do not have to fear every  
> day it will core-dump or abort or Lock up. Is freeSWITCH mature enough  
> so i can sleep at night for at least 3 month without a crash?
> Thank you for your Time and help in advance, and I am more than  
> willing to take all the information gathered here and create a wiki  
> page to help other people with the same questions/problems.
> best
> Ray
David Knell, Director, 3C Limited
T: +44 20 3298 2000
E: dave at 3c.co.uk
W: http://www.3c.co.uk

More information about the FreeSWITCH-users mailing list