> On June 5, 2014, 12:45 p.m., Mark Michelson wrote: > > /branches/12/include/asterisk/channel.h, line 4300 > > <https://reviewboard.asterisk.org/r/3585/diff/1/?file=59216#file59216line4300> > > > > It's a tough thing to do, but I'd like to see this function's name > > imply that channels that are being hung up do not count as "leaving the > > bridge". > > Matt Jordan wrote: > The intent is for a function to test to see if a channel that would > normally be "hung up" (ast_check_hangup would return true) just wants out of > a bridge, and is not actually "hung up". > > Our dual purposing of soft hangup flags was a really bad idea. > > Names I've thought of, besides this one: > - ast_channel_wants_out_of_bridge > - ast_channel_check_hangup_but_not_really_hungup > - ast_channel_will_survive_this_operation > > (Kidding, of course) > > Can you think of anything else to call this? > > Mark Michelson wrote: > Um...no. ast_channel_check_break_bridge() is the only thing I can think > of but it's not any better (in fact it's worse) than > ast_channel_is_leaving_bridge().
I can't think of much better right now either. I'll drop it for now, unless someone thinks of a better function name. - Matt ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3585/#review12053 ----------------------------------------------------------- On June 4, 2014, 11:43 a.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3585/ > ----------------------------------------------------------- > > (Updated June 4, 2014, 11:43 a.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > ------- > > This patch is a re-do of review 3535. > > When review request 3535 was merged, a major problem with it was uncovered. > UNBRIDGE soft hangup flags have a catastrophic effect on the pbx core if they > leak out from the bridge layer: the channel gets hung up. With the number of > threads involved in a blind transfer, and with the initial patch, it was > likely that this would occur. This caused a large number of test failures > > This patch is nearly identical with the one proposed in review 3535, save for > the following changes: > - We explicitly clear the UNBRIDGE flag when setting an after goto on a > channel in a bridge > - Defensively, if we encounter an UNBRIDGE flag in the pbx core, we handle it > > > Diffs > ----- > > /branches/12/main/pbx.c 414996 > /branches/12/main/framehook.c 414996 > /branches/12/main/channel.c 414996 > /branches/12/main/bridge_channel.c 414996 > /branches/12/main/bridge_after.c 414996 > /branches/12/include/asterisk/channel.h 414996 > /branches/12/bridges/bridge_native_rtp.c 414996 > > Diff: https://reviewboard.asterisk.org/r/3585/diff/ > > > Testing > ------- > > The blind transfer tests for PJSIP now pass (fingers crossed). See review > 3586. > > > 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
