[asterisk-bugs] [Asterisk 0011741]: Recorded files get deleted before mixing if the call was blind transfered

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11741 
====================================================================== 
Reported By:                garlew
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11741
Category:                   . I did not set the category correctly.
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             01-11-2008 06:47 CST
Last Modified:              01-31-2008 13:41 CST
====================================================================== 
Summary:                    Recorded files get deleted before mixing if the call
was blind transfered
Description: 
We record all calls coming into ACD queue with 
exten => 1,1,Set(MONITOR_FILENAME=NEW-${UNIQUEID})
exten => 1,n,Set(CDR(userfield)=${MONITOR_FILENAME}.wav)
exten => 1,n,monitor(alaw,${MONITOR_FILENAME},bm)
exten => 1,n,Queue(${QUEUENAME})

If the call is blind transfered (we use SIP endpoints) the recorded files
get deleted by Asterisk.

I believe the main reason is chan->monitor->filename_changed being set
incorrectly during transfer.
The quick fix (patch included) is to check if the file names in
ast_monitor_stop are
equal and not touch the files if so.


====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 01-31-08 13:41  
---------------------------------------------------------------------- 
You're definitely on the right track with this one, but the issue is a bit
deeper than the fix you provided (as you noted in the description). With
regards to monitor, it doesn't make sense for it to think that the filename
has changed if it really hasn't. Also, the renaming a file to itself
shouldn't cause it to end up with a different name (I found that if you
specify an absolute pathname, you'll end up with an extra / at the
beginning, which causes the error seen). I will get a fix created shortly.

Thanks for the submission, and sorry it took so long for someone to get
around to looking at it. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-31-08 13:41  putnopvut      Note Added: 0081521                          
======================================================================