8feb934169
This is an initial, experimental implementation of the feature proposed in https://github.com/bigbluebutton/bigbluebutton/issues/14021. The intention is to phase out the explicit listen only mode with two overarching goals: - Reduce UX friction and increase familiarity: the existence of a separate listen only mode is a source of confusion for the majority of users Reduce average server-side CPU usage while also making it possible for having full audio-only meetings. The proof-of-concept works based on the assumption that a "many concurrent active talkers" scenario is both rare and not useful. With that in mind, this including two server-side triggers: - On microphone inactivity (currently mute action that is sustained for 4 seconds, configurable): FreeSWITCH channels are held (which translates to much lower CPU usage, virtually 0%). Receiving channels are switched, server side, to a listening mode (SFU, mediasoup). * This required an extension to mediasoup two allow re-assigning producers to already established consumers. No re-negotiation is done. - On microphone activity (currently unmute action, immediate): FreeSWITCH channels are unheld, listening mode is deactivated and the mute state is updated accordingly (in this order). This is *off by default*. It needs to be enabled in two places: - `/etc/bigbluebutton/bbb-webrtc-sfu/production.yml` -> `transparentListenOnly: true` - End users: * Server wide: `/etc/bigbluebutton/bbb-html5.yml` -> `public.media.transparentListenOnly: true` * Per user: `userdata-bbb_transparent_listen_only=true` |
||
---|---|---|
.. | ||
methods | ||
modifiers | ||
index.js | ||
methods.js | ||
publishers.js |