This is an edge case with the uuid_hold command being used through
FSESL or fsapi where holding only works via the uuid_hold <toggle>
subcommand, which may cause the channel to be the opposite of what
we want.
Do not execute if the command is asking for the channel to be HELD
and the channel is already HELD.
There's a routine that's supposed to enforce the channel hold state if
mute and hold states are mismatched. This should only happen in case the
user is unmuted and the channel is held to avoid leaving an user without
inbound or outbound audio by accident. The routine currently checks for
the oppositve scenario as well (muted=true,hold=false), which should not
be enforced because of special scenarios (e.g.: audio-only breakout room
transfers, which have their transparent LO mechanism disabled).
Only enforce hold on muted state mismatch IF muted == false.
There are some scenarios where transparent listen only toggle RPCs are
directed to multiple different sessions in the SFU, which might cause a
hold-unhold loop because they're all anchored to the userId.
Append the callerNum to transparent listen only toggle RPCs so that they
are directed to the appropriate audio sessions in all cases.
* Send custom user data to akka apps
* Add user custom data to registered user
* Add user custom data to user join event
* Store user custom data in Redis
* Rename userCustomData to customParameters
* Rename xml tag to userdata
* Demo changes
* Revert "feat(captions): no longer writes in the pad"
This reverts commit a76de8c458.
* feat(transcriptoin): Add config options for the transcription backend
* feat(transcription): Add autodetect option to cc chevron
* feat(transcription): Move transcription options into settings modal
* feat(transcription): Set transcription options via userdata
* fix(transcription): Correct userdata for settings transcription params
* feat(transcriptions): options to auto enable caption button
* feat(transcriptions): Option to hide old CC pad funcionality
* fix(transcription): Fix PR comments
* fix(transcription): Refactor updateTranscript to prevent null user and make it more readable
* feat(transcription): bbb_transcription_provider can be set via userdata
* fix(transcription): Use base10 for parseInt
* fix(transcriptions): Fix CC language divider when using webspeech
* fix(transcriptions): Use a default pad in the settings instead of hardcoding 'en'
We still need to use a language pad such as 'en', but in the future we can better
separate these systems.
* fix(transcription): Add a special permission for automatic transcription updates to the pad and restore old per user updates permission
* feature(transcriptions): Include transcriptions submenu and locales
* chore: bump bbb-transcription-controller to v0.2.0
* fix(transcription): Add missing menu files
* fix(transcription): Fix transcription provider options in settings.yml
* fix: setting password for bbb-transcription-controller
* build: add gladia-proxy.log for transcription-controller
* fix(transcriptions): Remove transcript splitting and floor logic from akka apps
* fix(captions): Show long utterances as split captions, show multiple speaker captions
* chore: bump bbb-transcription-controller to 0.2.1
---------
Co-authored-by: Anton Georgiev <anto.georgiev@gmail.com>
Every dial in user has its RegistedUser authToken set to an empty string,
Since authToken is the RegUser's HashMap indexing key, this causes a
bunch of inconsistencies; eg.: endpoint ejection will stop working if
more than one dial-in user joined a meeting concurrently because the
later dial-in devices overwrite the earlier ones in the RegUsers map.
The authToken is now mocked as the user's intId (which, for dial-in, is
the voice user ID) so that some sort of uniqueness is guaranteed within
the voice conf scope.
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`
