It's actively blocked in code, but I think that's an oversight -
probably leftover from an initial iteration of the feature.
It should be useful in mobile endpoints and it's also supposed to work
seamlessly due to how the feature is implemented.
Lift the mobile block and expose "camera as content" in the presenter's
actions dropdown.
The original BBBVideoStream termination handlers are being overwritten
by screen sharing's service when "Present camera" is started, which
causes the stream not to be dereferenced in the VIDEO_STREAM_STORAGE
map when the camera presentation stops. This breaks subsequent
camera/present camera attempts for the affected deviceId.
The second issue with is that Chrome isn't assigning the
termination handlers for the screen sharing subsystem - which causes
device/permission ejections to be silent.
This extends screen sharing's trackStreamTermination routine to preserve
whatever previous termination handlers were assigned if the stream was
provided beforehand by an external caller - which should fix both of the
aforementioned issues.
This commit removes the wake lock activation toast along with the
enable/disable buttons, implementing the wake lock implicit activation
behavior. The wake lock feature is implicitly activated if the
`defaultSettings.application.wakeLock` in the `settings.yml` file is set
true. For mobile devices that do not support the API or fail when
requesting a wake lock, toasts are raised explaining that calls will be
dropped when the screen turns off.
In cases where `defaultSettings.application.wakeLock` is set false, users
can enable the wake lock manually through the settings menu.
* prevent duplication of presentation menu dropdown when visible
* move presentation options dropdown to the left (out of tldraw UI)
* adjust style menu UI in RTL
* prevent duplication of presentation menu dropdown when visible
* move presentation options dropdown to the left (out of tldraw UI)
* adjust style menu UI in RTL
The original debounce implementation (lodash) preserved the
caller's context - radash didn't, so it was failing and it wasn't noticed.
The new debounce implementation with the native function seems to preserve caller's context, but as a safety measure this commit binds the method to its appropriate scope.
If the autoplay block is triggered in listen only, the connection timer
keeps ticking even if the user correctly accepts the audio play prompt.
That causes an audio re-connect once the timeout expires.
Clear the connection timer if the audio bridge starts with
NotAllowedError as a soft error. For connection purposes, the audio join
procedure worked. The autoplay thing is at the UI/UX level, not WebRTC.
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`
The refactoring in 838accf015 incorrectly
replaced the wrong parseMessage function in addBulkGroupChatMsgs.js
This bug is only triggered when the option public.chat.bufferChatInsertsMs != 0.
SFU based audio is missing connection timers, which means the join
procedure can go on indefinitely in a couple of scenarios.
Refactor the connection timers added for re-connections in the SFU audio
bridge and make them valid for the first try as well.
Make 1010 errors (connection timeout) retriable when retryThroughRelay
is enabled.
1007 errors are still a large fraction of our overall audio join error
rate. This usually indicates some sort of firewall block or UDP issues
carrier networks. I can't figure out why some scenarios won't trickle
down to relay candidates though - I'm leaning to scenarios where STUN
packets with USE-CANDIDATE are being mangled/lost along the way or
something else that borks the (already fragile) conn checks for ICE-lite
implementations.
Add a new feature called retryThroughRelay which triggers a retry with
iceTransportPolicy=relay whenever audio fails to join with a 1007 error.
The goal is to force relay usage to try and bypass 1007s scenarios that
still happen.
Disabled by default.
Add secondsToActivateAudio, inputDeviceId, outputDeviceId and isListenOnly
to audio_joined.extraInfo
Add inputDeviceId, outputDeviceId and isListenOnly to
audio_failure.extraInfo
Add a try-catch to the device enforcement procedure triggered by
onAudioJoin - it may throw and block the modal.
