[asterisk-dev] [Code Review] 3731: Stasis: Prevent non-stasis channels from entering stasis bridges

[rmudgett]

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



team/rmudgett/stasis_linkedids/res/res_stasis.c
<https://reviewboard.asterisk.org/r/3731/#comment22811>

    This must be called with chan locked.
    
    Accessing datastores on channels must be done with the channel locked.
    
    I don't think you are locking chan for most calls to use this datastore.



team/rmudgett/stasis_linkedids/res/res_stasis.c
<https://reviewboard.asterisk.org/r/3731/#comment22809>

    This assignment is not necessary as you are going to immediately assign it in the next step.



team/rmudgett/stasis_linkedids/res/res_stasis.c
<https://reviewboard.asterisk.org/r/3731/#comment22810>

    Do this unconditionally.
    ast_free is NULL tollerant so you don't need to test first.



team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c
<https://reviewboard.asterisk.org/r/3731/#comment22814>

    obj should be data for consistency with the function typedef.



team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c
<https://reviewboard.asterisk.org/r/3731/#comment22813>

    Probably should not exec Stasis if channel is hungup.
    ast_check_hangup_locked()



team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c
<https://reviewboard.asterisk.org/r/3731/#comment22815>

    This should be ast_free(app_name) and swap_chan should be app_name.



team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c
<https://reviewboard.asterisk.org/r/3731/#comment22816>

    extra blank line



team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c
<https://reviewboard.asterisk.org/r/3731/#comment22817>

    Should these failures remove the queued stasis action?  Or should the queued action be done after the failures.


- rmudgett


On July 8, 2014, 9:03 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3731/
> -----------------------------------------------------------
> 
> (Updated July 8, 2014, 9:03 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23941
>     https://issues.asterisk.org/jira/browse/ASTERISK-23941
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This intercepts channels attempting to enter stasis-controlled bridges that are not themselves controlled by stasis and routes them through Stasis() to be controlled by the Stasis application that controls the channels they are replacing.
> 
> 
> Diffs
> -----
> 
>   team/rmudgett/stasis_linkedids/rest-api/api-docs/events.json 418213 
>   team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c 418213 
>   team/rmudgett/stasis_linkedids/res/stasis/control.c 418213 
>   team/rmudgett/stasis_linkedids/res/stasis/control.h 418213 
>   team/rmudgett/stasis_linkedids/res/stasis/app.c 418213 
>   team/rmudgett/stasis_linkedids/res/stasis/app.h 418213 
>   team/rmudgett/stasis_linkedids/res/res_stasis.c 418213 
>   team/rmudgett/stasis_linkedids/res/ari/ari_model_validators.c 418213 
>   team/rmudgett/stasis_linkedids/res/ari/ari_model_validators.h 418213 
> 
> Diff: https://reviewboard.asterisk.org/r/3731/diff/
> 
> 
> Testing
> -------
> 
> Tested against the updated ARI attended transfer test in https://reviewboard.asterisk.org/r/3732/
> 
> 
> File Attachments
> ----------------
> 
> Collation of this patch and dependency patches.
>   https://reviewboard.asterisk.org/media/uploaded/files/2014/07/09/37484ce9-9db8-4e86-a4b9-3791b8d8b9ac__ari_atxfer.diff
> 
> 
> Thanks,
> 
> opticron
> 
>

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