> On Jan. 16, 2015, 6:25 p.m., rmudgett wrote: > > /branches/13/res/stasis/stasis_bridge.c, lines 136-137 > > <https://reviewboard.asterisk.org/r/4341/diff/2/?file=70635#file70635line136> > > > > May need to add this call here to ensure that the swap channel leaves > > the bridge: > > ast_bridge_channel_leave_bridge(swap, > > BRIDGE_CHANNEL_STATE_END_NO_DISSOLVE, 0); > > > > Have to test to see if it is needed.
>From manual testing with PJSIP endpoints, there is no apparent difference in >operation with or without the suggested call. - Scott ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4341/#review14214 ----------------------------------------------------------- On Jan. 16, 2015, 3:58 p.m., Scott Griepentrog wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4341/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2015, 3:58 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24649 > https://issues.asterisk.org/jira/browse/ASTERISK-24649 > > > Repository: Asterisk > > > Description > ------- > > After a transfer completes that uses a local replacement channel, stasis > receives the stasis transfer message with the details of the transfer and > makes changes on the replacement channel. However, since a separate thread > was already started for the purpose of starting stasis on the new replacement > channel, this allowed for a race condition. Occasionally later then normal > arrival of the stasis transfer message would result in the stasis app name > not being set on the replacement channel before it was needed by the other > thread, causing it to fail to start stasis and hang up. > > This change moves the operations (assignment of the stasis app name and > setting the replacement snapshot on the new channel) into the > bridge_stasis_push() callback from the bridge transfer logic. This allows > these steps to be completed earlier and more deterministically, eliminating > the race condition. > > > Diffs > ----- > > /branches/13/res/stasis/stasis_bridge.c 430394 > /branches/13/res/stasis/app.c 430394 > > Diff: https://reviewboard.asterisk.org/r/4341/diff/ > > > Testing > ------- > > The stasis start/end tests that discovered the issue are now passing, and > I've not found any other test failures. > > > Thanks, > > Scott Griepentrog > >
-- _____________________________________________________________________ -- 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
