[asterisk-dev] Feedback on hashtab-trunk

[Steve Murphy]

On Sat, 2007-11-17 at 19:19 +0100, Niklas wrote:
> On Mon, 12 Nov 2007 11:46:42 -0700, Steve Murphy wrote:
> 
> > Hopefully I have found them all, and you should see no more
> > problems.
> 
> Well i have one issue, it picks the wrong extension. Using trunk SVN-trunk-r89346M:
> 
> extension.conf:
> 
> [general]
> static=yes
> writeprotect=no
> 
> [from-internal]
> include=>ext_test
> include=>ext_local
> 
> [ext-local]
> exten=>201,1,Noop(201)
> 
> [ext_test]
> exten=>20,1,Noop(20)
> 
> 
> The CLI output when dialing 201:
> 
> lisa*CLI> dialplan reload
>   == Parsing '/etc/asterisk/extensions.conf':   == Found
>     -- Registered extension context 'from-internal'
>     -- Including context 'ext_test' in context 'from-internal'
>     -- Including context 'ext_local' in context 'from-internal'
>     -- Registered extension context 'ext-local'
>     -- Added extension '201' priority 1 to ext-local
>     -- Registered extension context 'ext_test'
>     -- Added extension '20' priority 1 to ext_test
>   == Using TOS bits 0
>   == Using CoS mark 5
>     -- Executing [201 at from-internal:1] NoOp("SIP/2003-b7009610", "20") in new stack
>     -- Auto fallthrough, channel 'SIP/2003-b7009610' status is 'UNKNOWN'
> 
> 
> lisa*CLI> dialplan show
> [ Context 'ext_test' created by 'pbx_config' ]
>   '20' =>           1. Noop(20)                                   [pbx_config]
> 
> [ Context 'ext-local' created by 'pbx_config' ]
>   '201' =>          1. Noop(201)                                  [pbx_config]
> 
> [ Context 'from-internal' created by 'pbx_config' ]
>   Include =>        'ext_test'                                    [pbx_config]
>   Include =>        'ext_local'                                   [pbx_config]
> 
> [ Context 'app_queue_gosub_virtual_context' created by 'app_queue' ]
>   's' =>            1. KeepAlive()                                [app_queue]
> 
> [ Context 'app_dial_gosub_virtual_context' created by 'app_dial' ]
>   's' =>            1. KeepAlive()                                [app_dial]
> 
> [ Context 'parkedcalls' created by 'res_features' ]
>   '700' =>          1. Park()                                     [res_features]
> 
>      In-mem exten Trie for Fast Extension Pattern Matching:
> 
> 
>            Explanation: Node Contents Format = <char(s) to match>:<pattern?>:<specif>:[matched extension]
>                         Where <char(s) to match> is a set of chars, any one of which should match the current character
>                               <pattern?>: Y if this a pattern match (eg. _XZN[5-7]), N otherwise
>                               <specif>: an assigned 'exactness' number for this matching char. The lower the number, the more exact the match
>                               [matched exten]: If all chars matched to this point, which extension this matches. In form: EXTEN:<exten string>
>                         In general, you match a trie node to a string character, from left to right. All possible matching chars
>                         are in a string vertically, separated by an unbroken string of '+' characters.
> 
>  7:N:1:
>  +       0:N:1:
>  +       +       0:N:1:EXTEN:700
> 
> -= 5 extensions (5 priorities) in 6 contexts. =-
> 
> /niklas


Niklas--

Yes, I note two things: 

1. if you dial 201 in this regime, it will match the 20. (it doesn't
wait for the last digit at all)
2. This happens in 1.4 also.

20 is a shorter pattern, but the overall algorithm (above and beyond the
pattern matching algorithm) selected it in this setup in previous
versions, and my pattern matching does not affect this behavior in
trunk.

I also note that reversing the order of the two included contexts does
not change the situation at all, and 20 is still matched:

[from-internal]
include=>ext_local
include=>ext_test

But, in 1.4, putting the two patterns in the same context gave the
desired result-- the 201 would be matched:

[from-internal]
exten=>201,1,Noop(201)
exten=>20,1,Noop(20)

But, in trunk, 20 was being returned. I spent the better part of the day
researching the reason for this difference, and found it, and fixed it.
Try running trunk v. 89438 or greater, and see if it meets your
expectations.

murf



-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20071119/6eade6c2/attachment.bin