]> git.ipfire.org Git - thirdparty/asterisk.git/commit
Merged revisions 164801 via svnmerge from
authorSteve Murphy <murf@digium.com>
Tue, 16 Dec 2008 20:08:39 +0000 (20:08 +0000)
committerSteve Murphy <murf@digium.com>
Tue, 16 Dec 2008 20:08:39 +0000 (20:08 +0000)
commitcd1587ae990baa2d99283cf5c2de1c9d41e43a42
tree9ab66857d733f1381a12fd1309f72994b02adee4
parentd1b141fb9be0c4981d99373c3375dbbf6608f66e
Merged revisions 164801 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r164801 | murf | 2008-12-16 13:04:46 -0700 (Tue, 16 Dec 2008) | 36 lines

(closes issue #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.

........

git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@164803 65c4cc65-6c06-0410-ace0-fbb531ad65f3
main/pbx.c