We currently use full renegotiation for audio, video, and screen sharing
reconnections, which involves re-creating transports and signaling channels
from scratch. While effective in some scenarios, this approach is slow and,
especially with outbound cameras and screen sharing, prone to failures.
To counter that, WebRTC provides a mechanism to restart ICE without needing
to re-create the peer connection. This allows us to avoid full renegotiation
and bypass some server-side signaling limitations. Implementing ICE restart
should make outbound camera/screen sharing reconnections more reliable and
faster.
This commit implements the ICE restart procedure for all WebRTC components,
based on bbb-webrtc-sfu >= v2.15.0-beta.0, which added support for ICE restart
requests. This feature is off by default. To enable it, adjust the following
flags:
- `/etc/bigbluebutton/bbb-webrtc-sfu/production.yml`: `allowIceRestart: true`
- `/etc/bigbluebutton/bbb-html5.yml`: `public.kurento.restartIce`
* Refer to the inline documentation; this can be enabled on the client side
per media type.
* Note: The default max retries for audio is lower than for cameras/screen
sharing (1 vs 3). This is because the full renegotiation process for audio
is more reliable, so ICE restart is attempted first, followed by full
renegotiation if necessary. This approach is less suitable for cameras/
screen sharing, where longer retry periods for ICE restart make sense
since full renegotation there is... iffy.
There's an issue where permission-less sessions of video-preview
fail to change video profiles. Whenever gUM is on prompt mode,
deviceIds are obfuscated, which means getInitialCamera will need to
infer the deviceId based on the current media stream.
Since the virtual bg worker is now called synchronously (e28a595),
it'll be extracted incorrectly from the virtual effect MediaStream
(rather than the original stream) - which causes getInitialCamera to
use the effect's deviceId rather than the original stream's deviceId.
Guarantee that deviceId inference via MediaStreamTrack uses
BBBVideoStream's originalStream (so that virtual effect streams are
bypassed). Also remove the call to updateDeviceId in getInitialCamera
since it's redundant since commit e28a595.
A change in e28a595b52 introduced an issue where the "Share camera as
content" modal always has it's "share" action flagged as disabled. This
is due to a short-circuit introduced in the initial gUM procedure that
does not clear the "disabled" state before exiting.
Properly reset the "disabled" sharing state after the initial gUM in
video-preview when "Share camera as content" is used, thus fixing the
aforementioned issue.
* fix(webcam): client failing to apply virtual background effect
* fix: check for already dispatched background
* fix: make webcam start up with last selected virtual background
Fix a crash in the polls live result by filtering out undefined users.
This scenario might happen when getting user information by an id that
is not present in the current usernames list by some inconsistency
between the user's information from the users context and poll
votes/responses.
