Summary:	ASTERISK-11028: ast_streamfile expects filename argument to have extension removed
Reporter:	a3ulafia (a3ulafia)	Labels:
Date Opened:	2007-12-13 13:38:40.000-0600	Date Closed:	2011-06-07 14:07:46
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/FileFormatInterface
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
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@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.
Comments:	By: Jason Parker (jparker) 2007-12-13 13:56:13.000-0600 The filename isn't being truncated at all.  It's only showing you what you put in. This is also not a bug, but a feature request. Please see the bug guidelines document on the front page of bugs.digium.com for examples of ways you can get a feature implemented and added. By: a3ulafia (a3ulafia) 2007-12-13 14:01:06.000-0600 thanks for recommending I read the bug guidelines. They are very interesting. Why would you call this a feature request? I see a very large number of conflicting information regarding the way filenames are passed to Asterisk. For example: the documentation for the Background() application clearly states: [Synopsis] Play an audio file while waiting for digits of an extension to go to. [Description]  Background(filename1[&filename2...][|options[|langoverride][|context]]): This application will play the given list of files while waiting for an extension to be dialed by the calling channel. Following my example in the initial report, a user would call this application and get an error that the file is not found. The user will then locate the file in the underlying filesystem, confirm that it does in fact exist and have no way to debug the issue without reading the source in include/asterisk/file.h By: Jason Parker (jparker) 2007-12-13 14:09:55.000-0600 In the help text for Playback (which you referenced), you'll note that it does explain to not use extension.  I'll update Background to do the same. Adding this would be a new feature - however, if you would like to help clean up the documentation to make this clear (which would then all have to be changed again if this is added), please feel free to. By: a3ulafia (a3ulafia) 2007-12-13 14:16:00.000-0600 In addition to updating the documentation the error text from file.c and pbx.c should be updated to properly describe the situation. Claiming that a file is not found when it exists in the filesystem at the exact path Asterisk is reporting does not give the user any useful information to figure out why his dialplan is not working as expected. If you leave this bug open I'll make a patch if you promise to stop calling it a feature. FWIW, I was stuck on this problem for a day because I kept locating the files Asterisk claimed didn't exist and going back and forth between the dialplan and the filesystem. By: Jason Parker (jparker) 2007-12-13 14:28:53.000-0600 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). By: Jason Parker (jparker) 2008-01-15 13:28:59.000-0600 Please reopen if you come up with a patch for this.