[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:                       SWP-1809 
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-07-06 11:15 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
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015185 [patch] Patch to allow tone-list as arg...
====================================================================== 

---------------------------------------------------------------------- 
 (0124261) lmadsen (administrator) - 2010-07-06 11:15
 https://issues.asterisk.org/view.php?id=15188#c124261 
---------------------------------------------------------------------- 
Perhaps the bug and the feature should be broken out into separate features
so this can be better tested and merged (features only in trunk) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-06 11:15 lmadsen        Note Added: 0124261                          
======================================================================