[asterisk-bugs] [Asterisk 0011539]: ast_streamfile expects filename argument to have extension removed

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11539 
====================================================================== 
Reported By:                a3ulafia
Assigned To:                qwell
====================================================================== 
Project:                    Asterisk
Issue ID:                   11539
Category:                   Core/FileFormatInterface
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:            1.4.8  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             12-13-2007 13:38 CST
Last Modified:              12-13-2007 14:28 CST
====================================================================== 
Summary:                    ast_streamfile expects filename argument to have
extension removed
Description: 
All applications that expect a filename argument must have the string
truncated. Failure to do this returns a very confusing error from Asterisk.
For example:

$ ls /tmp/myfilename.wav
/tmp/myfilename.wav

In extensions.conf:

exten => s,1,Playback(/tmp/myfilename.wav)

In Asterisk error log:

[Dec 12 15:54:11] VERBOSE[21242] logger.c:     -- Executing
[ivr at arcalls:8] Playback("SIP/arconnect-09831bb0", "/tmp/myfilename.wav")
in new stack
[Dec 12 15:54:11] WARNING[21242] file.c: File /tmp/myfilename.wav does not
exist in any format
[Dec 12 15:54:11] WARNING[21242] file.c: Unable to open
/tmp/myfilename.wav (format 0x4 (ulaw)): No such file or directory
[Dec 12 15:54:11] WARNING[21242] pbx.c: ast_streamfile failed on
SIP/arconnect-09831bb0 for /tmp/myfilename.wav

This error message contradicts the requirement of ast_streamfile to have a
truncated filename, since the error message prints out the non-truncated
filename. This creates a mysterious situation while debugging since
Asterisk claims that a file with a valid path and correct permissions does
not exist.

I can't find any previous discussion of this as a bug. I believe it should
be classified as one. I never understood why the author of the dialplan
should be expected to remove what is seemingly an arbitrary string from the
end of a filename for it to playback properly. My unfamiliarity with the
Asterisk source made it difficult to trace this bug back to the function
that is doing the truncating.

I can see two solutions to this bug. 

1) Add a condition to first search for the literal string before
truncating. This will keep the error messages consistent with the
underlying filesystem and maintain backwards compatibility
2) Change the error logging to represent the truncated string. This will
prevent the user from viewing a contradictory error message.
====================================================================== 

---------------------------------------------------------------------- 
 qwell - 12-13-07 14:28  
---------------------------------------------------------------------- 
There is more to it than just that.  It cannot simply check that the given
file exists - that given file also has to actually be playable.  Obviously,
if somebody used Playback(mypresentation.ppt) we wouldn't be able to play
that - similarly, if somebody chose myfavoritesong.mp3, but the format_mp3
module is not loaded, it simply could not work - and even though the file
may actually exist (on disk), it would fail with the same warning message.

Having said that..  I've never claimed to think that adding this as a
feature is a bad idea.  In fact, I can't see any reason not to implement it
(but you'll have to keep the above in mind).  If you would like to create a
patch for this, I will leave this report open for a little while (if there
isn't a patch in some time, somebody else may close it though).

It would, however, be a feature (correcting the documentation would be a
bug fix - I will give you that).  Thus, it could only be added to svn trunk
(there is nothing stopping you from applying the patch locally in 1.4). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-13-07 14:28  qwell          Note Added: 0075360                          
======================================================================