[asterisk-dev] [Code Review] 2947: ARI: Adding a channel to a bridge while a live recording is active blocks

[Matt Jordan]

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



branches/12/include/asterisk/stasis_app.h
<https://reviewboard.asterisk.org/r/2947/#comment19392>

    I'm not sure I like these functions being present in stasis_app.h. If you look at the rest of the functions that we expose, none are quite at this level of granularity; that is, none are performing reference counting on an operation in progress.
    
    In fact, if you look at Paul's code change in https://reviewboard.asterisk.org/r/2943/, we have a similar situation: a channel is in a long running media operation and should not be changed while that operation is continuing. Anything that does attempt to manipulate the channel should return a 409.
    
    I think I'd prefer a slightly different mechanism, one that isn't so specific to recording or reference counts. Maybe something along the lines of:
    
    * A control object has a list of function pointers that something can register a function callback to that 'check' whether or not a certain operation is allowed. For certain operations - in particular, adding to a bridge and removing from a bridge - stasis_app can query those function callbacks to determine if the operation is currently supported. If not, it return an error from stasis_app_control_add_channel_to_bridge or stasis_app_control_remove_channel_from_bridge.
    
    Essentially, we need observers for adding a channel to a bridge/removing from a bridge that can inspect whether or not that operation is allowed and prevent it if need be.
    
    * The function callbacks can be implemented in the appropriate places, such as resource_recording. When a recording takes place, you register a function on the control object that will check to see if a recording is still occurring. When all recordings have ended, unregister the function.



branches/12/res/ari/resource_bridges.c
<https://reviewboard.asterisk.org/r/2947/#comment19393>

    You actually don't know that it failed due to the channel recording here. This function can fail for a multitude of reasons - the impart can fail, the setting of the after bridge callback, etc.
    
    This is actually a more systemic problem than just here: the stasis_app calls don't translate to HTTP error codes, and there are times when we need to know exactly why this failed.
    
    My suggestion would be to have the stasis_app calls return an enum that indicates their failure condition. That can then be turned into an appropriate HTTP error code in this function.



branches/12/res/ari/resource_channels.c
<https://reviewboard.asterisk.org/r/2947/#comment19391>

    This change shouldn't have been made.


- Matt Jordan


On Oct. 25, 2013, 4:52 p.m., Kevin Harwell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2947/
> -----------------------------------------------------------
> 
> (Updated Oct. 25, 2013, 4:52 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22624
>     https://issues.asterisk.org/jira/browse/ASTERISK-22624
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Added a channel recording flag that is checked before adding a channel to a bridge.  If the the channel is currently being recorded a "409 Conflict" is returned and the channel is not added to the bridge.
> 
> 
> Diffs
> -----
> 
>   branches/12/rest-api/api-docs/bridges.json 401536 
>   branches/12/res/stasis/control.c 401536 
>   branches/12/res/res_stasis_recording.c 401536 
>   branches/12/res/ari/resource_channels.c 401536 
>   branches/12/res/ari/resource_bridges.c 401536 
>   branches/12/include/asterisk/stasis_app.h 401536 
> 
> Diff: https://reviewboard.asterisk.org/r/2947/diff/
> 
> 
> Testing
> -------
> 
> Ran a manual test and also wrote a testsuite test: https://reviewboard.asterisk.org/r/2951/
> 
> 
> Thanks,
> 
> Kevin Harwell
> 
>

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