We currently use a simple producer round-robin algorithm to distribute
elements between mediasoup workers. This works for most scenarios but
fails in some edge cases, such as:
- 1-to-N scenarios where N >= ~600-800 (sample number, varies by
single-core performance). This is due to subscribers being pinned to a
producer's worker.
- Poor distribution results from round-robin.
Enable the following new features in bbb-webrtc-sfu via after-install by
default:
- `mediasoup.workerBalancing.strategy: least-loaded`: Replaces
round-robin with load scoring. Workers are selected based on which is
least loaded.
- `mediasoup.enableWorkerTransposing: true`: Allows media streams to be
bridged between workers through internal RTP pipes. This, along with a
per-worker stream limit, enables seamless offloading of streams between
workers (whether publishers or subscribers). The per-worker stream limit
is still under review.
These changes should address the issues mentioned. They are enabled via
after-install because the SFU version is shared with previous BBB versions
where these features are not desirable yet.
* first steps
* few messages added
* added more messages to the failed tests
* layouts,notifications
* more messages to help
* adding messages to the upload other presentations format
* messages for upload multiple presentation test
* added most of the expect messages
* updates for merging
* fixed broken tests
Jitter evaluation, as an alert trigger, was changed in 3.0 to get the internal
average jitter used in the conn-status component data (which is total jitter
delay divided by jitterbuffer emit events). This was done accidentally and that
metric is _very_ different from the one used in 2.7 (point-in-time jitter from
remote-inbound-rtp/inbound-rtp, highest on the interval, gathered on
/utils/stats.js). The alert thresholds were preserved, which makes it overly
sensitive in regards to jitter (and thus causes it to be critical whenever the
user is in audio).
Remove jitter as a connection status alert trigger, which fixes the
false positive. The implementation on <= 2.7 is also not ideal - if
anything, it generates false negatives. That's why I'm removing jitter for
the time being since it's ill-suited (at least in the way it's used)
for what we want to achieve.