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

[Mark Michelson]

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