-----------------------------------------------------------
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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
