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

[Matt Jordan]

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

(Updated Sept. 1, 2014, 9:07 a.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
-------

Committed in revision 422503


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 422438 
  /branches/12/res/res_stasis.c 422438 
  /branches/12/main/cli.c 422438 

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/20140901/d7c4da85/attachment.html>