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 <mmichel...@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