Revert "depend on fs before install"
This reverts commit 6c52217920.
Revert "removing commented work in progress on SDES and logging tunning on"
This reverts commit 6df5288f5a.
Revert "more formatting and logging tuning"
This reverts commit 0e89bbd033.
Revert "logging adjustment"
This reverts commit 764faad671.
Revert "missing host to network conversion highest_sequence_number_received"
This reverts commit 50c62cdfd7.
Revert "logging correction"
This reverts commit ea973b0b4c.
Revert "[FS-6623] implement RTCP report generation"
This reverts commit 0b7863a9b7.
Clang's static analyzer thinks we could be using `hosts` here when it
is NULL. We probably weren't, but it's easy to see how it could think
so. We were checking whether `from_addr` matched `ice->addr` three
times, and between the second on third time we might have modified the
`ice->addr`; however we only get there if it matched the second time,
so we could only make it not match at that point and avoid the third
branch. We can't make it match where it did not before.
We'll simplify the logic a bit here so static analyzers (and humans)
can hopefully see this more readily.
If we see a certain number of RTP packets from a host and port other
than was negotiated, we adjust to send our RTP to that host and port.
Traditionally we've waited for 10 packets. This commit makes the
threshold adjustable by setting the channel variable
`rtp_auto_adjust_threshold` to any positive value less than 2^16.
Clang 3.5 reported the following error: error: taking the absolute
value of unsigned type 'unsigned int' has no effect
[-Werror,-Wabsolute-value]
Subtracting unsigned variables will never be negative and will either
be the small expected value or will wrap to a very big value. This
code is trying to determine if the difference between these timestamps
is greater than 16000.
The variables last_write_ts and this_ts deal with timestamps. In the
normal case this_ts will be a larger timestamp than
last_write_ts. This change will maintain the intended behavior of
reseting the video if the difference is larger than
16000 and in the abnormal case this value would wrap and still exceed
the 16000.
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
Anthony Minessale