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. |