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

[Jonathan Rose]

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

(Updated March 13, 2014, 10:56 a.m.)


Review request for Asterisk Developers, Joshua Colp and Matt Jordan.


Changes
-------

Add recording events as well. It's the exact same logic.

Tested it as well:
RESPONSE: {"application":"hello","type":"RecordingStarted","recording":{"state":"recording","format":"wav","name":"fishsauce","target_uri":"bridge:0dcf0f67-4af8-46bb-9b81-8d72bf09b952"}}
RESPONSE: {"application":"hello","type":"RecordingFinished","recording":{"state":"done","format":"wav","name":"fishsauce","target_uri":"bridge:0dcf0f67-4af8-46bb-9b81-8d72bf09b952"}}


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 (updated)
-----

  /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/f58b0302/attachment-0001.html>