<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/4378/">https://reviewboard.asterisk.org/r/4378/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On January 27th, 2015, 9:57 a.m. CST, <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/4378/diff/1/?file=71097#file71097line1998" style="color: black; font-weight: bold; text-decoration: underline;">/branches/13/main/bridge_channel.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; ">int bridge_channel_internal_push(struct ast_bridge_channel *bridge_channel)</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">1998</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="k">if</span> <span class="p">(</span><span class="n">swap</span><span class="p">)</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">1999</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_bridge_channel_leave_bridge</span><span class="p">(</span><span class="n">swap</span><span class="p">,</span> <span class="n">BRIDGE_CHANNEL_STATE_END_NO_DISSOLVE</span><span class="p">,</span> <span class="mi">0</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">2000</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">bridge_channel_internal_pull</span><span class="p">(</span><span class="n">swap</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">2001</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </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;">The reason a swap channel is pulled after the new channel is pushed is because pulling the last channel out of a bridge may dissolve it! This is not good. If the AST_BRIDGE_FLAG_DISSOLVE_EMPTY flag is set the bridge will dissolve. Most mixing bridges are going to have this flag set.
The bridge technology must deal only with the channels that the bridge core has told it about with the technology join/leave callbacks. Otherwise, what is the point of the join/leave technology callbacks if the technology is going to look at the bridge channel member list at inappropriate times?</pre>
</blockquote>
<p>On January 27th, 2015, 10:05 a.m. CST, <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;">That flag can be unset and reset appropriately. The bridge is locked during this operation.
I firmly disagree with your statement about the bridge technology only dealing with channels it has been told about. That means each bridge technology has to DUPLICATE information that the core already has. And the point of the join/leave callbacks is so the bridge technology can react to the act of a channel joining or leaving a bridge. In case of bridge_native_rtp that means setting up local bridging or doing reinvites.</pre>
</blockquote>
<p>On January 27th, 2015, 10:08 a.m. CST, <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;">Additionally: During testing there was always one other channel in the bridge so the dissolve check never kicked in.</pre>
</blockquote>
<p>On January 27th, 2015, 10:29 a.m. CST, <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;">I'm going to agree with Josh on this one. The mixing technologies should not be required to maintain their own state of who is in the bridge and who is not. That feels like the domain of the bridging framework itself. It is not an unreasonable assumption for the mixing technologies to expect that the list of channels in the bridge is accurate during the various callbacks.
It may be worthwhile to be a bit paranoid and do a check on the dissolve flag and unset/reset it through this operation. I can't think of a situation where we only have a single channel in a bridge and we do a swap on it, but I suppose it could theoretically occur.</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;">Rather than temporarily clearing and resetting the AST_BRIDGE_FLAG_DISSOLVE_EMPTY, how about deferring the clearing of bridge_channel->swap till after the swap pull and if the bridge->v_table->push() fails. Then in bridge_channel_dissolve_check() not dissolve the bridge on the last channel leaving if there is a swap pointer.
like this:
bridge_channel_dissolve_check()
{
...
if !bridge_channel->swap && AST_BRIDGE_FLAG_DISSOLVE_EMPTY && !bridge->num_channels
/* Last channel leaving the bridge turns off the lights. */
bridge_dissolve()
return
...
}
bridge_channel_internal_push()
{
...
if bridge->v_table->push fails
...
bridge_channel->swap = NULL
...
return -1
if swap
bridge_channel_internal_pull()
bridge_channel->swap = NULL
...
}</pre>
<br />
<p>- rmudgett</p>
<br />
<p>On January 27th, 2015, 10:34 a.m. CST, 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 Jan. 27, 2015, 10:34 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;">Currently there exists two issues which prevent direct media from being reinvited depending on the scenario:
1. During a swap operation for a brief period of time there will exist 3 channels in a bridge. This is NOT handled by the bridge_native_rtp module and causes it to not reinvite one of the channels that it should when it may be leaving. As it's a reasonable expectation for a bridge technology which can only handle 2 channels to only ever see 2 I've moved the operation which causes the swap channel to leave to before the new channel is actually added to the bridge. This means bridge_native_rtp only sees the two channels it saw previously and reinvites occur as expected.
2. If the res_pjsip_sdp_rtp module received a re-invite *AFTER* the session had been established it did not notify upstream that things such as the bridge_native_rtp module should re-evaluate and potentially reinvite the remote side. The res_pjsip_sdp_rtp module will now do this using the UPDATE_RTP_PEER control frame if an offer is received after the session is established.</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;">Tried various scenarios including attended transfers and multiple Asterisk instances in the path. Previously media would go via the wrong route or not at all. With patch reinvites occur as expected.</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/res_pjsip_sdp_rtp.c <span style="color: grey">(431113)</span></li>
<li>/branches/13/main/bridge_channel.c <span style="color: grey">(431113)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/4378/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>