Without the value for source fraction, applications relying on RTCP events for making changes to FS behaviour or even for logging get false information.
With this change the value for source fraction is passed along in RTCP events correctly.
To my current understanding, as the value for fraction in the RTCP packet is represented by 8 bits according to the spec, calling `ntohl` on it will always zero it out. Fixed by removing the call.
FS-7203 #resolve
Revert "depend on fs before install"
This reverts commit 6c52217920148f633b3d03ef5428dfa5938e4fd3.
Revert "removing commented work in progress on SDES and logging tunning on"
This reverts commit 6df5288f5ac7ac9c48d7f7cc730c26dae3215495.
Revert "more formatting and logging tuning"
This reverts commit 0e89bbd0333c027273e4165af850bc304861dbdc.
Revert "logging adjustment"
This reverts commit 764faad671902d734bb18ca9f87798f0670396eb.
Revert "missing host to network conversion highest_sequence_number_received"
This reverts commit 50c62cdfd7a9ddee22e9e779c0a8c4dfba23f717.
Revert "logging correction"
This reverts commit ea973b0b4cde8ecf562252d6d22faad583e30846.
Revert "[FS-6623] implement RTCP report generation"
This reverts commit 0b7863a9b7e786d35ddf5babc51ba19f1dfa7a1a.
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: 828e03715f67f358671c6691c3e9c0f2a66ec6ec
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.
