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-0600Date Closed:2010-01-19 10:50:44.000-0600
Versions:Frequency of
Description:Regression - works as documented in!

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 behaves as documented.

Version 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:



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-  <-- 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