[asterisk-dev] Asterisk bridging framework

[asterisk at phreaknet.org]

On 12/27/2023 6:51 PM, Joshua C. Colp wrote:
> On Wed, Dec 27, 2023 at 5:23 PM <asterisk at phreaknet.org 
> <mailto:asterisk at 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