[asterisk-bugs] [JIRA] (ASTERISK-19205) Most Unique pattern matching broken when trailing "-" is part of extension
Richard Mudgett (JIRA)
noreply at issues.asterisk.org
Wed Nov 14 17:11:45 CST 2012
[ https://issues.asterisk.org/jira/browse/ASTERISK-19205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Mudgett updated ASTERISK-19205:
---------------------------------------
Description:
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
was:
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:
[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)
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:
-- 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'
The results from 1.8 show improper execution, the same was seen on 1.6.2:
-- 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
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
> 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
More information about the asterisk-bugs
mailing list