<h1>ASTERISK AGI 2.0 </h1>
<p> This document presumes basic knowledge of asterisk dial plan, dial plan applications, and the AGI interface. </p>
<p> </p>
<p> </p>
<p>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.
</p>
<p> </p>
<p>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.
</p>
<p> </p>
<p>Another new concept that we need to seriously take into consideration are the AGI events. In the current <font style="BACKGROUND-COLOR: #ffff00">AGI</font> 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.
</p>
<p> </p>
<p><b>Basic set of operations</b> </p>
<p> </p>
<p>Answer/Hangup/transfer(sip 302) </p>
<p>Playback/MusicOnHold/tones </p>
<p>Place call - create new call leg </p>
<p>Bridge (2 or more call legs) </p>
<p>Record </p>
<p>Get/Set Variable </p>
<p> </p>
<p><b>Events </b></p>
<p>HandleEvent-> DTMF, sip message </p>
<p> </p>
<p><b>Advanced set of operations</b> </p>
<p>dial = place call, ringing tone, bridge with current call </p>
<p>meetme = playback, bridge - x call legs, handle events (meetme options) </p>
<p>queue = playback, (operator logic), dial operator(s), bridge the first one who answers </p>
<p> </p>
<p> </p>
<p><b>Deprecated applications - this have native support in any programming language</b> </p>
<p>goto, gotoif </p>
<p>dbGet, dbPut,dbdel </p>
<p> </p>
<div id="lv7j" style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 1em; PADDING-TOP: 1em; TEXT-ALIGN: left"><img src="http://docs.google.com/a/teamanswers.com/File?id=dcxr8kn4_15f2nbmncf"> </div>
<p><b> Advantages of the new architecture</b> </p>
<p> </p>
<p>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.
</p>
<p> </p>
<p>With fewer basic applications a developer has to remember and fewer functions with a lot less parameters making it easier to use. </p>
<p> </p>
<p>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.
</p>
<p> </p>
<p>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.
</p>
<p> </p>
<p> </p>
<p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt"><b><span lang="HU" style="FONT-SIZE: 8.5pt; COLOR: #333333; FONT-FAMILY: Verdana">Zoltán Gáspár</span></b><span lang="HU"> </span></p>
<p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt"><span lang="HU" style="FONT-SIZE: 8.5pt; COLOR: #333333; FONT-FAMILY: Verdana">Director, IT Operations</span></p>
<p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt"><span lang="HU" style="FONT-SIZE: 8.5pt; COLOR: #333333; FONT-FAMILY: Verdana">TeamAnswers</span></p>