Summary:	ASTERISK-20719: Monitor recordings change filename unexpectedly after a blind transfer, but not attended transfer
Reporter:	Grzesiek (gzohop)	Labels:
Date Opened:	2012-11-22 03:17:38.000-0600	Date Closed:
Priority:	Major	Regression?
Status:	Open/New	Components:	Resources/res_monitor
Versions:	1.8.16.0 13.18.4	Frequency of Occurrence	Constant
Related Issues:
Environment:	Debian 686	Attachments:	( 0) extensions.conf ( 1) extensions.txt ( 2) sip.conf ( 3) xfer.txt
Description:	Monitor when executed with b option on channel transfered call changes the filenames if transfered channel was monitored at the moment of bridging. Here is how it looks: A calls ----> B(let's assume ${UNIQUEUEID}=1) exten => _XXXX,1,NoOp seme => n,Set(MONITOR_FILENAME=call-${UNIQUEID}) same => n,monitor(alaw,/var/spool/asterisk/monitor/${MONITOR_FILENAME},bm) When B answers the call, files call-1-in* and call1-out* are created. During The call, B tries to make attended transfer A is put on hold and B calls C using the same dialplan logic: B calls ----> C(let's assume ${UNIQUEUEID}=2) At the time off invoking monitor application none off the call-2 channels are monitored so the monitor application starts without errors, if B waits till C answers, everything is OK monitor starts recording and files call-2-in* and call-2-out* are created, When B transfers the call call-2 monitor is stopped. And call-2 files contain only the call between B and C. But there is problem when B does not wait until C answers the call, if transfer is done before C answers the call, the call-2* are not created and the call is still recorded to the call-1* files, but when the transferred call between A and C ends, the call-1* files get renamed to call-2* and the MONITOR_EXEC application is called with call-2* file names as parameters. This makes it impossible to locate the call record since the file names get changed, and there is no other way than figuring put file names from messages log.
Comments:	By: Rusty Newton (rnewton) 2012-11-27 17:57:49.177-0600 Grzesiek, thanks for reporting this. Please attach a full log with VERBOSE and DEBUG enabled at level 5 each, captured during demonstration of the issue. https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Please point out the channels involved in the process so they are easy to spot in the debug. Attach your extensions.conf, or at least the relevant portions that get called during the issue. sip.conf for the sip users involved may be helpful as well. By: Rusty Newton (rnewton) 2013-01-04 10:33:29.453-0600 As far as I can tell this behavior is expected and your request would be an improvement or feature (in that case, you'll need to provide a patch or find a community developer to at least create a basic patch) Without the debug requested we will not be able to investigate further. Once you have obtained the debug requested, you can requested to re-open the issue on irc.freenode.net #asterisk-bugs. By: Grzesiek (gzohop) 2013-01-10 03:25:06.428-0600 extensions.conf and sip.conf and debug information in file xfer.txt By: Rusty Newton (rnewton) 2013-01-10 15:22:58.609-0600 Reproduced this in SVN-branch-1.8-r373578 * A calls B   (while starting a Monitor with unique filename) * B blind transfer A to C  (while starting a Monitor with unique filename) * A and C hang up, then the original file set with Monitor started by the call from A is changed to the filename set in the monitor started by B. I used the 'b' and 'm' options set for Monitor. The second Monitor shouldn't begin recording since that call isn't bridged. Why does the filename set in the second Monitor get used when the first Monitor hangs up? I don't know - I'll acknowledge this and get it in our queue as well. Also, as Grzesiek mentioned, if you replace the blind transfer with an attended transfer, then the original file's name does not change, and instead you have a final set of two files with their respective unique names. By: Rusty Newton (rnewton) 2013-01-10 15:32:52.962-0600 Attached my extensions.txt for a much simpler example of the dialplan needed to reproduce this with the above described use case.