[asterisk-dev] Asterisk AGI 2.0 - with doc

[Tilghman Lesher]

On Wednesday 24 October 2007 11:17:02 Zoltan Gaspar wrote:
> ASTERISK AGI 2.0
>
>  This document presumes basic knowledge of asterisk dial plan, dial plan
> applications, and the AGI interface.
>
> Asterisk should be an interface between the phone-calls and the application
> layer that is implemented in a programming language. Asterisk should not
> try to define a language of it's own, it should try to enable the easy

I disagree with this, fundamentally.  AGI was always meant to be a stopgap
method of being able to control calls, prior to the time when a language was
developed to control the calls natively.

> control of the call flows in any programming language using a easy, stable
> and efficient interface. Asterisk developers should not try to make a lot
> of useful (complex) applications, they should pass as much as it can be
> passed, to the call flow control. Asterisk should give a small set of basic
> operations, operations that can implement any feature.
>
> The same way as in the early days of processors Complex Instruction Set
> Computers (CISK) were implemented, Asterisk started with defining high
> level applications adding more and more options and applications to it's
> Dial Plan (Asterisk's Instruction Set). We have come to a great landmark
> where it is needed to rethink the granularity of the commands, to structure
> the types of commands and there parameters so that we will have a full set
> of basic operations. A full set of basic operations is the minimal number
> of basic operations (instructions) that have the property that every other
> operation is a compose of one or more of basic operations.

No argument, there.  We've been trying to do that more in 1.4 and we are
continuing to refine where options should be placed.

> Another new concept that we need to seriously take into consideration are
> the AGI events. In the current AGI implementation there is no mechanism to
> send asynchronous notifications to the AGI script. This would be useful to
> control DTMF, SIP-call flow (an event can be generated when receiving the
> 200 OK for an Invite) events and so on. This could be implemented by
> putting the message in a channel variable and sending a signal to the AGI
> script.

AGI is a very synchronous protocol.  It would be difficult to change it in any
way that would be backwards compatible to be asynchronous.

> *Basic set of operations*
>
> Answer/Hangup/transfer(sip 302)
>
> Playback/MusicOnHold/tones
>
> Place call - create new call leg
>
> Bridge (2 or more call legs)
>
> Record
>
> Get/Set Variable
>
>
>
> *Events *
>
> HandleEvent-> DTMF, sip message

You're going to need to be a little more specific about the type of events.
While there are methods currently to deal with channel-specific events, these
are stopgap measures.  We would really prefer to find channel-nonspecific
methods of interaction that would apply equally well to any protocol.

> *Advanced set of operations*
>
> dial = place call, ringing tone, bridge with current call
>
> meetme = playback, bridge - x call legs, handle events (meetme options)
>
> queue = playback, (operator logic), dial operator(s), bridge the first one
> who answers
>
>
> *Deprecated applications - this have native support in any programming
> language*
>
> goto, gotoif

Disagree.  These are fundamentals which should be supported at any level.

> dbGet, dbPut,dbdel

These are ALREADY deprecated, and dbget and dbput have already been
removed.

> * Advantages of the new architecture*
>
> Giving access to basic commands to scripts the AGI programmer can access
> and control the call-flow in a more exact way. Each step can be enabled or
> disabled, customized sounds can be played back on various events etc. Any
> combination of action is possible making it possible to do exactly what you
> want in the call-flow. The disadvantage of this is that the number of basic
> actions taken is greater then the number of asterisk applications you use
> currently. This can be overcome by creating automated script compilers to
> basic actions, just like when you code in C and the compiler can transform
> this code to a more elaborate, optimised assembler code automatically.
>
> With fewer basic applications a developer has to remember and fewer
> functions with a lot less parameters making it easier to use.

Disagree.  With fewer applications, the programmer has to work a lot harder
to get certain functionality and there is greater chance of screwing up basic
functionality with a typo or missed logic flow.

It is the reason why we have gotten so much protest over the planned removal
of AgentCallBackLogin.  While you can emulate much of the logic in AGI or the
dialplan, it is complicated to the point that many people would prefer not to
have to deal with.

> The basic actions that implement a feature can be saved in a database and
> just loaded from there. The basic user can use them as they are provided,
> as set of actions. An advanced user can play around and modify the
> parameters and fine tune it to be exactly what he wants. With this we can
> give easy settings for basic users and the possibility to modify advanced
> settings for specific needs. It is a lot easier to modify a database value
> then to change the code in app_dial.c if you need a modification in the
> dial application.

I don't know that that is such a good idea.  If anything, it will require a
LOT of extra code, without giving a great deal more functionality than we
already have.

> And saving the best reason for last let's see how a change like this would
> affect the stability of Asterisk core. If we have a stable interface to
> powerful AGI applications the main development of features would move to
> the AGI area. Less changes to the core means it is more stable. Fewer
> applications access the core, so any modification to the core has to be
> tested on a lot less cases. Fewer test cases will result a better testing
> and finally a product with less bugs on this low level.

I don't think that it really follows that simplifying the architecture will
mean less bugs, only that the bugs will change from being inside C code
to being inside some other language.  The advantage to being inside C
is that some things are far easier to solve in a single process space than
they are to solve in multiple process space (as is the case with AGI).

-- 
Tilghman