<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/2965/">https://reviewboard.asterisk.org/r/2965/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On October 28th, 2013, 6:42 p.m. UTC, <b>rmudgett</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<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/2965/diff/1/?file=47645#file47645line492" style="color: black; font-weight: bold; text-decoration: underline;">/branches/12/res/stasis/control.c</a>
<span style="font-weight: normal;">
(Diff revision 1)
</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; ">struct ast_bridge *stasis_app_get_bridge(struct stasis_app_control *control)</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">492</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="k">static</span> <span class="kt">void</span> <span class="o">*</span><span class="nf">bridge_channel_depart</span><span class="p">(</span><span class="k">struct</span> <span class="n">stasis_app_control</span> <span class="o">*</span><span class="n">control</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">493</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="k">struct</span> <span class="n">ast_channel</span> <span class="o">*</span><span class="n">chan</span><span class="p">,</span> <span class="kt">void</span> <span class="o">*</span><span class="n">data</span><span class="p">)</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I expect you are going to have conflicts with app_control_continue() and app_control_remove_channel_from_bridge() because they depart the channel as well.
I think using departable channels for stasis is just wrong. I suggest looking at app_agent_pool.c for how to reclaim control of a channel when it leaves a bridge.</pre>
</blockquote>
<p>On October 28th, 2013, 7:28 p.m. UTC, <b>Matt Jordan</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Richard: how would using a non-departable channel work for Stasis? In Stasis, the thread that puts the channel into the bridge cannot block while the channel is in the bridge, as it is most likely (and almost certainly not) the PBX thread that the channel used when it entered into the application.</pre>
</blockquote>
<p>On October 29th, 2013, 6:53 p.m. UTC, <b>rmudgett</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Ok. Forget the last two sentences in my original comment.
However, calling app_control_continue() to remove the channel from a bridge is going to have problems with ast_bridge_depart() being called twice. This is not allowed. When app_control_continue() calls ast_bridge_depert() which kicks the channel out of a bridge, the after bridge callback calls the failure callback. With this patch, the normal and failure callbacks do the same thing. At this time, they call ast_bridge_depart() on a channel already being departed.</pre>
</blockquote>
<p>On October 29th, 2013, 6:58 p.m. UTC, <b>Joshua Colp</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">It actually won't. Those occur within the command queue thread and the ast_bridge_depart from the callback is added to the end of that queue. Once it executes and sees that the channel isn't in the bridge it basically becomes a noop.</pre>
</blockquote>
<p>On October 29th, 2013, 7:05 p.m. UTC, <b>rmudgett</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Oh. That works for app_control_continue() and app_control_remove_channel_from_bridge() since they take the channel out of a bridge an keep it out. However, app_control_add_channel_to_bridge() takes the channel out of a bride if it is in one and puts it into another bridge immediately. When the command queue gets around to processing the depart, it is in the new bridge and gets departed again.</pre>
</blockquote>
<p>On October 29th, 2013, 7:17 p.m. UTC, <b>Joshua Colp</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I suppose it would be possible if the pointer was immediately reused (as the bridge_channel is checked in the command queue item).</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">After looking again, app_control_add_channel_to_bridge() will also work because the bridge_channel pointer is never going to be the same. The command queue item has a reference to the bridge_channel.
This issue can be dropped. There doesn't seem to be anything left with this issue. :)</pre>
<br />
<p>- rmudgett</p>
<br />
<p>On October 27th, 2013, 5:19 p.m. UTC, Joshua Colp 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 Joshua Colp.</div>
<p style="color: grey;"><i>Updated Oct. 27, 2013, 5:19 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-22703">ASTERISK-22703</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;">Currently within Stasis there is no guarantee that a channel that leaves a bridge will have ast_bridge_depart called on it. The attached change changes this by having a command queued on the channel that explicitly departs it when it leaves a bridge. This works for outside manipulation, bridge deletion, hangup, etc.
This fixes an issue that the referenced bug exposed. When hanging up while in a bridge no synchronization occurred between the bridge and stasis - causing both to act on a channel at the same time. Depending on how fast the stasis side executed it was possible for the channel itself to be freed and the bridge reference this freed memory.</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;">Deleted a bridge with a channel in it, confirmed with the patch that departure occurs and the bridge is destroyed.
Hungup while in a bridge, confirmed with the patch that departure occurs.</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/stasis/control.c <span style="color: grey">(401922)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/2965/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>