If set to true, this prevents us from overriding the value of
send_silence_when_idle. When that is unset or set to zero and SRTP is
engaged, we typically override the value because many devices can't
handle gaps in the SRTP stream.
This variable is mostly for testing whether particular devices can
handle this behavior. Use at your own risk.
In commit 55d01d3defed4bfdc74704dbea0da9548a97a979 we set
send_silence_when_idle to -1 rather than 400 when SRTP is engaged.
But this left no way to enable white noise silence when desired.
When SRTP is engaged we can't simply not send RTP because it breaks
too many devices. So we need to prevent send_silence_when_idle from
being unset or being set to zero. This change allows it to be set to
other values so as to feed white noise rather than all zeros into the
codec.
Originally we did the same thing with SRTP that we do without SRTP,
which is to simply not send packets when e.g. sleep is called.
At commits d63323977fa611b141441f12af9a94ec19b5f829 and
5259814aee16ede974456490a79e8a98de1d6d2e we enabled sending silence
packets with comfort noise when SRTP is active. We appear to have
done this for interop purposes; many devices can't handle gaps in the
stream of SRTP packets.
But our current comfort noise implementation doesn't take the codec
rate into account (FS-6291), so on 16kHz codecs the constant we chose
created an annoying level of static between sound file playback.
With this commit we preserve the sending of SRTP packets during idle
periods, but make those packets completely silent.
Thanks-to: Anthony Minessale <anthm@freeswitch.org>
FS-5053 --resolve
libzrtp strings are weird, and we were previously misusing the
function zrtp_zstrcpyc. We can't use ZSTR_GV because it does insane
things and causes an array-bounds warning on gcc 4.7. So we have to
take matters into our own hands and setup the string correctly and
copy data into it.
Because we were doing it wrong, people would get weird pseudo-random
single-character names for the zrtp cache file, and the file would end
up in the wrong place. Now that this is fixed, users will need to
locate and move their zrtp cache file to their db_dir and name it
"zrtp.dat" if they wish to keep their current ZRTP cache.
FS-4344 --resolve