[asterisk-dev] [Code Review] 2726: ARI - allow other operations to happen while bridged

[David Lee]

> On Aug. 5, 2013, 2:08 p.m., Matt Jordan wrote:
> > /trunk/res/stasis/control.c, line 44
> > <https://reviewboard.asterisk.org/r/2726/diff/2/?file=43452#file43452line44>
> >
> >     What predicate does this condition wait variable guard?

The ao2_container_count of command_queue.


- David


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


On July 31, 2013, 8:17 p.m., David Lee wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2726/
> -----------------------------------------------------------
> 
> (Updated July 31, 2013, 8:17 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan, opticron, and rmudgett.
> 
> 
> Bugs: ASTERISK-22084
>     https://issues.asterisk.org/jira/browse/ASTERISK-22084
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch changes ARI bridging to allow other channel operations to
> happen while the channel is bridged.
> 
> ARI channel operations are designed to queue up and execute
> sequentially. This meant, though, that while a channel was bridged,
> any other channel operations would queue up and execute only after the
> channel left the bridge.
> 
> This patch changes ARI bridging so that channel commands can execute
> while the channel is bridged. For most operations, things simply work
> as expected. The one thing that ended up being a bit odd is recording.
> 
> The current recording implementation will fail when one attempts to
> record a channel that's in a bridge. Note that the bridge itself may
> be recording; it's recording a specific channel in the bridge that
> fails. While this is an annoying limitation, channel recording is
> still very useful for use cases such as voice mail, and bridge
> recording makes up much of the difference for other use cases.
> 
> We may add a /monitor control for channels, which can start a
> MixMonitor on a specific channel. But that would be another patch.
> 
> 
> Diffs
> -----
> 
>   /trunk/res/ari/resource_bridges.c 395904 
>   /trunk/include/asterisk/stasis_app_impl.h 395904 
>   /trunk/include/asterisk/stasis_app.h 395904 
>   /trunk/include/asterisk/bridge_internal.h 395904 
>   /trunk/include/asterisk/bridge_features.h 395904 
>   /trunk/res/res_stasis.c 395904 
>   /trunk/res/res_stasis_bridge_add.c 395904 
>   /trunk/res/res_stasis_bridge_add.exports.in 395904 
>   /trunk/res/res_stasis_playback.c 395904 
>   /trunk/res/res_stasis_recording.c 395904 
>   /trunk/res/stasis/control.h 395904 
>   /trunk/res/stasis/control.c 395904 
> 
> Diff: https://reviewboard.asterisk.org/r/2726/diff/
> 
> 
> Testing
> -------
> 
> * Played to channel
> * Recording to channel
> * Put channel in bridge
>   * Played to channel
>   * Recorded from channel
>   * Played to bridge
>   * Hungup channel from ARI
>   * Hungup channel from client
> 
> 
> Thanks,
> 
> David Lee
> 
>

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