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

[jrose]

> On July 26, 2013, 2:49 p.m., David Lee wrote:
> > /trunk/res/stasis_http/resource_bridges.c, lines 126-129
> > <https://reviewboard.asterisk.org/r/2691/diff/1/?file=42402#file42402line126>
> >
> >     Are there other reasons adding a role to a channel would fail, or is it always because of an allocation failure?

Well, since roles are always being stripped prior to applying them, the only reason a role would fail to be added is if we fail to allocate a datastore for it. So yeah, it's always going to be an allocation failure unless something important changes.


> 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.

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.


- jrose


-----------------------------------------------------------
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/20130726/cb3a6b98/attachment-0001.htm>