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

[fabled]

> On Dec. 29, 2011, 10:51 a.m., David Vossel wrote:
> > /trunk/apps/app_confbridge.c, lines 339-342
> > <https://reviewboard.asterisk.org/r/1645/diff/1/?file=22464#file22464line339>
> >
> >     do these sounds exist yet?

No. There was no similar recordings in MeetMe. I added this just to match with mute functionality, and they might be useful. But personally I do not need them (I have certain profiles that have startdeaf=yes, and their 'deaf' state will not be altered).


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

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.


- fabled


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1645/#review5083
-----------------------------------------------------------


On Dec. 28, 2011, 12:39 a.m., fabled wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1645/
> -----------------------------------------------------------
> 
> (Updated Dec. 28, 2011, 12:39 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/d4d32723/attachment-0001.htm>