[asterisk-dev] [Code Review] Prevent caller ID set on channel from getting discarded when originate used with local channel (small patch - review quickly, earn rewards!)

[Jeff Peeler]

> On 2010-08-04 17:36:19, Mark Michelson wrote:
> > There's more to this problem than what is being fixed here.
> > 
> > Here's what's happening: Asterisk requests the channel from the originate command (Local/5001 at default). When __ast_request_and_dial() returns, the channel returned is the ,1 channel of the local channel pair. ast_pbx_outgoing_exten then starts a PBX on this ,1 channel. The problem is that as soon as a write operation occurs on the ,2 channel, the masquerade will be set up. From there, just about any channel operation will cause the masquerade to occur. The wait(1) that is used in the s at kobaz3 extension actually is what is causing the masquerade to get set up and executed. Without the wait, the masquerade may not occur until the final bridge is up and running after the dial application call. The big issue here is that it's not just caller ID on the ,1 channel that will be lost, everything that's set on the channel prior to the masquerade will go away, such as channel variables, CDR data, and audiohooks.
> >  
> > I think a better solution here is to ensure that the masquerade occurs prior to starting the PBX on the returned channel from __ast_request_and_dial(). An ast_waitfor()/ast_read() pair may do the trick.
> 
> Mark Michelson wrote:
>     I mentioned that channel variables would be lost after the masquerade, but this isn't actually correct since the clone's channel variables will just be appended to the original channel, not swapped. Still, other data has the potential to be lost so my point still stands that the masquerade should be forced before the PBX is started.

I'm glad you said this because I checked on this before I started addressing just the lost caller ID. Your approach is much cleaner though, so a new patch will be produced.


- Jeff


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/847/#review2540
-----------------------------------------------------------


On 2010-08-04 16:20:43, Jeff Peeler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/847/
> -----------------------------------------------------------
> 
> (Updated 2010-08-04 16:20:43)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> The scenario here is that the channel that caller ID is set on is getting swapped with the zombie channel which is hung up and then lost. I am weary of the this change though as I am unsure if the clone channel would ever have valuable caller ID that needs to be swapped.
> 
> (Proof that this is not a trap)
> To demonstrate the issue put the snippet below in your dialplan, changing the endpoints sip/5001 and sip/5002:
> 
> [default]
> exten => 5001, 1, dial(sip/5001,,tTkK)
> 
> [kobaz3]
> exten => s, 1, noop("dialnumber")
> exten => s, n, set(CALLERID(name)=FooBarInc)
> exten => s, n, set(CALLERID(num)=8005551120)
> exten => s, n, set(CHANNEL(callgroup)=3)
> exten => s, n, noop("about to wait")
> exten => s, n, wait(1) ; delay so that masquerade completes
> exten => s, n, noop("done waiting callerid name ${CALLERID(name)}") ; callerid will not have original values
> exten => s, n, dial(sip/5002)
> 
> And then do an originate:
> originate local/5001 extension s at kobaz3
> 
> 
> This addresses bug 17138.
>     https://issues.asterisk.org/view.php?id=17138
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/main/channel.c 280912 
> 
> Diff: https://reviewboard.asterisk.org/r/847/diff
> 
> 
> Testing
> -------
> 
> Fixes the problematic scenario.
> 
> 
> Thanks,
> 
> Jeff
> 
>