[asterisk-dev] [Code Review] 2668: ARI/bridges: Implement POST /bridge/{id}/play

[jrose]

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



/trunk/apps/confbridge/conf_chan_announce.c
<https://reviewboard.asterisk.org/r/2668/#comment17981>

    This is in response to a bug discovered while working on this.  It doesn't actually address the working issue.



/trunk/main/core_announcer.c
<https://reviewboard.asterisk.org/r/2668/#comment17983>

    This commented out code should be fairly self explanatory... it's a necessary addition in order to keep announcer channel events from being sent to anything listening for events on the bridge being played to.



/trunk/main/core_announcer.c
<https://reviewboard.asterisk.org/r/2668/#comment17982>

    Discovered red space, cleaning it up.



/trunk/res/res_stasis.c
<https://reviewboard.asterisk.org/r/2668/#comment17984>

    Discovered this bug when the channel wasn't included in bridge leave events... caused failed validation.
    
    Technically it doesn't really address the issue, but it's small.



/trunk/res/res_stasis_http_bridges.c
<https://reviewboard.asterisk.org/r/2668/#comment17985>

    Generated by make ari-stubs.  Probably best to just ignore this for review purposes.


- jrose


On July 10, 2013, 10:12 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2668/
> -----------------------------------------------------------
> 
> (Updated July 10, 2013, 10:12 p.m.)
> 
> 
> Review request for Asterisk Developers, David Lee, kmoore, Matt Jordan, and rmudgett.
> 
> 
> Bugs: ASTERISK-21592
>     https://issues.asterisk.org/jira/browse/ASTERISK-21592
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This works in the following manner:
> 
> On receiving the request, we first try to grab a reference to the bridge being played to in stasis. If it exists, we proceed.
> 
> From here, a new type of unreal channel (core_announcer) is created. The ;2 part of this channel is then put into the bridge while the ;1 part is left dangling for a little while. For the rest of the playback starting operations, if anything fails this channel will be hungup.
> 
> Next a control structure is created for the new channel. This is one place where I think there might be contention on how things should be done...
> 
> Most of the rest of this process work in the same way as playback on a channel with the ;1 of the announcer channel being the target of playback. Once the playback is successfully queued, things start to deviate again.
> 
> With all of that in place, a new thread is spun off which will take care of executing the stasis_app_control pool until it is empty. If the thread is created successfully, we will succeed and put out a reply with a playback control object which can then be used to manipulate the playback as it runs.
> 
> Back on the other thread, the control queue will have all of its operations run continuously until the queue is empty at which point the channel will be hung up and the control object disposed of.
> 
> 
> Diffs
> -----
> 
>   /trunk/apps/confbridge/conf_chan_announce.c 393998 
>   /trunk/include/asterisk/_private.h 393998 
>   /trunk/include/asterisk/bridging.h 393998 
>   /trunk/include/asterisk/channel.h 393998 
>   /trunk/include/asterisk/core_announcer.h PRE-CREATION 
>   /trunk/include/asterisk/stasis_app.h 393998 
>   /trunk/include/asterisk/stasis_app_playback.h 393998 
>   /trunk/main/asterisk.c 393998 
>   /trunk/main/bridging.c 393998 
>   /trunk/main/channel.c 393998 
>   /trunk/main/core_announcer.c PRE-CREATION 
>   /trunk/res/res_stasis.c 393998 
>   /trunk/res/res_stasis_http_bridges.c 393998 
>   /trunk/res/res_stasis_http_playback.c 393998 
>   /trunk/res/res_stasis_playback.c 393998 
>   /trunk/res/stasis/control.c 393998 
>   /trunk/res/stasis_http/resource_bridges.h 393998 
>   /trunk/res/stasis_http/resource_bridges.c 393998 
>   /trunk/res/stasis_http/resource_channels.c 393998 
>   /trunk/rest-api/api-docs/bridges.json 393998 
>   /trunk/rest-api/api-docs/playback.json 393998 
> 
> Diff: https://reviewboard.asterisk.org/r/2668/diff/
> 
> 
> Testing
> -------
> 
> Tested playback with channels put into a stasis bridge by a stasis application.  In the process I hammered out a few validation bugs. I also made sure no allocations were left over in the bridging resource or the announcer and unreal channel drivers. That is hardly exhaustive though, as the actual places where objects are being allocated for this process are numerous.
> 
> 
> Thanks,
> 
> jrose
> 
>

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