Summary:	ASTERISK-16376: Record files with noise and/or audio cutting when using mixmonitor with medium call trafic on Asterisk.
Reporter:	Marco Aurelio (aureliors123)	Labels:
Date Opened:	2010-07-15 19:49:26	Date Closed:
Priority:	Minor	Regression?	No
Status:	Open/New	Components:	Applications/app_mixmonitor
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 0101000029023770833.WAV ( 1) 12_seconds.WAV ( 2) 99727.WAV ( 3) configs.txt ( 4) performance.png ( 5) scenario.jpg
Description:	When recording with mixmonitor, all record files gets with noise an cuts on the audio. The scenario was: - Medium call traffic: More than 60 and less than 120 concurrent calls. - All calls are recorded - Codec: Alaw - Record File format: GSM - Processor load: Never more than 50% - Asterisk Version: 1.6.1.11 - SO Debian 5.0.3 - 2.6.26-2-686 ****** ADDITIONAL INFORMATION ****** - The call always stay clean, even when monitoring using chanspy. - When tryed the same scenario recording WAV format, the record file stay clean. - When tryed recording GSM format with no call trafic, the record file stay clean. - Also realized the same problem at another customers, with different hardware and Asterisk version.
Comments:	By: Marco Aurelio (aureliors123) 2010-07-15 19:52:45 Added record file with issue example. By: Paul Belanger (pabelanger) 2010-07-15 20:44:15 Retest with 1.6.2, it is possible this is already fixed. --- Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.6.0 and 1.6.1 branches has ended. For continued maintenance support please move to the 1.6.2 branch. More information on this change can be found in the release announcement: http://www.asterisk.org/node/49924 By: Leif Madsen (lmadsen) 2010-07-16 10:27:47 Per pabelanger you will need to reproduce this with the Asterisk 1.6.2 branch. By: Marco Aurelio (aureliors123) 2010-07-16 15:04:19 Ok. Will try and feed-back you soon. By: Paul Belanger (pabelanger) 2010-08-04 11:49:22 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information can be found at http://www.asterisk.org/developers/bug-guidelines By: Marco Aurelio (aureliors123) 2010-08-16 22:02:18 Now using Asterisk V1.6.2.10. The same issue still happening. By: Marco Aurelio (aureliors123) 2010-08-16 22:08:33 Added record file with issue example. Recorded at the same scenario described at "Issue Description", but using Asterisk V1.6.2.10. By: Leif Madsen (lmadsen) 2010-08-17 14:00:10 Please provide the dialplan and call scenarios along with sip.conf configuration which is required to reproduce this scenario. By: John Todd (jtodd) 2010-08-17 16:03:13 I'd be interested to know if this problem occurs with ALAW as the stored codec, so you're not transcoding at all.  This could also be a bottleneck in I/O and not have anything to do with Asterisk.   Are you writing to disk, or to a network disk?  What do your disk I/O stats look like when you're pushing significant load?  Are you swapping? By: Leif Madsen (lmadsen) 2010-08-17 16:03:50 This still appears to be some sort of a load related issue, even though the CPU may be 50%, that just proves that is not the bottleneck -- perhaps it's an I/O issue, or some other issue. By: John Todd (jtodd) 2010-08-17 16:04:30 Also: the "noise" part is disturbing and indicates a deeper problem.  Can you please include a file sample where there is "noise" instead of just audio drops? By: Marco Aurelio (aureliors123) 2010-08-17 17:59:54 Just added the config files and an scenario png file. At the file 0101000029023770833.WAV it is possible to realize the “noise” i talked about. Maybe it can be the same audio drops you talked. The problem do not occurred when generate an record file in alaw format, while recording many calls in GSM format. It seems that it is not I/O bottleneck. The files are written directly to an local Sata disk. Not sure about swapping. I´ll provide an full time monitoring of this server to be 100% sure about disk I/O an processor load, but in this particular scenario we have low traffic (never more than 60 simultaneous calls) using the same hardware we use to put, in other customers, more than 100 simultaneous calls. However it is a fact  that the problem gets worse when call traffic is greater. By: Marco Aurelio (aureliors123) 2010-08-20 11:18:08 Just added an screenshot from the performance metrics. By: Marco Aurelio (aureliors123) 2010-08-30 23:05:42 Please, any news about this issue? I´m having serious problems with this behavior. In some cases the record file gets with more than 3 seconds of audio drop. In this very moment i´m being forced to test another boards with “onboard” record feature. By: Leif Madsen (lmadsen) 2010-09-07 15:30:32 Your issue is in queue, please be patient, and we will get to it as time permits and developer resources become available. By: Vila Lima (vlima) 2011-03-02 06:46:10.000-0600 Any update for this issue? Has been in queue for about 6 months and i have the same problem. I try with versions 1.6.2 and new 1.8.3 but same problem. Scenario is the same of aureliors123 (i´m brazilian to), call center about 50 simultanos calls, just one diference, no noise in records only cutting in the end. I guess is a old problem (1.2.x): losing frames. Mixmonitor stop ok in the end of call. This is a serius issue in some countries, such as Brazil, monitoring (record) calls in call centers is mandatory by federal laws. By: Marco Aurelio (aureliors123) 2012-05-17 12:04:01.172-0500 Any update about this issue? By: Marco Aurelio (aureliors123) 2013-04-30 10:16:45.929-0500 At this moment, the same issue still happening. As a workaround we changed to “.wav” (non compressed) format. The problem was reduced, and the audio quality increased a lot, but in some cases still occurs a lack (0.5, 1 second) of audio. We are using a very fast disk to generate de audio files, so I can guarantee that is not I/O bottleneck. Also made TCPDUMP at server and client, trying to find a problem at the client, switches or server network, but the audio captured by Wireshark is always fine, while the same conversation recorded on asterisk presents audio drops. Attached an example of audio drop in an uncompressed file recorded by mixmonitor app (12_seconds.wav).