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

jrose reviewboard at asterisk.org
Mon Jul 15 15:40:36 CDT 2013


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

(Updated July 15, 2013, 8:40 p.m.)


Review request for Asterisk Developers, Matt Jordan and rmudgett.


Changes
-------

Changed up the approach a little bit while addressing the reviews. With the bridge wrapper now containing an immutable bridge ID, I decided that there was no longer really a purpose to tracking the bridge ID here and instead just take a reference to the bridge. This has simplified a number of things.


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 (updated)
-----

  /trunk/apps/app_bridgewait.c 394388 
  /trunk/include/asterisk/bridging.h 394388 
  /trunk/main/bridging.c 394388 

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/20130715/70a01c61/attachment.htm>


More information about the asterisk-dev mailing list