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
    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
        when a channel is imparted to a bridge, a thread is always
        with the only difference being you don't need to join it later
        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?


-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Reply via email to