[asterisk-dev] [Code Review] 2642: app_bridgewait: Add a name argument so that multiple holding bridges may be used

[Matt Jordan]

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



/trunk/apps/app_bridgewait.c
<https://reviewboard.asterisk.org/r/2642/#comment17934>

    This isn't NULL safe and it needs to be.
    
    As a destructor in a RAII_VAR macro, you have to assume that you may be passed NULL. In bridgewait_exec, that will occur if your allocation routine fails - in which case this will be called and passed NULL. You'll pass NULL to holding_bridge_wrapper_pull_if_allowed, which will at a minimum FRACK when you pass NULL to ao2_ref.



/trunk/apps/app_bridgewait.c
<https://reviewboard.asterisk.org/r/2642/#comment17935>

    You may as well log out what channel attempting to enter the holding bridge, as well as the name of the holding bridge (in the same manner that you did in the previous error message)


- Matt Jordan


On July 8, 2013, 6:12 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2642/
> -----------------------------------------------------------
> 
> (Updated July 8, 2013, 6:12 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan and rmudgett.
> 
> 
> Bugs: ASTERISK-21922
>     https://issues.asterisk.org/jira/browse/ASTERISK-21922
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Previously the holding bridge used for bridgewait was a single bridge that once created would stick around until the application was unloaded.
> 
> Now things are a little more complicated. Each holding bridge has a name and will be destroyed when it is empty. Since it's theoretically possible to have channels enter a holding bridge without going through the bridge wait application, it isn't always possible to deliberately control when the bridge will be destroyed, so the bridge can effectively be abandoned and set to be destroyed once it empties out.
> 
> 
> Diffs
> -----
> 
>   /trunk/apps/app_bridgewait.c 393824 
>   /trunk/include/asterisk/bridging.h 393824 
>   /trunk/main/bridging.c 393824 
> 
> Diff: https://reviewboard.asterisk.org/r/2642/diff/
> 
> 
> Testing
> -------
> 
> Tested multiple simultaneous holding bridges, multiple channels in the same holding bridge, what would happen if one channel entered as another one was leaving but before the bridge was destroyed, tested bridges emptying out, tested module unload and module load after unload.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130709/7ef65982/attachment.htm>