<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Chris,<br>
<br>
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.<br>
<br>
<br>
C. Maj wrote:<br>
<blockquote cite="midPine.LNX.4.56.0408101956510.1655@screw" type="cite">
<pre wrap="">On Tue, 10 Aug 2004, David Pollak waxed:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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 ?
</pre>
</blockquote>
My application will initially have 25 Asterisk servers managed by 1
application server. That number must be scalable to at least 500
Asterisk servers.<br>
<br>
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.
<blockquote cite="midPine.LNX.4.56.0408101956510.1655@screw" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<blockquote cite="midPine.LNX.4.56.0408101956510.1655@screw" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">- 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
</pre>
</blockquote>
<pre wrap=""><!---->
This could be accomplished by Originating a call to an
application. Specifically, the AGI application. So this
functionality at least is already available.
</pre>
</blockquote>
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?<br>
<blockquote cite="midPine.LNX.4.56.0408101956510.1655@screw" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">- 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)
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<blockquote cite="midPine.LNX.4.56.0408101956510.1655@screw" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">- 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?
</pre>
</blockquote>
<pre wrap=""><!---->
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 ?
</pre>
</blockquote>
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.<br>
<br>
Thanks,<br>
<br>
David<br>
<br>
</body>
</html>