If this is set to true (default false) we assume the storage-dir is
shared, organized by realm/domain, with uses other than voicemail, so
we adopt a directory structure of:
<storage_dir>/<realm>/voicemail/<id>
This replaces the semantics of the storage-dir parameter without the
deprecation notice. The behavior of storage-dir never should have
been deprecated, though it was probably correct to deprecate the name
itself.
Rather than having both vm-storage-dir and vm-domain-storage-dir it
might be nice if the config system could just notice at what level it
was defined and do the right thing. Indeed, this is why I'd left
things as-is for so long.
But as Master Foo famously said, "which one will reach the other side
of the river: the one who dreams of a raft, or the one that hitchhikes
to the next bridge?"
FS-5329
Some OSes like linux provide a mechanism for sending TCP keepalive
pings. Sofia provides its own mechanism for doing this in userspace.
We shouldn't conflate these two mechanisms.
FS-6104
This separates out the Linux socket TCP keepalive timeout interval
from Sofia's internal mechanisms. Earlier we tied these together. In
retrospect this seems improper.
These two values can now be set separately.
You might, for example, want to keep the Sofia internal mechanism
disabled completely while enabling the platform-based mechanism if
your platform supports it.
We also here reform the default value of the socket TCP keepalive
parameter to 30 seconds.
This is what commit a0e9639a1f38f26a5dc586d386ae044ba82e0137 should
have been.
FS-6104
Sofia keeps the TCP keepalive timeout in milliseconds, but Linux
expects the value in seconds. Before this change, it's unlikely the
TCP_KEEPIDLE and TCP_KEEPINTVL calls were having much effect as we
would have been passing them a huge value.
FS-6104
This adds support for the ephemeral elliptic curve Diffie-Hellman key
exchange, which provides for forward secrecy in the event that
long-term keys are compromised.
For the moment, we've hard-coded the curve as prime256v1.
Previously there was no way to override the hard-coded cipher suite
specification of "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH".
This commit does leave in place the hardcoded cipher spec for WebRTC
of "HIGH:!DSS:!aNULL@STRENGTH".
Previously if tls-version was set to tlsv1 we supported only TLSv1,
but if it was set to sslv23 we supported all versions of TLS. This
was a weird incorrectly documented behavior that we hope no one was
relying on.
Now we can pass a comma-separated list of TLS/SSL versions that we
would like to support in tls-version.
FS-5839 --resolve
Previously if the TPTAG_TLS_VERSION was set to a non-zero value we
supported only TLSv1 (but not TLSv1.1 or TLSv1.2), and if was set to
zero we supported all versions of TLS and SSL (including the
ridiculous SSLv2).
Now we take an integer field where various bits can be set indicating
which versions of TLS we would like to support.
