Summary:ASTERISK-00085: Monitor application doesn't synchronize audio legs in file
Reporter:John Todd (jtodd)Labels:
Date Opened:2003-08-11 22:03:11Date Closed:2004-09-25 02:21:18
Versions:Frequency of
Description:The monitor application waits until an "Answer" event on the second leg of a call before starting to record audio, which results in files that are unsynchronized when combined together.  In other words, if it takes 5 seconds for the remote party to pick up the line, then audio from the caller will be 5 seconds ahead of the audio from the called party.  This doesn't work so well, especially when the calls are muxed together using soxmix.  Perhaps some type of silence buffering into the second leg audio channel so that both legs are recorded at the same time?  Another thing to think about: what happens if packet loss occurrs on the inbound leg of a VoIP call? Do things gradually get out of phase?  Can the silence buffering happen in this area, as well?
Comments:By: Brian West (bkw918) 2003-08-17 14:41:15

Good point.  I duplicated this bug report.  Mark has since closed the other.  But I am also looking at this feature.  I used your record-on macros in your example extensions.conf file ...

By: Brian West (bkw918) 2003-08-17 19:09:36


I had an idea.  The end times for the two files are the same no matter if its answered 20, 40 or whatever later.


If that gives you an idea of what I have done.  I reverse the in and out mux them. Then reverse it back.  Its an extra step right now but atleast the files are in sync.


By: Brian West (bkw918) 2003-08-17 19:46:20

Also using res_monitor and trying to park a call you will core *

check bug ASTERISK-116

edited on: 08-18-03 00:34

By: emilio (emilio) 2003-08-22 10:55:19

While doing a recording with monitor, if
GET DATA is used, the timeiout period, the "silence" (not the dtmf tones) is not recorded by the monitor.

When the -in and -out files are genereated they can't be mixed in synch because the are missing pieces of recordings inside the -out file.

By: John Todd (jtodd) 2003-09-08 21:14:23

Is this now fixed?  bkw was mentioning that this had been resolved with "some patches" kram had made to the system a week or so ago, but I hadn't seen any specific mention of it.  I do seem to get the ringing in my recordings, so it appears to be fixed, however, I am uncertain if that is a complete solution.  Does it handle lost packets or other instances where the two legs of a call might get "mis-aligned"?

By: Brian West (bkw918) 2003-09-08 21:17:48

2003-08-28 16:02  martinp

* channel.c (1.42), formats/format_g729.c (1.6),
formats/format_gsm.c (1.6), formats/format_mp3.c (1.4),
formats/format_pcm.c (1.6), formats/format_pcm_alaw.c (1.7),
formats/format_wav.c (1.6), formats/format_wav_gsm.c (1.6),
include/asterisk/channel.h (1.18), include/asterisk/file.h (1.7):
Fix synchronization of recorded files when using Monitor

By: John Todd (jtodd) 2003-09-08 22:59:09

OK, so I'll mark as resolved.  If the legs don't sync up after packet loss, that'll be a different bug.  :)