> 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<[email protected]> 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 <[email protected]> >>>> Reply-To: <[email protected]> >>>> Date: Mon, 31 Aug 2009 12:54:50 +1000 >>>> To: <[email protected]> >>>> 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<[email protected] >>>> > 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 >>>>> [email protected] >>>>> 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 >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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: [email protected] >> W: http://www.3c.co.uk >> >> >> _______________________________________________ >> FreeSWITCH-users mailing list >> [email protected] >> 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 > [email protected] > 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 [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
