Summary:	ASTERISK-13340: g option does not work if used from Local channel
Reporter:	Visu Kaka (visu)	Labels:
Date Opened:	2009-01-11 23:00:11.000-0600	Date Closed:	2009-01-20 17:09:16.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	If I dial Local/1@outer, I expected it to execute priority 1 in 'inner' context & then next priority in the line. However, if call is answered at priority 1 ('inner' context), it never goes to priority 2. Interestingly, if I invoke 'inner' context from a SIP account (by dialling Local/1@inner), it works as expected. So this seems to be a specific problem with Local channel. [outer] exten => 1,1,Dial(Local/1@inner) [inner] exten => 1,1,Dial(Gtalk/asterisk/someuser@gmail.com,60,g) exten => 1,n,Playback(vm-goodbye)
Comments:	By: Mark Michelson (mmichelson) 2009-01-15 18:32:02.000-0600 You are correct that this occurs due to the mechanics of local channels. When a local channel gets bridged with the far end (in your case, the gtalk user), then a channel masquerade occurs which results in the outgoing local channel being hung up. This channel which is hung up was the one actually executing dialplan logic in your "inner" context. Because the channel that is executing the dialplan logic has hung up, we cannot continue beyond the dial if the call is answered. That being said, there is a way to avoid the channel masquerade and have your situation work as you would like. If you change priority 1 of your "outer" context to be: exten => 1,1,Dial(Local/1@inner/n) ;notice the /n at the end this will tell the local channel driver not to attempt to optimize away its channels. Executing this way will allow the dialplan execution to continue past when a call is bridged, which will allow the playback to occur as you intend for it to. Now for the fun part of this bug report: whether this actually qualifies as a bug. In my opinion, this seems like one of the reasons why the /n option exists for local channels in the first place and seems like the "proper" way to get the behavior you desire. I don't really think this is a bug, but I do see why the behavior you experienced would be unexpected. By: Mark Michelson (mmichelson) 2009-01-20 17:09:16.000-0600 I've decided to close this as I have provided a workaround and "fixing" this would require rearchitecting how Local channels work.