There are scenarios where the full audio broker (SFU) stop procedure
may be called multiple times in a very short timestamp - eg a concurrent
stop + connection failure; a timeout in the transfer procedure + a
reconnect attempt, [...]. When that happens, calls to exitAudio may throw
errors if the broker was already released - and that's not the expected
behavior.
The talking-indicator, emoji-button and input-live-stream-selector
components are passing props downstream that weren't omitted or handled
by inherited components (Button, Icon). That causes a handful of error
logs to be spammed in the console of dev environments, which is
annoying.
This commit addresses the issue by:
- Making the talking, spoke, muted and isViewer props transient
(styled-components) - which means they won't reach the DOM (as
expected since they're style-only)
- Omitting the EmojiButton `rotate` prop in the Icon component itself
* Made that instead of transient because might be useful to migrate
the rotate code to the Icon component?
The UserJoinedVoice* event handler checks whether the caller is banned
and ejects them. That's valid for both SIP.js and SFU-based audio
flows, but for the latter there's a specific pre-flight permission check
as well.
This adds that same ban check to the pre-flight permission probe so that
calls are rejected earlier.
Audio's callerId depends on the user name and there isn't
an "on-demand" way of fetching that field internally, making callerId
assembly with trusted attributes (server-side generated) impossible in
bbb-webrtc-sfu.
The new extra header (User-Name, mapped to user_name in the proxied
connection) allows fetching the user name field in a cheap way and
consequently provides a cheap+safe way of assembling the callerId.
Alternatives I've considered but discarded:
- a new akka-apps req-resp pair for fetching the user name (+overhead)
- a new akka-apps req-resp pair for generating the callerId (+overhead)
- piggybacking on GetMicrophonePermissionReq/Resp to generate the
callerId (same overhead, but mixing responsabilities)
If the user is in akka-apps' user cache (which means they are still
visible in the user list) and triggers a screenshare re-connect, the
re-connect should be allowed to minimize outages.
If the user indeeds fails to be reconnected to the whole system, then
the screen sharing sessions will be ejected when the user is
completely ejected from the system.
If the user is in akka-apps' user cache (which means they are still
visible in the user list) and triggers a camera re-connect, the
re-connect should be allowed to minimize outages.
If the user indeeds fails to be reconnected to the whole system, then
the camera sessions will be ejected when the user is completely ejected
from the system.
The SFU microphone module was using global audio authentication RPCs in
akka-apps to determine whether a mic connection is valid.
Fixes an issue where SFU microphone connections wouldn't take lock
settings in account in the permission checks.
In detail: decouple them by adding GetMicrophonePermissionReqMsg and
RespMsg. Allows flexibility on which conditionals to use in both. IMO it
is also better than renaming+adding a boolean to GetGlobalAudioPermission*
due to the fact that it gets easier to guarantee backwards compatibility
between SFU and BBB (ie SFU 2.9 keeps working on 2.4, 2.5).
If the user is in akka-apps' user cache (which means they are still
visible in the user list) and triggers an audio re-connect, the
re-connect should be allowed.
If the user indeeds fails to be reconnected to the whole system, then
the audio session will be ejected when the user is completely ejected
from the system.
