Re: [asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?

[Corey Farrell]

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, maybe re-add the [compat] section.  We create the
built-in variable for retrieval purposes, but still set the value to
generate VarSet events.  It could be enabled by default on 13,
disabled on 14 and removed from 15?

On Wed, Aug 10, 2016 at 11:52 AM, Mark Michelson  wrote:
> 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  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 
>> 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 

Re: [asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?

[Mark Michelson]

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  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 
> 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

Re: [asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?

[Matthew Jordan]

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 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.
>
>
> Relying on BRIDGEPEER for only two party bridges will break down when you
> consider that
> ad-hock multi-party bridges are now allowed.  A bridge may start out being
> two party but wind up
> with multiple participants due to the DTMF transfer feature allowing ad-hock
> multi-party bridges.
>
> The upper limit of 11 is bowing to reality that BRIDGEPEER is not a good way
> to get participants
> for larger multi-party bridges.
>

I know ad-hoc multi-party bridges are why we ended up going with the
approach that we did. I think the issue that Mark outlines, however,
shows that the implications of the approach in large multi-party
bridges - ad-hoc or otherwise - becomes prohibitive.

Corey's suggestion of having the same behavior, but only calculating
it when someone asks for BRIDGEPEER - seems like a reasonable middle
ground. The downside is just that there won't be any events fed to
people, which means people who have built systems looking for those
events are going to be broken.

I suppose we could do the 'unfortunate' thing of having an
asterisk.conf (or some other relatively low level configuration file)
that sets whether or not BRIDGEPEER is evaluated on the fly or all the
time in 13/14, and in master, simply change it to a request-only
variant.

-- 
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

Re: [asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?

[Richard Mudgett]

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

Relying on BRIDGEPEER for only two party bridges will break down when you
consider that
ad-hock multi-party bridges are now allowed.  A bridge may start out being
two party but wind up
with multiple participants due to the DTMF transfer feature allowing
ad-hock multi-party bridges.

The upper limit of 11 is bowing to reality that BRIDGEPEER is not a good
way to get participants
for larger multi-party bridges.

Richard
-- 
_
-- 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

Re: [asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?

[Matthew Jordan]

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 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

Re: [asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?

[Corey Farrell]

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 
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

Re: [asterisk-dev] AstriDevCon on Sep 27th, 2016 in Glendale, AZ - Asterisk Developers invited!

[Matt Fredrickson]

Responses inline.

On Tue, Aug 9, 2016 at 4:42 PM, Ludovic Gasc  wrote:
> Hello Digium's Asterisk Development Team,
>
> Do you already have an overview about the general interest in AstriDevCon ?
> In other words, everybody already subscribed via the Google form will have
> an access to AstriDevCon ?

We historically haven't turned anybody away - so if you signed up via
the form, you are welcome to come.

>
> I come from Brussels, Belgium and I'm mainly interested by AstriDevCon, it's
> why I'm really interested by your answer ;-)

Let me know if you have anymore questions.  Looking forward to seeing you there!

Matthew Fredrickson

>
> Have a nice week.
>
> --
> Ludovic Gasc (GMLudo)
> http://www.gmludo.eu/
>
> 2016-07-19 1:21 GMT+02:00 Digium's Asterisk Development Team
> :
>>
>> Hello Asterisk Developers,
>>
>> This year's AstriDevCon will be held Tuesday, September 27th, 2016 at
>> the Renaissance Phoenix Glendale Hotel & Spa[1] in Glendale, AZ,
>> United States.
>>
>> Your attendance at AstriDevCon is welcome.
>>
>> AstriDevCon is a developers-only event held in conjunction with the
>> annual AstriCon conference.  It includes a review of Asterisk changes
>> and progress made in the past year as well as open discussion about
>> the future direction of the project.  AstriDevCon is also a great
>> opportunity to coordinate your Asterisk projects with other developers
>> in attendance, to pitch ideas for new features or functions, and to
>> meet the core development team in person.
>>
>> For 2016 we’ll be continuing to try new things with the format. We are
>> taking on the open round-table discussion format as used in years
>> past, but this year we are asking that those who want to lead a
>> focused discussion or provide a mini-presentation on a topic to let us
>> know ahead of time. That way we can structure the day accordingly.
>> These focused sessions will be followed by open discussion on how we
>> as a community can work to improve Asterisk accordingly. You'll see a
>> question and field on the registration form to request a slot and
>> provide your summary.
>>
>> As always there should be plenty of time to discuss a wide variety of
>> Asterisk topics until the point that our brains turn to mush.
>>
>> The event is free and open to any developer to attend; however,
>> capacity is limited and preference will be given to active Asterisk
>> code and documentation contributors, reviewers or testers.  Otherwise,
>> it's first-come, first-serve, so please sign up quickly.
>>
>> REGISTRATION:
>> For more details see the wiki page[2]
>> To sign up you can find the form on the wiki page or the direct link
>> in this E-mail[3]
>>
>> We hope to see you there!
>>
>> [1]:
>> http://www.asterisk.org/community/astricon-user-conference/venue-and-travel
>> [2]: https://wiki.asterisk.org/wiki/display/AST/AstriDevCon
>> [3]: http://goo.gl/forms/LAOjEeZVUqDWlwBh1
>>
>> --
>> Digium's Asterisk Development Team
>>
>> 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
>
>
>
> --
> _
> -- 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



-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA

-- 
_
-- 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