[Asterisk-Dev] Integration of AGI and Management API

[C. Maj]

On Tue, 10 Aug 2004, David Pollak waxed:

> Howdy,
> 
> I've been doing some development with Asterisk and AGI.  I'm using a 
> Java/J2EE application server for my business logic and database access.
> 
> In order to integrate my app server with Asterisk and AGI, my app server 
> opens a Manager API connection to the Asterisk server.  My dial plan is 
> basically AGI(passthrough.py) which fires off a Python script that opens 
> a socket connection to my app server and forwards the bytes from 
> Asterisk to the app server and from the app server to Asterisk.  Lots of 
> open sockets... lots of processes... lots of "selects" on the incoming 
> ports to see the traffic... all in all, no fun.

It sounds like your app server is the source of the
bottleneck.  But if you are already opening a manager
connection with the app server, then why not respond to the
events generated by asterisk via the manager interface
instead of having an AGI also initiate a connection ?

> So, I've been looking over the Asterisk source and I had an idea... what 
> if there was a merger of the Manager API and AGI.  Here's specifically 
> what I was thinking:

It looks like you've already done that above.  You already
started using the AGI and the AMI, so that's where the
merger is.  I could be wrong on this, but the rest of your
message concerns how to put these two things back together.
So you are making a circle, when a straight line would do.

> - Extend the Management API to accept an "AGI" command which would 
> contain a Channel ID, an AGI command line, and a unique ID
> 
>     Action: MAGI
>     Channel: SIP/12345
>     Command: meetme 1234
>     UniqueID: 22882292992929

This could be accomplished by Originating a call to an
application.  Specifically, the AGI application.  So this
functionality at least is already available.

> - Add a ast_magi struct that contains an AGI command, a "unique ID", and 
> a pointer to the next ast_magi (i.e., the ast_magi is a linked list)
> - Add a pointer to the MAGI struct into the ast_channel struct
> - Add functionality to the ast_channel cleanup code to destroy any 
> ast_magi structs in the linked list
> - Add helper routines to add an ast_magi to an ast_channel, get the 
> first ast_magi from a channel, etc.
> - Significant updates to res_agi.c to check the channel for available 
> ast_magi structs and execute them as well as sending the output to the 
> right place (manager_event rather than right to the file descriptor)  

What state would the channel have to be in for processing
MAGIs ?  Would this be a sort of "to do" list for each
channel ?  So a more dynamic dial plan ?  That's kind of
cool.

> Note that MAGI responses are URL encoded to that responses that contain 
> ':' newline chars, etc. will fit on the Response line
> 
>     Reponse after a MAGI command is executed:
>     MAGI: 22882292992929
>     Response: 200%20Success%20Result

I don't know about the URL encoding, but it would be nice if
all manager commands responded with newline delimited
key-value pairs.  That's another topic, I digress...

> - Add a flag to EVENT_FLAG for MAGI events
> 
> I've got the changes made to the codebase.  I'd like to get them 
> accepted back into the Asterisk distribution so that my copy of Asterisk 
> is in sync with the rest of the world.  What do I have to do to get the 
> changes accepted?

Would it be possible to use just the AMI w/o the AGI but
accomplish what you are after ?  Say, sending a channel a
new snippet of dial plan to execute after it moves off the
current extension ?

> Thanks,
> 
> David
> 

-- 
Chris Maj, Rochester
cmaj_at_freedomcorpse_dot_com
Pronunciation Guide: Maj == May