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

[Matt Jordan]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4519/#review14778
-----------------------------------------------------------


Make sure you document in the CHANGES file that app_stasis now sets a channel variable upon application completion.


./branches/13/apps/app_stasis.c
<https://reviewboard.asterisk.org/r/4519/#comment25358>

    You'll want to document this new channel variable in the XML documentation at the top of the file. Something like:
    
    			<para>This application will set the following channel variable upon completion:</para>
    			<variablelist>
    				<variable name="STASISSTATUS">
    					<para>This indicates the status of the execution of the Stasis application.</para>
    					<value name="SUCCESS" />
    					<value name="FAILED" />
    				</variable>
    			</variablelist>



./branches/13/res/res_stasis.c
<https://reviewboard.asterisk.org/r/4519/#comment25357>

    Since we get a StasisStart event, and the dialplan can't access the variable until the channel is released, I'm not sure we really need to set the STASIS_START variables to INITIALIZING and ACTIVE.
    
    With respect to the INITIALIZING value, a Stasis application won't see that value being set on the channel unless they've already subscribed to the channel. The implicit subscription is created as a result of the control_create call, which happens after the variable is set.
    
    With respect to the ACTIVE value, this is only set after the StasisStart message is sent - at which point, the application is aware of the channel.
    
    When the channel returns from the application, the code in app_stasis will set the value to either "SUCCESS" or "FAILED", which means these values will only have meaning for clients watching the state of the channel through an API.
    
    There may be some value in having AMI clients know this state, but I think it may be rather minor - and this will generate at least two Stasis messages per channel entering into the Stasis dialplan application - so I'm not sure it is really worth the overhead.


- Matt Jordan


On March 22, 2015, 11:36 p.m., Ashley Sanders wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4519/
> -----------------------------------------------------------
> 
> (Updated March 22, 2015, 11:36 p.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: STASIS_STATUS.
> 
> 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/res/res_stasis.c 433290 
>   ./branches/13/apps/app_stasis.c 433290 
> 
> Diff: https://reviewboard.asterisk.org/r/4519/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Ashley Sanders
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150323/9a3f3247/attachment-0001.html>