We should assume that someone is writing BRIDGEPEER to CDR or CEL, and
that this includes 3 party bridges. I don't like the idea of changing
the format of this variables value, at least not in released branches.
I actually like Matt's "unfortunate" idea of adding an option to
asterisk.conf,
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
On Wed, Aug 10, 2016 at 10:42 AM, Richard Mudgett wrote:
>
>
> On Tue, Aug 9, 2016 at 6:01 PM, Mark Michelson
> wrote:
>>
>> Hi folks,
>>
>> I've been looking into a Digium customer issue where ConfBridge audio has
>> been dropping out. The main issue
On Tue, Aug 9, 2016 at 6:01 PM, Mark Michelson
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
On Wed, Aug 10, 2016 at 10:11 AM, Corey Farrell 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
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
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