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 <[email protected]> wrote: > > On Tue, Nov 14, 2017 at 1:54 PM, Sean Bright <[email protected]> > 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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
