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@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@evolutiontel.net> Reply-To: <freeswitch-users@lists.freeswitch.org> Date: Mon, 31 Aug 2009 12:54:50 +1000 To: <freeswitch-users@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@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@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@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@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@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@3c.co.uk W: http://www.3c.co.uk
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@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