Summary:ASTERISK-09298: [patch] Allow execution of commands after app_dictate exits
Reporter:Thomas (thomas andrews)Labels:
Date Opened:2007-04-23 06:15:35Date Closed:2007-07-11 19:59:25
Versions:Frequency of
Environment:Attachments:( 0) app_dictate.c.patch
( 1) app_dictate.c.patch-svn
Description:App_dictate can be made much more useful if it returns 0 because this then allows subsequent commands to be executed in the dialplan. This is particularly desirable, because app_dictate files often need to be converted to other formats, and perhaps moved elsewhere in the filesystem.

Currently app_dictate generally returns an unknown non-zero value. This patch has been tested in asterisk-1.2.14 (debian)


I have looked through the latest version (as of 23/04/2007) in svn trunk, and the issue appears to be there too.

Two patches are attached: One for asterisk-1.2.14, and one for svn head.
Comments:By: Russell Bryant (russell) 2007-04-23 10:45:44

If the user hangs up and the application returns -1, you should be able to perform your cleanup operations in the 'h' extension, right?  This is how most of the applications in Asterisk work ...

By: Thomas (thomas andrews) 2007-04-23 11:15:17

I tried putting something into the 'h' context, and it never got there even though a file was recorded successfully. Once the patch was applied, it did get to the 'h' context, and there was no longer a message logged about the application finishing with non-zero status like this:

== Spawn extension (bla, 8, 2) exited non-zero on 'Zap/1-1'

In my opinion a message successfully recorded should return 0 always. In the app_dictate application, the return value is based on the values returned by these calls:

res = ast_set_read_format(chan, AST_FORMAT_SLINEAR)


res = ast_waitfor(chan, -1)


res = ast_say_number(chan, speed, AST_DIGIT_ANY, chan->language, (char *)NULL);


res = ast_writestream(fs, f);

This seems a little arbitrary to me. Perhaps app_dictate should only return non-zero if there was an error.

By: Russell Bryant (russell) 2007-06-08 17:23:45

This patch has been added to 1.2, 1.4, and trunk in revision 68526, 68527, and 68528.  Thanks!