Summary:	ASTERISK-20313: GotoIf redirection to label not working in included extension - document expected behavior on wiki and update sample config
Reporter:	Noah Engelberth (mlnoah)	Labels:
Date Opened:	2012-08-23 18:46:14	Date Closed:
Priority:	Minor	Regression?	No
Status:	Open/New	Components:	Applications/General Core/General
Versions:	SVN 10.4.2 11.0.0-beta1 13.18.4	Frequency of Occurrence
Related Issues:
Environment:	CentOS 6.3 VM on CentOS 6.2 KVM cluster; CentOS 6.3 on Dell Optiplex 790	Attachments:	( 0) dialplan.txt
Description:	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]).
Comments:	By: Noah Engelberth (mlnoah) 2012-08-23 19:30:38.998-0500 Additionally, (at least with the SVN build), Goto and GotoIfTime exhibit the same behavior. By: Leif Madsen (lmadsen) 2012-08-29 10:51:49.275-0500 Actually I don't believe this is a bug. Because you have the switch in the top layer context (users), it is trying to match there first. It likely is matching an extension in your switch, but unable to go to the correct label. If you placed the switch in a context, and included that below the [internal] context, then it would work. I don't believe this to be a bug. By: Leif Madsen (lmadsen) 2012-08-29 10:52:34.891-0500 Additionally, to leave the configuration as-is, the correct dialplan would be to specify the context and extension along with the label name, as you've stated works. By: Noah Engelberth (mlnoah) 2012-08-29 12:18:51.268-0500 At a minimum, it's pretty inconsistent behavior.  Assume you have a context [foo] that is where your call has come into (because the endpoint dials to it or whatever).  [foo] includes [bar], which has the extension you actually are dialing.  If there's a Goto in the extension in [bar] that uses a relative label, and [foo] does NOT have an active DUNDi switch, the Goto works.  However, if the [foo] context (where the call is executing) does have a DUNDi switch, the Goto a relative label within an extension in the included context [bar] doesn't work. In addition, the same behavior occurs if you try to Goto(foo,${EXTEN},label) from context [blah].  If there is no DUNDi switch in [foo], the call falls through to the included [bar],${EXTEN},label.  If there is an active DUNDi switch (reachable or otherwise -- all that matters is that pbx_dundi.so is loaded and the DUNDi switch is active in the dialplan, as I have been doing this on a test box with no DUNDi peers defined and it still "fails"), then the call sent to [foo],${EXTEN},label fails with the error reported -- "Priority 'notloggedin' must be a number > 0, or a valid label".   Further, even when DUNDi is on (or when it is off), Goto(foo,${EXTEN},9) will fall through to [bar],${EXTEN},9.  In addition, Goto(9) within the extension in [bar] will work, whether or not DUNDi is on. I found it pretty jarring to have an otherwise working dialplan break simply because I turned DUNDi on. By: Matt Jordan (mjordan) 2012-09-14 11:10:46.533-0500 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. By: Noah Engelberth (mlnoah) 2012-09-14 11:18:25.050-0500 The reason I reported it as a bug is that, with the switch active, GotoIf works as desired *if* the jump is a numeric priority only, but *not if* the jump is a labeled priority. So, my match has already correctly cascaded into an included context, is executing happily there.  Within the extension that it's operating in using the included context, I have a Goto to jump past dialing the user and go straight to voicemail.  If said Goto is in the format Goto(9), it jumps to priority 9 within the included context & extension it's already operating in.  If said Goto is in the format Goto(label), it complains about the label not existing.  If said Goto is in the format Goto(context,extension,label), it works -- although, of course, the call has now been completely moved into the included context, which I'm trying to avoid for the sake of maintainability. The ONLY time it complains about the label not existing is when there is an active switch in the call's originating context.  With an inactive switch due to unloading DUNDi, or no switch at all, the Goto(label) does correctly jump to priority 9 in the included context & extension the call is operating in. By: Rusty Newton (rnewton) 2012-09-14 14:15:36.823-0500 Yeah, that does seem buggy. Whoever works on documenting the current behavior nuance here will also examine the buggy behavior to see where the issue may lie.  Thanks again for reporting this. By: Birger "WIMPy" Harzenetter (wimpy) 2012-09-15 18:56:20.372-0500 Somehow this issue here escaped me so far. But I discussed it in #asterisk-dev some months ago. I don't think it's related to dundi. It happened to me with loopback switches, but I do indeed have a dundi switch deeper in the dialplan as well. The issue seems to occur when you have both [a] switch[es] and [a] include[s] in a context. My workaround was to convert the includes to loopback switches. Additionally the patterns some people wrote about don't seem to work. [stdissue]But as there is no documentation I'm not sure if that's another bug.