[asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?

[Corey Farrell]

It might be a problem if BRIDGEPEER is being compared to an empty string to
see if a channel is alone.

What if you made BRIDGEPEER into a built-in channel variable (like
${EPOCH}).  This would mean that you wouldn't be setting any channels,
you'd only do a lookup when requested.  One side-effect is that VarSet
events would never be produced for this variable, not sure how much this
would matter given better events to monitor ConfBridge joins/parts?

On Tue, Aug 9, 2016 at 7:01 PM, Mark Michelson <mmichelson at digium.com>
wrote:

> Hi folks,
>
> I've been looking into a Digium customer issue where ConfBridge audio has
> been dropping out. The main issue there had to do with DNS, and there is
> currently a review [1] up to fix that.
>
> A secondary issue, though, is that there would be brief audio cutouts when
> participants joined and left the conference. Looking into it, I believe the
> problem is that when a participant enters or leaves the bridge, the
> BRIDGEPEER channel variable is updated for every remaining participant in
> the bridge. The basic algorithm is like this:
>
> * Lock the bridge
> * Iterate through the channels in the bridge (a maximum of 11 of them)
>     * Lock the channel
>     * Append the channel to an array of channel names
>     * Unlock the channel
> * Iterate through the channels in the bridge again (no upper limit this
> time)
>     * Lock the channel
>     * Set the BRIDGEPEER channel variable using the names in the generated
> array from before (comma-separated)
>     * Unlock the channel
> * Unlock the bridge
>
> In addition, this same process occurs every time an announcement is played
> into a bridge, such as join/leave beeps. Playing an announcement involves
> pushing an announcer channel into the bridge and then removing the
> announcer channel when the playback completes.
>
> My question to the list is this: do you find value in having the
> participants in a multi-party bridge packaged into the BRIDGEPEER channel
> variable? I know that for two-party bridges, there are probably lots of
> scripts and dialplans out there that rely on that variable to be set; my
> question specifically is for bridges with more than two parties.
>
> My thoughts on the matter are that since bridges are query-able now
> directly, getting the list of participants from the bridge makes more sense
> than trying to get the participants based on a single channel in that
> bridge. In addition, the code places a hard limit on the number of channel
> names it will actually put in the BRIDGEPEER variable. The code currently
> has a #define that makes it so that only the first 11 channels in the
> bridge will have their names in BRIDGEPEER. Because of the hard-coded
> maximum, if you have more than 11 channels in the bridge, you can't get the
> full list of participants using BRIDGEPEER.
>
> By not setting BRIDGEPEER on channels in multi-party bridges, we can avoid
> holding the bridge ransom while calculating the value and setting the
> variable.
>
> Let me know what your thoughts are on the matter.
>
> Thanks,
> Mark Michelson
>
> [1] https://gerrit.asterisk.org/#/c/3445
>
> --
> _____________________________________________________________________
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160810/915a0a1f/attachment-0001.html>