----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3852/#review12880 -----------------------------------------------------------
Ship it! Minor nit. team/group/ari-greedy-atxfer/res/res_stasis.c <https://reviewboard.asterisk.org/r/3852/#comment23249> Probably should assert on this exit path because the datastore inexplicably dissapeared between finding it and removing it. Or you could forget about the assert and either invert the test or make it unconditonal to eliminate a return path. - rmudgett On July 25, 2014, 4:30 p.m., opticron wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3852/ > ----------------------------------------------------------- > > (Updated July 25, 2014, 4:30 p.m.) > > > Review request for Asterisk Developers, Mark Michelson and rmudgett. > > > Bugs: ASTERISK-23941 > https://issues.asterisk.org/jira/browse/ASTERISK-23941 > > > Repository: Asterisk > > > Description > ------- > > This handles the situation where a channel is masqueraded out of stasis to go > elsewhere. It ensures that the correct StasisEnd message is sent and performs > other cleanup necessary to prevent spurious messages from reaching Stasis > applications that aren't prepared for them. > > > Diffs > ----- > > team/group/ari-greedy-atxfer/res/res_stasis.c 419315 > > Diff: https://reviewboard.asterisk.org/r/3852/diff/ > > > Testing > ------- > > Used the AMI Bridge command to pull the channel currently in Stasis() into a > non-Stasis bridge and verified the messages coming back. > > > Thanks, > > opticron > >
-- _____________________________________________________________________ -- 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
