[Home]

Summary:ASTERISK-10796: [patch] Execute AGI from the CLI and the manager interface
Reporter:Moises Silva (moy)Labels:
Date Opened:2007-11-17 23:09:59.000-0600Date Closed:2008-01-03 00:13:15.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_dynapp-rev89394.c.patch
( 1) asterisk-async-AGI-rev91983.patch
( 2) asterisk-async-AGI-rev92002.patch
( 3) asterisk-async-AGI-rev92324.patch
( 4) asyncagi-rev89442.patch
Description:This new application allow to take control of the applications executed using the Asterisk console or via AMI.

[default]
exten => _X.,1,Answer()
exten => _X.,2,DynamicApp()
exten => _X.,3,Hangup()

Once the channel enter DynamicApp, it will wait there for applications to execute. Applications may arrive either from the console or AMI, like this:

*CLI> dynapp SIP/testing-09124338 Playback hello-world

That will execute Playback application with hello-world arguments.

The same using AMI:

Action: AddDynApp
Channel: SIP/testing-09124338
App: Playback
Data: hello-world

I need some help of you guys to check locking/unlocking of channels, I think I am doing right, but I am still unsure about some cases. It seems to work though.

Comments and corrections are always welcomed.
Comments:By: Moises Silva (moy) 2007-11-23 11:03:27.000-0600

After trying to use heavily app_dynapp to do some stuff I was used to do with MAGI, I found several limitations ( not being able to query variables, get execution notification with ID etc ). So I changed my mind, and implemented an Asynchronous AGI. This is pretty much a new implementation of David Pollak's idea of integrating AGI and the manager. I just implemented it using channel datastores to avoid patching the core and keep the changes mostly in res/res_agi.c.

So here is the idea.

You can send calls to AGI(agi:async). That will put the call to wait for commands and it will send an event to the manager with the same data an AGI script receives. Now the manager can start sending AGI commands using the channel name and a command id. When the AGI command is executed, an event with the command id is launched with the result of the AGI command. AGI data is urlencoded for easy management and avoid it to interfer with the manager protocol, just in case.

Additionally you can also execute AGI commands from the Asterisk console:

 tcore*CLI> agi exec SIP/testing-09a5b960 "EXEC startmusiconhold"
 tcore*CLI> agi exec SIP/testing-09a5b960 "EXEC stopmusiconhold"
 tcore*CLI> agi exec SIP/testing-09a5b960 "EXEC Dial(Agent/23)"

This means one could actually implement a queue using the manager. You can receive calls and put them in AGI(agi:async) and put them on hold. When you get some event of an Agent being free to receive calls, the manager can stop the music on hold and execute Dial to send the call, etc etc.

The CLI feature is mostly useful only for testing.

So, can somebody delete the app_dynapp patch and consider the asyncagi patch only.

Thanks!

By: Moises Silva (moy) 2007-12-08 14:42:13.000-0600

Updated patch for latest trunk: asterisk-async-AGI-rev91983.patch

I have also added more comments to the code.

By: Moises Silva (moy) 2007-12-08 14:43:57.000-0600

Also it would be nice if you can change the bug title to better match my intentions now. Something like "[patch] Execute AGI from the CLI and the manager interface"

By: Moises Silva (moy) 2007-12-10 08:25:41.000-0600

More updates to the patch. Fixed a small error introduced in the last one where I used the same value for EVENT_FLAG_AGI than for EVENT_FLAG_CDR. Fixed missing return statement when allocation failed.

By: Eliel Sardanons (eliel) 2007-12-10 08:40:15.000-0600

Could you give an example of when this application could be usefull?

Thanks

By: Moises Silva (moy) 2007-12-10 09:27:10.000-0600

I thought I had already done that.

You can implement your own queue system from a scripting language without using any of the native queues facilities provided by Asterisk. You implement your own blind transfer, transfer, parking and other type of services from a scripting language, which means, you will get less error prone implementations.

By: Eliel Sardanons (eliel) 2007-12-10 09:42:29.000-0600

ah, ok, now I see it, sorry for asking again.

Thanks!

By: Matthew Nicholson (mnicholson) 2007-12-11 10:48:48.000-0600

This exact same thing could be done using FastAGI and AMI in the same application.  You would still have two APIs, but you have all the data in one app.  This is how adhearsion works.

By: Moises Silva (moy) 2007-12-11 11:49:46.000-0600

mnicholson: I have not tried Adhearsion, sounds like a pretty cool project. Similar in goals to the closed source framework we developed in PHP at the company I worked for 2 years ago. I would have to try it to be able to give an educated opinion and point out the differences.

In the other hand, I do know using FastAGI is a feasible way of approaching the same problem. But I don't need nor want a separate TCP socket for each call.

And what about the CLI AGI feature! ain't that cool? :)

Seriously, discussion can continue in asterisk-dev, the "Unified Asterisk Interface" topic is getting hot.

By: Tilghman Lesher (tilghman) 2007-12-11 13:00:16.000-0600

Okay, couple of things:

1) you're open-coding ast_uri_encode().  Please use the API directly, instead of coding your own version.
2) Wrap comments at 80 characters, please.
3) The command to exit should be "asyncagi break", not the other way around.
4) Use the CALL level of AMI control, instead of inventing a new one.
5) I don't see what differentiates AGI_RESULT_SUCCESS_ASYNC from AGI_RESULT_SUCCESS in a way that you need your own separate status.  Please explain or remove it.

By: Moises Silva (moy) 2007-12-11 14:01:29.000-0600

Thanks for your comments Tilghman.

1. Thanks for pointing that out.

2. Done.

3. Done.

4. Done.

5. Just after launch_script, a verification is done in order to call run_agi(). For the Async AGI, we don't want to run_agi(), since launch_script does all the work. That's why AGI_RESULT_SUCCESS_ASYNC is needed. If you don't like it or find a good reason to try to avoid that return code, we can work around it in some other way.

The patch is updated for revision 92324.

By: Digium Subversion (svnbot) 2008-01-03 00:13:15.000-0600

Repository: asterisk
Revision: 96174

U   trunk/res/res_agi.c

------------------------------------------------------------------------
r96174 | tilghman | 2008-01-03 00:13:13 -0600 (Thu, 03 Jan 2008) | 4 lines

Add coordination between AMI and AGI applications, with an asyncagi method
Feature proposed and patched by: moy
(Closes issue ASTERISK-10796)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=96174