False positive loop detection on duplicate RTCP packets

[alexbakker]

rtpengine version the issue has been seen with

26.0.1.22

Used distribution and its version

Debian 12

Linux kernel version used

6.1.0-52-cloud-arm64

CPU architecture issue was seen on (see uname -m)

aarch64

Expected behaviour you didn't see

Calls that are on hold (sendonly/recvonly) do not time out if RTCP is still flowing.

Unexpected behaviour you saw

During a hold (sendonly/recvonly), when no RTP is flowing, RTCP receiver reports on a given stream can appear identical to rtpengine, because the reported statistics (loss, jitter, etc) stop changing and rtpengine seems to only look at the first 28 bytes for its duplicate detection. After 30 consecutive identical packets, rtpengine's loop detection engages and drops all subsequent RTCP. And because dropped packets don't update the stream's last-packet timestamp, the call eventually hits the global timeout (not silent-timeout) and is torn down, even though the endpoints are still actively sending RTCP.

Steps to reproduce the problem

This is especially noticeable in B2BUA scenarios where both call legs pass through the same rtpengine and the B2BUA steps out of the media path by sending re-INVITEs to both legs. The local endpoint detection then enables loop checking on the media, and if the call in that state is on hold for some time without any media flowing, it will eventually time out.

Even when the remote endpoint later changes back to a non-local address on a re-INVITE, the loop detection stays enabled. This could be addressed by #2152, but the broader issue of false positive loop detection on RTCP remains.

Additional program output to the terminal or logs illustrating the issue

Anything else?

One approach could be to skip loop detection for RTCP streams, since they're at fairly high risk for false positives. RTP loop detection would still catch actual loops.

I'm filing this as an issue instead of a patch, because I'm not sure what the right approach would be to fix this.

[rfuchs]

I think skipping loop detection for RTCP packets is a good idea. Do you want to tackle this via PR yourself?

Edit: never mind, we must still avoid sending packets in a loop, even if they're RTCP. Let me think about it.

[rfuchs]

Perhaps take reception time into account? Looping packets would be seen in very short succession. Packets that are received more than a certain interval apart (500 ms? 1 second?) are not in danger of being looping. This could even be done for all packets, not just RTCP.

[alexbakker]

I like that. I've submitted #2155 which implements that approach.