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

[Matt Jordan]

> On July 26, 2013, 2:49 p.m., David Lee wrote:
> > /trunk/rest-api/api-docs/bridges.json, line 128
> > <https://reviewboard.asterisk.org/r/2691/diff/1/?file=42403#file42403line128>
> >
> >     Aren't there use cases where a single channel can have multiple roles within the bridge? After Review 2698 is committed, implementing roles as a comma separated list would be fairly easy.
> 
> jrose wrote:
>     I discussed this very thing with Matt Jordan and he said that since there are currently no situations where multiple roles matter that we should just have this as a singular option for now.
>     
>     That discussion was part of what prompted the conversation about the allowMultiple property actually. I'm certainly down with making multiple roles possible.

Right now, the way roles are envisioned is pretty "coarse" - that is, if I join a bridge that has a mixing technology that understands roles, and that role is "supervisor", it's unlikely that another role - such as "agent" - would have much meaning. In fact, mixing the two may get very odd results.

It is possible, however, that there is some mixing technology that is outside of the use cases we've thought of while developing 12. Being flexible and having multiple roles would be more flexible for future expansion.

So: meh? If it's easy to add then go for it; otherwise, I think it's of limited benefit for the immediate future.


- Matt


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


On July 22, 2013, 10:55 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2691/
> -----------------------------------------------------------
> 
> (Updated July 22, 2013, 10:55 p.m.)
> 
> 
> Review request for Asterisk Developers, David Lee, Matt Jordan, and rmudgett.
> 
> 
> Bugs: ASTERISK-21973
>     https://issues.asterisk.org/jira/browse/ASTERISK-21973
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   /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/
> 
> 
> Testing
> -------
> 
> Actually, the scenario described above was pretty much how I tested it.
> 
> 
> Thanks,
> 
> jrose
> 
>

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