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

1 files changed, 18 insertions, 4 deletions

diff --git a/res/res_srtp.c b/res/res_srtp.c
index a77a90b47..4fa3c1120 100644
--- a/res/res_srtp.c
+++ b/res/res_srtp.c
@@ -448,11 +448,25 @@ 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 because of %s\n", srtp_errstr(res));
 		} else {
-			srtp->warned++;
+			if ((srtp->warned >= 10) && !((srtp->warned - 10) % 150)) {
+				ast_verb(2, "SRTP unprotect failed because of %s %d\n",
+					srtp_errstr(res), srtp->warned);
+				srtp->warned = 11;
+			} else {
+				srtp->warned++;
+			}
 		}
 		errno = EAGAIN;
 		return -1;