* feat(screenshare): Option to show disabled screenshare button for non presenters
* Update bigbluebutton-html5/imports/ui/components/screenshare/service.js
---------
Co-authored-by: Ramón Souza <contato@ramonsouza.com>
Commit 26815f4679 was seemingly lost
during a merge in the 3.0.x-release branch. Nothing breaks, but we're
missing the log info originally added via that commit.
Restore the changes in 26815f4679:
- 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.
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'
*outbound* peers. It is 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.
Endpoints that are inbound/`recvonly` only (client's perspective) do *not*
support ICE restart yet. There are two main reasons:
- Server-side changes are required to support `recvonly` endpoints,
particularly the proper handling of the server’s `setup` role in the
its SDPs during an ICE restart. These changes are too broad for now,
so they are deferred to future releases (SFU@v2.16).
- Full reconnections for `recvonly` endpoints are currently reliable,
unlike for `send*` endpoints. ICE restarts could still provide benefits
for `recvonly` endpoints, but we need the server updates first.
- We were sending one websocket message for each removed shape, send only one with all IDs.
- The shape limit verification was not always working with rapid updates and if somehow the db got more shapes,
the users couldn't update or delete any shape anymore
- Unnecessary remove shape messages were being sent to the server when going over limit
When a shape is changed, the full shape objcect was being transmitted to the server again.
Do a diff to only send what changed (similarly as it was in tldraw v1) to save upload bw.
TODO:
Draw segments diffs (array) is still not working, so all the segments are still being sent every time.
* Batch shapes and persist on idle or editing states
* add highlight.idle to condition
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
---------
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
Background shape can show white borders due to rounding erros in the tldraw canvas, change size and position of background shape to avoid it.
Also disable tl container outline showing when in focus.
* fix(dark-theme): adjust Dark Reader CSS selectors
Clean up inverted css selectors passed to Dark Reader and add new ones
for elements not correctly transformed to dark theme. These include the
tldraw color picker, text shape color, selected color indicator, tool
opacity slider, and camera dock background.
* Suggestions from review
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
* Suggestions from review
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
* Suggestions from review
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
* changes requested in review
* changes requested in review
---------
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
In BBB 3.0, a change was made to collect full WebRTC stats continuously.
This method gathers stats from *all* peers and *all* senders and receivers
every 2 seconds. Originally, it was intended to run only when the user opened
the connection status dialog, providing in-depth info in the UI and making it
available for copying.
This new behavior is not ideal. Running full stats collection every 2 seconds
in meetings with 20+ peers/transceivers wastes client resources since the
collected data is unused 99% of the time.
This commit reverts to the pre-3.0 behavior (≤2.7), where full stats collection
(`startNetworkMonitoring`) runs only when the connection status modal is open.
As a bonus, it fixes the packet loss status transition log to use the packet
loss percentage, which is the actual trigger metric.
