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" <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
To: "Reza - Asterisk Enthusiast" <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
Cc: "TAUG" <[email protected] <mailto:[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 <[EMAIL PROTECTED]
<mailto:[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.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.
begin:vcard
fn:Mike Ashton
n:Ashton;Mike
org:Quality Track Intl
adr:;;63 Kenpark Ave;Brmpton;ON;L6Z 3L4;Canada
email;internet:[EMAIL PROTECTED]
title:CTO
tel;work:905-840-4995
tel;cell:416-527-4995
x-mozilla-html:FALSE
url:http://www.QualityTrack.com
version:2.1
end:vcard
