We're checking whether we've hit the warning threshold before checking
whether we should just end the call. This causes an off-by-one error
where we take one SRTP error more than intended.
This commit reverses the order of the tests.
In a carrier interop we saw the call get killed for SRTP failures
during a reinvite. We're wondering if the SRTP errors may have been
transitory and if it may have recovered after a few more packets.
It's debatable whether we should kill calls at all for SRTP auth
failures; semantically the right thing to do when a MAC fails is to
ignore the packet completely. So raising this limit to 100 packets
shouldn't do any harm. With this change we still warn at 10 errors
and every 10 errors thereafter.
We hangup the channel after receiving 10 SRTP packets in a row with a
bad auth tag or that are replayed. Prior to this commit we were
indicating a normal clearing. When doing interop and looking first at
packet traces, this made freeswitch's behavior look surprising. With
this commit we'll indicate more loudly what's happening.
switch_rtp_set_invalid_handler has been misspelled as
switch_rtp_set_invald_handler going all the way back to the
beginning. So while it's possible that someone somewhere could be
relying on this misspelling, I think it's more likely that no one has
used it much and that's why it wasn't spotted. We don't even use it
ourselves anywhere anymore.
Introduced in commit: 828e03715f
On start DTMF packets we were showing the last write timestamp as a
signed value when it's an unsigned value, which could result in it
appearing incongruous with later packets where the value was displayed
correctly.
rtp_secure_media=mandatory
rtp_secure_media=optional
rtp_secure_media=mandatory:AES_CM_256_HMAC_SHA1_80,AES_CM_256_HMAC_SHA1_32
rtp_secure_media=optional:AES_CM_256_HMAC_SHA1_80
rtp_secure_media=forbidden
true implies mandatory
false implies forbidden
not set implies optional
rtp_secure_media_inbound or rtp_secure_media_outbound take precedence and are treated the same way based on leg direction
This was momentarily called force_send_silence_when_idle, but that was
non-obvious as you had to set that value to true to be able to not
send silence when idle. This name describes the purpose much better.
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 55d01d3def 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 d63323977f and
5259814aee 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
Travis Cross