On PRI circuits failover with ha is possible using a red tone appliance, but I m sure it's going to be almost impossible to transfer the running calls during the event of fs box going down.
Thanks & Regards, Mitul Limbani, Founder & CEO, Enterux Solutions Pvt. Ltd., The Enterprise Linux Company (r), http://www.enterux.com http://www.entVoice.com On 29-Aug-2009, at 11:35 PM, David Knell <[email protected]> wrote: > Hi Raimund, > > The difficult bit in all of this is having calls seamlessly > transferred > from one box to another when the first box dies. There's a lot of > state > associated with a call, not all of which is easy to replicate across. > > 99.99% uptime implies an average of no more than 15 seconds downtime > during a 40 hour business week (or about one unscheduled reboot every > couple of months), which is easily achievable using FreeSWITCH (and, > in > my experience, Asterisk) on standard hardware. > > People agonize about their four or five nines too much, in my opinion. > Folk are used to their phones crashing, needing rebooting and dropping > calls - we've cellphones to thank for that - and a half-decent VoIP > solution will knock the spots off your favourite mobile carrier for > reliability. Plus there's all the external factors - 99.999% uptime > on > your PRI means that someone can only drive a digger through the cable > once every 273 years, assuming that it takes a day to fix, and no > telco's going to give you that in an SLA. And your power can't go > off. > And so on. > > Lastly, I'm afraid that virtualization and VoIP don't play well > together, at least not if you want to achieve a sensible density. The > large number of small packets being moved around the network > interfaces > - both physical and virtual - will quickly chew up your CPU. > > Cheers -- > > Dave > > >> Thinking about it, maybe we can create a solution, if some of us work >> together: >> >> >> My strength are in virtualization, linux, development, databases, >> integration, etc. >> What I do not now much about is how SIP (and everything else for that >> matter in the Voice world) works under the hood, and how it's >> implemented in FS. >> >> >> I know that the state information for a call has to be stored and >> retrieved somewhere and somehow, only I do not know that part. What I >> know is that it hast to be do-able to store all the stream >> information >> (ip's, port's, current state's, etc.) in a very fast database (e.g. >> my >> idea would be memcached) so another FS could just take this >> information and take over the call, maybe you loose a second of >> voice, >> maybe you loose the recorded call file or a part of it, but that >> should be it. (SipFoundry has a boxed opensource PBX, which, of >> course >> is not flexible like FreeSWITCH or Asterisk, but has Call Live >> Migration and Call Live Failover integrated!). >> >> >> What I want is for my company to be able to sell a 99.99 uptime PBX >> (we do mostly call-center related stuff), which can scale well, and >> can grow with the company without lot's of hassles, my Dream would >> be: >> >> >> To begin with: >> >> >> One Hardware Node with the essential hardware (digium cards for >> example). >> On this node are OpenVZ virtualized containers: >> [VirtCnt1: FS which only talks to the Hardware and forwards >> everything] = Could be replaced with hardware media gateway, etc. >> [VirtCnt2: FS which handles the PBX] \___ Loadbalanced, with odbc or >> xml, Failover, Livetakeover >> [VirtCnt3: FS which handles the PBX] / >> [VirtCnt4: Database for state information] (maybe something as >> resource-friendly as memcached? ressource heavvy database?) >> >> >> With this we can achieve all this: >> >> >> Problem with VirtCnt2 (e.g. crash, lock, ...) >> * VirtCnt3 can take over. >> -> You are free without stress to investigate the problem, you can >> debug and analyze whyle the machine is still running >> -> you can also create a machine-state-dump of the virtual container, >> dump the container as well, copy the data to your lab and restore the >> machine up the state which it was running with the problem, so you >> can >> liveinvestigate it in the lab (some prerequirements given, but easy >> doable) >> -> just think about the possibility of better bugreports because >> someone can take the time to read out all the data with GDB to >> investigate the proper cause of a machine Lock! >> >> >> You want to upgrade to a new FreeSWITCH version? >> * Take VirtCnt2 out of the LoadBalancing Scheme, >> * Stop it, Clone it, >> * Upgrade FreeSWITCH in the cloned Container >> * Start the cloned container >> * if there's something wrong, stop it and restart the original >> VirtCnt2 >> -> No problem at all, you can Test on the Live Hardware, with part of >> the Live users (maybe a low-volume queue) to be sure everything works >> out fine before you activate the full loadbalance >> >> >> Server on it's own can't handle the load >> * Buy new machine >> * Setup Hardware Node >> * Livemigrate VirtCnt3 (no downtime) >> >> >> Now the first Server with the VrtCnt1 and VirtCnt2 as well has to >> much >> load >> * Buy new machine >> * Setup Hardware Node >> * Livemigrate VirtCnt2 (no downtime) >> -> Now you have a 3 server solution (1 mediaprox, 2 loadbalanced / >> failover PBXes) out of the first box you bought, without headaches, >> because the system was built for it from the beginning! >> >> >> The Database drains to much? >> * Buy new machine >> * Setup Hardware Node >> * Livemigrate database VirtCnt4 (no downtime) >> >> >> You want to upgrade Hardware/Kernel in Hardware node 1? >> * Livemigrate VirtCnt2 to a hotstandby machine, or to the other PBX >> machine, upgrade the hardware, Re-Livemigrate the containers. (no >> downtime) >> * OR just break the loadbalancing, wait until all current calls are >> teared down correctly, upgrade machine, reenable the loadbalancer >> >> >> You want an exact copy of the first server for Hardware HA? >> * Buy new machine >> * Setup Hardware node >> * Buy hardware PRI switchover box >> * Clone VirtCnt1 - VirtCnt4 to the new machine >> * Make basic failover configuration >> >> >> >> >> -> the sky's the limit, as the saying goes ... >> >> >> >> >> So, I can do all the openvz stuff and the integration with database / >> memcached / heartbeat / whatever is needed here, someone there to be >> willing to work with me on this on the FreeSWITCH side? or at least >> provide me with the necessary information about what's needed / how >> to >> talk / what states from FreeSWITCH? >> >> >> I know this seems very ambitious but if this could be made in a >> rather >> relativly easy to setup package, with good documentation, it would be >> a boost for FreeSWITCH, i am sure, because after all this is what >> everyone is grown accustomed to from good old phone companys and the >> good old pbx's: carrier grade uptimes ... >> >> >> Thanks for everyone reading up until here, >> all the best, >> >> >> Ray >> >> >> >> >> >> >> -- >> 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 3:17 PM, Raimund Sacherer wrote: >> >>> Oh yeah, that would be so helpfull for my situation, as my client >>> *demands* now a solution where he can press a big red button and all >>> fails over to another box. Hi es totally scared because of the >>> Lockups in Asterisk which under specific situations including AMI, >>> Automated Call Setup, and murphy led to a lockup of the entire >>> machine, no console was working anymore, only cold-reset could do >>> it. >>> >>> >>> So, IF there is the possibility for life-takeover, / failover etc. I >>> would love to here how has been done. >>> >>> >>> I am very experienced with openvz and use for about two years now >>> only openvz virtualization servers for anything because of >>> live-migration etc. But as I am new in this company we could not >>> adopt this until now. >>> >>> >>> So Please Ken, if you can, describe what need's to be done to get a >>> failover / takeover working (an outline would be enough) >>> >>> >>> Thanks in Advance >>> >>> -- >>> 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 11:58 AM, Steve Kurzeja wrote: >>> >>>> On Sat, Aug 29, 2009 at 2:34 PM, Diego Viola >>>> <[email protected]> wrote: >>>> Yes, FreeSWITCH is a system that you can trust 100%. I >>>> have switched my Asterisk servers to FreeSWITCH and have >>>> peace now. >>>> >>>> If I were you I would get rid of Asterisk and use >>>> FreeSWITCH, FS will handle all what you want very well. >>>> >>>> And I agree with David, fail-over is kinda irrelevant >>>> since the FS doesn't crash like Asterisk does. >>>> >>>> >>>> >>>> You still have hardware failures and fail-over is also useful for >>>> hit-less maintenance on boxes. >>>> >>>> I'd be interested to know how Brian West was approaching his live >>>> migration work. >>>> >>>> Steve >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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
