<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/1640/">https://reviewboard.asterisk.org/r/1640/</a>
</td>
</tr>
</table>
<br />
<p>Ship it!</p>
<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 put together a test that exercised the scenario that you had and was able to produce some bad side effects from the local bridge not handling that particular frame. As it stands now, if two SIP endpoint's RTP sessions are bridged using the local bridge loop, and the frame is queued up to the local bridge for any reason, the bridge will exit prematurely.
Since the channels currently do not handle the frame (chan_sip absorbs it in sip_indicate; other drivers have no handler for it and will, for the most part, return -1 from their respective indicate methods), having the bridge swallow the frame is at least in line with how the remote_bridge handles it in the case of everything but an UNHOLD. Since, in the local bridge, there isn't any reason to send any additional re-invites in the case of an UNHOLD, there's no reason to send anything up to the channel driver level.
I'll check in the tests for the testsuite after this has been committed, but I'm inclined to think there isn't any additional work that needs to be done to handle this control frame at this time.</pre>
<br />
<p>- Matt</p>
<br />
<p>On December 22nd, 2011, 3:58 a.m., schmidts wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers and jrose.</div>
<div>By schmidts.</div>
<p style="color: grey;"><i>Updated Dec. 22, 2011, 3:58 a.m.</i></p>
<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;">with adding the AST_CONTROL_UPDATE_RTP_PEER control frame music on hold stoped working when a call was put on hold. The problem was that the control frame was only handled when received in a remote_bridge but not in a local_bridge.
By adding the handling of the UPDATE_RTP_PEER frame also to local_bridge moh works again.</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;">tested several calls. Moh is working again when a call is put on hold.</pre>
</td>
</tr>
</table>
<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-19095">ASTERISK-19095</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>team/schmidts/unleash-the-beast/main/rtp_engine.c <span style="color: grey">(348832)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1640/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>