Mike:
All good points, and I wish to add a form of "me too" to your points. We have two switches (primary and backup) and our Real Time MySQL server is on third box. Thus, if we had to go to the backup switch, our configs on the SQL server are current. Being able to define a different host as a config "server", as you can in Real Time, allows for easier config backups and better DR, in my mind. The third box actually does the "heavy lifting" (httpd, SQL server, voicemail handling and storage), so it is isolated from the main switch(es) (which just have asterisk) and most call routing. This format also makes potential clustering much easier. The above, and the convenience of using a dbase over flat files in automated or custom GUI applications (as you and Leif mentioned below), makes me not want to go back to flat files, at least for dynamic config data (sip.conf, voicemail.conf, etc). Of course I still use flat files, but only for elements that I do not change, or want to change, ever, such as standard call macros, or PBX interlinks. Mark. Please note: Effective April 1, my e-mail address is <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] _____ From: Mike Ashton [mailto:[EMAIL PROTECTED] Sent: Monday, July 09, 2007 5:34 PM To: [email protected] Subject: Re: [on-asterisk] To Realtime, or NOT to Realtime? Reza, Like Leif said depends on the business case. Off the top of my head, here are a few thoughts. Flat file, good for implementations that are not as dynamic ( only a few changes per hour ). Can require less infrastructure, which means fewer points of failure. Should also provide faster response on dial plans, since it is in RAM and not dependent on a network connection/driver, etc overhead. Real Time, this shines where there is very dynamic data and/or has the requirement to integrate into other real time business systems. It should also be easier to cluster for greater redundancy and offer better data integrity if properly implemented. Personally I like the idea of isolating applications. So your asterisk server is just running asterisk, no httpd, no MySQL. This makes maintenance and upgrades less of a nightmare. It eliminates or at least greatly reduces the dependency conflicts that can raise their ugly heads. Of course I don't speak on this one with any experience, NOT. And from what I've seen of Real time, this will fall nicely into my isolation model. We're in the process of moving this way utilizing Xen so our hardware gets better utilization, isolation becomes a snap, and recovery from a failed upgrade is a snap ( well that is if you have a snap shot of the img file pre upgrade ). Mike Reza - Asterisk Enthusiast wrote: Hello Leif: Thanks for the feedback. This is valuable info and to answer few of your questions so you get a better idea, are as follows: 1. Are you doing clustering? -- Not yet. But it may get there! Right now its planning stages, so we are prepared for the future. 2. Are you adding so many people at such a time that you need them IMMEDIATELY available instead of waiting for a couple minutes for your reload script to run (or are you adding them so much that you are finding it hard to keep up by doing a 'sip reload'?) -- The customer base to arrive in large number is only a matter of time. Having spoken with a friend in the States, who runs his home phone business on Asterisk highly discourages flat files, and recommends real time. His input is based on merging and the ability to edit client information by service agents linked to other crm apps. I've so far also been highly discouraged to run 'sip reloads' by 3 well established organizations who's client base is in the thousands. 3. Why do you think you need realtime? -- I like the concept of "realtime". It has no logic behind it... but something analogous to why some folks prefer espresso vs cappuccino :). On the logistics perspective -- at the technical level I see that it has a lot of benefits when you are handling a subscription base that requires customer service reps., to do some form of edits, whether feature sets or password/userid changes. Of course I can only truly say whether Realtime is a good idea or not based on a business model, when it has been implemented. But between now and then, its all about planning, and learning from the mistakes of other successful organizations -- and getting input from other Asterisk consultants such as yourself. Waiting for the book to be released! I'm assuming this is also going to be a PDF version available? Cheers! Reza. ----- Original Message ----- From: "Leif Madsen" < <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]> To: "Reza - Asterisk Enthusiast" < <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]> Cc: "TAUG" < <mailto:[email protected]> [email protected]> Sent: Monday, July 09, 2007 3:57 PM Subject: Re: [on-asterisk] To Realtime, or NOT to Realtime? > You're not giving us enough information to determine if it really is > the right solution or not. Whether to use realtime or not will depend > on what you are actually trying to accomplish. Just using it because > you think you need it, without any real reason is probably a good > enough reason to say you don't need it. > > Are you doing clustering? Are you adding so many people at such a time > that you need them IMMEDIATELY available instead of waiting for a > couple minutes for your reload script to run (or are you adding them > so much that you are finding it hard to keep up by doing a 'sip > reload'?) > > Why do you think you need realtime? Sounds to me like you really don't. > > I *need* it because we have a custom GUI interface which updates a > database, and then we use realtime so we don't have any scripts > running to build and reload the flatfiles. We used this approach, and > it worked well enough, except I got tired of editing PHP code to > generate those flat files and to reload them every 5 minutes. Now I > use a combination of realtime and func_odbc so I only need to write > the dialplan, then things can change in the GUI (which updates the > DB), and now Asterisk can just pull that information as it needs it > with no reloads. > > (You'll find more information about this in the next version of The > Future of Telephony, probably released sometime in August). > > Leif Madsen. > > On 7/8/07, Reza - Asterisk Enthusiast < <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]> wrote: >> >> >> Hello Enthusiasts: >> >> This question is more for those die hard command line junkies running >> production platforms, though feedback from ALL is appreciated and needed! >> >> The question is quite simple: To Real Time, or NOT to Realtime? >> >> Been running Asterisk now for the longest time with Flat File configs. Time >> has come to convert this all to a TRUE REAL TIME through SQL. So >> technically the question is, on your production platforms do you prefer FLAT >> file configs versus REALTIME configs in SQL? If so why? >> >> Any technical concerns, advise or suggestions before I convert it all to >> REALTIME? >> >> Realtime from my non-experience perspective, is appealing as more users are >> being added - the ability to change certain things, specially creation & >> deletion of new extensions in real time is quite tempting to convert to >> realtime configs - since this does not require a configs reload. >> >> Waiting for your feedback! >> >> Cheers! >> Reza. >> > > > -- > Leif Madsen. > <http://www.leifmadsen.com> http://www.leifmadsen.com > <http://www.oreilly.com/catalog/asterisk> http://www.oreilly.com/catalog/asterisk > -- Mike Ashton Quality Track Intl Ph: 647-722-2092 x 301 Cell: 416-527-4995 Fax: 416-352-6043 QTI CONFIDENTIAL AND PROPRIETARY INFORMATION The contents of this material are confidential and proprietary to Quality Track International, Inc. and may not be reproduced, disclosed, distributed or used without the express permission of an authorized representative of QTI. Use for any purpose or in any manner other than that expressly authorized is prohibited. If you have received this communication in error, please immediately delete it and all copies, and promptly notify the sender. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
