[asterisk-dev] [Code Review]: ConfbridgeExecAction AMI Command

[Matt Jordan]

> On May 14, 2012, 12:09 p.m., opticron wrote:
> > If two ConfbridgeExecAction commands are run near the same time, the second (and subsequent) commands will not be run as expected if they are added to the deferred list before the channel has exited the deferred state.  The other actions will remain in the deferred queue until the next ConfbridgeExecAction puts the channel into the deferred state (at which point the new action will be added to the end of the queue and not performed).

Good catch - thanks!


> On May 14, 2012, 12:09 p.m., opticron wrote:
> > /trunk/main/bridging.c, line 830
> > <https://reviewboard.asterisk.org/r/1902/diff/3/?file=27860#file27860line830>
> >
> >     This function should execute deferreds until the list is empty.

Well, not quite.  This approach would have two drawbacks:
1) If a callback issued another deferred, we'd end up in an endless loop
2) If some other thread issues a large number of deferred requests - and continues to do so - we could end up starving the normal channel operations, DTMF framehooks, etc.

Instead, the channel state requests should be queued up and processed as they arrive.  The exception would be any state change that removes a bridge_channel from the bridge, which would be processed as soon as they arrive (or as soon as possible).


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1902/#review6211
-----------------------------------------------------------


On May 14, 2012, 9:08 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1902/
> -----------------------------------------------------------
> 
> (Updated May 14, 2012, 9:08 a.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Summary
> -------
> 
> Currently, most actions that are executed upon a channel in a conference (increasing/decreasing listening volume, playing back a sound on a channel, etc.) are handled via DTMF menus associated with a user profile.  While this suffices for scenarios where a user initiates an action upon themselves, it does not account for scenarios where a third party application wants to interact with the channels in a ConfBridge.  While there are a handful of AMI commands that allow for external interaction with the channels in the conference, they are currently limited to a subset of the defined actions.
> 
> Rather then add individual AMI commands for each confbridge action, this patch adds a single new AMI command for ConfBridge, ConfbridgeExecAction.  The command lets you execute any of the ConfBridge actions on a channel in the conference.
> 
> In order to facilitate this, a new mechanism has been added to the bridging layer to allow for a callback function to be executed at the next convenient moment on a bridged channel's thread.  This lets a user of the bridging layer defer execution of some function until such a time that the bridging layer determines that it is safe to execute that action on the channel's thread.
> 
> Example Usage:
> 
> Action: ConfbridgeExecAction
> Conference: 1
> Channel: Local/blah at foo
> Actions: increase_listening_volume,playback(tt-monkeys)
> 
> This would playback monkeys to the offending channel.  Very loudly.
> 
> 
> Diffs
> -----
> 
>   /trunk/CHANGES 364579 
>   /trunk/apps/app_confbridge.c 364788 
>   /trunk/apps/confbridge/conf_config_parser.c 364579 
>   /trunk/apps/confbridge/include/confbridge.h 364579 
>   /trunk/include/asterisk/bridging.h 364579 
>   /trunk/main/bridging.c 364579 
> 
> Diff: https://reviewboard.asterisk.org/r/1902/diff
> 
> 
> Testing
> -------
> 
> Initial testing using a test in the Asterisk Test Suite verified proper behavior of the AMI command.  The channel was properly suspended from the bridging layer, the playback confbridge action was executed, and the channel was placed back into the bridging layer.  All of this was similar to what would occur if the same action was triggered using a DTMF menu.
> 
> Note that a test case is being written to handle the various actions, but will be posted under a separate review.
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120515/ab706ea9/attachment-0001.htm>