[Freeswitch-users] FreeSWITCH HA + Loadbalancing

Mon Aug 31 05:36:48 PDT 2009

Hi David,

On Aug 31, 2009, at 2:22 PM, David Knell wrote:

> A random thought.  It strikes me that adding support for live call
> failover to FreeSWITCH might well be the wrong thing to do - it's
> something which is probably not too difficult to achieve if starting
> from the ground up, but which is going to be a right PITA to do
> retrospectively.  And, once you've done switching, there's  
> conferencing,
> IVR stuff...
>
> Here's an alternative approach.  Have two FS boxes (which I'll call  
> FS1
> and FS2 - you can't fault *my* imagination) and a front-end B2BUA/RTP
> proxy with a bit of a difference.  The B2BUA sends incoming stuff to
> both FS1 and FS2 as two separate call legs, and the RTP proxy forwards
> inbound RTP to both FS1 and FS2.  Assuming that FS1 is the current
> "master", it forwards RTP and call state transitions from FS1 back to
> the caller.  If it detects that FS1 has gone away, then - as FS2  
> should
> be in roughly the same state as FS1 - it flips to using FS2 as its
> source.
>
> The internal state of the B2BUA/RTP proxy should be relatively simple,
> and therefore should be able to be duplicated to a hot standby.
>
> I can see a collection of gotchas, such as registration (the B2BUA  
> needs
> access to the user database), and I haven't even begun to try to think
> of how to deal with calls *from* the FS boxes.  Actually, that's not
> true: I have, and they clearly need to go through the same sort of
> mechanism in reverse, which is fine until I start trying to work out  
> how
> to pair up calls from FS1 and FS2 reliably, and then my head hurts.
Yeah, sounds like a real challenge

>
> But I think that this idea has merit.  Firstly, it abstracts the
> failover mechanism away into one place; secondly, it is general - FS1
> and FS2 could just as easily be Asterisk1 and Asterisk2.
this, in theory, sound quite interesting ...
would be nice to have a proof of concept setup thought.

-> Sound's not quite THAT nice than a full-built-in solution to FS ...  
but if it works ...

>
> And I'll do it for just $98,650..
Haha, that's really funny :-)

>
> --Dave
>
>> Your forgetting that with RTP theres the duplication of RTP that  
>> may be
>> required along with a mechanism that keeps media timers working  
>> properly...
>>
>> Where many things don't support RTP timers they sure come in handy  
>> on a
>> regular basis especially dealing with several of the other software  
>> based
>> platforms out there that just love to have calls end but never want  
>> to send
>> a BYE
>>
>>
>>> From: Jim Burke <jim at evolutiontel.net>
>>> Reply-To: <freeswitch-users at lists.freeswitch.org>
>>> Date: Mon, 31 Aug 2009 12:54:50 +1000
>>> To: <freeswitch-users at lists.freeswitch.org>
>>> Subject: Re: [Freeswitch-users] FreeSWITCH HA + Loadbalancing
>>>
>>> Conceptually in a pure SIP installation of Freeswitch, hot standby  
>>> or
>>> active standby could be achieved through duplication of messages
>>> (INVITE, 200OK and BYE for calls) between 2 boxes and then using  
>>> VRRP
>>> to change the IP address when the box falls over.  Going this way
>>> allows call state to be as up to date as possible.  Obviously this
>>> would require logic added to sofia to transfer the RTP port
>>> information and UUID information between the FS instances (Easily
>>> achieved using additional SIP headers).  It would also require that
>>> sofia does not forward duplicated messages to gateways or user  
>>> agents.
>>> CDR information would also need to be generated correctly (My
>>> experience of Radius with Opensips is that it generates start and  
>>> stop
>>> messages on INVITE/200OK then BYE respectively so this could be an
>>> easy solution to the CDR issue).
>>>
>>> Regards,
>>>
>>>
>>>
>>> On Sun, Aug 30, 2009 at 11:19 PM, Raimund Sacherer<rs at runsolutions.com 
>>> > wrote:
>>>> So, the first way would be to have a look on the sip stack, which  
>>>> is, in
>>>> fact, sofia ..., well, sound's like a nice, fun, long-going hobby  
>>>> project to
>>>> me :-)
>>>> I will definitly at least look at the sip code to check if it is  
>>>> something i
>>>> would myself willingly give over to ...
>>>> But I *really* do want  a setup where it does not matter if one  
>>>> specific FS
>>>> instance is UP or NOT ...
>>>>
>>>> --
>>>> Raimund Sacherer
>>>> -
>>>> RunSolutions
>>>>    Open Source It Consulting
>>>> -
>>>>
>>>> Parc Bit - Centro Empresarial Son Espanyol
>>>> Edificio Estel - Local 3D
>>>> 07121 -  Palma de Mallorca
>>>> Baleares
>>>> On Aug 29, 2009, at 10:04 PM, Brian West wrote:
>>>>
>>>> The sip stack needs to be modified to spin that data up into the  
>>>> state
>>>> machine so that it can take over calls once the fail over takes  
>>>> place... its
>>>> not an easy task.
>>>> /b
>>>> On Aug 29, 2009, at 2:56 PM, Mitul Limbani wrote:
>>>>
>>>> Is itnpossible to have a db cluster know the state of each and  
>>>> every call
>>>> and then use Heartbeat on this db +
>>>> fs cluster so that clients see only one ip where as internally  
>>>> all fs boxes
>>>> refer db for call states, db again is under replication.
>>>> This in the thioery can be written, but I am sure if we think bit  
>>>> more on
>>>> this direction the problem seem to be getting addressed.
>>>> Other guys also chip in their 2 cents, we just need 50 of em to  
>>>> make a full
>>>> dollar.
>>>>
>>>> Thanks & Regards,
>>>> Mitul Limbani,
>>>> Founder & CEO,
>>>> Enterux Solutions Pvt. Ltd.,
>>>> The Enterprise Linux Company (r),
>>>> http://www.enterux.com
>>>> http://www.entVoice.com
>>>>
>>>> _______________________________________________
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/ 
>>>> freeswitch-users
>>>> http://www.freeswitch.org
>>>>
>>>>
>>>> _______________________________________________
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/ 
>>>> freeswitch-users
>>>> http://www.freeswitch.org
>>>>
>>>>
>>>
>>>
>>>
>>> -- 
>>> Jim Burke
>>> Director Evolutiontel.
>>> http://www.evolutiontel.net
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch- 
>>> users
>>> http://www.freeswitch.org
>>
>>
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch- 
>> users
>> http://www.freeswitch.org
>>
> -- 
> David Knell, Director, 3C Limited
> T: +44 20 3298 2000
> E: dave at 3c.co.uk
> W: http://www.3c.co.uk
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch- 
> users
> http://www.freeswitch.org