[A*UG] Astricon

[Gil Kloepfer]

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

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