[Home]

Summary:ASTERISK-15859: [patch] MixMonitor records shorter files than the call duration.
Reporter:Geoff Mina (geoff2010)Labels:
Date Opened:2010-03-23 00:38:48Date Closed:2010-04-16 16:47:02
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dw-M17078.patch
Description:Hello,
I am having an 100% reproducible issue with MixMonitor.  My recording files are being truncated by a few seconds.  

I am a 100% SIP deployment.  No dahdi channels or anything.

I have narrowed it down to a particular scenario which causes the problem.  It appears the issue is related to delaying the Answer() in the dial plan.  Basically, i have a dialplan which does this:

[start]
exten => _NXXNXXXXXX,1,Ringing()
exten => _NXXNXXXXXX,n,AGI(agi://localhost/dosomething.agi)
exten => _NXXNXXXXXX,n,Hangup()


[conference]
exten => _NXXNXXXXXX,1,MixMonitor(/home/recordings/blah.WAV,a)
exten => _NXXNXXXXXX,n,Conference(1234)
exten => _NXXNXXXXXX,n,Hangup()


In that scenario, the FastAGI script would do a lookup.  Depending on the results of the lookup, it will do an Answer() and then a redirect to the [conference] context where the MixMonitor would be attached.  We are basically looking for a condition, so sometimes the FastAGI could wait up to 20 or 30 seconds before returning an Answer().

If I modify the flow and return Answer() immediately, the recording file will be perfect.  The way I have it flowed out above - I lose 3-7 seconds of audio at the end of the file.  

If there is anything else I can provide, i would be happy to.  

Thanks.
Comments:By: Dwayne Hubbard (dhubbard) 2010-04-05 22:31:58

I am able to reproduce this issue on the reporter's equipment.  May have a fix available very soon.
By: Dwayne Hubbard (dhubbard) 2010-04-06 01:13:50

Potential fix has been applied to reporter's systems.
By: Geoff Mina (geoff2010) 2010-04-06 08:05:36

I have applied the patch to my 1.4.26 machines and will let them run in a limited production environment today.  Initial testing is showing that the issue has been resolved.

I'll post further confirmation later today.

thanks.
By: Geoff Mina (geoff2010) 2010-04-06 21:04:18

We have run the updated code on the 1.4.26 branch all day.  All recordings appear to be 100% normal.  From my point-of-view, problem solved.

Thanks for all your efforts on this one, Dwayne!
By: Dwayne Hubbard (dhubbard) 2010-04-07 16:55:08

Updated issue to include the reviewboard link ( https://reviewboard.asterisk.org/r/611/ )


By: Dwayne Hubbard (dhubbard) 2010-04-07 17:10:27

Uploaded changes to 1.4.30 (dw-M17078.patch)
By: Leif Madsen (lmadsen) 2010-04-14 14:22:26

Update on this? Looks like someone gave it a ship it, and someone else just asked for clarification on another part of the code?
By: Dwayne Hubbard (dhubbard) 2010-04-16 13:31:58

Reviewboard was updated to answer the outstanding question.
By: Digium Subversion (svnbot) 2010-04-16 16:15:45

Repository: asterisk
Revision: 257686

U   branches/1.4/apps/app_mixmonitor.c

------------------------------------------------------------------------
r257686 | dhubbard | 2010-04-16 16:15:44 -0500 (Fri, 16 Apr 2010) | 21 lines

Make the mixmonitor thread process audio frames faster

Mantis issue 17078 reports MixMonitor recordings have shorter durations than
the call duration.  This was because the mixmonitor thread was not processing
frames from the audiohook fast enough.  The mixmonitor thread would slowly fall
behind the most recent audio frame and when the channel hangs up, the mixmonitor
thread would exit without processing the same number of frames as the channel;
leaving the mixmonitor recording shorter than actual call duration.

This revision fixes this issue by moving the ast_audiohook_trigger_wait() and
the subsequent audiohook.status check into the block where the
ast_audiohook_read_frame() function returns NULL.

(closes issue ASTERISK-15859)
Reported by: geoff2010
Patches:
     dw-M17078.patch uploaded by dhubbard (license 733)
Tested by: dhubbard, geoff2010

Review: https://reviewboard.asterisk.org/r/611/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=257686
By: Digium Subversion (svnbot) 2010-04-16 16:22:31

Repository: asterisk
Revision: 257713

_U  trunk/
U   trunk/apps/app_mixmonitor.c

------------------------------------------------------------------------
r257713 | dhubbard | 2010-04-16 16:22:31 -0500 (Fri, 16 Apr 2010) | 28 lines

Merged revisions 257686 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r257686 | dhubbard | 2010-04-16 16:15:43 -0500 (Fri, 16 Apr 2010) | 21 lines
 
 Make the mixmonitor thread process audio frames faster
 
 Mantis issue 17078 reports MixMonitor recordings have shorter durations than
 the call duration.  This was because the mixmonitor thread was not processing
 frames from the audiohook fast enough.  The mixmonitor thread would slowly fall
 behind the most recent audio frame and when the channel hangs up, the mixmonitor
 thread would exit without processing the same number of frames as the channel;
 leaving the mixmonitor recording shorter than actual call duration.
 
 This revision fixes this issue by moving the ast_audiohook_trigger_wait() and
 the subsequent audiohook.status check into the block where the
 ast_audiohook_read_frame() function returns NULL.
 
 (closes issue ASTERISK-15859)
 Reported by: geoff2010
 Patches:
       dw-M17078.patch uploaded by dhubbard (license 733)
 Tested by: dhubbard, geoff2010
 
 Review: https://reviewboard.asterisk.org/r/611/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=257713
By: Digium Subversion (svnbot) 2010-04-16 16:28:10

Repository: asterisk
Revision: 257738

_U  branches/1.6.0/
U   branches/1.6.0/apps/app_mixmonitor.c

------------------------------------------------------------------------
r257738 | dhubbard | 2010-04-16 16:28:10 -0500 (Fri, 16 Apr 2010) | 35 lines

Merged revisions 257713 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r257713 | dhubbard | 2010-04-16 16:22:30 -0500 (Fri, 16 Apr 2010) | 28 lines
 
 Merged revisions 257686 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r257686 | dhubbard | 2010-04-16 16:15:43 -0500 (Fri, 16 Apr 2010) | 21 lines
   
   Make the mixmonitor thread process audio frames faster
   
   Mantis issue 17078 reports MixMonitor recordings have shorter durations than
   the call duration.  This was because the mixmonitor thread was not processing
   frames from the audiohook fast enough.  The mixmonitor thread would slowly fall
   behind the most recent audio frame and when the channel hangs up, the mixmonitor
   thread would exit without processing the same number of frames as the channel;
   leaving the mixmonitor recording shorter than actual call duration.
   
   This revision fixes this issue by moving the ast_audiohook_trigger_wait() and
   the subsequent audiohook.status check into the block where the
   ast_audiohook_read_frame() function returns NULL.
   
   (closes issue ASTERISK-15859)
   Reported by: geoff2010
   Patches:
         dw-M17078.patch uploaded by dhubbard (license 733)
   Tested by: dhubbard, geoff2010
   
   Review: https://reviewboard.asterisk.org/r/611/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=257738
By: Digium Subversion (svnbot) 2010-04-16 16:32:32

Repository: asterisk
Revision: 257739

_U  branches/1.6.1/
U   branches/1.6.1/apps/app_mixmonitor.c

------------------------------------------------------------------------
r257739 | dhubbard | 2010-04-16 16:32:32 -0500 (Fri, 16 Apr 2010) | 35 lines

Merged revisions 257713 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r257713 | dhubbard | 2010-04-16 16:22:30 -0500 (Fri, 16 Apr 2010) | 28 lines
 
 Merged revisions 257686 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r257686 | dhubbard | 2010-04-16 16:15:43 -0500 (Fri, 16 Apr 2010) | 21 lines
   
   Make the mixmonitor thread process audio frames faster
   
   Mantis issue 17078 reports MixMonitor recordings have shorter durations than
   the call duration.  This was because the mixmonitor thread was not processing
   frames from the audiohook fast enough.  The mixmonitor thread would slowly fall
   behind the most recent audio frame and when the channel hangs up, the mixmonitor
   thread would exit without processing the same number of frames as the channel;
   leaving the mixmonitor recording shorter than actual call duration.
   
   This revision fixes this issue by moving the ast_audiohook_trigger_wait() and
   the subsequent audiohook.status check into the block where the
   ast_audiohook_read_frame() function returns NULL.
   
   (closes issue ASTERISK-15859)
   Reported by: geoff2010
   Patches:
         dw-M17078.patch uploaded by dhubbard (license 733)
   Tested by: dhubbard, geoff2010
   
   Review: https://reviewboard.asterisk.org/r/611/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=257739
By: Digium Subversion (svnbot) 2010-04-16 16:47:02

Repository: asterisk
Revision: 257740

_U  branches/1.6.2/
U   branches/1.6.2/apps/app_mixmonitor.c

------------------------------------------------------------------------
r257740 | dhubbard | 2010-04-16 16:47:01 -0500 (Fri, 16 Apr 2010) | 35 lines

Merged revisions 257713 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r257713 | dhubbard | 2010-04-16 16:22:30 -0500 (Fri, 16 Apr 2010) | 28 lines
 
 Merged revisions 257686 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r257686 | dhubbard | 2010-04-16 16:15:43 -0500 (Fri, 16 Apr 2010) | 21 lines
   
   Make the mixmonitor thread process audio frames faster
   
   Mantis issue 17078 reports MixMonitor recordings have shorter durations than
   the call duration.  This was because the mixmonitor thread was not processing
   frames from the audiohook fast enough.  The mixmonitor thread would slowly fall
   behind the most recent audio frame and when the channel hangs up, the mixmonitor
   thread would exit without processing the same number of frames as the channel;
   leaving the mixmonitor recording shorter than actual call duration.
   
   This revision fixes this issue by moving the ast_audiohook_trigger_wait() and
   the subsequent audiohook.status check into the block where the
   ast_audiohook_read_frame() function returns NULL.
   
   (closes issue ASTERISK-15859)
   Reported by: geoff2010
   Patches:
         dw-M17078.patch uploaded by dhubbard (license 733)
   Tested by: dhubbard, geoff2010
   
   Review: https://reviewboard.asterisk.org/r/611/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=257740