> On Aug. 25, 2014, 2:43 p.m., rmudgett wrote:
> > /branches/12/res/ari/resource_bridges.c, lines 425-431
> > <https://reviewboard.asterisk.org/r/3929/diff/1/?file=66745#file66745line425>
> >
> > Remove. This is redundant and too late anyway. The announcer role is
> > already added to the ;2 channel as part of the setup by the Announcer
> > channel technology in chan_bridge_media.c.
Nuts, I misread what happens in my CLI output:
-- Started music on hold, class 'default', on channel
'Announcer/ARI_MOH-00000001;1'
-- Channel Announcer/ARI_MOH-00000001;2 joined 'holding_bridge'
stasis-bridge <1ee2638f-f22a-4599-9bce-31b0447d94a2>
Since the MoH start happens with the joined participant channel just prior to
that, I glanced at that and thought MoH was getting started on the Announcer
channel as a function of them joining the holding bridge (and not the fact that
they're a MoH channel). Doh!
> On Aug. 25, 2014, 2:43 p.m., rmudgett wrote:
> > /branches/12/res/stasis/stasis_bridge.c, lines 208-210
> > <https://reviewboard.asterisk.org/r/3929/diff/1/?file=66747#file66747line208>
> >
> > Why is this being done? For MOH or playback channels they are
> > immovable and can only be hungup when they leave the bridge.
> >
> > If anything, this should be done when the channel is moved out of
> > stasis to a non-stasis controlled bridge as part of the move hook.
This isn't being done for MOH or playback channels, but rather for channels
that join a bridge with a role specified in the POST call:
POST /bridges/1234/addChannel?channel=foo&role=announcer
Say 1234 is a holding bridge. foo joins as an announcer - yay.
Now, however, if we leave the bridge, we don't actually clear the roles. So if
I do this:
POST /bridges/1234/removeChannel?channel=foo
POST /bridges/5678/addChannel?channel=foo
Channel foo will join 5678 as an announcer, as the bridge_channel for the
channel never had its roles removed when the channel was removed from the
bridge.
This concept doesn't feel like it applies to moving between Stasis and
non-Stasis bridges, as it is a problem contained solely within the realm of
Stasis bridges.
- Matt
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3929/#review13171
-----------------------------------------------------------
On Aug. 22, 2014, 11:13 p.m., Matt Jordan wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3929/
> -----------------------------------------------------------
>
> (Updated Aug. 22, 2014, 11:13 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 421906
> /branches/12/res/res_stasis.c 421906
> /branches/12/res/ari/resource_bridges.c 421906
> /branches/12/main/cli.c 421906
>
> 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
