[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-07 02:17 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0124292) jcovert (reporter) - 2010-07-07 02:17
 https://issues.asterisk.org/view.php?id=15188#c124292 
---------------------------------------------------------------------- 
Based on the checkin comments in issue 001585 it looks like there was an
attempt to check in the feature before:

-------
r234776 | qwell | 2009-12-14 15:32:03 -0600 (Mon, 14 Dec 2009) | 12 lines
  
  Allow tonelist as argument to ReadExten.
  
  ReadExten already supported playing a tonezone from indications.conf.
  It now has the ability to use a tonelist like 440+480/2000|0/4000
-------

So this is all a bugfix. :-)

However, the TIMEOUT bug is the bit with the "if (x == 0) {" and "}"
around existing code.

The tonelist is all of the rest.  All of the simplification of the code is
to make ReadExten have "the ability to use a tonelist like
440+480/2000|0/4000". 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-07 02:17 jcovert        Note Added: 0124292                          
======================================================================