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

[rmudgett]

> On Dec. 12, 2014, 7:43 a.m., Matt Jordan wrote:
> > /branches/13/main/bridge_basic.c, lines 2386-2410
> > <https://reviewboard.asterisk.org/r/4259/diff/1/?file=69667#file69667line2386>
> >
> >     Put this in a shared function with the code in retransfer_enter.
> >     
> >     The function could take two channels, lock both, propagate the information, and unlock them.

The code isn't quite the same in both places.  It is just slightly different.  Recalling the transferrer needs common things configured as well as COLP and CLID set.  Recalling the transfer target needs common things as well as just COLP with the private party id removed.  I'll have to think about what common code to pull into a routine.


- rmudgett


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


On Dec. 11, 2014, 6:05 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4259/
> -----------------------------------------------------------
> 
> (Updated Dec. 11, 2014, 6:05 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 429406 
> 
> 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/20141212/d3263ecf/attachment-0001.html>