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

[Matthew Jordan]

On Wed, Aug 10, 2016 at 10:42 AM, Richard Mudgett <rmudgett at digium.com> wrote:
>
>
> On Tue, Aug 9, 2016 at 6: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.
>
>
> Relying on BRIDGEPEER for only two party bridges will break down when you
> consider that
> ad-hock multi-party bridges are now allowed.  A bridge may start out being
> two party but wind up
> with multiple participants due to the DTMF transfer feature allowing ad-hock
> multi-party bridges.
>
> The upper limit of 11 is bowing to reality that BRIDGEPEER is not a good way
> to get participants
> for larger multi-party bridges.
>

I know ad-hoc multi-party bridges are why we ended up going with the
approach that we did. I think the issue that Mark outlines, however,
shows that the implications of the approach in large multi-party
bridges - ad-hoc or otherwise - becomes prohibitive.

Corey's suggestion of having the same behavior, but only calculating
it when someone asks for BRIDGEPEER - seems like a reasonable middle
ground. The downside is just that there won't be any events fed to
people, which means people who have built systems looking for those
events are going to be broken.

I suppose we could do the 'unfortunate' thing of having an
asterisk.conf (or some other relatively low level configuration file)
that sets whether or not BRIDGEPEER is evaluated on the fly or all the
time in 13/14, and in master, simply change it to a request-only
variant.

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org