Summary:	ASTERISK-03799: [patch] Dialplan lacks instant match for unambiguous wildcard.
Reporter:	David Woodhouse (dwmw2)	Labels:
Date Opened:	2005-03-29 04:55:10.000-0600	Date Closed:	2011-06-07 14:05:00
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) earlymatch.patch.txt ( 1) earlymatch-2.patch.txt
Description:	The UK dialplan is fairly haphazard and unpredictable. You receive audible feedback immediately while you dial a number, getting a recorded message the moment you go wrong. Thus, when making trunk calls in the UK it's important to connect using the CAPI 'earlyb3' option and send DTMF digits in real time as the user dials them. We should connect the outgoing channel as _soon_ as we know that the number being dialled is one which will be routed in that direction; we should not wait for the user to finish dialling before we place the outgoing call. The simple approach to a dialplan would use patterns ending in '.' to match those numbers which will be routed to the local telco. However, this does not achieve the early connection which is desired -- there is a delay of DigitTimeout after the user ceases dialling, before the call is actually placed. The attached patch adds a new form of wildcard to the dialplan pattern. This uses the '+' character to match zero or more characters, and has special behaviour when used with ast_matchmore_extension(). Normally, the loop waiting for DTMF digits will terminate only when there is either a precise match, or _no_ match, for the digits which have been dialled. This '+' wildcard pattern will terminate that loop immediately if no other extensions _without_ the '+' wildcard are possible. So the following becomes possible: [btoutgoing] ; Outgoing calls via BT by default exten => _X+,1,Dial(${TRUNK}:b${EXTEN}) [ustollfree] ; US free numbers via FWD exten => _001800NXXXXXX,1,Macro(stdoutgoing,IAX2/fwdnet-outbound/*${EXTEN:2}) exten => _001888NXXXXXX,1,Macro(stdoutgoing,IAX2/fwdnet-outbound/*${EXTEN:2}) exten => _001877NXXXXXX,1,Macro(stdoutgoing,IAX2/fwdnet-outbound/*${EXTEN:2}) exten => _001866NXXXXXX,1,Macro(stdoutgoing,IAX2/fwdnet-outbound/*${EXTEN:2}) [default] ; What you should get when you pick up an internal phone and get a dialtone include => ustollfree include => btoutgoing With a dialplan like this, I can pick up the phone and start dialling digits and still get the user experience I expect. As _soon_ as I deviate from the 001800 numbers which would be routed by VoIP, I am connected to the local telephone exchange and I hear audible feedback as I continue to dial. There may be better ways of achieving the early-matching functionality I need; I'm open to alternative suggestions. ****** ADDITIONAL INFORMATION ****** Disclaimer on file.
Comments:	By: David Woodhouse (dwmw2) 2005-03-29 05:03:16.000-0600 This is one alternative solution which I considered but discarded in favour of the above. I'm including it for completeness: We could have a way of specifying that a pattern is _not_ applicable for matching with ast_matchmore_extension(). We could perhaps start it with '^' instead of '_' to indicate that. Then I could use that type of pattern for the wildcards which are upsetting my DTMF users. My dialplan would end up something like this... [btoutgoing] ; wildcards for when the full number is dialled up-front ('dial' command) exten => ^Z.,1,Dial(${TRUNK}:b${EXTEN}) exten => ^0Z.,1,Dial(${TRUNK}:b${EXTEN}) exten => ^001[012345679].,1,Dial(${TRUNK}:b${EXTEN}) exten => ^0018[123459].,1,Dial(${TRUNK}:b${EXTEN}) exten => ^00180Z.,1,Dial(${TRUNK}:b${EXTEN}) exten => ^00188[012345679].,1,Dial(${TRUNK}:b${EXTEN}) exten => ^00187[012345689].,1,Dial(${TRUNK}:b${EXTEN}) exten => ^00186[012345789].,1,Dial(${TRUNK}:b${EXTEN}) ; Match-as-you-dial for DTMF users exten => _Z,1,Dial(${TRUNK}:b${EXTEN}) exten => _0Z,1,Dial(${TRUNK}:b${EXTEN}) exten => _001[012345679],1,Dial(${TRUNK}:b${EXTEN}) exten => _0018[123459],1,Dial(${TRUNK}:b${EXTEN}) exten => _00180Z,1,Dial(${TRUNK}:b${EXTEN}) exten => _00188[012345679],1,Dial(${TRUNK}:b${EXTEN}) exten => _00187[012345689],1,Dial(${TRUNK}:b${EXTEN}) exten => _00186[012345789],1,Dial(${TRUNK}:b${EXTEN}) It looks like it could work, but compare that snippet of dialplan with the one line I have in [btoutgoing] at the moment: exten => _Z+,1,Dial(${TRUNK}:b${EXTEN}) Hence my choice of the other approach over this one. Still, if there are better approaches which I hadn't thought of, I'd be happy to consider those instead. By: David Woodhouse (dwmw2) 2005-03-29 07:55:38.000-0600 The second patch is in response to feedback on asterisk-dev that '+' is a bad character to use with special meaning, since it's already used to indicate international numbers. I picked 'e' mostly at random. By: Brian West (bkw918) 2005-03-29 09:16:42.000-0600 Actually this should already work.. It would depend on the order in the includes.. have mark look at it. /b By: David Woodhouse (dwmw2) 2005-03-29 09:37:54.000-0600 bkw: When you say "this should already work" I think you mean just that the dialplan using the '.' wildcard can probably be optimised to use just '_N.' instead of all the longer patterns. That's true, and in fact the example already has the includes in the correct order. So the 'alternative solution' to make overlap dialling work correctly could be simplified; it could look like this: [btoutgoing] ; wildcards for when the full number is dialled up-front ('dial' command) exten => ^N.,1,Dial(${TRUNK}:b${EXTEN}) ; Match-as-you-dial for DTMF users exten => _Z,1,Dial(${TRUNK}:b${EXTEN}) exten => _0Z,1,Dial(${TRUNK}:b${EXTEN}) exten => _001[012345679],1,Dial(${TRUNK}:b${EXTEN}) exten => _0018[123459],1,Dial(${TRUNK}:b${EXTEN}) exten => _00180Z,1,Dial(${TRUNK}:b${EXTEN}) exten => _00188[012345679],1,Dial(${TRUNK}:b${EXTEN}) exten => _00187[012345689],1,Dial(${TRUNK}:b${EXTEN}) exten => _00186[012345789],1,Dial(${TRUNK}:b${EXTEN}) That's slightly prettier than it was, but the version I implemented is still better, I think. One of the two would still be required. By: Mark Spencer (markster) 2005-03-29 13:34:57.000-0600 If you have overlap dial support enabled you can do something like: exten => _9,1,Dial(Zap/g2/) on a PRI and continue to dial digits. By: David Woodhouse (dwmw2) 2005-03-29 13:45:06.000-0600 Does that solution work even if I issue the command "dial 901223248854", for example? Is this done by another hack in the channel driver itself, rather than generic functionality? By: Mark Spencer (markster) 2005-03-29 13:49:08.000-0600 When overlap dial is enabled, DTMF digits received before the call is proceeding are transmitted as info digits to the outbound leg.  Is this not what you're looking for? By: petersv (petersv) 2005-03-29 13:55:55.000-0600 Doesn't that prevent you from reusing (through includes etc) the same extensions for channels using enbloc signalling such as sip and non-overlap isdn? We had some problems with that and ended up creating a similar patch to this one. We changed the meaning of the "." wildcard to be zero-or-more (like the regular unix "*" wildcard. By: David Woodhouse (dwmw2) 2005-03-29 14:39:18.000-0600 Mark: that's part of what I'm looking for, but that part was already working with Dial(CAPI/${MYMSN}:${EXTEN}). The main problem I'm trying to fix here is the problem of _when_ the match happens. If I use '_9.' and the client dials using DTMF, then the match doesn't actually happen until after DigitTimeout. This is unacceptable because it should happen (and the outgoing channel should be brought up, etc.) as _soon_ as Asterisk realises that the number being dialled doesn't match anything else (such as the _9001800 numbers which are routed over VoIP instead of the ISDN). Alternatively, if I use '_9' then it won't work when the client uses non-DTMF dialling modes -- because if they dial the full outgoing number, that doesn't match the '9'. By: Mark Spencer (markster) 2005-03-30 00:51:20.000-0600 At least I understand the problem now :) You could set the context differently for the DTMF and non-DTMF dialing mode things.  What are your DTMF mode things and non-DTMF mode things? Alternatively, how would you feel about: exten => _9!,1,Dial(foo) exten => _9.,1,Dial(bar) Where this means if "9" is dialed by itself, match immediately, but also accept the _9. pattern... By: David Woodhouse (dwmw2) 2005-03-30 04:37:44.000-0600 Using a different context for the DTMF-mode and non-DTMF mode things is hard, because in cases they are the _same_ hardware. An ISDN telephone, for example, will use DTMF if you press the 'off-hook' button before any numbers, and will use non-DTMF dialling if you dial the numbers first. I suppose you could put a Goto() in the 's' extension of its incoming context, but still you'd end up duplicating the _entire_ dialplan for each dialling mode, and it isn't going to be pretty. Your suggestion of '_9!' and '_9.' sounds very similar to the 'alternative solution' which I described in the first bugnote, except that (AIUI) your '!' wildcard would match immediately in DTMF mode, even when there are other possible matches. My alternative was the other way round -- to flag those 'other possible matches' as invalid in DTMF mode, not to mark the '_9' as overriding them. Thus basically achieving the same effect, except that my version gave me the control to individually select which 'other possible matches' should be ignored and which should still be considered. So your '_9!' would _also_ match immediately in preference to my '_9001800NXXXXXXX' pattern, which would be a problem. If this is the direction you want, then consider the approach in my first bugnote. However, I still think the original version which I implemented and described in the original report is cleaner. That just gives me a wildcard which is matched immediately once it's unambiguous, without waiting for further digits. This is a selected part of my dialplan using the patch I submitted -- some devices are in the 'default' context and get outgoing lines by default, and some are in the 'internal' context. Each works with either DTMF or non-DTMF, and the dialplan has no duplication to handle this; just my new '+' wildcard. [btoutgoing] ; Outgoing calls via BT by default exten => _X+,1,Dial(${TRUNK}:b${EXTEN}) [ustollfree] ; US free numbers via FWD exten => _001800NXXXXXX,1,Macro(stdoutgoing,IAX2/fwdnet-outbound/*${EXTEN:2}) exten => _001888NXXXXXX,1,Macro(stdoutgoing,IAX2/fwdnet-outbound/*${EXTEN:2}) exten => _001877NXXXXXX,1,Macro(stdoutgoing,IAX2/fwdnet-outbound/*${EXTEN:2}) exten => _001866NXXXXXX,1,Macro(stdoutgoing,IAX2/fwdnet-outbound/*${EXTEN:2}) [default] include => ustollfree include => btoutgoing exten => _*+,1,GotoIf($[${EXTEN} = *]?internal,s,1:internal,${EXTEN:1},1) [internal] exten => _9+,1,GotoIf($[${EXTEN} = 9]?default,s,1:default,${EXTEN:1},1) ; Force breakout to BT exten => _8+,1,Dial(${TRUNK}:b${EXTEN:1}) By: Kevin P. Fleming (kpfleming) 2005-03-31 17:18:40.000-0600 Since this only affects systems using a combination of 'overlap dial' and DTMF dialing, I think this is a pretty safe addition to the pattern matching logic. Personally I don't think that + is a bad character to use for this, since we already use '.' and that is used frequently in written communication for PSTN numbers as well. But any character that works is OK... even using '!' would be fine, but with the original proposed semantics. By: Kevin P. Fleming (kpfleming) 2005-04-03 16:42:15 Committed the version using '+' to CVS, thanks! By: Kevin P. Fleming (kpfleming) 2005-04-03 16:42:57 New feature, not for stable By: Terry Wilson (twilson) 2005-04-04 10:10:53 Not sure if I should have reopened this or submitted a new bug, but using the + will certainly break some setups.  Some providers actually send the number as +15555551212, so if we use the plus in the pattern won't that break this?  I know of one nation-wide SIP provider that ONLY sends inbound numbers this way. By: Terry Wilson (twilson) 2005-04-04 10:14:15 My bad, you already changed this. By: Digium Subversion (svnbot) 2008-01-15 15:30:15.000-0600 Repository: asterisk Revision: 5370 U   trunk/pbx.c ------------------------------------------------------------------------ r5370 | kpfleming | 2008-01-15 15:30:14 -0600 (Tue, 15 Jan 2008) | 2 lines add 'early-match' wildcard for extension patterns (bug ASTERISK-3799) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5370 By: Digium Subversion (svnbot) 2008-01-15 15:30:16.000-0600 Repository: asterisk Revision: 5371 U   trunk/configs/extensions.conf.sample ------------------------------------------------------------------------ r5371 | kpfleming | 2008-01-15 15:30:15 -0600 (Tue, 15 Jan 2008) | 2 lines add docs for bug ASTERISK-3799 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5371 By: Digium Subversion (svnbot) 2008-01-15 15:30:17.000-0600 Repository: asterisk Revision: 5372 U   trunk/configs/extensions.conf.sample U   trunk/pbx.c ------------------------------------------------------------------------ r5372 | kpfleming | 2008-01-15 15:30:16 -0600 (Tue, 15 Jan 2008) | 2 lines further thought says '!' is a better early-match wildcard (bug ASTERISK-3799, take 2) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5372