[asterisk-dev] Weirdness-- intermittent loss of recordings w/ 13.5.0

[Steve Murphy]

More news--

I demonstrated that this problem still exists in 13.19.0, although we are
still
probing/debugging this problem with 13.5.0; if we find a solution, we hope
it will apply to all
versions of 13, as well as those more recent releases also.

As I described in a recent letter to asterisk-dev, we have a separate
daemon that
opens an AMI connection to asterisk. When it spots both channels are joined
to a bridge,
it issues a StartMonitor AMI action, which invokes res_monitor on Asterisk.
It kinda looked
like those times when the AMI action arrived in less than a millisecond
were more successful
than those which came slightly later. To test this theory, I added a
millisecond wait to the
issuance of the StartMonitor, and roughly doubled the probablility of an
empty recording file.
I upped it to 2 msec, and the probability got even higher.

The failed recordings are done with the bridge technology of native_rtp;
the successful ones
switch from native_rtp to simple_bridge. There appears to be a vanishing
opportunity to
switch the bridge tech, after which the call to __ast_monitor_start is
ineffective. It would appear that
the native_rtp tech doesn't honor the monitor structure attached to the
channel.

murf


On Tue, Nov 14, 2017 at 2:12 PM, Steve Murphy <murf at parsetree.com> wrote:

>
> On Tue, Nov 14, 2017 at 1:54 PM, Sean Bright <sean.bright at gmail.com>
> wrote:
>
>> On 11/14/2017 3:10 PM, Steve Murphy wrote:
>>
>> This is a preliminary cry for help... We are seeing a 51.2% 'loss' of
>> recordings
>> on one of our 13.5.0 systems. All calls are are in u-law format. The
>> incoming calls are offered
>> gsm and 729, among others,  but we restrict to only u-law. We only offer
>> ulaw on outgoing calls.
>>
>>
>> To confirm - you are talking about 13.5 and not 13.15, correct?
>>
>
>
> Yes, 13.5.0, is "in production", and we have 13.15 in testing for the next
> release. We are working on
> 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
> equal.
>
> And if moving to a more late-model asterisk release doesn't work, then we
> roll up our
> sleeves and being investigating.
>
> murf
> --
>
> Steve Murphy
> ParseTree Corporation
> 57 Lane 17
> Cody, WY 82414
> ✉  murf at parsetree dot com
> ☎ 307-899-0510 <(307)%20899-0510>
>



-- 

Steve Murphy
ParseTree Corporation
57 Lane 17
Cody, WY 82414
✉  murf at parsetree dot com
☎ 307-899-0510
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20180324/c63f1637/attachment.html>