Summary:	ASTERISK-04815: [request] [post 1.2] dialplan order / match order problems
Reporter:	Roy Sigurd Karlsbakk (rkarlsba)	Labels:
Date Opened:	2005-08-11 08:11:37	Date Closed:	2005-08-12 09:12:32
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	the following dialplan is used, and regardless of the order, a number 000398013356 is matched by the _0003X., and not the 0003XXXXXXXX. The logical approach would be to have the extension giving the _best_ match handle the call, not just one of them. I have been told separating the dialplan on several contexts and then including them can help this, but this is not optimal, then this is a bug.... exten => _0003XXXXXXXXX,1,Macro(dial,0034${EXTEN:4}) exten => _0003XXXXXXXX,1,Macro(dial,0047${EXTEN:4}) exten => _0003X.,1,Macro(dial,${EXTEN:4}) exten => _X.,1,Macro(feil)
Comments:	By: Mark Spencer (markster) 2005-08-11 14:02:52 By using separate contexts and include => you can force the order to whatever you want. By: Roy Sigurd Karlsbakk (rkarlsba) 2005-08-11 18:07:31 The whole reason of opening this bug was that the dialplan itself does not work properly. The dialplan should prioritise the best hit, not just whatever is the first match. By: Michael Jerris (mikej) 2005-08-11 22:27:41 we can leave this open to see if there are any takers for a week.  This is a request for an enhancement, the dialplan is not desinged to work how you think it is.  The best way to handle this is to not have conflicting things in the same context. By: Mark Spencer (markster) 2005-08-11 23:18:27 The order is by strcasecmp, very fast, very efficient, very well understood.  It is not worth trying to write our own, unoptimized, less efficient system to order the entries just so that you don't have to use an "include =>" to be able to split up examples in the form that you specified (i.e. with total overlap). By: Roy Sigurd Karlsbakk (rkarlsba) 2005-08-12 05:35:24 It is indeed worth a rewrite. With a new, logical dialplan matching, the dialplan will be far easier to write and maintain. AFAIK the current approach also does not compare to other telephony systems with regard to the dialplan order. By: Michael Jerris (mikej) 2005-08-12 09:12:32 well, at this point it is clear that mark will not allow anything in that is less efficient than the current methods.  If you can produce a patch that matches this efficiency and meets your goals, please re-open this bug, otherwise, I think this one is dead.