[asterisk-dev] [Code Review]: Support 'deaf' participants in ConfBridge
David Vossel
reviewboard at asterisk.org
Fri Dec 30 15:23:09 CST 2011
> On Dec. 29, 2011, 10:51 a.m., David Vossel wrote:
> > /trunk/bridges/bridge_softmix.c, lines 852-870
> > <https://reviewboard.asterisk.org/r/1645/diff/1/?file=22467#file22467line852>
> >
> > This will work, but it breaks the layers of abstraction set up between app_confbridge bridging.c and bridge_softmix.
> >
> > Until now, the bridging technology layer (in this case bridge_softmix) did not need to know anything about the bridge's features. All it was responsible for was the bridge's tech_args structure. By forcing all the features to live at the bridging.c layer, we can be sure all those features are handled in a way that is generic to all bridging technologies. This is very important as it allows us to completely exchange bridging_softmix.c with another bridging technology in the future without having to re-implement any of the user features in the bridging API.
> >
> > This layer can be preserved by defining a function that is a wrapper for the ast_write() function in bridging.c which can intercept the frame before it is written to the channel and replace it with the NULL frame when deaf mode is in use. bridge_softmix will then use that function to write frames to a channel instead of ast_write directly.
>
> fabled wrote:
> Yes, I figured this was the intention. For bridge_softmix, it would still make sense to detect it explicitly, as we can avoid the per-participant mixing (removal of own voice), and transcoding (if participant using codec of it's own).
>
> Additionally, it appears that sending NULL frames will inhibit outbound RTP packets. Is there a way to force sending of silence RTP frames, or should those be sent explicitly? Or is it acceptable inhibit them?
>
> Will fix the two other typos.
>
> David Vossel wrote:
> Ah yes, the rtp thing is an issue. Something like this might work.
>
> --------------------
> /* Make SLINEAR write frame from local buffer */
> if (sc->write_frame.subclass.format.id != cur_slin_id) {
> ast_format_set(&sc->write_frame.subclass.format, cur_slin_id, 0);
> }
> sc->write_frame.datalen = softmix_datalen;
> sc->write_frame.samples = softmix_samples;
>
> if (deaf) {
> memset(sc->final_buf, 0, softmix_datalen);
> } else {
> memcpy(sc->final_buf, buf, softmix_datalen);
>
> /* process the softmix channel's new write audio */
> softmix_process_write_audio(&trans_helper, &bridge_channel->chan->rawwriteformat, sc);
> }
>
> /* The frame is now ready for use... */
> sc->have_frame = 1;
>
> ast_mutex_unlock(&sc->lock);
>
> /* Poke bridged channel thread just in case */
> pthread_kill(bridge_channel->thread, SIGURG);
> ----------------------
>
> I still don't like the idea of having this at the mixing technology layer. I understand it is more efficient to do it this way. I don't really have a good solution for this. I suppose it is possible we could create a generic way of doing deaf mode and allow the bridge technology to override the generic way for a technology specific way.
>
> fabled wrote:
> This would mean that each deaf/talk-only channel would need it's transcoder to encode silence. So this would lose the other part of the optimization. But I guess that would not be a common problem.
>
> I will try to come up with a proper bridge wrapper for ast_write that will handle this too for other technologies. Any suggestions for the wrapper function?
Something like this in the bridging_technology.h file would work I suppose.
/*! \brief Used by bridging technologies to hand off a frame to be written to a bridge_channel.
*
* \note This function is essentially a wrapper for ast_write(). The bridging core has some features associated with it
* that requires it to have control over how frames are written into a channel. For these features to be available, the bridging
* technology must use this wrapper function over ast_write when pushing a frame out a channel.
*/
ast_bridge_handle_channel_write(struct ast_bridge *bridge, struct ast_bridge_channel *bridge_channel, struct ast_frame *frame)
- David
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1645/#review5083
-----------------------------------------------------------
On Dec. 30, 2011, 8:44 a.m., fabled wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1645/
> -----------------------------------------------------------
>
> (Updated Dec. 30, 2011, 8:44 a.m.)
>
>
> Review request for Asterisk Developers.
>
>
> Summary
> -------
>
> Support 'deaf' participants in ConfBridge
>
>
> This addresses bug ASTERISK-19109.
> https://issues.asterisk.org/jira/browse/ASTERISK-19109
>
>
> Diffs
> -----
>
> /trunk/apps/app_confbridge.c 349196
> /trunk/apps/confbridge/conf_config_parser.c 349196
> /trunk/apps/confbridge/include/confbridge.h 349196
> /trunk/bridges/bridge_softmix.c 349196
> /trunk/include/asterisk/bridging_features.h 349196
>
> Diff: https://reviewboard.asterisk.org/r/1645/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> fabled
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111230/2a38244a/attachment-0001.htm>
More information about the asterisk-dev
mailing list