res_srtp: lower log level of auth failures
Previously, sRTP authentication failures were reported on log level WARNING. When such failures happen, each RT(C)P packet is affected, spamming the log. Now, those failures are reported at log level VERBOSE 2. Furthermore, the amount is further reduced (previously all two seconds, now all three seconds). Additionally, the new log entry informs whether media (RTP) or statistics (RTCP) are affected. ASTERISK-16898 #close Change-Id: I6c98d46b711f56e08655abeb01c951ab8e8d7fa0
This commit is contained in:
parent
317b62c8b4
commit
1e4c1cec7f
|
@ -446,11 +446,26 @@ tryagain:
|
|||
}
|
||||
|
||||
if (res != err_status_ok && res != err_status_replay_fail ) {
|
||||
if ((srtp->warned >= 10) && !((srtp->warned - 10) % 100)) {
|
||||
ast_log(AST_LOG_WARNING, "SRTP unprotect failed with: %s %d\n", srtp_errstr(res), srtp->warned);
|
||||
srtp->warned = 11;
|
||||
/*
|
||||
* Authentication failures happen when an active attacker tries to
|
||||
* insert malicious RTP packets. Furthermore, authentication failures
|
||||
* happen, when the other party encrypts the sRTP data in an unexpected
|
||||
* way. This happens quite often with RTCP. Therefore, when you see
|
||||
* authentication failures, try to identify the implementation
|
||||
* (author and product name) used by your other party. Try to investigate
|
||||
* whether they use a custom library or an outdated version of libSRTP.
|
||||
*/
|
||||
if (rtcp) {
|
||||
ast_verb(2, "SRTCP unprotect failed on SSRC %u because of %s\n",
|
||||
ast_rtp_instance_get_ssrc(srtp->rtp), srtp_errstr(res));
|
||||
} else {
|
||||
srtp->warned++;
|
||||
if ((srtp->warned >= 10) && !((srtp->warned - 10) % 150)) {
|
||||
ast_verb(2, "SRTP unprotect failed on SSRC %u because of %s %d\n",
|
||||
ast_rtp_instance_get_ssrc(srtp->rtp), srtp_errstr(res), srtp->warned);
|
||||
srtp->warned = 11;
|
||||
} else {
|
||||
srtp->warned++;
|
||||
}
|
||||
}
|
||||
errno = EAGAIN;
|
||||
return -1;
|
||||
|
|
Loading…
Reference in New Issue