Get bridged channel from current channel (in dialplan)

Asterisk Asterisk Support
1

Is there a way to determine, within the dialplan, what the bridged channel is? For example, if I do “Action: CoreShowChannels” in AMI, I can see the BridgedChannel header and get this info. But near as I can tell there is no in dialplan channel variable that tells you this. Also, there seems to be no argument to the CHANNEL(…) application that can tell me this info either.

How can I get the bridged channel from my current channel without resorting to using AMI?

2

There is a variable. Off the top of my head, it is BRIDGEPEER, maybe BRIDGED_PEER, or something in between.

3

That’s kind of what I thought, so I put ${BRIDGEPEER}, ${BRIDGED_PEER}, ${BRIDGEDPEER} in NoOps and they show up in the console as blank. Or are you suggesting these are arguments I should pass to the CHANNEL(…) function?

Also I haven’t manually bridged two channels together yet. I simply trying to get both the channel and bridged channel on an incoming picked up call.

Thanks.

4

${BRIDGEPEER} is set when the bridge is created. Of course the dIalplan is witing in Dial or Queue at that time, but it should be available to AMI, and remain after the bridge has been dropped.

main/features.c: pbx_builtin_setvar_helper(chan, “BRIDGEPEER”, peer->name);
main/features.c: pbx_builtin_setvar_helper(peer, “BRIDGEPEER”, chan->name);

5

So since I am not explicitly doing a bridge myself (I’m just handling an incoming call) then ${BRIDGEPEER} will not be set? So if I understand then, ${BRIDGEPEER} in my case will stay not set even though AMI CoreShowChannels knows the value?

Going through AMI for this is not really an option in my case. Is there some way that the C method “ast_bridged_channel(…)” is exposed somewhere?

Thanks again.

6

It will be set when DIal or Queue bridges the call. It definitely works in 1.6.1.0.

7

I’m on 1.8. So just to clarify, AMI knows what the bridged channel is but I don’t. Is there some way to do something similar to AMI “Action: CoreShowChannels” only done in the dialplan instead? If so I could parse through and pull out the equivalent of BridgedChannel header.

Thanks.

8

How do you intend to locate the channel for which you want to import ${BRIDGEPEER}? There is no point in trying to read it on the channel itself, as, by the time that you can run the dialplan, the peer channel has been hung up.

9

Why do you say the peer channel has been hung up? I maintain an active call tables that holds source/destination/account/channel/bridged channel (not yet). I populate it with func_odbc calls immediately as the call comes in. Hangup handlers remove entries from this table.

The channel and bridged channel would most certainly not be hung up as I’m trying to determine the bridged peer as soon as an incoming call is handled.

Thanks.

10

The bridged peer only comes into existence inside the Dial or Queue application. By that time that application terminates, that channel no longer exists. It might just be accessible from custom features, but, otherwise, you are past the last time to run custom dialplan before the channel even exists, and the channel is closed before the next time you can run dialplan.

11

I’m starting to understand, so thanks for your patience. ${BRIDGEPEER} being limited to use by Dial/Queue is clearly not the solution then.

Is there some dialplan analog of the AMI CoreShowChannels (the CHANNEL(…) function is inadequate apparently)? I desperately need to be able to deteremined the BridgedChannel value as calls come in.

12

There is no bridged channel at the time calls come in!

13

Pardon, once the call is picked up.

14

The underlying channel data structure pointer is not set until the channel is bridged. that is after the last option to run custom dialplan.

DIALEDPEERNAME is set between answer and the various dialplan exists from Dial. However, I think that the CDR also has the same value set at that time.