[asterisk-bugs] [JIRA] Commented: (ASTERISK-20313) GotoIf redirection to label not working in included extension

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-20313:
----------------------------------------

So Leif, Jason and I discussed this problem for awhile in #asterisk-bugs.  I completely understand how this issue is confusing.

The expected priority order for dialplan evaluation will be:
# local
# switch
# includes

Since you're operating under the [users] context, the dialplan matching starts there.  The fact that the current executing extension happens to be in an include matters when the dialplan has to evaluate where to jump to.  When execution hits your {{GotoIf}}, it will do the following:

* Notice that its in the context {{\[users\]}}.  It will first look to see if there's something in that local context with a matching extension and a matching priority label.  Since none exists, it moves on.
* It will then look at the {{switch}}.  Since there is apparently an extension match, but not a priority label match, it bombs.
* *If* there was no extension match in the DUNDi {{switch}}, then I would expect it would evaluate the {{includes}}, at which point you would get the behavior you expect.

Note that you should be able to create the behavior you want by doing:

{noformat}

[users]

include => internal
include => dummyextensions
include => switches

[switches]

switch => DUNDi/dundi-peer

[internal]

; ...

{noformat}

Since the {{switch}} is now in an {{include}}, that occurs after your {{include}} of {{\[internal\]}}, it will be evaluated in the order that you want.

This certainly merits a lot of detailed explanation that is not readily present, and the readily available documentation is unclear at best, and potentially misleading at worst.  So we'll accept this issue as an opportunity to go clarify the documentation.

> GotoIf redirection to label not working in included extension
> -------------------------------------------------------------
>
>                 Key: ASTERISK-20313
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20313
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/General, Core/General
>    Affects Versions: SVN, 10.4.2, 11.0.0-beta1
>         Environment: CentOS 6.3 VM on CentOS 6.2 KVM cluster; CentOS 6.3 on Dell Optiplex 790
>            Reporter: Noah Engelberth
>            Assignee: Matt Jordan
>            Severity: Minor
>         Attachments: dialplan.txt
>
>
> I run a hotdesking system based on the example from Asterisk: The Definitive Guide.  Calls come into the [hotdesk] context, which verifies the phone has a logged in user and sends the call to users,${EXTEN},1 if there is a user logged in.  The [users] context then includes several other contexts for internal/external call handling, as attached.  In both Asterisk 10 and Asterisk 11, the GotoIf does not work under the circumstances shown, giving me the following error and hanging up the call:
> [Aug 23 15:17:35] WARNING[3558][C-00000565]: pbx.c:11799 pbx_parseable_goto: Priority 'notloggedin' must be a number > 0, or valid label
> I can work around the issue with any of the following:
> -	Change the GotoIf to point to internal,${EXTEN},notloggedin
> -	Change the GotoIf to point to 9
> -	Comment out the DUNDi switch in [users]
> -	Unload the pbx_dundi.so module
> In the latter two cases, the call redirects to the notloggedin priority label within [internal],${EXTEN} without me changing the GotoIf - as long as the DUNDi switch is not active in [users].  With the DUNDi switch active, I get the warning message above and the call hangs up.
> I have tried with several other words for the label -- no label works.  I've had the target priority at different points in the extension, ranging from 9 to 15 -- if I call it numerically or as a full context,extension,priority it works, but just calling the priority as a label does not as long as the DUNDi switch is active in the original context the call is operating out of ([users]).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira