[Home]

Summary:ASTERISK-09326: App Read() Should not Disconnect on failed File
Reporter:Douglas Garstang (dgarstang)Labels:
Date Opened:2007-04-26 17:48:40Date Closed:2011-06-07 14:02:48
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:See bug 9605. App Read() will stop dialplan processing if the file it tries to play is missing. Background() and Playback() do not do this. This is incorrect and undesirable behaviour imho. This is a feature request to request that app_read does not do this.

Corydon76 summarily closed bug 9605. I'd love to just how this is expected and desire behaviour. What could the rationale this possibly be?

I also wish bugs could not be closed like this. People who open bugs should be the ones that close them. Not other people. At the very least their should be a revue process before a bug is summarily closed too soon.
Comments:By: John Todd (jtodd) 2007-04-26 19:16:13

Correction: Current versions of SVN-TRUNK do not continue the dialplan when a missing sound file is encountered - they terminate the call, and this is noted in the descriptions for the apps.

I will say that this is a change from some point in the past, as I frequently would create IVRs which had missing sound files (because I didn't want to put placeholders in during testing) and the call process would continue even over the errored playback/background app calls.

I would suggest this for Playback, Background, and Read: an option (perhaps "c" for "c"ontinue?) that would allow the application to simply proceed to the next priority in the dialplan if the file did not exist.

This is useful in cases where audio files are dynamically copied or created, so that an error can be meaningfully trapped.  It is also useful to prevent disconnects where merely confusion may result from a mis-typed filename.

I would also perhaps suggest that app_read gets a resule code status like "PLAYBACKSTATUS" or "BACKGROUNDSTATUS", and that all three applications get a status of "NOFILE" or something like that as a possible result code.
By: Tilghman Lesher (tilghman) 2007-04-30 14:29:44

Since nobody has picked this up, I am suspending it in accordance with our policy on feature requests.  You are invited to post your feature request on the Bounty page of the Wiki, along with any appropriate bounty.  You may reopen this feature request when you have candidate code to place under consideration for inclusion in Asterisk.  If you are unable to open this bug, please ask a bug marshal to do it for you.