On 12/27/2023 6:51 PM, Joshua C. Colp wrote:
On Wed, Dec 27, 2023 at 5:23 PM <aster...@phreaknet.org
<mailto:aster...@phreaknet.org>> wrote:
A few questions about the native bridging framework:
In contrast to DAHDI conferencing, which still requires manually
servicing each channel in the conference, in whatever arbitrary
threads
desired, the bridging API is more "event oriented". I have a couple
questions about the latter:
* Is there any way to retain control of a channel in a bridge and
service it manually, e.g. call ast_waitfor/ast_read on it? It
seems
when a channel is imparted to a bridge, a thread is always
created,
with the only difference being you don't need to join it later
with
AST_BRIDGE_IMPART_CHAN_INDEPENDENT. I'm pretty sure the answer is
'no', since that's the entire point of native bridging, but just
want to confirm that... (and that the bridging framework
requires 1
thread per channel)
No. Servicing is yielded to the bridge on being put into a bridge.
Control can be temporarily yielded to a different thread using
ast_bridge_suspend and returned to the bridge using
ast_bridge_unsuspend while in a bridge.
* There are a couple functions for hooking into the bridge, e.g.
ast_bridge_dtmf_hook for DTMF events and ast_bridge_interval_hook
periodically. I don't see anything more generic than this, though.
Say that for certain channels in the bridge I wanted to intercept
the voice frames from the bridge and modify them. I suppose
you just
use framehooks as usual on the channel? I'm guessing there's no
difference in behavior, and that ast_bridge_dtmf_hook is purely a
convenience function.
Framehooks would be used for that purpose. DTMF hooks aren't strictly
a convenience, because they are aware of the threading model of
bridging and can do things within the confines of the bridge without
leaving it.
* Is there any current way to detect if a channel is muted in a
bridge? There's an ast_channel_suppress API, but no API to
read the
datastore, and I don't see anything else that seems relevant to
determining this. Not sure if I've missed something... would code
need to be added to do this?
There is no explicit API for the bridge level muting to check, but
provided the channel lock was held you could probably grab the
ast_bridge_channel using ast_channel_get_bridge_channel, and then look
at the features, and check mute. If the suppress API method is used
instead to mute it and an API doesn't exist for that, then it would
have to be extended.
Thanks, Josh,
One other question I have: is there any current mechanism for
retaining a channel's TX audio in the RX audio it gets from the bridge?
I see in bridge_softmix that the channel's audio is removed, but at
least here I don't see any logic to keep the audio:
https://github.com/asterisk/asterisk/blob/master/bridges/bridge_softmix.c#L199
I thought maybe this was related to the binaural setting, but now I
don't think so since both paths subtract.
Interface wise, this is more about the bridging framework as a whole,
but practically speaking, only bridge_softmix is used as the bridging
technology, so I'm more focused on that.
If the answer is 'no', I'm assuming a bridging option would need to be
added to not subtract the sender's audio from what it gets back from the
bridge? If this was done, would it be fine if only certain technologies,
e.g. bridge_softmix obeyed this? Or does it have to be universally
implemented?
NA
--
_____________________________________________________________________
-- 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
