I see the point that if my cloud based DB server were to fail yes I would lose call processing capabilities at the site.. or if the internet connection were to fail.. however these properties I am working on a solution for are just wanting CHEAP CHEAP CHEAP. in fact they only want 2 Copper lines brought into the hotel for their FAX(not on the PBX) and one as an emergency line(911 access from the PBX..) they want 100% of their trunking on SIP.. from what I understand of "realtime" asterisk is that if the database server fails it can use data that is in the Config files..
Wit hthe current USA economy and the cell phone being the main means of communications.. the hotel phone system is a necessary evil. its there for the "feel-good" and because code requires it for 911.. Another route im headed in which seems to fit the astlinux model better is to scrap using asterisk realtime and simply update the asterisk DB with data for call restriction levels, mailbox status, etc.(as I understand it the asterisk DB is stored in RAM and not on disk??) I could also write this data to an off-site server so that a reboot of my astlinux box a script would run to re-populate the DB with the previous values.. if the cloud is down well then the property will have no service anyway so its not real important if the mailboxes and call restriction data are up to date until the cloud returns to service. So yes there are other areas im exploring(other than MYSQL) and no im not planning on running astlinux on a full blown PC.. im looking at likely the net5501 as these are small properties..the astlinux on site will be trimmed down quite a bit.. in fact no gui,(ill leave lonnie's as it has no overhead) no routing , no Dahdi hardware (just dummy), no meetme, no ACD, very few asterisk modules etc.. being these are hotels MAC's will be few and far between (most less than 100 rooms) and reality is that rarely do I ever see any more than 5 calls up at a time in a hotel up to 150 rooms.. unless it is a more advanced hotel that has sales / catering/. And convention departments.. but these properties do not. Exploring MySQL wasn't intended to start a flame war.. it was intended to do exactly what it did and get your guys insight and opinions on it and thank you for that as I have a good direction of where I want to go now. -Christopher From: Philip Mullis [mailto:philip.mul...@syx.ca] Sent: Wednesday, January 06, 2010 8:48 AM To: astlinux-users@lists.sourceforge.net Subject: Re: [Astlinux-users] (no subject) MySQL I think I came into this one a bit late and missed that he was planning on using this for a hotel... Adding a database server and using several small boxes although sounds better in many people minds would have an increased risk of failure due to the external database becoming a serial dependancy and single point of failue. Embedded systems design thrives on being reliable due to simplified design and target use of hardware that dosnt use moving parts like fans or spinning disks, adding an external database for something other than logging would detract from reliability. Are alot of people using astlinux using on fully blown pc's? if so whats the attraction for those users over pbx in a flash. I cant imagine someone (other than a geek testing/playing) with a stack of linksys's or other mips based processor type embedded units running large scale clusters of them to facilitate a larger need (the alix/sokries boards are i386 based, and can do 25-50 concurrent calls no compression), it just seems way to daft. You can buy a really powerful,relaible redundant system and pack it with a ton of memory and make a large md, setup carp and rysnc and sleep easy knowing youll crank out nearly 800 concurrent calls with live failover. Phil. _____ From: Tod Fitch [mailto:t...@fitchdesign.com] Sent: Tue 1/5/2010 6:32 PM To: AstLinux Users Mailing List Subject: Re: [Astlinux-users] (no subject) MySQL In the context of a follow up post by the originator of this thread it does make sense for an embedded Asterisk box. As I understand it he will have a separate SQL server someplace that multiple AstLinux boxes would be accessing via "Asterisk Realtime" (what a lousy term for database driven call management). If I had multiple boxes that needed frequent update as customers checked in and out of my hotel I sure would like to centralize the management of it with one database but have all the call handling boxes be immediately up to date. So the flash memory usage would not be an issue, the database is elsewhere not on the AstLinux box. It does fit an embedded model. And it does solve a real-world problem. Whether or not it solves enough problems for enough people is a whole different question. --Tod Fitch On Tue, January 5, 2010 2:59 pm, Philip Mullis wrote: > Chris, > > Realtime is cool, but it strays way way far from the embedded track of > such projects like astlinux and askozia like mentioned below by > Darrick/John you really will kill your media in a hurry and your > bloating a streamlined system with items that really don't need to be in > there for that target device type. (If you want bigger and more features > for a bigger office or need, use a bigger box :-) and pbx in a flash or > vanilla asterisk) > > That beings said though, the realtime module could be added for mysql > and also the cdr mysql module (cdr is really the only one I would > consider personally also) you don't need to use the local storage you > can have it point at a remote server (again though I see this as > somewhat pointless for embedded devices, because anything that needs > that sort of volume for changes often isn't usually targeted for an > embedded box deployment) > > ________________________________ > > From: John Novack [mailto:jnov...@stromberg-carlson.org] > Sent: Tuesday, January 05, 2010 5:23 PM > To: AstLinux Users Mailing List > Subject: Re: [Astlinux-users] (no subject) MySQL > ---------------------------------------------------------------------------- -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Astlinux-users mailing list Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org.
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Astlinux-users mailing list Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org.
