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

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

Reply via email to