[asterisk-dev] [Code Review] 4519: Asterisk: stasis: set a channel variable on websocket disconnect error

[Ashley Sanders]

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150327/2d343121/attachment.html>