[asterisk-dev] [Code Review] 2691: ARI: Add the ability to specify channel role for /bridges/{}/addChannel

jrose reviewboard at asterisk.org
Mon Jul 22 17:55:11 CDT 2013

This is an automatically generated e-mail. To reply, visit:

Review request for Asterisk Developers, David Lee, Matt Jordan, and rmudgett.

Bugs: ASTERISK-21973

Repository: Asterisk


Some bridges/bridge technology observe a property on channels known as bridge roles. Bridge roles can affect the flow of media in a bridge. One example of this is that the holding bridge technology has two roles at the moment, those being 'holding_participant' and 'announcer'. If no role is specified on channels entering that bridge, they are automatically holding participants and just hear music on hold (or other entertainment options if they are set via role options, but that doesn't apply to ARI yet).

However, if an announcer joins the bridge, all participants currently hearing music on hold will cease to hear music on hold and the announcer will send one way audio to all participants in the bridge. Prior to the addition of this option, there was no way to add a channel to a holding bridge as an announcer through ARI. Now you can do cool things like this:

1. Stick a bunch of people, dogs, scarecrows, automatons, lions, etc in a holding bridge where they are stuck listening to music on hold for a while.
2. Add an announcer channel to the holding bridge so that they can hear a booming voice say "I am the Great and Powerful Wizard of Public Domain Literature!'
3. Remove the announcer and have them resume music on hold.

And it is glorious.


  /trunk/include/asterisk/bridging_roles.h 395076 
  /trunk/include/asterisk/stasis_app.h 395076 
  /trunk/main/bridging_roles.c 395076 
  /trunk/res/res_stasis_http_bridges.c 395076 
  /trunk/res/stasis/control.c 395076 
  /trunk/res/stasis_http/resource_bridges.h 395076 
  /trunk/res/stasis_http/resource_bridges.c 395076 
  /trunk/rest-api/api-docs/bridges.json 395076 

Diff: https://reviewboard.asterisk.org/r/2691/diff/


Actually, the scenario described above was pretty much how I tested it.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130722/74852ecb/attachment-0001.htm>

More information about the asterisk-dev mailing list