On Mon, Sep 19, 2016 at 8:34 AM, Jonas Kellens <jonas.kell...@telenet.be> wrote:
> Hello
>
> I can confirm that the variable DIALEDPEERNAME contains the information that
> I would expect in the variable BRIDGEPEER.
>
> But I read nowhere that DIALEDPEERNAME has replaced BRIDGEPEER as of
> Asterisk version 13 ?!
>
> So if this is not the intention, then yes this is probably a bug and should
> be reported.
>

It's intentional.

The BRIDGEPEER variable is set to the parties that you are bridged
with at that moment in time. As participants enter/leave a bridge, the
BRIDGEPEER variable gets set (up to some somewhat reasonable number).
When a channel leaves a bridge, it is removed from the BRIDGEPEER
list.

You can imagine then why the BRIDGEPEER variable isn't typically set
any longer when you are in the 'h' extension - the participants all
left.

Why did this change occur?

In Asterisk 12+, all bridging in Asterisk happens using a flexible
bridging framework. That framework accommodates not just two-party
bridges, but multi-party bridges as well. In fact, all bridges can be
turned into a multi-party bridge simply by adding additional channels.
That flexibility is pretty nice, and enables some pretty interesting
features. Unfortunately, it also makes the value of BRIDGEPEER
somewhat hard to predict. It's not hard to create a scenario where the
value of BRIDGEPEER - if we didn't remove parties that left a bridge -
becomes completely arbitrary.

So what is BRIDGEPEER good for?

It's pretty useful if you're building applications on top of Asterisk
outside of the dialplan. For example, using AMI, you can query that
channel variable to get a snapshot of who all you are in a bridge with
at that point in time.

Why wasn't DIALEDPEERNAME not affected in a similar fashion?

Mostly because dialling is still 'atomic' from the perspective of the
dialplan. When Dial ends, you presumably didn't perform 10 other dials
while that application was executing. Bridging isn't that way; phones
have the ability to manipulate the bridge themselves outside of
Asterisk's control (via attended transfers).

Matt

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

Join the Asterisk Community at the 13th AstriCon, September 27-29, 2016
      http://www.asterisk.org/community/astricon-user-conference

New to Asterisk? Start here:
      https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to