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.
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.
