Summary:	ASTERISK-08066: [patch] callee->context is always empty
Reporter:	Sergey Tamkovich (sergee)	Labels:
Date Opened:	2006-11-03 16:35:46.000-0600	Date Closed:	2006-11-20 09:57:11.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) patch1-dial-r47050.diff
Description:	I'm not sure if this is a bug or a feature, but callee's context is always explicitly blanked in wait_for_answer() subroutine... However there is a code in asterisk, that checks callee's context - real_ctx() routine in res_features.c in case if transferer == callee (most common case i suppose) [see bug 8224 ] I suppose that we need to remove blanking of context from wait_for_answer() subroutine.
Comments:	By: Olle Johansson (oej) 2006-11-07 02:22:05.000-0600 Very good catch! By: Olle Johansson (oej) 2006-11-07 02:24:31.000-0600 ->context might be suffering from dual use - indicating the entry for new calls or transfers in this channel as well as the current execution point. We might have to split it up and add ->entrycontext By: Sergey Tamkovich (sergee) 2006-11-07 02:55:20.000-0600 oej, i didn't find a reason, why we can't keep nonblank values in calee->context and callee->exten. E.g. i didn't find any evidences of dual usage... Those fields are always blank on my asterisk.. By: Joshua C. Colp (jcolp) 2006-11-07 13:03:09.000-0600 So - the reason the change that caused this originally went in is because of directed pickup. Kevin and I couldn't think of a reason why exten and context would be set on outbound calls from app_dial, and it seems we may have been wrong. As it stands right now what happens is that during the phase before the channel is answered we set the extension and context to the values in the dialplan where app_dial was executed from, if present. This allows directed pickup to essentially iterate through and find channels that can be picked up easily. Now - this might affect res_features transfers and needs to be tested. I will try to lab it up when I get time, or if someone else can do it easily - feel free to. By: Joshua C. Colp (jcolp) 2006-11-20 09:57:10.000-0600 This has been changed to use a separate variable as of revision 47850 for 1.4 and 47851 for trunk - so this isn't valid anymore. Peace!