[Asterisk-Users] MWI for SER and Asterisk - ast_data vs "realtime"

[Terry Wilson]

On Apr 7, 2005 9:30 AM, Matthew Boehm <mboehm at cytelcom.com> wrote:
> Matteo Brancaleoni wrote:
> 
> > ARA is something different from ast_data:
> > * ast_data is real realtime: for example extensions.conf
> >   is looked up from DB in realtime without reload.
> 
>     Hmm. RealTime extensions are exactly like this. I've never done a single
> extensions reload using RealTime.

Then you have never had to add a context to your dialplan, because you
need the context to exist before you can put a realtime switch in it. 
This is an absolute necessity if you want to set up more than one
organization on your asterisk box which use the same extensions.
 
> >   With ARA you can only:
> > * load the whole dialplan from DB (ARA static), (not realtime)
> >   an apply mods with reload
> 
>     *buzzer* (read above)
> 
> > * make it dynamic with switch statements.
> >   ast_data is like having the whole dialplan in DYNAMIC mode.
> >   This can be desiderable in certain situations (ie quickly
> >   changing dialplan)
> 
>     Again, this sounds exactly like RealTime behavior.

Almost, but not quite.  See above.

> > * ast_data iaxfriends & sipfriends is like ARA dynamic
> >   sip&iax friends, but with a lot of params in addition for
> >   the peer. just look the patches.
> 
>     What parameters are not supported by ARA? I believe all parameters that
> are supported in sip.conf are also supported by ARA since its basically the
> same code that parses the options.
> 
>     BTW, this is not a ARA vs. ast_data debate. Use whatever works for you.
> My point here is that there is alot of misinformation about ARA (as shown
> above) and I'm just trying to get it all straightened out.
> 
> -Matthew

Aside from not being able to create contexts on the fly without a
reload, take a look at your sql query logs sometime.  ARA for
extensions will query 4-5 times PER PRIORITY because it is based of of
the switch architecture which seems to want to *really make sure* that
the extension is there.  It is not particularly scalable for both of
these reasons in my opionion.  Now I know that my case (having
serveral thousand users with lots of calls per second) may not be the
norm, but it would be nice to see some true scalability in the
realtime design.

The best thing I have seen for asterisk to do truly real time dialplan
stuff is using res_perl.  Who cares how you store the information when
you can use perl/DBI to do anything you want with data in any db
format you chose... (not saying that I wouldn't ALSO like the option
to use Realtime--it just won't do what I need yet)