[Freeswitch-users] FreeSWITCH HA + Loadbalancing

[Jim Burke]

Hi Ken,

I don't disagree, the scenario you mentioned is just the tip of the
iceberg when it comes to getting something like this working smoothly.
 However to try and cover them all in a single post (assuming that I
could) would have resulted in something akin to War and Peace and
probably bored the pants off of most readers :)  For any HA solution
to move from a concept into reality, it would require some serious
brainstorming to identify all scenarios and how to handle them.

Given that many posts in this thread mentioned transfer of call state
at time of failure or some form of virtualisation, I wanted to provide
another solution that would provide real time call state updates
between FS boxes utilising mechanisms that are largely already
in-place and thus (hopefully) reducing software development time if
someone was willing to cough up the $$$$$.

Regards,

On Mon, Aug 31, 2009 at 1:23 PM, Ken Rice<krice at freeswitch.org> wrote:
> 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
>



-- 
Jim Burke
Director Evolutiontel.
http://www.evolutiontel.net