[A*UG] Astricon

[Jim Freeze]

Thanks Gil for that information.

On Sep 29, 2007, at 2:23 AM, Gil Kloepfer wrote:

> On Sat, Sep 29, 2007 at 12:12:31AM -0500, Brett Nemeroff wrote:
>> It appears that Adhearsion is just a Ruby AGI interface.

:) It's a little more than that.
With Adhearsion, you have a 2-line extension.conf file:

[asterisk-context]
exten => _.,1,AGI(agi://127.0.0.1)

The rest is handled by Adhearsion. This is the part that makes dial  
plans portable.
Here is an example of part of a dialplan in Adhearsion

internal {
   case extension
   when 10...100
     dial SIP/extension
   when 6000...6020, 7000...7030
     join extension
     ....
   when ('21XX')
     if Time.now.hour.between? 2,10
       dial SIP/"berlin-office"/extension[2..4]
     else speak "It is not business hours in Germany"
     end
   end
}

There is a good video on Jay's presentation at: http:// 
rubyhoedown2007.confreaks.com/session03.html.
It's quite basic, but will give you the idea of what Adhearsion is  
about.
Also, you can order the Lone Star Rubyconf DVD's at http:// 
lonestarrubyconf.com and see a similar presentation.

Jim



>
> I haven't looked at this much and I'm really actually replying to the
> reply to the above comment:
>
> Basically, I haven't really felt compelled to move to Ruby as opposed
> to any of the other scripting (essentially) languages.  I'm sure if
> you love Ruby, you'll feel comfortable with it.  If you love perl,
> you'll feel comfortable with that.
>
> The problem with sharing dialplan code has more to do with the basic
> architecture of Asterisk where they really want you to put all your
> extensions in extensions.conf.  Personally, I don't see this as a
> scalable solution.  I do write much of my dialplan logic to be
> somewhat modular.  It's hard, but can be done.
>
>> I've never had a lot of faith in AGI.
>
> AGI is a somewhat ugly interface, but if you can get past that it's
> amazingly stable and I've never had any problems with it.
>
> To continue the dialplan discussion as it applies here:  Most of the
> individual extension configuration (except for SIP subscriptions)
> for the installation I've built is in MySQL, and I use an AGI script
> to do the MySQL queries.  Why not use the Realtime interface or one
> of the C-language Asterisk modules?  Well, IMO the Realtime interface
> is even more ugly, and I hate having to use ODBC.  Using a compiled-in
> module can cause Asterisk to crash if a mistake was made in writing
> the module or if there's a bug or resource leak in the MySQL  
> libraries.
> To generate voicemail.conf and sip.conf, I actually use "#exec" that
> runs a perl script that uses the database to generate most of each
> config file contents (so a "sip reload" or a "reload app_voicemail.so"
> will generate sip.conf and voicemail.conf on-the-fly based on our
> data model).
>
> I thought that using AGI (not even FastAGI) would be too slow for
> doing real-time database lookups, but it isn't.  Our Asterisk  
> deployment
> handles approximately 900 extensions and 750 (as of today) phones.   
> Every
> call made by someone requires several MySQL queries, and it works
> quickly and flawlessly with the AGI script I wrote in perl.
>
>> But then again, I tend to not  have a
>> lot of faith in Asterisk. it's a love hate thing, right? Yes, I'm an
>> asterisk bashing asterisk user. :P
>
> Asterisk has its problems.  I'd like to look at alternatives, but
> with the investment (knowledge, Digium hardware) our organization
> has made in Asterisk, it would be hard to change to something else.
>
> IMO, the biggest problem with Asterisk is that it doesn't scale
> well (which goes back to the extensions.conf dialplan logic issues).
> The changes they've made in 1.4 only band-aid the underlying problems.
> I feel that most of the configuration files need to be changed to
> use relational database primitives, with SQLite being a good default
> database.  Asterisk keeps per-phone data structures memory-resident,
> which is a scalability problem (this information should be kept in
> the database).  It also means Asterisk is fairly self-contained,
> with clumsy interfaces like the manager interface being the only
> "clean" way for external programs to communicate with it.  It would
> also probably be helpful for the dialplan language to be split
> into two components:  digitmaps for Zaptel, MGCP, and similar devices,
> and a standard interface to many external languages (perl, Ruby, C,
> etc.) to implement call routing logic (what Asterisk calls a  
> "dialplan").
> Basically it would get a number, fully formed from the digitmap (like
> what we see from a SIP phone) and perform actions based on what
> it receives (and there's no reason why one of the actions couldn't
> be "read a digit" to do IVRs, authentication, etc. tasks).
>
> Status events ("subscriptions") have no business being in the  
> dialplan.
>
> Asterisk has some great concepts (like channels) but to me it falls
> short of being a true PBX "swiss-army knife" toolkit, particularly
> for large installations, because of the scalability problems.
>
> I missed Astricon this year because we're in the final stages of our
> deployment (72 extensions left as of today, yay!).  I'm hoping that
> next year I can actually write a paper on how I did our implementation
> and some of the ways we (ab)used Asterisk and present it at Astricon.
> If we ever do have a real meeting of AAUG again, I'd be happy to
> do a mini-presentation (not quite as polished as I'd like to do
> for Astricon) of how we implemented Asterisk.
>
> ---
> Gil Kloepfer
> aaug at kloepfer.org
> _______________________________________________
> Austin-Asterisk-Users-Group mailing list
> Austin-Asterisk-Users-Group at bybent.com
> http://buzzard.onr.com/mailman/listinfo/austin-asterisk-users-group
> AAUG Web Site: http://aaug.bybent.com/