----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3040/#review10341 -----------------------------------------------------------
/branches/12/include/asterisk/bridge.h <https://reviewboard.asterisk.org/r/3040/#comment19741> Suggest changing the attended parameter name to imply that it is a boolean value: is_attended. /branches/12/main/bridge.c <https://reviewboard.asterisk.org/r/3040/#comment19740> Word wrap the long comment line or shorten the wordy sentence. /branches/12/main/bridge.c <https://reviewboard.asterisk.org/r/3040/#comment19743> A blank line should be added between variable declarations and code as a separator. /branches/12/main/bridge.c <https://reviewboard.asterisk.org/r/3040/#comment19745> the the How about changing: the the requested transfer to: the transfer /branches/12/main/bridge.c <https://reviewboard.asterisk.org/r/3040/#comment19742> Suggest changing the attended parameter name to imply that it is a boolean value: is_attended. /branches/12/main/bridge.c <https://reviewboard.asterisk.org/r/3040/#comment19746> Use ast_bridge_peers() rather than inlining it. Actually, you don't need to lock the bridge at all because the only caller already has it locked. /branches/12/main/bridge_basic.c <https://reviewboard.asterisk.org/r/3040/#comment19744> The comment no longer makes sence here. - rmudgett On Dec. 4, 2013, 6:11 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3040/ > ----------------------------------------------------------- > > (Updated Dec. 4, 2013, 6:11 p.m.) > > > Review request for Asterisk Developers, Mark Michelson and rmudgett. > > > Repository: Asterisk > > > Description > ------- > > There were still a few cases in which ATTENDEDTRANSFER and BLINDTRANSFER > wouldn't be set on channels involved with blind and attended transfers. This > would happen with features that were initialized by channel driver specific > mechanisms in multiparty calls. This patch resolves those cases while > attempted to keep the behavior for setting those variables as consistent as > possible. > > > Diffs > ----- > > /branches/12/res/parking/parking_manager.c 403068 > /branches/12/res/parking/parking_bridge_features.c 403068 > /branches/12/main/bridge_basic.c 403068 > /branches/12/main/bridge.c 403068 > /branches/12/include/asterisk/bridge.h 403068 > > Diff: https://reviewboard.asterisk.org/r/3040/diff/ > > > Testing > ------- > > Test One - single peer tansfers > 1. Started a two way call between two chan_sip channels. > 2. SIP atxfer'd it to an extension that would display the ATTENDEDTRANSFER > and BLINDTRANSFER variables > 3. repeated test with SIP blindxfer and compared the results. > > Without patch: > Blind transfer variable would be present on blind transfer, attended transfer > variable would be present on attended transfer. > > With patch: > No behavioral change > > Test Two - transferring three party calls > 1. Started a two way call between two chan_sip channels. > 2. Feature ATXfer'd to a local channel that would screech something about > weasels every few seconds. Merged into a 3 way call with *3. > 3. SIP atxfer'd the bridge to an extension that would display > ATTENDEDTRANSFER and BLINDTRANSFER variables > 3. repeated test with SIP blindxfer and compared the results. > > Without patch: > Attended transfer variables weren't set at all. > Blind transfer variables would be set on the channels that were already in > the bridge, but not on the local channel that was used to transfer. > > With patch: > Attended transfer variable set for all channels in the bridge as well as the > local channel used for the transfer. > Blind transer variables set for all channels in the bridge as well as the > local channel used for the transfer. > > > Thanks, > > Jonathan Rose > >
-- _____________________________________________________________________ -- 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
