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
mod_sofia's parameter shutdown-on-fail now accepts the value
"reincarnate-now". This will cause the switch to exit immediately
with a non-zero exit code so that the supervisor can recover the
switch. For this to work you have to pass in -reincarnate or
-reincarnate-reexec to freeswitch.
This is the result of auditing each mod_sofia profile parameter to
ensure that it can be unset or reset after being set. One use-case
for this being done correctly is so a later parameter in a
configuration file can reliably override an earlier one, which is
useful for setups with layered include files.
This commit allows you to set a `log-file` string parameter in a
format_cdr profile. This string is a template that may (and should!)
contain variables. This template will be expanded and used as the
file name of the CDR to be written. This parameter should contain
only the template for the file name itself; the path is relative to
the `log-dir`.
Previously if send-display-update was set to false we would also
remove UPDATE from our Allow: headers. This is unnecessary. The
UPDATE message is useful in SIP transactions even if we're not sending
display updates.
With this commit, we add a new boolean profile flag, allow-update. If
set to true we'll send Allow: UPDATE. If set to false, we will not.
If there is a conflict with another setting that requires UPDATE
support, the allow-update parameter will win and a warning will be
printed.
ref: RFC 3311
Anthony Minessale