[Freeswitch-users] FreeSWITCH HA + Loadbalancing

Mon Aug 31 18:27:14 PDT 2009

> And I'll do it for just $98,650..

Haha, that's really funny :-)

Dave is talking New Zealand Dollars ;)

On Mon, Aug 31, 2009 at 10:36 PM, Raimund Sacherer<rs at runsolutions.com> wrote:
> 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
>
>
> _______________________________________________
> 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