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? >
I think fixing this is going to be a breaking change no matter what we do. Having a 'pull' mechanism that still results in the same output is nice, in that if someone *were* relying on getting some form of list of the participants, they can still do so. I will say that removing the VarSet for BRIDGEPEER would break a fair number of testsuite tests, although that shouldn't be a reason not to do the change. It is evidence, however, that we ourselves relied on the setting of BRIDGEPEER to get an indication of who the channel was in a bridge with. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- 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
