<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/3340/">https://reviewboard.asterisk.org/r/3340/</a>
</td>
</tr>
</table>
<br />
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">{quote}
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.
{quote}
This is the expected behaviour.
The fact that we use a channel (which happens to be an unreal channel) to inject media into the bridge is an internal implementation detail. From the perspective of the ARI client, the media should be in relation to the bridge, not some magical channel that shows up and then leaves that we never have control over.</pre>
<br />
<p>- Matt Jordan</p>
<br />
<p>On March 12th, 2014, 1:02 p.m. CDT, Jonathan Rose wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers, Joshua Colp and Matt Jordan.</div>
<div>By Jonathan Rose.</div>
<p style="color: grey;"><i>Updated March 12, 2014, 1:02 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-23444">ASTERISK-23444</a>
</div>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
Asterisk
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/branches/12/res/ari/resource_bridges.c <span style="color: grey">(410487)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/3340/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>