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:03Date Closed:
Status:Open/NewComponents:Channels/chan_dahdi Core/PBX
Versions: 11.4.0 13.18.4 Frequency of
Environment:analog phonesAttachments:
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.