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

[Corey Farrell]

We should assume that someone is writing BRIDGEPEER to CDR or CEL, and
that this includes 3 party bridges.  I don't like the idea of changing
the format of this variables value, at least not in released branches.

I actually like Matt's "unfortunate" idea of adding an option to
asterisk.conf, maybe re-add the [compat] section.  We create the
built-in variable for retrieval purposes, but still set the value to
generate VarSet events.  It could be enabled by default on 13,
disabled on 14 and removed from 15?

On Wed, Aug 10, 2016 at 11:52 AM, Mark Michelson <mmichelson at digium.com> wrote:
> 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
>
>
>
> --
> _____________________________________________________________________
> -- 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