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.
