Summary:	ASTERISK-22066: Analog phone digit delay when using cannot-complete-as-dialed catch-all in dialplan
Reporter:	Justin Killen (justinkillen)	Labels:
Date Opened:	2013-07-11 11:47:03	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Channels/chan_dahdi Core/PBX
Versions:	1.8.23.0 11.4.0 13.18.4	Frequency of Occurrence	Constant
Related Issues:
Environment:	analog phones	Attachments:
Description:	When an analog phone is picked up and a number is dialed, there are three associated timeouts (from chan_dahdi.c): firstdigittimeout = 1600 gendigittimeout = 8000 matchdigittimeout = 3000 This creates reasonable timeouts.  However, it is a common occurrence to add a catch-all entry in the dialplan to provide a nice message when an invalid number is entered.  Because of this catch-all, all dahdi calls have a match, and the 3 second timeout is used instead of the intended 8 second timeout. It would be nice to have reasonable timeouts and nice messages not be mutually exclusive.  Perhaps a special extension target (like i and t) that gets used when there's no match?
Comments:	By: Richard Mudgett (rmudgett) 2013-07-11 12:36:21.191-0500 See the users list thread: http://lists.digium.com/pipermail/asterisk-users/2013-July/279770.html By: Matt Jordan (mjordan) 2013-07-11 15:34:38.598-0500 I'd personally prefer to avoid yet another 'special' extension if possible. Even if we had a special extension, from the perspective of the channel driver, control has still been passed off into the pbx, so I don't think that solves the timeout problem - I would suspect that even if we dropped it into a "analog-dump" extension, it would still use the {{matchdigittimeout}}. Would making these timeouts configurable solve the problem? Or does it have to be that we hand off control to the dialplan, but we still use the {{gendigittimeout}} instead of {{matchdigittimeout}}? By: Justin Killen (justinkillen) 2013-07-11 15:44:22.448-0500 I agree that a custom extension seems overkill, but I thought it would be the simplest and least intrusive. I don't think making them configurable solves the core problem.  The core problem here is that the catch-all is used for custom error reporting, not for 'valid' extension handling.  The only other way I could think of besides having a custom extension would be to somehow flag the catch-all pattern so that it uses the longer timeout (perhaps a custom timeout option on the pattern, like:  _X:notimeout or _X:nomatchtimeout or _X:senddigittimeout=matchdigittimeout ), which could be a hint as to what timeout to use for that specific match. By: Richard Mudgett (rmudgett) 2013-07-11 16:09:09.646-0500 Actually the i extension already exists for just this kind of situation.  Otherwise, the channel driver cannot determine which timeout to use.  chan_misdn uses the 'i' and 'e' extensions this way.  chan_dahdi would need to do this for all of its subchannels (analog, PRI, SS7, and MFC/R2). By: Justin Killen (justinkillen) 2013-07-11 16:39:42.320-0500 I agree on the i extension.  That was my initial suggestion on the mailing list, but it seems that it's currently only valid for things like WaitExten().  If the i extension could just be extended to this context, I think that would work out nicely.  The only minor issue is that there might be confusion if you have the channel pointed to a context that also had a WaitExten, then you wouldn't know which one you were coming from; that seems like it might be a rare edge case though, and it's easy enough to fix by putting WaitExten's into an isolated context. By: Matt Jordan (mjordan) 2013-07-15 16:16:36.321-0500 Fair enough on the use of the {{i}} extension. I'm going to go ahead and ack this issue. Since this is a minor bug/improvement (I'd classify at as a bug, as having to recompile or otherwise modify the source to get this to work in an environment is really a bug), a patch that sends the call to the {{i}} extension would help get the issue resolved faster.