Under some scenarios, cameras are freezing when the virtual background
code is running due to runPostProcessing(_renderMask) throwing
NS_ERROR_FAILURE - mainly on Firefox - consequently preventing
subsequent TimerWorker ticks from being scheduled.
Cases where I've seen that happen are:
- conferences running under an iframe where the iframe is briefly
stalled for some reason
Address the issue with a try-catch and a log for debugability (it's high
frequency, hence why not error level). We should probably remove the log
entirely once we figure out why the post-processing method is failing.
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)
