Summary:	ASTERISK-06515: Monitor()'ed calls end up out of sync
Reporter:	Gary Richardson (garyrichardson)	Labels:
Date Opened:	2006-03-09 15:43:53.000-0600	Date Closed:	2006-05-19 13:32:21
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_features
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When recording calls with Monitor(), the audio from the two call legs is out of sync. The calls I'm recording are typically around an hour long. Within 3 minutes, the call participants are talking over each other. I'm using the following macro for recording calls: [macro-record-call] exten => s,1,Monitor(wav,${CALLERIDNAME}-${ARG1:1}-${STRFTIME(,,%Y%m%d%H%M%S)},mb) exten => s,2,Goto(to-pstn,${ARG1},1) ****** ADDITIONAL INFORMATION ****** The box that is doing the recording is: - 2.4GHz P4 with HT enabled - 1GB of ram - 3ware raid controller - mirrored hard drive - CentOS 4.2 - sox 12.17.5-3 - all calls going through SIP. I also experienced this problem with 1.2.4. I'm now trying to Set(MONITOR_EXEC,/usr/bin/soxmix) so that the call legs are not deleted. I have to wait for a call to be recorded before I have any results.. Thanks.
Comments:	By: Olle Johansson (oej) 2006-03-14 01:34:26.000-0600 What channels are you using for each call leg? By: Gary Richardson (garyrichardson) 2006-03-14 09:49:35.000-0600 The phones are Cisco 79[46]0's with the 7.4 SIP image. Calls to the PSTN are forwarded to a Cisco 2811 via SIP. The calls then go out a PRI attached to the Cisco router. Does that help? By: wes (whoiswes) 2006-03-22 17:06:28.000-0600 We have the same issue on 1.2.4, also using the 'm' and 'b' flags for the monitor command. On two other boxes running 1.2.4, we are NOT using the 'b' flag, and, to my knowledge, those boxes are not having any issues with the Monitor app. We record every inbound and outbound call, so I should have heard if any of the recordings have had issues. I am going to remove the 'b' flag from the problematic server to see if that resolves the issue - perhaps that will give us some further info. Sorry this isn't more technical, and please let me know if I can add anything further. wes By: wes (whoiswes) 2006-03-24 08:42:50.000-0600 Well, removing the 'b' flag did not resolve the issue for us.  I am going to be wiping the affected server clean later today (it was our first build, and thus isn't optimized for * at all) and will see if the issue clears up after that point. By: wes (whoiswes) 2006-04-07 14:12:52 Sorry I didn't update sooner - after a complete wipe of the server and doing a fresh install of Fedora Core 4/Asterisk 1.2.4/Zaptel 1.2.4, the problem still exists. We use a mix of Polycom 501's and Counterpath's Eyebeam softphone, and out of 8  * servers, this is the only server that has this issue.  We are using a collections software package to initiate many of our outbound calls by writing CALL files to the asterisk spool directory.  Calls are routed out via robbed-bit T1's. If there is anything I can do to help debug this issue, please let me know. EDIT:  we were running sox 12.17.7, i updated it to 12.17.9, will update if that helps. By: Serge Vecher (serge-v) 2006-04-07 14:59:48 whoiswes: could you please also upgrade to the latest asterisk (1.2.6) and zaptel (1.2.5) distributions as well? By: Andrey S Pankov (casper) 2006-04-07 15:11:58 What happens if you soxmix both call legs on a not-busy-at-all box (removing 'm' from options first and not removing 'b')? By: Abhay Gupta (agupta) 2006-04-08 02:44:48 check the channel.c file /* uncomment if you have problems with 'monitoring' synchronized files */ #if 0 #define MONITOR_CONSTANT_DELAY #define MONITOR_DELAY 150 * 8 /* 150 ms of MONITORING DELAY */ #endif uncomment and compile , the problem will be solved. By: Andrey S Pankov (casper) 2006-04-10 12:08:27 Did you try what agupta suggested? By: wes (whoiswes) 2006-04-14 10:12:08 been busy working on several projects, one of which was to update all our boxes to the current zaptel release, and update any older boxes to 1.2.4. i will probably try updating to 1.2.6 on the affected box, and if that doesn't work, i will try the channel.c hack posted above.  this might take a while, but i will post back if/when i have any definitive results. thanks! By: Serge Vecher (serge-v) 2006-05-08 00:13:19 is this still an issue? Does moving to MixMonitor() resolve the issue? By: Nic Bellamy (nic_bellamy) 2006-05-10 17:18:28 I've only had this happen once that I'm sure of. The setup was Asterisk 1.2.6 (IIRC) with a TE110P (E1/EuroISDN) on a dual Xeon box. The call came in via the PRI, into a test dialplan that monitored the call, answered, then played back 60 seconds worth of impulse responses. The calls legs were _not_ mixed at the end, as I wanted to look at each separately. What I saw was not an offset, but a drift - the two files started off synchronised, but slowly drifed apart - by about 130ms over the 60-odd second call. I'm about to do some more fiddling on this machine, so I'll see if I can reproduce it (it's now running Asterisk 1.2.7.1). -- NicB By: Serge Vecher (serge-v) 2006-05-19 13:31:52 nic_bellamy: if you are able to reliable reproduce the issue in 1.2.7.1, please describe how to do it and ask for the bugmarshall on #asterisk-dev or -bugs channel to reopen the issue. Thanks.