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 <[email protected]> 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 <[email protected]> > 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
