B Fixed RTCP unprotect replay window for GCM

[jimm98y]

Same issue as in 8877339, only in RTCP. Removed the CheckAndUpdateReplayWindow method as it was no longer being used.

[sipsorcery]

Below is from Claude Code:

Thanks for porting the replay-window fix to the RTCP path. The core change is correct — splitting into a read-only CheckReplayWindow before decrypt and UpdateReplayWindow only after authentication, with the AEAD decrypt wrapped so an auth failure returns without advancing the window, faithfully mirrors the RTP fix (8877339) and the RFC 3711 §3.3 ordering. Removing the now-dead CheckAndUpdateReplayWindow is fine too.

However, I think this introduces a functional regression in UnprotectRtcp for the encrypted path (AES-CM and AEAD GCM/CCM): the decrypt IV is still derived from ssrcContext.S_l rather than from this packet's index.

// ~line 1288 (AES-CM), ~1302 (AEAD GCM/CCM), ~1325 (Double AEAD outer)
SRTP.Encryption.CTR.GenerateMessageKeyIV (context.K_s, ssrc, ssrcContext.S_l, context.Iv16);
SRTP.Encryption.AEAD.GenerateMessageKeyIV(context.K_s, ssrc, ssrcContext.S_l, context.Iv12);

Previously this happened to work because the old CheckAndUpdateReplayWindow(index) ran before the decrypt and advanced S_l = index for newer packets, so S_l == index at IV-generation time. Now that the update is (correctly) deferred to after the decrypt, S_l still holds the previous packet's index when the IV is generated.

In-order stream:

• Packet 1 (index 0): S_l defaults to 0 → IV uses 0, matches the sender → decrypts (this is why a single-packet round-trip passes).
• Packet 2 (index 1): UpdateReplayWindow(0) left S_l = 0; CheckReplayWindow(1) does not touch it → IV uses 0 while the sender used 1 → wrong keystream / mac check in GCM failed. Every subsequent packet is off by one.

The RTP path avoids this by deriving the IV from the local index rather than S_l (e.g. GenerateMessageKeyIV(..., index, ...)). RTCP should do the same:

SRTP.Encryption.CTR.GenerateMessageKeyIV (context.K_s, ssrc, index, context.Iv16);
SRTP.Encryption.AEAD.GenerateMessageKeyIV(context.K_s, ssrc, index, context.Iv12);   // GCM + Double AEAD outer

index already has the E-flag stripped (line ~1233), and the AAD continues to use originalIndex (with the E-flag), which is correct.

Net effect without this change: encrypted RTCP (SR/RR, NACK/PLI/REMB, BYE) stops decrypting after the first report for the standard WebRTC profiles — and this path worked before the PR, so it's a regression rather than a pre-existing issue.

The green CI looks to be a coverage gap: there's no multi-packet encrypted-RTCP round-trip test for CM/GCM. A two-packet GCM protect→unprotect round trip fails on packet 2 and catches this; happy to contribute one.

[jimm98y]

Thank you very much! You're right, both about the issue and the missing test coverage. The issue should be fixed now, not sure when I get to writing the tests though, so any contributions/PRs are welcome!

[sipsorcery]

Claude already wrote the test. Thanks for the update I'll give it a spin.