[asterisk-dev] [Code Review] 3340: ARI: Bridge Playback needs to have PlaybackStarted and PlaybackFinished messages get relayed to the bridge topic

[Joshua Colp]

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



/branches/12/res/ari/resource_bridges.c
<https://reviewboard.asterisk.org/r/3340/#comment20799>

    Add a comment about why forwarding all messages doesn't result in channel events going out.
    
    The reason is because these types of channels are marked as internal, which are sanitized by ARI and not allowed to go out as events.
    
    In the case of the event you are forwarding it is unrelated to the channel and allowed to pass.


- Joshua Colp


On March 12, 2014, 6:02 p.m., Jonathan Rose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3340/
> -----------------------------------------------------------
> 
> (Updated March 12, 2014, 6:02 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp and Matt Jordan.
> 
> 
> Bugs: ASTERISK-23444
>     https://issues.asterisk.org/jira/browse/ASTERISK-23444
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch adds a stasis forwarder to put events from the playback channel (the side of the unreal channel chain responsible for playing sounds to the bridge) into the bridge stasis topic. This way if you are subscribed to the bridge and play sounds to it using ARI, you'll know when those sounds start and stop.
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/ari/resource_bridges.c 410487 
> 
> Diff: https://reviewboard.asterisk.org/r/3340/diff/
> 
> 
> Testing
> -------
> 
> 1. Had a websocket connect using stasis application 'hello'
> 2. Created a bridge using ARI
> 3. Subscribed 'hello' to the bridge created in (2) using ARI
> 4. Used bridge/play to play tt-wesels to the bridge
> 
> Before patch:
> 
> *crickets*
> 
> After patch:
> RESPONSE: {"application":"hello","type":"PlaybackStarted","playback":{"id":"2f88583c-ccee-4340-9fe7-25352c1e6c5e","media_uri":"sound:tt-weasels","target_uri":"bridge:0ec1f7f4-62a3-49d1-9877-734ac987112e","language":"en","state":"playing"}}
> RESPONSE: {"application":"hello","type":"PlaybackFinished","playback":{"id":"2f88583c-ccee-4340-9fe7-25352c1e6c5e","media_uri":"sound:tt-weasels","target_uri":"bridge:0ec1f7f4-62a3-49d1-9877-734ac987112e","language":"en","state":"done"}}
> 
> I also repeated this test with a PJSIP channel in the bridge to confirm that the sounds were starting and stopping at the expected times.
> 
> I only receive the PlaybackStarted and PlaybackFinished events on the bridge topic and not anything like BridgeEnter/Leave events or channel hangup events. The reason for this I believe is because I'm pushing the opposite (unreal;1 vs unreal;2) channel into the bridge from the one actually executing the playback events and I'm canceling the forward before a hangup stasis message is generated. At first I suspected I would receive channel hangup notifications on account of hanging up the channel in the bridge prior to canceling the stasis forward. I'm not sure if that would go against the intent of this patch or not, but it doesn't appear to be the case... probably a matter of the stasis forward being canceled before the playback channel hangs up.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140313/7437b862/attachment.html>