FS has an intermittent issue where unmuting a HELD channel sometimes
takes significantly (seconds) longer than usual.
conference <XYZ> unmute <WVU> simply gets stuck with no FS_API response,
which delays the unmute action whenever transparent listen only is
active.
Apparently, unholding the channel PRIOR TO unmuting works around the
issue - at least it could not be reproduced with the scenario at hand.
The unmute API already triggered an unhold in FS internally, which is
the reason why this was not done beforehand. The aforementioned issue is
way worse than an extra "redudant" API call, though.
Always unhold audio channels manually _before_ unmuting.
Transparent listen only is currently only worth it for meetings with a
number of duplex audio channels larger than a certain value (dependant
on system performance). That is due to the fact that global audio
bridges created for the mechanism also use significant CPU (roughly the
same as an unheld duplex channel), which means it's cost is usually
offset only once there are enough potential channels to be held in a
conference.
This commit adds a new optional feature that introduces some dynamicity
for the mechanism: it'll only be triggered after at least
@voiceConf.transparentListenOnlyThreshold number of muted duplex
audio channels are present in a conference.
The default is 0 (always trigger transparent listen only if the general
mechanism is activated).
FreeSWITCH incorrectly generates callerNum headers in its ESL events
when specific, special characters are in place. e.g.:
w_etc_0-bbbID-User;Semi (notice the semicolon) will be generated by
FS as w_etc_0-bbbID-User (everything after the semicolon is ignored).
This breaks callerId comparision for session matching in a few places -
one of the is the unmute/unhold toggle control.
Compare callerNum as prefixes instead of exact strings to match those
scenarios.
This is a temporary fix; we should review callerNum generation in the
future (use Caller-Id-Name in FSESL), as well as stop relying on it
for session matching (use UUIDs and/or client session numbers instead).
Both of these are more involved changes, though.
Alway send the unhold command since it doesn't change flip the state
(contrary to the uuid_hold toggle command).
It's not idempotent, though - so always update the internal hold state
to prevent state mismatches preventing channels from being unheld.
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`
