Summary:	ASTERISK-23850: Park Application does not respect Return Context Priority
Reporter:	Andrew Nagy (tm1000)	Labels:
Date Opened:	2014-06-10 11:43:04	Date Closed:	2015-01-13 12:09:17.000-0600
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Resources/res_parking
Versions:	12.2.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Linux 2.6.32-431.el6.i686 (CentOS 6.5 Variant)	Attachments:	( 0) cli.txt ( 1) dialplan.txt ( 2) irc.txt
Description:	Looking at https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Application_Park One of the options for the application is c, used as a return point if the park times out. The parameters are thus: c(context,extension,priority) It appears as if Asterisk 12 does not respect the priority portion and will return the call to the top of the context instead of at the priority point. I have attached the dialplan the CLI log and the relevant IRC conversation between rmudgett and mjordan for review.
Comments:	By: Andrew Nagy (tm1000) 2014-06-10 11:48:37.276-0500 Please note, that the dialplan I have attached has my workaround in there which is to set a variable to know when I am being returned. By: Richard Mudgett (rmudgett) 2014-06-10 12:44:24.328-0500 I think the key here may be that this is taking place within a Macro execution context. By: Andrew Nagy (tm1000) 2014-06-10 14:38:28.039-0500 I will change to gosub and test if you need, matt should probably be hitting me anyways for using macro. By: Richard Mudgett (rmudgett) 2014-12-19 17:21:05.746-0600 The key is using a Macro to park the channel and returning the parked call to an extension *within* that active macro.  (I can get something like this to happen in v11 if I redirect a channel to an extension within an active macro.)  It is actually a bug in app_macro that erroneously restores the macro invocation location when it exits because of a redirect.  When PBX execution comes out of the last active macro level, the PBX executes the restored macro invocation location instead of the expected redirection location. The situation described by this issue does not happen with v11 and earlier versions because parked channels are masqueraded into a brand new context so any PBX context location no longer exists.  In v12+, parked channels are no longer masqueraded.  They are just stuck into the park holding bridge.  Therefore, any active PBX context is still active when the parked channel leaves the parking lot.  The PBX context includes active Macro and Gosub levels. By: Richard Mudgett (rmudgett) 2014-12-22 18:45:40.913-0600 Patch for v11 on reviewboard. https://reviewboard.asterisk.org/r/4292/ I backported a minor ast_channel_lock() movement from v13 to v11 so the patch on reviewboard will not apply without a minor tweak for v13.