[asterisk-bugs] [JIRA] (ASTERISK-19205) Most Unique pattern matching broken when trailing "-" is part of extension

Tue Nov 20 19:05:45 CST 2012

    [ https://issues.asterisk.org/jira/browse/ASTERISK-19205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199976#comment-199976 ] 

Richard Mudgett edited comment on ASTERISK-19205 at 11/20/12 7:04 PM:
----------------------------------------------------------------------

Asterisk has been skipping '\-' chars in patterns and the extens to match with patterns since at least Asterisk v1.2.  It just has not been very consistent about ignoring the '\-' characters as shown by this issue.

      was (Author: rmudgett):
    Asterisk has been skipping '-' chars in patterns and the extens to match with patterns since at least Asterisk v1.2.  It just has not been very consistent about ignoring the '-' characters as shown by this issue.

> Most Unique pattern matching broken when trailing "-" is part of extension
> --------------------------------------------------------------------------
>
>                 Key: ASTERISK-19205
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19205
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/PBX
>    Affects Versions: 1.8.7.2
>            Reporter: Philippe Lindheimer
>            Assignee: Richard Mudgett
>            Severity: Minor
>
> The following FreePBX bug has some information. The crux is as follows. FreePBX uses some dialplan where extension patterns take on a format that might look like: "_RG-10111-." for a pattern. The crux of the issue is given two similar patterns, one always expect Asterisk to do the "most specific match". It appears starting with 1.6.2 something in Asterisk changed the behavior if that trailing "-" is left off. Tests were done on 1.4.32 where Asterisk seemed to work properly, and on 1.6.2.21 and 1.8.7.2 where it works improperly.
> The following is a simple dialplan context that can be used to demonstrate the error:
> {noformat}
> [from-internal]
> exten => 1112,1,Goto(tst-parse,s,1)
> [tst-parse]
> exten => s,1,Noop(Running Parse Priority Text)
> exten => s,n,Dial(Local/RG-10111-99999 at tst-parse)
> exten => s,n,Dial(Local/RG-20111-99999 at tst-parse)
> exten => s,n,Hangup
> exten => h,1,Hangup
> exten => _RG-10111-.,1,Noop(IN 10111, this is CORRECT)
> exten => _RG-101-.,1,Noop(IN 101, this is WRONG)
> exten => _RG-20111.,1,Noop(IN 20111, this is CORRECT)
> exten => _RG-201.,1,Noop(IN 201, this is WRONG)
> {noformat}
> In this example, you dial "1112" to trigger teh context. Note the difference in the two sets of target dialplan, in one case there is a trailing "\-" and in the other case there is not. One wold expect both cases to execute the instruction that results in the "CORRECT" more specific match however leaving off the trailing "\-" is required for this to happen and if not, the wrong dialplan is executed.
> The results from 1.4 show proper execution:
> {noformat}
> -- Executing [1112 at from-internal:1] Goto("SIP/7001-000005bf", "tst-parse|s|1") in new stack 
>     -- Goto (tst-parse,s,1) 
>     -- Executing [s at tst-parse:1] NoOp("SIP/7001-000005bf", "Running Parse Priority Text") in new stack 
>     -- Executing [s at tst-parse:2] Dial("SIP/7001-000005bf", "Local/RG-10111-99999 at tst-parse") in new stack 
>     -- Called RG-10111-99999 at tst-parse 
>     -- Executing [RG-10111-99999 at tst-parse:1] NoOp("Local/RG-10111-99999 at tst-parse-8d8c,2", "IN 10111| this is CORRECT") in new stack 
>   == Auto fallthrough, channel 'Local/RG-10111-99999 at tst-parse-8d8c,2' status is 'UNKNOWN' 
>     -- Executing [h at tst-parse:1] Hangup("Local/RG-10111-99999 at tst-parse-8d8c,2", "") in new stack 
>   == Spawn extension (tst-parse, h, 1) exited non-zero on 'Local/RG-10111-99999 at tst-parse-8d8c,2' 
>   == Everyone is busy/congested at this time (1:0/0/1) 
>     -- Executing [s at tst-parse:3] Dial("SIP/7001-000005bf", "Local/RG-20111-99999 at tst-parse") in new stack 
>     -- Called RG-20111-99999 at tst-parse 
>     -- Executing [RG-20111-99999 at tst-parse:1] NoOp("Local/RG-20111-99999 at tst-parse-6a9b,2", "IN 20111| this is CORRECT") in new stack 
>   == Auto fallthrough, channel 'Local/RG-20111-99999 at tst-parse-6a9b,2' status is 'UNKNOWN' 
>     -- Executing [h at tst-parse:1] Hangup("Local/RG-20111-99999 at tst-parse-6a9b,2", "") in new stack 
>   == Spawn extension (tst-parse, h, 1) exited non-zero on 'Local/RG-20111-99999 at tst-parse-6a9b,2' 
>   == Everyone is busy/congested at this time (1:0/0/1) 
>     -- Executing [s at tst-parse:4] Hangup("SIP/7001-000005bf", "") in new stack 
>   == Spawn extension (tst-parse, s, 4) exited non-zero on 'SIP/7001-000005bf' 
>     -- Executing [h at tst-parse:1] Hangup("SIP/7001-000005bf", "") in new stack 
>   == Spawn extension (tst-parse, h, 1) exited non-zero on 'SIP/7001-000005bf'
> {noformat}
> The results from 1.8 show improper execution, the same was seen on 1.6.2:
> {noformat}
>     -- Executing [1112 at from-internal:1] Goto("SIP/700-000003ac", "tst-parse,s,1") in new stack
>     -- Goto (tst-parse,s,1)
>     -- Executing [s at tst-parse:1] NoOp("SIP/700-000003ac", "Running Parse Priority Text") in new stack
>     -- Executing [s at tst-parse:2] Dial("SIP/700-000003ac", "Local/RG-10111-99999 at tst-parse") in new stack
>     -- Called Local/RG-10111-99999 at tst-parse
>     -- Executing [RG-10111-99999 at tst-parse:1] NoOp("Local/RG-10111-99999 at tst-parse-6114;2", "IN 101, this is WRONG") in new stack
>     -- Auto fallthrough, channel 'Local/RG-10111-99999 at tst-parse-6114;2' status is 'UNKNOWN'
>     -- Executing [h at tst-parse:1] Hangup("Local/RG-10111-99999 at tst-parse-6114;2", "") in new stack
>   == Spawn extension (tst-parse, h, 1) exited non-zero on 'Local/RG-10111-99999 at tst-parse-6114;2'
>     -- No one is available to answer at this time (1:0/0/0)
>     -- Executing [s at tst-parse:3] Dial("SIP/700-000003ac", "Local/RG-20111-99999 at tst-parse") in new stack
>     -- Called Local/RG-20111-99999 at tst-parse
>     -- Executing [RG-20111-99999 at tst-parse:1] NoOp("Local/RG-20111-99999 at tst-parse-19bc;2", "IN 20111, this is CORRECT") in new stack
>     -- Auto fallthrough, channel 'Local/RG-20111-99999 at tst-parse-19bc;2' status is 'UNKNOWN'
>     -- Executing [h at tst-parse:1] Hangup("Local/RG-20111-99999 at tst-parse-19bc;2", "") in new stack
> {noformat}
> In the case of FreePBX, this breaks functionality when in the event that someone were to have two phone extensions configured with 101 and 10111. The following ticket with FreePBX references this issue:
> http://www.freepbx.org/trac/ticket/5521

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira