Dial-in endpoints currently follow the same guest approval process as regular
users. While this is correct for default installations, it complicates the join
procedure in setups where approval is managed externally, such as with pre-
configured conference PIN codes. Another relevant scenario is when call
origination is done from BBB, rather than as an inbound call.
This commit makes the enforcement of the guest policy for dial-in/external
endpoints optional in akka-apps. The default behavior remains unchanged
(enforce). This provides more flexibility for the dial-in mechanism, allowing
for smoother handling of the scenarios mentioned above.
The current default setting of muteOnStart=false can lead to performance
issues in larger rooms, especially with the "transparent listen only
mode" and LiveKit, as proven by load testing. In contrast,
muteOnStart=true helps mitigate these issues but complicates the entry
process for smaller meetings, such as 1-on-1 sessions or small classes.
Additionally, the ability to override muteOnStart via the API can create
scalability issues if not managed properly.
Add a new akka-apps flag `voiceConf.muteOnStartThreshold` which acts as
a trigger that forces muteOnStart=true when the number of audio
participants reaches the configured threshold. 0 means no threshold
(disabled).
This trigger overrides any API parameter or static configurations
related to muteOnStart, as well as the client's meeting mute actions.
Pending:
- Remove MeetingStatus.meetingMute state side effects from the client's
"Mute all" and "Mute all except presenter" actions. They should no
longer alter the meeting mute state once this becomes default (just
mute users instead).
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.
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.
Whenever both microphone lock settings and transparent listen are
active, users fail to join audio due to an oversight in the audio join
permission procedure. It's denying users from *joining* audio if they're
locked, even though they should only be prevented from *unmuting*
themselves.
Change the permission checks for audio join to allow users even when
they're locked. Use the lock setting to force the muteOnStart flag for
locked users instead.
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.
This is a rework of the audio join procedure whithout the explict listen
only separation in mind. It's supposed to be used in conjunction with
the transparent listen only feature so that the distinction between
modes is seamless with minimal server-side impact. An abridged list of
changes:
- Let the user pick no input device when joining microphone while
allowing them to set an input device on the fly later on
- Give the user the option to join audio with no input device whenever
we fail to obtain input devices, with the option to try re-enabling
them on the fly later on
- Add the option to open the audio settings modal (echo test et al)
via the in-call device selection chevron
- Rework the SFU audio bridge and its services to support
adding/removing tracks on the fly without renegotiation
- Rework the SFU audio bridge and its services to support a new peer
role called "passive-sendrecv". That role is used by dupled peers
that have no active input source on start, but might have one later
on.
- Remove stale PermissionsOverlay component from the audio modal
- Rework how permission errors are detected using the Permissions API
- Rework the local echo test so that it uses a separate media tag
rather than the remote
- Add new, separate dialplans that mute/hold FreeSWITCH channels on
hold based on UA strings. This is orchestrated server-side via
webrtc-sfu and akka-apps. The basic difference here is that channels
now join in their desired state rather than waiting for client side
observers to sync the state up. It also mitigates transparent listen
only performance edge cases on multiple audio channels joining at
the same time.
The old, decoupled listen only mode is still present in code while we
validate this new approach. To test this, transparentListenOnly
must be enabled and listen only mode must be disable on audio join so
that the user skips straight through microphone join.
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 sometimes drop frames in very long recordings generating
a raw file smaller than the total time recorded. The other issue is the
occasional drifiting.
This adds option to split audio recording in multiple files by
duration to avoid this problem in setups that are prone to it. Disabled
by default.
* Refactor: Make bundle using webpack
* Fix: restore after install codes and a few settings
* Fix: build script folder permission
* Refactor: Remove support to async import on audio bridges
* Upgrade npm using nvm
* Avoid questions on npm ci execution
* Let npm ci install dev dependencies (as we need the build tools here)
* Fix: enconding
* Fix: old lock files
* Remove: bbb-config dependency to bbb-html5 service, bbb-html5 isn't a service anymore
* Fix: TS errors
* Fix: eslint
* Fix: chat styles
* npm install with "lockfileVersion": 3 (newer npm)
* build: allow nodejs 22
* node 22; drop meteor from CI and bbb-conf
* TEMP: use bbb-install without mongo but with node 22 and newer image
* build: relax nodejs condition to not trip 22.6
* build: ensure dir /usr/share/bigbluebutton/nginx exists
* init sites-available/bbb; drop disable-transparent-
* nginx complaining of missing file and ;
* TMP: print status of services
* WIP: tweak nginx location to debug
* Fix: webcam widgets alignments
* akka-apps -- update location of settings.yml
* build: add locales path for nginx
* docs and config changes for removal of meteor
* Fix: build encoding and locales enpoint folder path
* build: set wss url for media
* Add: Enable minimizer and modify to Terser
* Fix: TS errors
---------
Co-authored-by: Tiago Jacobs <tiago.jacobs@gmail.com>
Co-authored-by: Anton Georgiev <anto.georgiev@gmail.com>
Co-authored-by: Anton Georgiev <antobinary@users.noreply.github.com>
* feat(plugins): add chat server command and chat message type `plugin`
This commit adds the required code for the plugins SDK's chat server
command `CHAT_SEND_MESSAGE`, which allows plugins to send chat
messages. Messages sent by plugins are identified by the message
type `plugin` and belong to the user (senderID) of the client that
sent it. Plugin messages are not displayed by the client itself because
these messages are meant to be custom-rendered by plugins, typically by
the plugin that sent them.
* feat(plugins): add message metadata
Plugin name and plugin custom metadata are stored in message's metadata,
so plugins need it to identify messages when applying custom render.
* feat(chat): removes specific code for plugin messages
Removes specific akka messages, handlers and routes for plugin messages
and adds metadata parameter in `GroupChatMsgFromUser`.
* feat(chat): adds option parameter to mutation
Adds optional parameter `metadata` to the already existing mutation
`chatSendMessage` and use this mutation for plugin chat server command.
* feat(chat): rendering of plugin messages
This commit implements the correct rendering of plugin messages, which
is:
- Plugin messages with metadata attribute `custom` set to true are not
rendered by the client, and are meant to be custom-rendered by
plugins.
- Plugin messages with metadata attribute `custom` set to false are
rendered by the client as being sent by the user that triggered it.
* Update sdk version to v0.0.56
* update sdk version to v0.0.57
