[asterisk-dev] Asterisk AGI 2.0 - with doc

[Ariel Mónaco]

Sounds like reinventing the wheel to me.

----- Original Message ----- 
From: Zoltan Gaspar
To: asterisk-dev at lists.digium.com
Sent: Wednesday, October 24, 2007 1:17 PM
Subject: [asterisk-dev] Asterisk AGI 2.0 - with doc


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 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.

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.

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

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
dbGet, dbPut,dbdel


 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.

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.

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.


Zoltán Gáspár
Director, IT  Operations
TeamAnswers



_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev



No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.15.1/1078 - Release Date: 18/10/2007 
05:47 p.m.