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

[fabled]

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

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?


- fabled


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