[asterisk-bugs] [Asterisk 0014212]: g option does not work if used from Local channel

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14212 
====================================================================== 
Reported By:                visu
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14212
Category:                   Applications/app_dial
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-01-11 23:00 CST
Last Modified:              2009-01-15 18:32 CST
====================================================================== 
Summary:                    g option does not work if used from Local channel
Description: 
If I dial Local/1 at 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 at inner),
it works as expected. So this seems to be a specific problem with Local
channel.

[outer]
exten => 1,1,Dial(Local/1 at inner)

[inner]
exten => 1,1,Dial(Gtalk/asterisk/someuser at gmail.com,60,g)
exten => 1,n,Playback(vm-goodbye)

====================================================================== 

---------------------------------------------------------------------- 
 (0097997) putnopvut (administrator) - 2009-01-15 18:32
 http://bugs.digium.com/view.php?id=14212#c97997 
---------------------------------------------------------------------- 
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 at 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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-15 18:32 putnopvut      Note Added: 0097997                          
======================================================================