[asterisk-bugs] [Asterisk 0017078]: [patch] MixMonitor records shorter files than the call duration.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17078 
====================================================================== 
Reported By:                geoff2010
Assigned To:                dhubbard
====================================================================== 
Project:                    Asterisk
Issue ID:                   17078
Category:                   Applications/app_mixmonitor
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.30 
JIRA:                       SWP-1133 
Regression:                 No 
Reviewboard Link:           https://reviewboard.asterisk.org/r/611/ 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-03-23 00:38 CDT
Last Modified:              2010-04-16 16:47 CDT
====================================================================== 
Summary:                    [patch] MixMonitor records shorter files than the
call duration.
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0120555) svnbot (reporter) - 2010-04-16 16:47
 https://issues.asterisk.org/view.php?id=17078#c120555 
---------------------------------------------------------------------- 
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 https://issues.asterisk.org/view.php?id=17078)
    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 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-16 16:47 svnbot         Checkin                                      
2010-04-16 16:47 svnbot         Note Added: 0120555                          
======================================================================