failure when RTP sequence number switches from 65535 -> 0 about libsrtp HOT 6 CLOSED

There isn't much detail in the asterisk bug report on this. The one comment about TLS and 3DES is a bit confusing since libsrtp supports neither of these. Perhaps the problem is in Asterisk.

Given the limited information in the bug report, this looks like the roll-over counter (ROC) logic isn't working. If the ROC were broken in libsrtp, it's difficult to imagine that nobody else would have experienced the same problem.

from libsrtp.

@jfigus this issue depens on the client implementation of srtp.
E.g. all nokia s60 devices have this issue and it is 100% reproducible with this devices.
Some nokia s40 phones with do not have this issue, but newer nokia phones do also have.
I saw this issue on some other devices too, but do not know the exact device model at the moment.

from libsrtp.

Just as an FYI, my test suite using libsrtp has one test that does 1 million encode/decodes on the same stream, which obviously causes the sequence number to roll over around 16 times - This always succeeds... Implies the issue is not in libsrtp. Maybe the nokia phones are doing something nonstandard (but not forbidden by RTP) like changing the ssrc when the sequence number rolls over - I've seen similar oddities in the past, and that would certainly cause decryption to break.

from libsrtp.

Alexander Traud (@traud) did some patches to fix this issue (see: https://issues.asterisk.org/jira/browse/ASTERISK-16898).
At the moment I did not had the time to test the patches, but I will report the result after some tests.

from libsrtp.

I have tested the patch with Nokia E66. I had to modify the recognition string in the asterisk patch since the E66 uses "E66-1 RM-343 510.21.009".
But the patch does work and fixes the issue.

from libsrtp.

Closing this since there are no plans to patch libsrtp.

from libsrtp.