Summary:	ASTERISK-15448: [regression] soxmerge arguments broken if Monitoring to absolute path
Reporter:	Kirill Katsnelson (kkm)	Labels:
Date Opened:	2010-01-17 02:23:59.000-0600	Date Closed:	2010-01-19 10:50:44.000-0600
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Resources/res_monitor
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Regression - works as documented in 1.6.1.6! When Monitor() is passed absolute file name and the m flag, the leg channel recorded is into the specified file. After recording is done, soxmerge (or another program specified by MONITOR_EXEC) is called with the file name as argument. Version 1.6.1.6 behaves as documented. Version 1.6.1.12 is broken: all 3 soxmerge file paths are prepended with "/var/spool/asterisk/monitor/". Since they are already absolute, the resulting syntax is invalid. ****** STEPS TO REPRODUCE ****** Create a fake soxmerge script that dumps its arguments to a file Set MONITOR_EXEC to point to it. Create a directory /usr/sample Run a dialplan with Monitor(wav,/usr/sample/foo,m) Files are recorded as expected: /usr/sample/foo-{in,out}.wav The arguments passed to the script are invalid though: $1=/var/spool/asterisk/monitor//usr/sample/foo-in.wav $2=/var/spool/asterisk/monitor//usr/sample/foo-out.wav $3=/var/spool/asterisk/monitor//usr/sample/foo.wav ****** ADDITIONAL INFORMATION ****** Diffing res/res_monitor.c shows where the breakage occurs (line 179). New code blindly prepends ast_config_AST_MONITOR_DIR to the filename_base stored in the channel's monitoring structure: snprintf(monitor->filename_base, FILENAME_MAX, "%s/%s", ast_config_AST_MONITOR_DIR, fname_base); Old version stored the fname_base without modification: ast_copy_string(monitor->filename_base, fname_base, sizeof(monitor->filename_base)); Behavior seems not to be affected by the -t switch, as in two previous statements monitor->read_filename and write_filename are set correctly. Why was this change made? It is easy to unbreak but I cannot find why the behavior was changed in the first place in the first place.
Comments:	By: Leif Madsen (lmadsen) 2010-01-18 10:42:53.000-0600 I believe a change went in recently about paths with Monitor() -- can you try updating to the latest 1.6.1 branch and see if it has already been resolved? If not, please provide information about how to reproduce this issue (extensions.conf, sip.conf, etc...) along with the console output with debugging enabled in logger.conf showing the issue present. By: Kirill Katsnelson (kkm) 2010-01-18 22:07:12.000-0600 Yes, it seems to me that the issue should have been fixed by the patch [235943] merged from [235941] on ^/branches/1.4 from [235940]. Perhaps my report is duplicate, see ASTERISK-15261, ASTERISK-15263. By: Kirill Katsnelson (kkm) 2010-01-18 22:08:42.000-0600 How can I tell if that fix is in a particular release? .13 is already out but I cannot tell from the 1.6.1's branch log alone when it was released. By: Leif Madsen (lmadsen) 2010-01-19 10:48:02.000-0600 Look at the ChangeLog to see which changes are in the release. By: Leif Madsen (lmadsen) 2010-01-19 10:50:17.000-0600 http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-1.6.1.13  <-- 1.6.1.13 contains the fixes you reference above. I'm going to close this issue for now as it appears the issue was already resolved. Thanks! By: Leif Madsen (lmadsen) 2010-01-19 10:50:43.000-0600 Closed as this appears to already be resolved in 1.6.1.13.