[asterisk-users] Ast 13.11.2 : bridgepeer variable empty ?

[Ludovic Gasc]

Hi Matt,

Thank you for your explanation, it's clear to me.

Nevertheless, it doesn't help me in my use case: I'm trying to collect all
SIP callid and store that with cdr_adaptive_odbc.
The business use case is to link Asterisk CDRs with logs from our operators
via their API and our capture tool to give an access in our GUI.

I retrieve easily SIP callid of caller, but not easily for the callee.
For now, the best I have is to use the b option in Dial application and
take that via a subroutine with:
same  =   n,ExecIf($[${LEN(${SIPCALLID})} >
0]?Set(CDR(callee_callid)=${SIPCALLID}))
same  =   n,ExecIf($[${LEN(${SIPCALLID})} =
0]?Set(CDR(callee_callid)=${PJSIP_HEADER(read,call-id)}))

It works, only if the remote party answers. If not, I don't retrieve callid.

Somebody has an idea with dialplan ? My B and C plan is to poll current
channels via asterisk or to intercept callids with a kamailio, but it seems
a little bit overkill, at least to me.

Thanks a lot for your answer.

Have a nice week.

--
Ludovic Gasc (GMLudo)
http://www.gmludo.eu/

2016-09-19 22:57 GMT+02:00 Matthew Jordan <mjordan at digium.com>:

> On Mon, Sep 19, 2016 at 8:34 AM, Jonas Kellens <jonas.kellens at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160920/3fd5fedc/attachment.html>