<div dir="ltr">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.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 10, 2016 at 10:11 AM, Corey Farrell <span dir="ltr"><<a href="mailto:git@cfware.com" target="_blank">git@cfware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It might be a problem if BRIDGEPEER is being compared to an empty string to see if a channel is alone.<div><br></div><div>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?</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Aug 9, 2016 at 7:01 PM, Mark Michelson <span dir="ltr"><<a href="mailto:mmichelson@digium.com" target="_blank">mmichelson@digium.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Hi folks,<br>
<br>
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.<br>
<br>
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:<br>
<br>
* Lock the bridge<br>
* Iterate through the channels in the bridge (a maximum of 11 of them)<br>
* Lock the channel<br>
* Append the channel to an array of channel names<br>
* Unlock the channel<br>
* Iterate through the channels in the bridge again (no upper limit this time)<br>
* Lock the channel<br>
* Set the BRIDGEPEER channel variable using the names in the generated array from before (comma-separated)<br>
* Unlock the channel<br>
* Unlock the bridge<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Let me know what your thoughts are on the matter.<br>
<br>
Thanks,<br>
Mark Michelson<br>
<br>
[1] <a href="https://gerrit.asterisk.org/#/c/3445" rel="noreferrer" target="_blank">https://gerrit.asterisk.org/#/<wbr>c/3445</a></div></div><span class="HOEnZb"><font color="#888888"><span><font color="#888888"><br>
<br>
-- <br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailma<wbr>n/listinfo/asterisk-dev</a><br>
</font></span></font></span></blockquote></div><br></div>
<br>--<br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/<wbr>mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div></div>