[asterisk-bugs] [Asterisk 0015188]: [patch] ReadExten returns TIMEOUT in cases where it should return OK or INVALID

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15188 
====================================================================== 
Reported By:                jcovert
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15188
Category:                   Applications/app_readexten
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-05-23 14:07 CDT
Last Modified:              2010-05-06 14:06 CDT
====================================================================== 
Summary:                    [patch] ReadExten returns TIMEOUT in cases where it
should return OK or INVALID
Description: 
The documentation for ReadExten states:

TIMEOUT   No extension was entered in the specified time

but ReadExten is returning TIMEOUT also in the case of a partial (INVALID)
extension or a completed (OK) variable length extension.

The behaviour of asterisk dialplan processing has always been that
"timeout" (i.e. continuation at the "t" extension) would only occur if "no
extension" (i.e. nothing, not any digits, not even an invalid extension)
was entered.  A "TIMEOUT" was always nothing entered in the Response
Timeout. Once a single digit was entered, and processing switched to the
Digit Timeout, the result could only be "INVALID" (continuation at the "i"
extension) or "OK" continuation at an actual extension.

ReadExten is not doing this correctly.  Consider use of ReadExten
specifying a context containing ONLY the following two extensions:

exten => 12,1,Noop()

exten => 345.,1,Noop()

The expected asterisk behaviour is that (1) entering just a "1" and
waiting for a timeout would end up at the "i" extension.  Similarly, (2)
entering 345 would also end up at the "i" extension, but (3) entering
"3456" would be processed.

ReadExten returns "TIMEOUT" in all three cases, and the digits entered are
lost.

The attached patch corrects this behaviour.  Cases (1) and (2) will return
"INVALID" with the digits dialled returned in ${INVALID_EXTEN} and case (3)
will return "OK" with the result in the return argument variable.

The patch also includes my suggestion concerning allowing tonelists, issue
https://issues.asterisk.org/view.php?id=15185.

It also allows a "#" as the FIRST character of an extension (if the
dialplan contains such an extension, frequently used for #xx feature
codes).  Entry of a "#" when the dialplan does not contain such an
extension is processed as an INVALID (with the "#" returned in
INVALID_EXTEN).

Regards/john
====================================================================== 

---------------------------------------------------------------------- 
 (0121496) jcovert (reporter) - 2010-05-06 14:06
 https://issues.asterisk.org/view.php?id=15188#c121496 
---------------------------------------------------------------------- 
I am now running 1.6.2.6 and have tested the work which was checked in.

It fixes the error associated with TIMEOUT/OK/INVALID.

However, the feature change -- to make the indication the same as the
indication argument to Playtones (indication or tonelist) didn't happen.

I'm submitting another patch, relative to 1.2.6.2, which both simplifies
the code and implements the feature.  It makes sense, if an indication is
allowed, that it is the SAME interface to playing an indication that the
user has in "Playtones."

I remember there being a comment made earlier about a potential conflict
between a filename and a numeric tonelist.  Such a conflict really doesn't
exist.  A filename (audio file) is the default, and an indication (either a
named indication or a tonelist) is only applicable with the "i" option, in
which case there are no filenames, only indications from indications.conf
and tonelists.  The same considerations exist as for Playtones -- in fact,
we use the "Playtones" call in order to preserve better modularity and
consistency, rather than "rolling more of our own" in another place.

Please consider the feature request: it's very useful -- it avoids having
to edit indications.conf to add various tones used for special ReadExten
usage.

/john 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-06 14:06 jcovert        Note Added: 0121496                          
======================================================================