> On Aug. 29, 2014, 3:52 p.m., rmudgett wrote: > > /branches/12/res/stasis/stasis_bridge.c, line 140 > > <https://reviewboard.asterisk.org/r/3929/diff/2/?file=66975#file66975line140> > > > > Optional nit: Extra blank line :) > > Matt Jordan wrote: > Well, that extra blank line was there to prevent the conditional clauses > in the if statement from lining up to closely with the code inside the if > statement. I can remove the tabs for the conditional clauses and use spaces > instead, but I'm not sure how much it will improve readability.
I don't think simply removing the blank line alters the readability because the guidelines make it that way. Though mixing tabs and spaces tends to make people see red. :) - rmudgett ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3929/#review13203 ----------------------------------------------------------- On Aug. 29, 2014, 7:31 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, 7:31 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 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
