<div dir="ltr">Hi Matt,<div><br></div><div>Thank you for your explanation, it's clear to me.</div><div><br></div><div>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.<br>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.</div><div><br></div><div>I retrieve easily SIP callid of caller, but not easily for the callee.<br>For now, the best I have is to use the b option in Dial application and take that via a subroutine with:</div><div><div>same  =   n,ExecIf($[${LEN(${SIPCALLID})} > 0]?Set(CDR(callee_callid)=${SIPCALLID}))</div><div>same  =   n,ExecIf($[${LEN(${SIPCALLID})} = 0]?Set(CDR(callee_callid)=${PJSIP_HEADER(read,call-id)}))</div></div><div><br></div><div>It works, only if the remote party answers. If not, I don't retrieve callid.<br><br>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.</div><div><br></div><div>Thanks a lot for your answer.</div><div><br></div><div>Have a nice week.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>--<br><div style="font-size:small"><div>Ludovic Gasc (GMLudo)</div></div><div style="font-size:small"><a href="http://www.gmludo.eu/" target="_blank">http://www.gmludo.eu/</a></div></div></div></div></div>
<br><div class="gmail_quote">2016-09-19 22:57 GMT+02:00 Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Sep 19, 2016 at 8:34 AM, Jonas Kellens <<a href="mailto:jonas.kellens@telenet.be">jonas.kellens@telenet.be</a>> wrote:<br>
> Hello<br>
><br>
> I can confirm that the variable DIALEDPEERNAME contains the information that<br>
> I would expect in the variable BRIDGEPEER.<br>
><br>
> But I read nowhere that DIALEDPEERNAME has replaced BRIDGEPEER as of<br>
> Asterisk version 13 ?!<br>
><br>
> So if this is not the intention, then yes this is probably a bug and should<br>
> be reported.<br>
><br>
<br>
</span>It's intentional.<br>
<br>
The BRIDGEPEER variable is set to the parties that you are bridged<br>
with at that moment in time. As participants enter/leave a bridge, the<br>
BRIDGEPEER variable gets set (up to some somewhat reasonable number).<br>
When a channel leaves a bridge, it is removed from the BRIDGEPEER<br>
list.<br>
<br>
You can imagine then why the BRIDGEPEER variable isn't typically set<br>
any longer when you are in the 'h' extension - the participants all<br>
left.<br>
<br>
Why did this change occur?<br>
<br>
In Asterisk 12+, all bridging in Asterisk happens using a flexible<br>
bridging framework. That framework accommodates not just two-party<br>
bridges, but multi-party bridges as well. In fact, all bridges can be<br>
turned into a multi-party bridge simply by adding additional channels.<br>
That flexibility is pretty nice, and enables some pretty interesting<br>
features. Unfortunately, it also makes the value of BRIDGEPEER<br>
somewhat hard to predict. It's not hard to create a scenario where the<br>
value of BRIDGEPEER - if we didn't remove parties that left a bridge -<br>
becomes completely arbitrary.<br>
<br>
So what is BRIDGEPEER good for?<br>
<br>
It's pretty useful if you're building applications on top of Asterisk<br>
outside of the dialplan. For example, using AMI, you can query that<br>
channel variable to get a snapshot of who all you are in a bridge with<br>
at that point in time.<br>
<br>
Why wasn't DIALEDPEERNAME not affected in a similar fashion?<br>
<br>
Mostly because dialling is still 'atomic' from the perspective of the<br>
dialplan. When Dial ends, you presumably didn't perform 10 other dials<br>
while that application was executing. Bridging isn't that way; phones<br>
have the ability to manipulate the bridge themselves outside of<br>
Asterisk's control (via attended transfers).<br>
<br>
Matt<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Matthew Jordan<br>
Digium, Inc. | CTO<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at: <a href="http://digium.com" rel="noreferrer" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" rel="noreferrer" target="_blank">http://asterisk.org</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
Join the Asterisk Community at the 13th AstriCon, September 27-29, 2016<br>
      <a href="http://www.asterisk.org/community/astricon-user-conference" rel="noreferrer" target="_blank">http://www.asterisk.org/<wbr>community/astricon-user-<wbr>conference</a><br>
<br>
New to Asterisk? Start here:<br>
      <a href="https://wiki.asterisk.org/wiki/display/AST/Getting+Started" rel="noreferrer" target="_blank">https://wiki.asterisk.org/<wbr>wiki/display/AST/Getting+<wbr>Started</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" rel="noreferrer" target="_blank">http://lists.digium.com/<wbr>mailman/listinfo/asterisk-<wbr>users</a><br>
</div></div></blockquote></div><br></div>