> On March 24, 2015, 1:15 p.m., rmudgett wrote: > > ./branches/13/apps/app_stasis.c, lines 77-79 > > <https://reviewboard.asterisk.org/r/4519/diff/1/?file=72716#file72716line77> > > > > Using a parameter value before asserting that it is non-NULL is just > > wrong. > > > > That's just closing the barn door after the barn has been destroyed by > > the tornado. :)
Got it. > On March 24, 2015, 1:15 p.m., rmudgett wrote: > > ./branches/13/res/res_stasis.c, lines 1229-1231 > > <https://reviewboard.asterisk.org/r/4519/diff/1/?file=72717#file72717line1229> > > > > Idem. I am dropping this issue since the referenced line is no longer existent after applying the changes brought up by Matt Jordan. - Ashley ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4519/#review14803 ----------------------------------------------------------- On March 27, 2015, 9:54 a.m., Ashley Sanders wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4519/ > ----------------------------------------------------------- > > (Updated March 27, 2015, 9:54 a.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24802 > https://issues.asterisk.org/jira/browse/ASTERISK-24802 > > > Repository: Asterisk > > > Description > ------- > > When an error occurs while writing to a web socket, the web socket is > disconnected and the event is logged. A side-effect of this, however, is that > any application on the other side waiting for a response from Stasis is left > hanging indefinitely (as there is no mechanism presently available for > notifying interested parties about web socket error states in Stasis). > > To remedy this scenario, this patch introduces a new channel variable: > STASISSTATUS. > > The possible values for STASIS_STATUS are: > INITIALIZING - Indicates Stasis is starting > ACTIVE - The channel is active in Stasis > SUCCESS - The channel has exited Stasis without any failures > FAILED - Something caused Stasis to croak. Some (not all) possible > reasons for this: > - The app registry is not instantiated; > - The app requested is not registered; > - The app requested is not active; > - Stasis couldn't send a start message > > ***Note*** This is just the patch to the Asterisk source. The testsuite > review is coming soon to a reviewboard near you (well, this reviewboard.) > https://reviewboard.asterisk.org/r/4520 > > > Diffs > ----- > > ./branches/13/apps/app_stasis.c 433290 > > Diff: https://reviewboard.asterisk.org/r/4519/diff/ > > > Testing > ------- > > The testing done for this issue can be found at: > https://reviewboard.asterisk.org/r/4520/ > > The test in Testsuite exercises three scenarios to elicit updates to the > STASISSTATUS channel variable: > 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' > state is correctly applied. For this test, a call is originated under normal > conditions and then the system is polled for the value of STASIS_STATUS > before the channel is hung up. > 2) The 'Bugs' scenario: tests the situation where a call is originated > requesting an app that was never registered in Stasis to verify the 'FAILED' > state is correctly applied. > 3) The 'Buster' scenario: tests the situation where an app that was > registered in Stasis when call A was originated (and while call A is still > active) but is no longer registered when call B is originated. Determines if > the 'FAILED' state is correctly applied. > > > Thanks, > > Ashley Sanders > >
-- _____________________________________________________________________ -- 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
