|Summary:||ASTERISK-20882: Make AsyncAGI actually asynchronous; support asynchronous media operations|
|Reporter:||Matt Jordan (mjordan)||Labels:||Asterisk12|
|Date Opened:||2013-01-03 21:03:44.000-0600||Date Closed:||2013-01-22 09:16:58.000-0600|
|Description:||AsyncAGI currently is not really asynchronous - while it allows for commands to be queued from AMI/CLI, the asynchronous break command is still queued for synchronous operation on a channel. Additionally, media operations (such as playback on a channel) can be controlled from the channel via DTMF, but cannot be controlled asynchronously by a remote source (AMI). This task is to do two things:
# Make AsyncAGI support asynchronous operations on a channel. AGI commands that act as dialplan execution should still be executed synchronously; AGI commands that query for information or can be executed asynchronously should execute immediately in the context of the thread that dispatches the command.
# Implement fine grained media control. This includes stop, pause, rewind, and fast forward for media being played on a channel. These operations should be initiated by the thread dispatching the command.
As a result of this, it may also be beneficial to place AsyncAGI in it's own separate module.
|Comments:||By: Matt Jordan (mjordan) 2013-01-07 11:28:16.846-0600|
Actually, #1 may not really be needed.
The goal of this is to get external control of media operations. Think AMI acting as the DTMF that a user would send during a control playback. We should be able to get there without #1, since this can be done purely within the context of the AMI thread.
This has the added benefit of not having to hack apart AsyncAGI, which is good. Mostly because the AGI code is a bit of a pile of spaghetti, but also because it limits the scope of the changes.
By: Matt Jordan (mjordan) 2013-01-10 08:20:12.938-0600