<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/2459/">https://reviewboard.asterisk.org/r/2459/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On April 18th, 2013, 9:35 p.m. UTC, <b>Mark Michelson</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;">The behavior of this doesn't seem correct to me. If I've set up jitter buffer parameters in a channel driver config file, but I then use JITTERBUFFER in the dialplan to set up different parameters for the particular call, I'd expect that the jitter buffer set up by JITTERBUFFER would be the one in effect on the bridge. However, instead what happens is that the bridge always uses the configuration as set in the channel driver configuration. This behavior is especially bothersome if someone has enabled jitter buffers in their channel driver config but then used the JITTERBUFFER function to attempt to disable the jitter buffer.
One potential way of fixing the problem would be to call ast_jb_enable_for_channel() during channel creation and remove the call to ast_jb_enable_for_channel() from app_confbridge. This way, the jitter buffer as configured by the channel driver is first applied at channel creation, and then any jitter buffer created by JITTERBUFFER can override the initial jitter buffer configuration. When the channel enters the bridge, the bridge will not need to worry about trying to apply a jitter buffer because it will already be there if configured.</pre>
</blockquote>
<p>On April 18th, 2013, 9:37 p.m. UTC, <b>Mark Michelson</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;">The second paragraph's first sentence should say bridging.c instead of app_confbridge. My mistake.</pre>
</blockquote>
<p>On April 18th, 2013, 9:51 p.m. UTC, <b>jrose</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 discussed this behavior with Matt earlier today and his opinion was that as long as it's consistent, it's alright. I already knew of a perfectly feasible way to fix it simply by providing an option to ast_jb_create_framehook which would reject the new jitterbuffer configuration if one was found from the datastore instead of wiping the one pointed to by the datastore and replacing it. In such a scenario, jitterbuffers applied by bridges would always use this option.
We don't want to create the jitterbuffer on channel creation as that would get in the way of native bridging.</pre>
</blockquote>
</blockquote>
<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 fine with either way, as long as it's consistent and documented.
However, simply preventing any new jitterbuffer configuration doesn't solve Mark's problem either - it only solves it on the initial bridge join. If a channel goes into a bridge and gets a channel configuration provided jitterbuffer, func_jitterbuffer can no longer replace or change the channel provided one. This is the same situation as now.
Channel configuration provided jitter buffers are only being supported for legacy reasons: they are not the preferred way of putting jitter buffers on channels. Mixing and matching the two is already odd - I'm more concerned that the behavior is documented and predictable than anything else.</pre>
<br />
<p>- Matt</p>
<br />
<p>On April 18th, 2013, 7:52 p.m. UTC, jrose 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.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers, Matt Jordan and rmudgett.</div>
<div>By jrose.</div>
<p style="color: grey;"><i>Updated April 18, 2013, 7:52 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-21333">ASTERISK-21333</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 support for applying jitterbuffers based on channel settings for jitterbuffers when bridging channels with simple bridges and softmixed bridges by use of func_jitterbuffer.</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 simple two way calls with SIP with the SIP option jbenable on and off. While on the jitterbuffer is applied as expected and while off it is not applied. Note that this is different from behavior in trunk. In trunk if a SIP channel calls another SIP channel with jbenabled=yes, there generally will not be a jitterbuffer created unless jbforced is set. This is because trunk checks both channels in a two way bridge for the following condition:
if (((!c0_wants_jitter && c1_creates_jitter) || (c0_force_jb && c1_creates_jitter)) && c0_jb_enabled) {
/* jitter buffer creation flag is raised for c0 */
...
}
and since SIP has the wants_jitter flag enabled, the jitter buffer is not applied.
We are no longer reaching across the bridge to look at both channels when doing this, so the jitter buffer will be applied unconditionally on bridging. This means the jbforced option is no longer respected.</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>/team/group/bridge_construction/CHANGES <span style="color: grey">(386018)</span></li>
<li>/team/group/bridge_construction/configs/confbridge.conf.sample <span style="color: grey">(386018)</span></li>
<li>/team/group/bridge_construction/funcs/func_jitterbuffer.c <span style="color: grey">(386018)</span></li>
<li>/team/group/bridge_construction/include/asterisk/abstract_jb.h <span style="color: grey">(386018)</span></li>
<li>/team/group/bridge_construction/main/abstract_jb.c <span style="color: grey">(386018)</span></li>
<li>/team/group/bridge_construction/main/bridging.c <span style="color: grey">(386018)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/2459/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>