Tuesday, October 5, 2010


I have found Asterisk::AGI to be the standard tool that most programmers seem to reach for when developing simple AGI applications (at least in Perl) for Asterisk. Such as grabbing a bit of digits entered info and forwarding it onto a web service.

I have my own reservations regarding Asterisk::AGI all the way from it's camel case method names to it's stubborn inflexibility and so on and so forth. I plan to create a new AGI API using Moose and in the process separate the high level application framework elements away from an AGI "session" and the underlying transport layer (fastagi, vs plain ol' system() agi). Hopefully, the result will be a nice framework that developers can extend to present a business specific API for their Asterisk interaction needs.

Here is a bit of code I seem to write a lot:

The implementation of SCALAR ref and CODE ref callbacks were a convention of the specific code-base I was having to "fix". As you can see though, this does the basic fetching of information from an Asterisk daemon while returning a boolean value allowing us to easily loop around it. With a simple routine like this:

And as a result a sample agi script using this for a prompt would go something like this:

Now this is fine for simple bit of IVR logic - but something much larger must be developed in the same way you would develop a larger application; This is something I think Asterisk::AGI lacks but Moose has in spades.

Maybe something more like this (I'm thinking about calling my currently unwritten AGI API Asterisk::MGI)?

This may seem to be a long winded way of accomplishing such a simple task (and admittedly the interface was mocked up off the top of my head) but I think the real power is in the possible use and extension of different transport layers that interact with io in different ways via using a response and request model.

Danga socket anyone?

Of course these are some ruff ideas - I will be sorting out the initial interface soon.

No comments:

Post a Comment