[Asterisk-Dev] Integration of AGI and Management API

[David Pollak]

Chris,

Thanks for the in depth response.  Given that I've only been using 
Asterisk for a couple of weeks and have only reviewed about 20% of the 
source code, I really welcome thoughtful analysis from folks who know 
more about Asterisk than I do.


C. Maj wrote:

>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 ?
>
>  
>
My application will initially have 25 Asterisk servers managed by 1 
application server.  That number must be scalable to at least 500 
Asterisk servers.

Given the initial 25 servers, with 100 open channels each, that's 2,500 
channels to manage.  I'm trying to build the management system to be as 
lightweight as possible.  Thus, running a process with 2 threads for 
each open channel puts additional demands on the kernel.  While I 
haven't done a lot of benchmarking, it seems to me that 200 extra 
threads is not a good thing for the kernel.  Having 2,500 open sockets 
connected to the application server presents some challenges as well.  
2,500 open sockets is a load on the app server's OS.  Once again, being 
able to reduce that to 25 open sockets is much better.  Thus the driver 
to figure out how to do stuff over the Manager API.

>>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.
>  
>
I have not found a straight line from the Manager API that allows the 
execution of an application on a given channel with all the normal 
responses (e.g., waiting for DTMF, etc.)  If you can show me how to do 
that, I'd really appreciate it.

>  
>
>>- 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.
>
>  
>
Yep... I can see originating a call to an application, but I cannot see 
how to respond to an existing channel.  For example, how would one 
create the Calling Card sample AGI application by originating a call?

>>- 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.
>
>  
>
To my mind, all AGI scripts represent dynamic dial plans.  I haven't 
done the full analysis, but it seems that dial plans themselves are 
Turing complete.  However, it's really, really hard to build complex 
applications using dial plans.  Thus, AGI script allow for a better 
language to write dynamic dial plans.  My changes are simply to allow 
the AGI commands to be sent to a channel via the Manager API rather than 
via a pipe to a separate process.  In res_agi.c, the next command is 
recalled from the Channel rather than by reading from the pipe.  That's 
the fundimental difference.

>>- 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 ?
>  
>
I don't think that works.  I think the AGI was added to Asterisk because 
the ability to control a channel via the Manager API is limitted.  My 
changes have simply added a new way in which an AGI script can send 
commands to a Channel that's expecting AGI commands.

Thanks,

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20040810/7632c2cb/attachment.htm