[asterisk-dev] Channels in a bridge
Jonathan Rose
jonathan.rose at motorolasolutions.com
Fri Jun 2 11:14:51 CDT 2017
Using ast_channel_get_bridge(struct ast_channel *chan), you can get a
reference for the bridge. The channel needs to be locked before you use
that function and you'll need to cleanup the bridge reference when you are
done with it. From there you can use the bridge reference to get the list
of channels (channel snapshots more specifically) on the bridge fairly
trivially using ast_bridge_peers(struct ast_bridge *bridge). You'll have
channel names that way at least which, if you really need to, can be used
to get the channels themselves using ast_channel_get_by_name.
I'm not sure how much that helps. I'm assuming you are using Asterisk 12+
since the bridging API is only usable in those versions.
On Fri, Jun 2, 2017 at 7:17 AM, Wray Ferrell <wferrell1 at nc.rr.com> wrote:
> Hi,
>
> Is there anyway for a channel to know the other channels in their current
> bridge? The reason I ask is I have a customer application that negotiates a
> port using the SIP SDP for out of call signalling using UDP. For security
> purposes they want to route all traffic through their box which is running
> Asterisk instead of allowing the two phones to set up a direct socket
> between them. In other words both phones will negotiate a port with
> Asterisk and I need to take the incoming message from phone A and send it
> on the Phone B. So I added some fields to the configuration file and now
> Asterisk is listening on the negotiated ports for incoming messages. The
> problem is since the message is out of the call I get just the data and the
> IP address/Port it was sent from. Since I saved the negotiated port in the
> sip_pvt structure, I can iterate over all the active dialogs to get the
> sip_pvt structure for the channel, but I don't know how to reach the other
> channel in the call. It seems to me that writing my own channel tech
> doesn't help because of the lack of a call-id associated with the message
> so I was hoping to piggyback on the existing call by stuffing the data in a
> SIP info messge and calling __sip_xmit with the sip_pvt pointer for the
> other call leg. Or maybe there is a more elegant way to solve this issue?
>
> Thanks, Wray
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
--
*Jonathan R. Rose*Senior Systems Engineer
Emergency CallWorks
Motorola Solutions
email: jonathan.rose at motorolasolutions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170602/a205f74f/attachment.html>
More information about the asterisk-dev
mailing list