There are a couple of hardcoded UA checks targeted at iOS endpoints
introduced circa 2.2-beta. One of those pops up an "unsupported" toast
when the device joins a conference - the other blocks camera
sharing.
Those checks are outdated since we transitioned to minBrowserVersions
approach that redirects the client to an unsupported view upon join. I
also assume the checks are bugged since, in some environments, it flags
iPadOS endpoints as iOS and version-checks it to a hardcoded "12.2"
threshold (which is incompatible with iPadOS versioning). That caused
camera sharing not to work, which is a false negative.
I consider the checks to be outdated, so I removed all references to
them.
The current Vosk CC provider does not support stereo mic streams
(pending investigation as to why).
This commits makes sure stereo is forcefully disabled via SDP munging
only when transcription is active and using Vosk. Having it disabled
in the server side (FreeSWITCH) is not enough because the stereo parameter
is client mandated and replicated by FS on its answer. So we need to
make sure it's always disabled for the time being.
SFU audio does munging server side (and stereo is always off), so no changes
needed there.
The rest of the providers (except WebSpeech) need to be validated against
stereo audio as well.
This is also intended to be temporary - ideally this needs to be fixed in
mod_audio_fork/Vosk/wherever this is breaking.
Firefox has a buggy ICE implementation and needs WebRTC media traffic to
be routed through a turn server to work reliably with mediasoup.
Use the information fetched by the STUN API to determine if the operator
has configured a turn server. If there is one force firefox to use it.
Closes#16164
New features:
- A simplified echo test mode that only does a local loopback (instead of
going to FS and back)
- A volume meter for microphone streams to the AudioSettings view
Those two features are experimental and disabled by default; see
public.app.media.simplifiedEchoTest and public.app.media.showVolumeMeter configs
Collateral changes:
- fix: localize fallback device strings in AudioSettings/DeviceSelector
- Refactor on some media stream utils to be re-usable across components
- Refactor in AudioSettings to keep gUM #uses stable.
* TODO: need to pass streams through AudioManager to avoid the surplus gUM.
- fix(audio): drop ScriptProcessorNode usage (deprecated)
* Used in volume meter for tracking - use hark instead
The idea is to run a loadbalancer node which maps each BBB node to a
path. That way each user gets only one gUM permission query for a
cluster. The loadbalancer node only serves the html5 client, each BBB
node will serve its own API and handle the websockets for freeswitch and
bbb-webrtc-sfu.
Configuring a cluster setup
===========================
* let bbb-lb.example.com be the loadbalancer node
* let bbb-01.eaxmple.com be a BBB node
Loadbalancer
------------
On the loadbalancer node add an nginx configuration similar to this one
for each BBB node:
```
location /bbb-01/html5client/ {
proxy_pass https://bbb-01.example.com/bbb-01/html5client/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}
```
BBB Node
--------
On the BBB node add the following options to
`/etc/bigbluebutton/bbb-web.properties`:
```
defaultHTML5ClientUrl=https://bbb-lb.example.com/bbb-01/html5client/join
presentationBaseURL=https://bbb-01.example.com/bigbluebutton/presentation
accessControlAllowOrigin=https://bbb-lb.example.com
```
Add the following options to `/etc/bigbluebutton/bbb-html5.yml`:
```
public:
app:
basename: '/bbb-01/html5client'
bbbWebBase: 'https://bbb-01.eaxmple.com/bigbluebutton'
learningDashboardBase: 'https://bbb-01.eaxmple.com/learning-dashboard'
media:
stunTurnServersFetchAddress: 'https://bbb-01.eaxmple.com/bigbluebutton/api/stuns'
sip_ws_host: 'bbb-01.eaxmple.com'
presentation:
uploadEndpoint: 'https://bbb-01.eaxmple.com/bigbluebutton/presentation/upload'
```
Create the following unit file overrides:
* `/etc/systemd/system/bbb-html5-frontend@.service.d/cluster.conf`
* `/etc/systemd/system/bbb-html5-backend@.service.d/cluster.conf`
with the following content:
```
[Service]
Environment=ROOT_URL=https://127.0.0.1/bbb-01/html5client
```
Change the nginx `$bbb_loadbalancer_node` variable to the name of the
load balancer node in `/etc/bigbluebutton/nginx/loadbalancer.nginx` to
allow CORS requests:
```
set $bbb_loadbalancer_node https://bbb-lb.example.com
```
Prepend the mount point of bbb-html5 in all location sections except
from the `location @html5client` section in
`/etc/bigbluebutton/nginx/bbb-html5.nginx`
```
location @html5client {
...
}
location /bbb-01/html5client/locales {
...
}
```
Firefox doesnt fire the ended evt/onended callback for live video mediastreamtracks. That caused the stream storage to not run the cleanup procedure in some scenarios
Manually emit the ended event which works with the onended callback when a track is stopped
Shave off the number of calls in video-preview and video-provider by
using a stream storage
We don´t call an upfront gUM in video-preview anymore to lift the
fingerprinting barrier on device labels and IDs. Flow has been reversed:
upfront enumerate, load first preview, then check if previous
enumeration was obfuscated.
Add a stream storage in video-preview`s service to avoid re-fetching
them in video-providerj
Remove some unneeded video-preview container props
Improve some of video-preview`s error locales
Here's what we do when user activates mic:
1 - When we do something similar to listenonly's joining process
until we find a valid candidate-pair. The information about this
local candidate is store.
2 - We then start a new userAgent, and as soon as browser finds
a candidate with the same local ip address, we leave only this
candidate in the SDP and send this to FreeSWITCH. SDP should
contain only a single candidate.
3 - The rest of signaling process is basically the same.
Remove parts of a previous connection monitor.
To add some context (as far as my memory goes) to the multiple connection
monitor features the product has, `stats` (currently named `connection status`)
was introduced at the Flash client back in ~2016. @fcecagno and I did it
as a BigBlueButton's Summit activity. Our work was squashed into a single
commit in 92554f8b3e :).
I'm not sure about the whole story behind `network information` (the late
connection monitor added to the HTML5 client) but I assume it should work
as a collector for a bunch of different connectivity monitors. I remember
when it was introduced but I don't know why it wasn't adopted. My best guess
would be because of some performance issues the `user list` had back then.
To follow on why `connection status` replaced `network information` at the
HTML5 client, when I did the `multiple webcams` feature I had to refactor
a big chunk of the `video provider` (#8374). Something that wasn't really
helping there was the adaptation of `stats` that was made to show local
feedback for each webcam connection. Although this feature wasn't being
used anymore, `network information` did rely on that to build up data. With
this monitor gone I assumed it was my responsibility to provide an alternative
so I promoted Mconf's port of the Flash `stats` monitor to BigBlueButton's
HTML5 client (#8579).
Well, that's my perspective on how things went for those features. If
anyone would like to correct me on something or add something else on
that history I would appreciate to know.
