<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">More news--<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I demonstrated that this problem still exists in 13.19.0, although we are still<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">probing/debugging this problem with 13.5.0; if we find a solution, we hope it will apply to all<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">versions of 13, as well as those more recent releases also.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">As I described in a recent letter to asterisk-dev, we have a separate daemon that<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">opens an AMI connection to asterisk. When it spots both channels are joined to a bridge,<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">it issues a StartMonitor AMI action, which invokes res_monitor on Asterisk. It kinda looked<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">like those times when the AMI action arrived in less than a millisecond were more successful<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">than those which came slightly later. To test this theory, I added a millisecond wait to the<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">issuance of the StartMonitor, and roughly doubled the probablility of an empty recording file.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I upped it to 2 msec, and the probability got even higher.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The failed recordings are done with the bridge technology of native_rtp; the successful ones<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">switch from native_rtp to simple_bridge. There appears to be a vanishing opportunity to<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">switch the bridge tech, after which the call to __ast_monitor_start is ineffective. It would appear that<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">the native_rtp tech doesn't honor the monitor structure attached to the channel.<br><br></div>murf<br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 14, 2017 at 2:12 PM, Steve Murphy <span dir="ltr"><<a href="mailto:murf@parsetree.com" target="_blank">murf@parsetree.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Nov 14, 2017 at 1:54 PM, Sean Bright <span dir="ltr"><<a href="mailto:sean.bright@gmail.com" target="_blank">sean.bright@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span>
<div class="m_6908393267334675690m_8849504001936973677moz-cite-prefix">On 11/14/2017 3:10 PM, Steve Murphy
wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:arial,helvetica,sans-serif">This is a
preliminary cry for help... We are seeing a 51.2% 'loss' of
recordings</div>
<div style="font-family:arial,helvetica,sans-serif">on one of our
13.5.0 systems. All calls are are in u-law format. The incoming
calls are offered</div>
<div style="font-family:arial,helvetica,sans-serif">gsm and 729,
among others, but we restrict to only u-law. We only offer ulaw
on outgoing calls.</div>
</blockquote>
<br></span>
To confirm - you are talking about 13.5 and not 13.15, correct?<br>
</div>
</blockquote></div><br><br clear="all"></div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Yes, 13.5.0, is "in production", and we have 13.15 in testing for the next release. We are working on</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">reproducing the high-frequency problem on 13.5.0; once we get that, we can see if 13.15 solves the problem, all other things being</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">equal.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">And if moving to a more late-model asterisk release doesn't work, then we roll up our</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">sleeves and being investigating.</div><span class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div>murf<br>-- <br><div class="m_6908393267334675690gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Steve Murphy<br>ParseTree Corporation<br>57 Lane 17<br>Cody, WY 82414<br>✉ murf at parsetree dot com<br>☎ <a href="tel:(307)%20899-0510" value="+13078990510" target="_blank">307-899-0510</a></div></div></div></div></div></div></div></div>
</span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Steve Murphy<br>ParseTree Corporation<br>57 Lane 17<br>Cody, WY 82414<br>✉ murf at parsetree dot com<br>☎ 307-899-0510</div></div></div></div></div></div></div></div>
</div>