[asterisk-dev] Asterisk AGI 2.0 - with doc

[Zoltan Gaspar]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20071024/5236fed0/attachment.htm