[Asterisk-Dev] Integration of AGI and Management API

[mattf]

When you say 100 concurrent channels do you mean 50 SIP phones connected to
50 Zap channels or 100 SIP phones in conversations with 100 other end
points?

Have you done any load testing ? What kind of system configuration are you
planning on?

How exactly would you go about "creating" a calling card AGI through the
manager?

What's wrong with just using AGI scripts?

A busy Asterisk server with 100 concurrent manager connections will not
work, especially if you want to actually use those manager connecitons for
anything.

Attempting to run interactive programs like AGIs through the manager API
would complicate the managerAPI by adding many new inputs, outputs and
parsing rules to it and would slow it down even more, not to mention the
fact that you are depending on that client socket connection to keep flowing
perfectly in order to run your phone system and I can tell you that the
manager API is not fault tolerant enough to handle that kind of volume,
complexity and data-delivery-assurance with any kind of reliability.

The manager is enough of a bottleneck as it is now on high-volume systems. I
think you will find that adding a lot more functionality to the managerAPI
on the system loads that you mention will slow things down and cause a lower
capacity for your servers in the end.

MATT---


-----Original Message-----
From: David Pollak [mailto:dpp-asterisk at projectsinmotion.com]
Sent: Tuesday, August 10, 2004 10:58 PM
To: asterisk-dev at lists.digium.com
Subject: Re: [Asterisk-Dev] Integration of AGI and Management API



  
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.  

 

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.
  

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?


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.

  
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