4 thoughts on - Ast 13.11.2 : Bridgepeer Variable Empty ?

• Hi,

  You might use DIALEDPEERNAME instead of BRIDGEPEER.

  Nevertheless, I’ve the same issue with another BRIDGE prefix variable:

  I never retrieve at one moment BRIDGEPVTCALLID variable, even if it’s documented in Asterisk wiki:
  https://wiki.asterisk.org/wiki/display/AST/Asterisk+Standard+Channel+Variables

  Nevertheless, the variable seems to be set in the Asterisk source code:
  https://github.com/asterisk/asterisk/blob/13.10/main/bridge.c#L1222
  I see no issues open about that, do I need to open an issue ?

  Have a nice week.

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

  Kind regards.

  Jonas.

• 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

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