[Freeswitch-users] FreeSWITCH HA + Loadbalancing

Mon Aug 31 18:26:19 PDT 2009

Actually Dave, our idea's are very similar.

The difference being is that you fork the calls into 2 separate legs
at a B2BUA and sending each to an FS box, while I would duplicate
messages to an FS box acting in Standby mode using extra SIP headers
to let the standby machine know the RTP port number and the UUID.
These 2 FS boxes would essentially become the core switching units in
Active/Standby configuration and be used to handle switching logic and
billing.  Thus if FS2 became the Active box, it would have exactly the
same call information as FS1 had.  Theoretically there would nothing
stopping FS1 and FS2 being master and standby for each other at the
same time and both handling traffic, although this has the potential
to cause over load if something did fail.

i.e FS1 receives INVITE, handles call and forwards INVITE to Gateway
and then sends a second INVITE (Duplication of Original message,
utilising extra SIP headers to pass on required information) to FS2.
FS1 fails FS2 takes over and handles call.

Then you would look at way's to distribute functionality across other
boxes to allow scalability.  An example would be to use dedicated FS
boxes for TDM cards and Opensips to handle registrations, SIP proxy or
SBC controllers.

Of course this assumes you are looking to build a softswitch that can
handle large call numbers and have the $$$ to do so.  Sadly, I have
niether the money or the requirement.

On Mon, Aug 31, 2009 at 10:22 PM, David Knell<dave at 3c.co.uk> 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.
>
> 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.
>
> And I'll do it for just $98,650..
>
> --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
>

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