[asterisk-dev] [Code Review]: Support 'deaf' participants in ConfBridge

[David Vossel]

> 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.

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.


- 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/e71fd0c4/attachment.htm>