<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/3920/">https://reviewboard.asterisk.org/r/3920/</a>
</td>
</tr>
</table>
<br />
<div>
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://reviewboard.asterisk.org/r/3920/diff/2/?file=66624#file66624line824" style="color: black; font-weight: bold; text-decoration: underline;">/branches/13/res/stasis/control.c</a>
<span style="font-weight: normal;">
(Diff revision 2)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">static void bridge_after_cb(struct ast_channel *chan, void *data)</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">824</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="tb"> </span><span class="n">ast_channel_lock</span><span class="p">(</span><span class="n">chan</span><span class="p">);</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">825</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="tb"> </span><span class="n">ast_softhangup_nolock</span><span class="p">(</span><span class="n">chan</span><span class="p">,</span> <span class="n">hangup_flag</span><span class="p">);</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">826</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="tb"> </span><span class="n">ast_channel_unlock</span><span class="p">(</span><span class="n">chan</span><span class="p">);</span></pre></td>
</tr>
</tbody>
</table>
<pre style="margin-left: 2em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Drop the explicit locks and use ast_softhangup() instead since it locks chan for you.</pre>
</div>
<br />
<p>- opticron</p>
<br />
<p>On August 19th, 2014, 11:10 a.m. CDT, Mark Michelson 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.</div>
<div>By Mark Michelson.</div>
<p style="color: grey;"><i>Updated Aug. 19, 2014, 11:10 a.m.</i></p>
<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;">When a channel is moved from a Stasis bridge to a non-Stasis bridge, the behavior after the non-Stasis bridge dissolves is incorrect. The issue is that since channels are imparted into Stasis bridges as departable rather than independent, control of the channel returns to the main Stasis application loop after the non-Stasis bridge dissolves. From the end-user perspective, this is most odd.
As an example, say that Alice calls into Stasis and is placed into a Stasis bridge. Bob places a call into the dialplan and calls Bridge(Alice,x), requesting to be bridged with Alice and requesting that Alice be hung up if Bob hangs up first. Alice is pulled from the Stasis, is sent a StasisEnd event, and is pushed into the non-Stasis bridge created by the Bridge application. If Bob were to hang up, the expectation would be that Alice's channel would be hung up as well. However, in actuality, Alice remains in the Stasis application and must be hung up manually. Expecations of Alice's post-bridge destination are also not met when passing the 'F' option or no options at all to the Bridge application.
This patch aims to correct the unexpected behavior by detecting the circumstances when Alice's channel leaves the bridging system. If Alice has already had a StasisEnd published when leaving the bridging system, then Stasis's after bridge callback will attempt to direct Alice to where she is intended to go.
To be honest, I'm not a huge fan of this patch, but it gets the job done. The proper way to fix the issue is to devise a method such that channels that enter Stasis bridges are not departable. However, such a change is of larger scope and risk than is acceptable for Asterisk 12 or 13 (in my judgment anyway), so I have gone with the patch seen here. For Asterisk 14, I would recommend a mini-project to make channels in Stasis bridges independent so that the correct behavior is taken care of innately by the bridging system instead.</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;">I created a small ARI application that places any channel that enters the app into a Stasis bridge. I then had a second channel call an extension in the dialplan that called the Bridge application to move the original channel into a non-Stasis bridge. I tested with several options passed to the Bridge application. With the patch, the following occurred:
Bridge(Alice): Channel re-entered Stasis when the non-Stasis bridge dissolved.
Bridge(Alice,F): Channel moved to the priority after the Bridge() application when the non-Stasis bridge dissolved.
Bridge(Alice,x): Channel was hung up after the non-Stasis bridge dissolved.</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/13/res/stasis/control.c <span style="color: grey">(421326)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/3920/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>