[asterisk-dev] [Code Review] 3929: ARI: Holding bridge issues with bridge Music on Hold, playback operations, and default channel roles

[Matt Jordan]

> On Aug. 29, 2014, 3:52 p.m., rmudgett wrote:
> > /branches/12/res/stasis/stasis_bridge.c, lines 137-139
> > <https://reviewboard.asterisk.org/r/3929/diff/2/?file=66975#file66975line137>
> >
> >     Since ARI can set a channel's role as holding_participant but currently cannot set options on a role, the holding technology will play MOH as a default.  You probably want to check that the idle_mode option is set as well.

I'm not sure why I would check that. If the channel has any role currently set, then I should just not bother setting anything, as someone else has set the role. Whether or not the idle mode is set is immaterial: if someone has set a role that the holding bridge would recognize, I shouldn't override that.


> On Aug. 29, 2014, 3:52 p.m., rmudgett wrote:
> > /branches/12/res/stasis/stasis_bridge.c, line 146
> > <https://reviewboard.asterisk.org/r/3929/diff/2/?file=66975#file66975line146>
> >
> >     Would silence be a better thing to send than nothing while a channel is in a holding bridge without an announcer?
> >     
> >     Optionally it could be "none" or "silence" depending on the asterisk.conf:transmit_silence option.

No. Inferring actions in ARI is bad. Users can start a silence generator on a channel already; if they want silence, they can start it.

Guessing what users want is how we got here in the first place :-)


- Matt


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


On Aug. 29, 2014, 3:15 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3929/
> -----------------------------------------------------------
> 
> (Updated Aug. 29, 2014, 3:15 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24264
>     https://issues.asterisk.org/jira/browse/ASTERISK-24264
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> When ARI manipulates a bridge, it generally doesn't care what the mixing technology is. Operations should initiate on the bridge regardless of its mixing technology - and while that mixing technology may determine the experience channels within the bridge have, the actual operations themselves should be the same.
> 
> This isn't the case with holding bridges. Currently, the following issues exist:
>  * Music on Hold is played into a bridge using an Announcer channel. There are two issues with it currently:
>    (1) The Music on Hold channel is also not marked as being allowed within a Stasis bridge, so it generally never makes it into the bridge (of any type).
>    (2) Even if it did, because it does not have a bridge role of "announcer", it joins the holding bridge as a participant. Additionally, the holding bridge starts MoH on the Announcer channel (which is ironic, but not super useful).
>  * Playback channels do not join as an announcer. Playing back announcements using the /play operation would not be heard by participants.
>  * Participants join without a role. As such, MoH is started for the channels automatically; however, subsequent bridge operations that would stop MoH would fail (as there is no Announcer channel playing MoH to the bridge). From the perspective of ARI users, this is counter-intuitive - I would not expect MoH to be started for me. The mixing technology determines how media is shared between participants, not the application experience.
> 
> This patch does the following:
>  * The Stasis bridge class now inspects channels as they are going into a bridge. If the bridge has a holding capability, and the channel has no roles, we give it a participant role and mark the default behaviour to have no entertainment. This allows addChannel operations to continue to set a participant role with an entertainment option if it felt like it (or could do it).
>  * The playback channel now gets a role of announcer, as does the music on hold channel. For mixing technologies this is a NoOp; for holding bridges it means the channels should have the expected behaviour.
>  * The music on hold channel is now Stasis approved (tm)
>  * Finally, a small bug in 'core show channel' was observed, in that we attempted to calculate CDR variables for internal channels. That generates an annoying warning; internal channels now no longer attempt to access CDR data.
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/stasis/stasis_bridge.c 422380 
>   /branches/12/res/res_stasis.c 422380 
>   /branches/12/res/ari/resource_bridges.c 422380 
>   /branches/12/main/cli.c 422380 
> 
> Diff: https://reviewboard.asterisk.org/r/3929/diff/
> 
> 
> Testing
> -------
> 
> The bridge-infinite-wait examples on the wiki (that Sam and I are working on) now ... work.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140830/26c20cff/attachment.html>