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

[Joshua Colp]

On Sat, Mar 24, 2018, at 12:44 PM, Steve Murphy wrote:
> 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.

It's up to what changes the channel (such as Monitor) to indicate that conditions have changed, which results in the bridge re-evaluating the situation and potentially changing the underlying technology. As Monitor is quite old it's entirely possible that it doesn't have the call to do that.

The code is the following:

        if (ast_channel_is_bridged(chan)) {
                ast_channel_set_unbridged_nolock(chan, 1);
        }

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org