Summary:	ASTERISK-11719: MixMonitor with 'b' option record the 'Ringing' and audio is out of sync
Reporter:	Joel Vandal (jvandal)	Labels:
Date Opened:	2008-03-25 10:43:39	Date Closed:	2008-04-08 10:01:46
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_mixmonitor
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 12296.diff ( 1) callFailLog.zip
Description:	When we use the 'b' option in MixMonitor, the record/audio file is out of sync and the ringing is recorded. By example, if it ring duging 5 seconds, one of the record side/leg will be delayed of 5 seconds. If we dont use the 'b' option, ringing is also recorded but both leg are 'sync'. ****** ADDITIONAL INFORMATION ****** Have same output with(out) with or without 'b' option (ok, no b on MixMonitor on 2nd call)... -- Executing [s@macro-default-dial-1000-000050:53] MixMonitor("Local/XXXXX@default-outgoing-6092,2", "1206458792.2655.WAV|b") in new stack ... -- Executing [s@macro-default-dial-1000-000050:56] Dial("Local/XXXXX@default-outgoing-6092,2", "SIP/XXXXX@1000|60") in new stack -- Called XXXXX@1000  == Begin MixMonitor Recording Local/XXXXX@default-outgoing-6092,2 -- SIP/1000-18f10604 is ringing -- SIP/1000-18f10604 is making progress passing it to Local/XXXXX@default-outgoing-6092,2 -- Local/XXXXX@default-outgoing-6092,1 is ringing -- Local/XXXXX@default-outgoing-6092,1 is making progress passing it to SIP/10.0.0.1-ac2f3794 -- SIP/1000-18f10604 answered Local/XXXXX@default-outgoing-6092,2 -- Local/XXXXX@default-outgoing-6092,1 stopped sounds -- Local/XXXXX@default-outgoing-6092,1 answered SIP/10.0.0.1-ac2f3794
Comments:	By: Joshua C. Colp (jcolp) 2008-03-25 15:31:38 I just spent the last hour trying to reproduce this under various scenarios. Ringing, Progress, Answer with and without 'b'. All worked as expected. What I need to see is the complete console output with debug enabled and turned up to 9. By: Eric Caron (ecaron) 2008-04-05 14:53:11 I'm having this exact issue, it occurs on random calls that go out over our T1-PRI, not any SIP-to-SIP calls. It started occurring after we upgraded to 1.4.18, and persists in 1.4.19 - when we were running 1.4.15 this issue did not exist. The "out of sync" occurs for us whether or not option "a", "b" or nothing is set for the MixMonitor function. I'm also running zaptel-1.4.9.2, libpri-1.4.3, and asterisk-addons-1.4.6. My asterisk is built with just the default options. On Monday (2008-04-07), I'll be able to provide the console output. By: Eric Caron (ecaron) 2008-04-07 09:49:09 I've uploaded the console output (I've done my best to strip it down to just the relevant information) with the debug enabled and turned up to 9. The call is from James Doe on extension 538 to 1112223333. The call is saved as 1207578781.3952.wav. I have the wav file, but since it contains sensitive information, I'm not going to attach it to this bug. Anyone from Digium is welcomed to contact me and I'll email them the wav file. I hope this helps in debugging this issue. By: Joshua C. Colp (jcolp) 2008-04-07 09:58:12 How did you install this Asterisk? I'm not seeing the output I would expect to see from the fixed code... By: Eric Caron (ecaron) 2008-04-07 10:07:09 Its been a gradual upgrade from an initial Trixbox-build to now only having some remnants of Trixbox in the etc configurations. Now everything (zaptel, libpri, asterisk*) is all built from src releases. I can give direct SSH access to the box. I'm on the IRC channel now. By: Joshua C. Colp (jcolp) 2008-04-07 10:10:09 Source releases from the HTTP server or subversion? If you are on IRC please join #asterisk-bugs By: Joshua C. Colp (jcolp) 2008-04-07 10:43:50 Please try the attached patch. It will flush both audio factories once the second starts feeding some in. It should make sure they are in sync. By: Eric Caron (ecaron) 2008-04-07 14:16:50 So far applying the diff against the HTTP release of 1.4.19 fixes our problem. I'll update again in 2 days if the problem is still gone. By: Digium Subversion (svnbot) 2008-04-08 09:59:01 Repository: asterisk Revision: 113296 U   branches/1.4/include/asterisk/slinfactory.h U   branches/1.4/main/audiohook.c U   branches/1.4/main/slinfactory.c ------------------------------------------------------------------------ r113296 | file | 2008-04-08 09:58:54 -0500 (Tue, 08 Apr 2008) | 4 lines If audio suddenly gets fed into one side of a channel after a lapse of frames flush the other factory so that old audio does not remain in the factory causing the sync code to not execute. (closes issue ASTERISK-11719) Reported by: jvandal ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=113296 By: Digium Subversion (svnbot) 2008-04-08 10:01:01 Repository: asterisk Revision: 113297 _U  trunk/ U   trunk/main/audiohook.c ------------------------------------------------------------------------ r113297 | file | 2008-04-08 10:00:57 -0500 (Tue, 08 Apr 2008) | 12 lines Merged revisions 113296 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r113296 | file | 2008-04-08 12:03:43 -0300 (Tue, 08 Apr 2008) | 4 lines If audio suddenly gets fed into one side of a channel after a lapse of frames flush the other factory so that old audio does not remain in the factory causing the sync code to not execute. (closes issue ASTERISK-11719) Reported by: jvandal ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=113297 By: Digium Subversion (svnbot) 2008-04-08 10:01:46 Repository: asterisk Revision: 113298 _U  branches/1.6.0/ U   branches/1.6.0/main/audiohook.c ------------------------------------------------------------------------ r113298 | file | 2008-04-08 10:01:45 -0500 (Tue, 08 Apr 2008) | 20 lines Merged revisions 113297 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r113297 | file | 2008-04-08 12:05:35 -0300 (Tue, 08 Apr 2008) | 12 lines Merged revisions 113296 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r113296 | file | 2008-04-08 12:03:43 -0300 (Tue, 08 Apr 2008) | 4 lines If audio suddenly gets fed into one side of a channel after a lapse of frames flush the other factory so that old audio does not remain in the factory causing the sync code to not execute. (closes issue ASTERISK-11719) Reported by: jvandal ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=113298