[asterisk-dev] [Code Review] 4259: DTMF atxfer: Setup recall channels as if the original transferrer originated the call.

[Matt Jordan]

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

Ship it!


Ship It!

- Matt Jordan


On Dec. 15, 2014, 12:51 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4259/
> -----------------------------------------------------------
> 
> (Updated Dec. 15, 2014, 12:51 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23841
>     https://issues.asterisk.org/jira/browse/ASTERISK-23841
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> After the initial DTMF atxfer call attempt to the transfer target fails to
> answer during a blonde transfer, the recall callback channels do not get
> setup with information from the initial transferrer channel.  As a result,
> the recall callback to the transferrer does not have callid, channel
> variables, datastores, accountcode, peeraccount, COLP, and CLID setup.  A
> similar situation happens with the recall callback to the transfer target
> but it is less visible.  The recall callback to the transfer target does
> not have callid, channel variables, datastores, accountcode, peeraccount,
> and COLP setup.
> 
> * Added missing information to the recall callback channels before
> initiating the call.  callid, channel variables, datastores, accountcode,
> peeraccount, COLP, and CLID
> 
> * Set callid of the transferrer channel on the DTMF atxfer controller
> thread attended_transfer_monitor_thread().
> 
> * Added missing channel unlocks and props unref to off nominal paths in
> attended_transfer_properties_alloc().
> 
> 
> Diffs
> -----
> 
>   /branches/13/main/bridge_basic.c 429611 
> 
> Diff: https://reviewboard.asterisk.org/r/4259/diff/
> 
> 
> Testing
> -------
> 
> A calls B
> B initiates a DTMF blonde transfer to C but C doesn't answer
> 
> * When B is recalled, B sees A's CLID with the patch and a UUID without
> the patch.
> 
> * If B answers the recall call, A gets the original B channel COLP
> information with the patch.  Without the patch A loses COLP information
> such as B's name.  Also "core show channel B" shows channel variables that
> wouldn't be there without the patch.
> 
> * The debug log now has a callid for the recall calls where before the
> recall calls didn't have any callid.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141219/0a6a3401/attachment.html>