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

[Mark Michelson]

An alternative could be to set BRIDGEPEER to something like "multi-party",
"conference", or the bridge ID if there are more than two participants.
This way, the only channel you have to set a variable on is the one
joining/leaving the bridge, which means you are not having to lock the
bridge at all. Yes, there would likely be a special case for when the
number of channels first goes from 2 to 3, but the majority of the time,
that's not what would be happening. This way, you still get the VarSet when
the channel enters and leaves, and you have a non-empty value for
BRIDGEPEER when the channel is with multiple parties in a bridge. You won't
get VarSets on the other channels in a bridge when a channel enters or
leaves, though. I'm not sure if that's something that people rely on or not.

On Wed, Aug 10, 2016 at 10:11 AM, Corey Farrell <git at cfware.com> wrote:

> 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
>>
>
>
> --
> _____________________________________________________________________
> -- 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/c37dae12/attachment-0001.html>