[asterisk-bugs] [Asterisk 0014076]: Extensions configuration is not being sorted correctly

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14076 
====================================================================== 
Reported By:                toc
Assigned To:                blitzrage
====================================================================== 
Project:                    Asterisk
Issue ID:                   14076
Category:                   Core/PBX
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.0 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-12-15 06:53 CST
Last Modified:              2008-12-16 14:04 CST
====================================================================== 
Summary:                    Extensions configuration is not being sorted
correctly
Description: 
The matching performed on extensions.conf is not sorting the items as
expected.

Take this example:

[test-ext]
exten => _.,1,NoOp(Match 1)
exten => s-Nothing,1,NoOp(Match 3)
exten => _s.,1,NoOp(Match 2)
exten => _s-.,1,NoOp(Match 4)

The result of:
[test-ext]
exten => _.,1,NoOp(Match 1)
exten => s-Nothing,1,NoOp(Match 3)
exten => _s.,1,NoOp(Match 2)
exten => _s-.,1,NoOp(Match 4)

Is:
— Executing [s-Test at test-ext:1] NoOp("Local/s-Test at test-ext-0cbc;2",
"Match 2") in new stack

I would expect the match to occur on Match 4, this is the closed match
based on the number of items to match on.

Swap them around:
[test-ext]
exten => _.,1,NoOp(Match 1)
exten => s-Nothing,1,NoOp(Match 3)
exten => _s-.,1,NoOp(Match 4)
exten => _s.,1,NoOp(Match 2)

And this is the output:
— Executing [s-Test at test-ext:1] NoOp("Local/s-Test at test-ext-5f64;2",
"Match 4") in new stack

It appears to be inconsistent in applying the matching as I would expect
regardless of entry position, the same results to occur due to the
matching.
====================================================================== 

---------------------------------------------------------------------- 
 (0096473) svnbot (reporter) - 2008-12-16 14:04
 http://bugs.digium.com/view.php?id=14076#c96473 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 164801

U   trunk/main/pbx.c

------------------------------------------------------------------------
r164801 | murf | 2008-12-16 14:04:42 -0600 (Tue, 16 Dec 2008) | 36 lines

(closes issue http://bugs.digium.com/view.php?id=14076)
Reported by: toc
Tested by: murf

OK, Well this issue has had its share of flip-flopping.
I found the following:

1. the code in question, in ext_cmp1 in pbx.c, would not
allow two extensions that vary only by any dashes contained
within them, to be defined in the same context.

2. for input dialstrings, dashes are NOT ignored.
So, skipping them when sorting patterns seemed a bit silly.
Thus, you might declare ext 891 in a context, but
if you try dialing 8-9-1, it will NOT match 891.

So, I proposed to remove the code from ext_cmp1 to 
skip the spaces and dashes. Just kept us from 
declaring 891 and 8-9-1 in the same context,
forcing users to generate otherwise uselessly
obfuscated dialplan code to get the same effect.

Then, I tried out 1.4, and found that:

1. you can declare 891 and 8-9-1 in the
same context!

2. You can't define 891, and have 8-9-1 match
it! Nor can you define 8-9-1, and have 891
match it!

So, it appears that my proposal simply restores
the pbx to behaving as it did in 1.4.



------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=164801 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-16 14:04 svnbot         Checkin                                      
2008-12-16 14:04 svnbot         Note Added: 0096473                          
======================================================================