search

Kurento / bugtracker

[ARCHIVED] Contents migrated to monorepo: https://github.com/Kurento/kurento
46 stars 10 forks source link

SRTP & multicast streams: roll-over counter #587

Open makkarpov opened 3 years ago

makkarpov commented 3 years ago

Prerequisites

These are MANDATORY, otherwise the issue will be automatically closed.

Issue description

Same setup as in #586, but now with encryption. Less important (and much more difficult to do), so feel free to close it as 'wontfix'.

The issue occurs when someone is broadcasting encrypted RTP stream, and RTP packet counter rolls over. Since RTP has only 16 bits of packet counter, SRTP maintains "hidden" upper part of it, called "ROC" or "roll-over counter". Various RFC's say that if you want to join an already running session, you have to supply it's value out of band.

So here is the request: allow it to be supplied.

How to reproduce?

Unfortunately, this is much harder than previous one:

  1. Run SRTP stream long enough for 16-bit packet counter to overflow. It will now start from zero and ROC will be one.
  2. Now any attempt to play it with regular player should fail, since they will be out of sync.

Unfortunately, I don't know easy ways to extract current ROC from media frameworks. ffmpeg definitely sucks at that, since I looked at their source code and there is literally no way to do it without patching. gstreamer seems to be better, at least gstreamer is aware of ROC existence (from documentation of srtpdec block):

If a stream is to be shared between multiple clients the SRTP rollover counter for a given SSRC must be set in the caps "roc" field when the request-key signal is emitted by the decoder. The rollover counters should have been transmitted by a signaling protocol by some other means. If no rollover counter is provided by the user, 0 is used by default.

Another possible way to reproduce is to "reverse" the set up:

  1. Initialize Kurento to listen with ROC=1
  2. Start SRTP stream
  3. If Kurento can't decrypt anything -- ROC counter works.
github-actions[bot] commented 3 years ago

Hello @makkarpov! :wave: we're sorry you found a bug... so first of all, thank you very much for reporting it.

To know about progress, check in Triage. All issues are considered Backlog Candidates until work priorities align and the issue is selected for development. It will then become part of our official Backlog.