There are some issues with the way FreeSWITCH changes candidate pairs
based on connectivity checks. That generally manifests as: 1) an asymmetric
start time between inbound and outbound audio (eg inbound audio takes 20
seconds to come in while outbound works right out of the bat
2) wrong pairs being picked initially and FS taking longer
than ideal to find a new one 3) 1006s, 4) ....
This backports signalwire PR 1914 in an attempt to mitigate
the aforementioned issues. The PR description explains the rationale
rather well and seems sound. I've tested this in demo servers with midly
satisfying results, but still needs further testing.
The etherpad component's nginx configuration needs to know the request
scheme in order to set some variables that influence whether the
'Secure' flag is set on cookies. Right now it directly uses the $scheme
variable, but this variable does not get set to the expected value if
nginx is behind a reverse-proxy where the proxy handles TLS termination.
Adjust the etherpad nginx config to use a variable with a different name
$real_scheme, which can be set in the nginx server block to match the
configuration of the nginx listeners.
This variable is set to the value of $scheme in the default
/etc/sites-available/bigbluebutton file. The bbb-install.sh script will
be updated to set this variable in the configurations it writes.
People using other installation scripts will need to add this variable
to their nginx configuration file, or etherpad might not operate correctly.
Add mod_audio_fork to FreeSWITCH's build alongside libwebsockets
(which mod_audio_fork depends on).
mod_audio_fork is used by the built in transcription feature as
a way to extract L16 streams from FreeSWITCH via WebSockets for further
processing by arbitrary transcription servers.
For full details on mod_audio_fork itself, please check drachtio's
source repo: github.com/drachtio/drachtio-freeswitch-modules.git
A few cautionary tales about this one:
- The new patch (mod_audio_fork_build.patch) guarantees libwebsockets
is properly linked to FreeSWITCH and that mod_audio_fork is built as
well. That's because mod_audio_fork is not an upstream module.
- The patch _may_ introduce conflicts on FreeSWITCH bumps more easily
than the other patches we have. They shouldn't be too hard to adapt,
though.
- There's fine tuning to be done to FreeSWITCH's unit file regarding
mod_audio_fork's capabilities. Again: check drachtio's repo.
There are some issues with the way FreeSWITCH changes candidate pairs
based on connectivity checks. That generally manifests as: 1) an asymmetric
start time between inbound and outbound audio (eg inbound audio takes 20
seconds to come in while outbound works right out of the bat
2) wrong pairs being picked initially and FS taking longer
than ideal to find a new one 3) 1006s, 4) ....
This backports signalwire PR 1914 in an attempt to mitigate
the aforementioned issues. The PR description explains the rationale
rather well and seems sound. I've tested this in demo servers with midly
satisfying results, but still needs further testing.
After node-config was bumped to 3.3.9 (from 3.3.6), it started throwing errors if
configurations are mutated without the ALLOW_CONFIG_MUTATIONS env var set.
We mutate some configs directly, but I every time I added one of those I made sure that
they are always deep cloned.
However, we hit an issue with kurento-client mutating a config input, which is an indirect mutation.
So, to prevent further surprises I'm allowing mutations on production while prohibiting them in dev
envs until I'm 100% sure nothing, direct on indirect, improperly mutates configuration values.
bbb-webrtc-sfu (and mediasoup) are running in the CFS scheduler which
means it has to compete with (much) lower priority tasks like
presentation conversion, recording processing, [...]
Since it encompasses an RTC application which also handles audio, it
should be _at least_ on the same scheduling policy as FS/bbb-html5 - and
that should be safer now with mediasoup which has a lower footprint
(and generates lower CPU noise overall).
This commit puts bbb-webrtc-sfu in the FIFO scheduling policy (same as
bbb-html5). Also bumps bbb-html5 nice level up to 18 and sets SFU to
nice 19 (so bbb-html5 has some advantage when push comes to shove).
This can be improved further by using per-process priorities in SFU.
Ideally we'd want mediasoup audio workers and mcs-core to be the same
priority as FS (so higher than bbb-html5), but the rest of them
(video/screen workers) to be the same or lower than bbb-html5. For
future reference:
- https://github.com/bigbluebutton/bbb-webrtc-sfu/commit/3e245122dfa155ecb77b536eeadac1e4607cee
- 66d443d204
Files are compressed on build, but gzip_static on isn't set on their
nginx route - so original files are being served, uncompressed.
This commit serves the previously compressed files instead (thus
reducing initial transfer size by ~1 MB).
Someone should look into whether serving compressed version of the rest
of assets makes sense - it probably does.
Still pending: fonts, locales, svgs, everything under resources, ...
docker container and pass them in as environment variables, since we
can't compute them inside the docker container if the source directory
is a git worktree
Audio's callerId depends on the user name and there isn't
an "on-demand" way of fetching that field internally, making callerId
assembly with trusted attributes (server-side generated) impossible in
bbb-webrtc-sfu.
The new extra header (User-Name, mapped to user_name in the proxied
connection) allows fetching the user name field in a cheap way and
consequently provides a cheap+safe way of assembling the callerId.
Alternatives I've considered but discarded:
- a new akka-apps req-resp pair for fetching the user name (+overhead)
- a new akka-apps req-resp pair for generating the callerId (+overhead)
- piggybacking on GetMicrophonePermissionReq/Resp to generate the
callerId (same overhead, but mixing responsabilities)
the redis dependency for `bbb-apps-akka` and `bbb-fsesl-akka` has
already beed added in commit b6777ed9cb so
the override is no longer neccesary.
closes#15192
* fix unit name: the unit name on Ubuntu is `redis-server.service`
* services which need a working redis require both After= and Wants=
See the description in the `systemd.unit` man page.
Etherpad uses the sessionID cookie for authorization. In cluster setups the
host part of the URI which serves the html5 frontend is different from
the hostname part of the URI which serves etherpad. Therefore the
bbb-html5 client can't set a cookie for etherpad which contains the
etherpad sessionID.
This patch uses the `ep_auth_session` etherpad plugin which takes the
`sessionID` as query parameter, sets the cookie in the browser and
redirects the iframe to the pad URI.
