On Apr 7, 2005 9:30 AM, Matthew Boehm <[EMAIL PROTECTED]> 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) _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
