Summary:	ASTERISK-11589: Monitor with blind transfer deletes files returns bad paths.
Reporter:	K Anderson (kanderson)	Labels:
Date Opened:	2008-03-06 09:42:20.000-0600	Date Closed:	2008-04-02 12:32:51
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_monitor
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I marked this as major because it is used in a call center contractually obligated to record calls. Using monitor records all calls UNLESS the first transfer is blind.  If the first transfer is an attended transfer or not transfered at all the call is recorded in its entirety.  If the first transfer is attended then subsequent transfers can be either blind or attended and the call will be recorded over all legs.  However, if the first transfer is blind the call will not be recorded, the files are deleted, and if you are using MONITOR_EXEC the params passed all have an extra / at the front: In: '//var/spool/asterisk/monitor/in-13:27:57-in.WAV' Out: '//var/spool/asterisk/monitor/in-13:27:57-out.WAV' Output: '//var/spool/asterisk/monitor/in-13:27:57.WAV'   An additional information available at request.  Thank you
Comments:	By: K Anderson (kanderson) 2008-03-06 09:43:40.000-0600 Oops, sorry.  I put mix monitor in the title,  it should have been just monitor.  I had just finished reading a mix monitor case. By: Joshua C. Colp (jcolp) 2008-03-06 09:49:21.000-0600 Complete console output and a more descriptive view of the call flow is required to look at this, including what channels are involved and how the transfer is being done. By: Grzegorz Garlewicz (garlew) 2008-03-06 11:30:49.000-0600 This was fixed in 1.4.18. Upgrade. By: K Anderson (kanderson) 2008-03-06 12:48:56.000-0600 I guess I didn't look hard enough in the cases, I will upgrade a server when 1.4.19 comes out because it has a bug fix for an audio issue I have been having with Level 3.  Thanks for the info. By: Joshua C. Colp (jcolp) 2008-03-12 16:27:23 I would still really like to see your output... I suspect you are starting monitoring on the wrong channel. By: Grzegorz Garlewicz (garlew) 2008-03-13 09:39:52 I still think it should be closed as a duplicate of 0011741. By: K Anderson (kanderson) 2008-03-13 10:10:48 Sorry about the delayed response,  if this case is still open on the weekend I will add the requested captures for file.  In the meantime I will try to explain where the monitor is attached : For this example lets say we get a call from Bandwidth.com for 4073133136 calls enter at the context from_bandwidth which is only exten => _+X.,1,Macro(incomingHandler|${EXTEN:2}) At incomingHandler I set up some indefinitely inherited vars and DUNDI my boxes for a server configured for the incoming number.  If no box is found a gosub is used to load the intended context and entry point of the incoming number.  This works by calling gosub on context incoming with entries such as, exten => 4073133136,1,Macro(loadStatic|001|CEP1) At loadStatic the args are set as indefinitely inherited vars and then a return.  If that is successful then a GOTO is used with the returned info.  All entry points are into a context are extensions CEP (context entry point) followed by a number, such as CEP1.  Extension CEP1 uses another macro to set context specific vars, MOH class, attaches monitoring, and then preforms GOTO on time based routing. Throughout this process there are only goto's so the monitor should be attached to the  original channel.  However, if this channel dials a queue, the members are of type local to execute a standard extension macro with dundi to find phones that are registered to their fail over servers.  It seems to occur if the extension is dialed directly or through the queue.   Just to make sure my intensions are clear, I am confident upgrading will correct this issue. By: Jason Parker (jparker) 2008-04-02 12:32:48 No response, assumed fixed.