----------------------------------------------------------- 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev