> On May 13, 2014, 7:40 a.m., Joshua Colp wrote: > > /branches/12/bridges/bridge_native_rtp.c, lines 233-234 > > <https://reviewboard.asterisk.org/r/3535/diff/1/?file=58431#file58431line233> > > > > I'd add a message SOMEWHERE mentioning this logic, or make it obvious, > > or something. If someone goes mucking with softhangup flags and this > > doesn't get changed... it could go badly. > > Matt Jordan wrote: > Yeah... I had that same feeling writing this. In fact, after checking > again, there's a similar check in bridge_channel which is slightly different > (and slightly wrong) - so this really does belong in its own function some > place. Probably in bridge_channel.
Ended up adding this to channel, as it doesn't really make sense anywhere else. - Matt ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3535/#review11878 ----------------------------------------------------------- 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
