[Home]

Summary:ASTERISK-14256: MixMonitor is not releasing the file handle on the recorded file
Reporter:Travis Glenn Hansen (travisghansen)Labels:
Date Opened:2009-06-02 22:21:29Date Closed:2009-06-24 13:55:04
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Applications/app_mixmonitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have been using MixMonitor in my dialplan through all the 1.6.0.x line and recently updated to 1.6.1.0.  Upon update it quit working.

My scenario is as follows:

I accept an incoming call, prompt for some IVR, start MixMonitor with b option.  Subsequently I initiate a Dial command to an external endpoint.  On answer the conversation starts recording to a temp directory on my server.  After either end hangs up, the dialplan continues to the h extension where I launch an AGI script to convert the wav sound clip to mp3 and do some other post processing.

In all builds prior to 1.6.1 this all worked great.  However starting with 1.6.1 when I externally launch the sox command via the agi script the resultant file has no audio.  I did some testing and discovered that this behavior is the same as if I am mid-call even though the line is hung up.
Comments:By: David Vossel (dvossel) 2009-06-09 13:41:23

Are you using StopMixMonitor() before attempting to convert the file?  Can you post a sample dialplan so I can see exactly how you are doing this?  What you have described makes sense, but from my testing I don't see how that could have ever worked without using StopMixMonitor().


By: Travis Glenn Hansen (travisghansen) 2009-06-09 15:17:36

I was never calling StopMixMonitor (I didn't know it existed) so I'll try it again with that in there.  Should I put this in the h extension?  I want the recording to be processed if either end hangs up.
By: David Vossel (dvossel) 2009-06-09 15:29:37

Putting it in the h extension before the AGI script should work.  If MixMonitor() was never on to begin with it just won't do anything.  Let me know if that fixes it.
By: Travis Glenn Hansen (travisghansen) 2009-06-11 02:52:12

I tried with 1.6.1.1 including the StopMixMonitor in the h extension and still no worky.

Here is the bit from my dialplan...

exten => qa-record-menu,1,Read(SecurityTraxCustomerID,hivalley/key-in-securitytrax-id,10,s,3,7);
exten => qa-record-menu,n,Wait(1);
exten => qa-record-menu,n,SayDigits(${SecurityTraxCustomerID});
exten => qa-record-menu,n,Verbose(${STRFTIME(${EPOCH},,%Y-%m-%d-%H-%M-%S)}: ${SecurityTraxCustomerID});
exten => qa-record-menu,n,Read(YesNo,hivalley/confirm23,1)
exten => qa-record-menu,n,GotoIf($["${YesNo}" != "2"]?1);
exten => qa-record-menu,n,Set(MY_TIME=${STRFTIME(${EPOCH},,%Y-%m-%d-%H-%M-%S)});
exten => qa-record-menu,n,Set(MY_RECORDED_AUDIO=/tmp/recorded_audio_customer_number_${SecurityTraxCustomerID}_${MY_TIME});
exten => qa-record-menu,n,Set(MY_RECORDED_AUDIO_EXTENSION=wav);
exten => qa-record-menu,n,Set(MY_RECORDED_AUDIO_FILENAME=${MY_RECORDED_AUDIO}.${MY_RECORDED_AUDIO_EXTENSION});
;exten => qa-record-menu,n,Monitor(wav,${MY_RECORDED_AUDIO},mb);
exten => qa-record-menu,n,MixMonitor(${MY_RECORDED_AUDIO_FILENAME},b);
exten => qa-record-menu,n,Playback(vm-dialout);
exten => qa-record-menu,n,Goto(qa-record-menu-extra,qa-record-menu,1);
exten => qa-record-menu,n,Hangup();

;exten => h,1,Verbose(Cleaning up);
;exten => h,n,Verbose(${MY_RECORDED_AUDIO_EXTENSION});

[qa-record-menu-extra]
exten => qa-record-menu,1,Dial(SIP/${qa_office_did}@vitel-outbound,30,TtWwg);
;exten => qa-record-menu,n,Verbose(Audio file: ${MY_RECORDED_AUDIO_FILENAME});
;exten => qa-record-menu,n,StopMonitor();
exten => qa-record-menu,n,Playback(beep);
exten => qa-record-menu,n,Playback(vm-goodbye);
exten => qa-record-menu,n,Hangup();

exten => h,1,Verbose(Cleaning up);
exten => h,n,Verbose(Dial status: ${DIALSTATUS});
exten => h,n,StopMixMonitor();
;exten => h,n,Verbose(${MY_RECORDED_AUDIO_FILENAME});
exten => h,n,GotoIf($["${DIALSTATUS}" = "ANSWER"]?sendfile:done);
exten => h,n(sendfile),AGI(convertAudioFile.php,"--filename=${MY_RECORDED_AUDIO_FILENAME}","--new_type=mp3");
exten => h,n,AGI(sendcustomerfile.php,"--company_id=${securitytrax_company_id}","--filename=${CONVERTED_FILENAME}","--customer_id=${SecurityTraxCustomerID}");
;exten => h,n,AGI(deleteFile.php,"--filename=${CONVERTED_FILENAME}");
;exten => h,n,AGI(deleteFile.php,"--filename=${MY_RECORDED_AUDIO_FILENAME}");
exten => h,n(done),Hangup();
By: David Vossel (dvossel) 2009-06-11 13:44:37

This is not a proper solution, but if you put exten => h,n,Wait(1) right after StopMixMonitor() I believe it will fix it for you.
By: Travis Glenn Hansen (travisghansen) 2009-06-11 14:27:59

I can try that, but this is on a production machine and I don't want to keep installing then reverting back constantly :(.  In the mean time do you need any additional info from me?  Either way, I think the expected behavior should be as before where you don't need to explicity call StopMixMonitor if you're in the h extension.  At any rate, thanks for the help with this and let me know if you need any more info for the time being.
By: David Vossel (dvossel) 2009-06-11 15:03:16

I'm sorry, wait will not work in the h extension, don't even try it.  I don't need anymore information at the moment, I have a good idea of what is going on.
By: David Vossel (dvossel) 2009-06-17 14:18:16

The change I'm about to commit requires the use of StopMixMonitor to guarantee the file is available.  I believe fact that you were able to use the AGI script in the h extension in 1.6.0 and not in 1.6.1 was pure luck.  This situation was caused by a race condition that just happened not to fail in 1.6.0 for your specific dialplan.  StopMixMonitor closes and releases the file handle now before returning to the dialplan.
By: Digium Subversion (svnbot) 2009-06-17 14:28:13

Repository: asterisk
Revision: 201423

U   branches/1.4/apps/app_mixmonitor.c

------------------------------------------------------------------------
r201423 | dvossel | 2009-06-17 14:28:13 -0500 (Wed, 17 Jun 2009) | 19 lines

StopMixMonitor race condition (not giving up file immediately)

StopMixMonitor only indicates to the MixMonitor thread to stop
writing to the file.  It does not guarantee that the recording's
file handle is available to the dialplan immediately after execution.
This results in a race condition.  To resolve this, the filestream
pointer is placed in a datastore on the channel. When StopMixMonitor
is called, the datastore is retrieved from the channel and the
filestream is closed immediately before returning to the dialplan.
Documentation indicating the use of StopMixMonitor to free files
has been updated as well.

(closes issue ASTERISK-14256)
Reported by: travisghansen
Tested by: dvossel

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


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

http://svn.digium.com/view/asterisk?view=rev&revision=201423
By: Digium Subversion (svnbot) 2009-06-17 14:45:35

Repository: asterisk
Revision: 201445

_U  trunk/
U   trunk/apps/app_mixmonitor.c

------------------------------------------------------------------------
r201445 | dvossel | 2009-06-17 14:45:35 -0500 (Wed, 17 Jun 2009) | 25 lines

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

........
 r201423 | dvossel | 2009-06-17 14:28:12 -0500 (Wed, 17 Jun 2009) | 19 lines
 
 StopMixMonitor race condition (not giving up file immediately)
 
 StopMixMonitor only indicates to the MixMonitor thread to stop
 writing to the file.  It does not guarantee that the recording's
 file handle is available to the dialplan immediately after execution.
 This results in a race condition.  To resolve this, the filestream
 pointer is placed in a datastore on the channel. When StopMixMonitor
 is called, the datastore is retrieved from the channel and the
 filestream is closed immediately before returning to the dialplan.
 Documentation indicating the use of StopMixMonitor to free files
 has been updated as well.
 
 (closes issue ASTERISK-14256)
 Reported by: travisghansen
 Tested by: dvossel
 
 Review: https://reviewboard.asterisk.org/r/283/
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=201445
By: Digium Subversion (svnbot) 2009-06-17 14:52:00

Repository: asterisk
Revision: 201447

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

------------------------------------------------------------------------
r201447 | dvossel | 2009-06-17 14:52:00 -0500 (Wed, 17 Jun 2009) | 32 lines

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

................
 r201445 | dvossel | 2009-06-17 14:45:35 -0500 (Wed, 17 Jun 2009) | 25 lines
 
 Merged revisions 201423 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r201423 | dvossel | 2009-06-17 14:28:12 -0500 (Wed, 17 Jun 2009) | 19 lines
   
   StopMixMonitor race condition (not giving up file immediately)
   
   StopMixMonitor only indicates to the MixMonitor thread to stop
   writing to the file.  It does not guarantee that the recording's
   file handle is available to the dialplan immediately after execution.
   This results in a race condition.  To resolve this, the filestream
   pointer is placed in a datastore on the channel. When StopMixMonitor
   is called, the datastore is retrieved from the channel and the
   filestream is closed immediately before returning to the dialplan.
   Documentation indicating the use of StopMixMonitor to free files
   has been updated as well.
   
   (closes issue ASTERISK-14256)
   Reported by: travisghansen
   Tested by: dvossel
   
   Review: https://reviewboard.asterisk.org/r/283/
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=201447
By: Digium Subversion (svnbot) 2009-06-17 14:54:02

Repository: asterisk
Revision: 201448

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

------------------------------------------------------------------------
r201448 | dvossel | 2009-06-17 14:54:02 -0500 (Wed, 17 Jun 2009) | 32 lines

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

................
 r201445 | dvossel | 2009-06-17 14:45:35 -0500 (Wed, 17 Jun 2009) | 25 lines
 
 Merged revisions 201423 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r201423 | dvossel | 2009-06-17 14:28:12 -0500 (Wed, 17 Jun 2009) | 19 lines
   
   StopMixMonitor race condition (not giving up file immediately)
   
   StopMixMonitor only indicates to the MixMonitor thread to stop
   writing to the file.  It does not guarantee that the recording's
   file handle is available to the dialplan immediately after execution.
   This results in a race condition.  To resolve this, the filestream
   pointer is placed in a datastore on the channel. When StopMixMonitor
   is called, the datastore is retrieved from the channel and the
   filestream is closed immediately before returning to the dialplan.
   Documentation indicating the use of StopMixMonitor to free files
   has been updated as well.
   
   (closes issue ASTERISK-14256)
   Reported by: travisghansen
   Tested by: dvossel
   
   Review: https://reviewboard.asterisk.org/r/283/
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=201448
By: Digium Subversion (svnbot) 2009-06-17 14:55:44

Repository: asterisk
Revision: 201449

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

------------------------------------------------------------------------
r201449 | dvossel | 2009-06-17 14:55:44 -0500 (Wed, 17 Jun 2009) | 32 lines

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

................
 r201445 | dvossel | 2009-06-17 14:45:35 -0500 (Wed, 17 Jun 2009) | 25 lines
 
 Merged revisions 201423 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r201423 | dvossel | 2009-06-17 14:28:12 -0500 (Wed, 17 Jun 2009) | 19 lines
   
   StopMixMonitor race condition (not giving up file immediately)
   
   StopMixMonitor only indicates to the MixMonitor thread to stop
   writing to the file.  It does not guarantee that the recording's
   file handle is available to the dialplan immediately after execution.
   This results in a race condition.  To resolve this, the filestream
   pointer is placed in a datastore on the channel. When StopMixMonitor
   is called, the datastore is retrieved from the channel and the
   filestream is closed immediately before returning to the dialplan.
   Documentation indicating the use of StopMixMonitor to free files
   has been updated as well.
   
   (closes issue ASTERISK-14256)
   Reported by: travisghansen
   Tested by: dvossel
   
   Review: https://reviewboard.asterisk.org/r/283/
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=201449
By: Leif Madsen (lmadsen) 2009-06-24 13:55:03

Oops! Sorry -- mistagged!