----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3535/#review11884 -----------------------------------------------------------
/branches/12/bridges/bridge_native_rtp.c <https://reviewboard.asterisk.org/r/3535/#comment21768> Soft hangup flags are bit flags. You need to be using the & operator to test not the == operator. if (flags & (ASYNCGOTO | UNBRIDGE)) at least one of the flags is set - rmudgett On May 13, 2014, 7:11 a.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3535/ > ----------------------------------------------------------- > > (Updated May 13, 2014, 7:11 a.m.) > > > Review request for Asterisk Developers and Joshua Colp. > > > Repository: Asterisk > > > Description > ------- > > This patch fixes the currently failing > pjsip/transfers/blind_transfer/caller_direct_media test (with a few small > tweaks to the test as well). > > The test currently fails primarily for two reasons: > (1) When Bob and Charlie (the transfer target and the transfer destination) > enter a bridge together, the framehook remains on the transfer target channel > until both channels are in the bridge. As it consumes voice frames, the > initial bridge type is a simple bridge. The framehook is removed when both > channels are in the bridge; however, this does not currently cause the > bridging framework to re-evaluate the bridge. This patch adds a > AST_SOFTHANGUP_UNBRIDGE poke to the transfer target channel when a framehook > is removed so the bridge can re-evaluate itself. > > (2) When a channel leaves a native RTP bridge, it may be leaving due to being > hung up. Sending a re-INVITE to a channel that is about to be hung up is not > nice - in fact, there's a good chance we'll send the BYE request before the > channel has had a chance to send back a 200 OK. To be somewhat nicer, this > patch makes it so that we only send the re-INVITE if there's a chance the > channel will survive the native bridging experience. > > > Diffs > ----- > > /branches/12/main/framehook.c 413786 > /branches/12/bridges/bridge_native_rtp.c 413786 > > Diff: https://reviewboard.asterisk.org/r/3535/diff/ > > > Testing > ------- > > Once some timing issues were removed from the test, it passes with this patch. > > > Thanks, > > Matt Jordan > >
-- _____________________________________________________________________ -- 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
