On Wed, Dec 27, 2023 at 5:23 PM <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.

Joshua C. Colp
Director of Engineering | Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:

Reply via email to