Strategy for preventing unprotect/ROC issues when using an SFU?

[Brian Baldino]

We've got an SFU that only forwards the current active speakers' video to other participants and we're running into the following issue:

T0: Speaker A is forwarded to receiver B

T1: Speaker C is forwarded to receiver B (B is no longer receiving A's video stream)

T2: Speaker A is forwarded to receiver B

The problem is when the difference in time between T0 and T2 is long enough for A's sequence numbers to roll over enough to throw off the srtp index calculation, so at time T2, B complains with a bunch of srtp_unprotect errors.

I know this must be a common scenario, what are people doing to work around it?  We've added logic to forward, say, 10 out of every 2500 packets from A to B (always, regardless if it is the active speaker or not) so that B can always calculate the srtp index properly, but that makes the peerconnection stats on B look a bit wonky (it's viewed as huge chunks of packet loss).  Is there a better way?

-brian

[Peter Boström]

I would assume that it's quite common to rewrite sequence numbers in the SFU for every outgoing packet.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAAEyqM4JMaxo8AQioO45yZDrzY75iu%2BR9%2BBzUc0ohyucbEpV0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Baldino]

We implemented sequence number rewriting on the SFU to fix the ROC problems, but ran into an issue with slow switching due to some logic in the jitter buffer which causes switches between streams to sometimes be very slow (5-10 seconds).  details in the bug here: https://bugs.chromium.org/p/webrtc/issues/detail?id=6026

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGFX3sHsC9DutXHYAWxopu1kdms8p58my8eFTNyMJskuDnwRjA%40mail.gmail.com.

[emanuele bizzarri]

You could try this.
Don't manage sequence. Leave the original values.
When you stop sending A to B, send a new sdp B, removing A SSRC.
When you want to restart sending A to B, send a new sdp to B, containing a NEW DIFFERENT SSRC for A. B should start decrypting A srtp immediately.
Using this solution you have to rewrite ssrcs for rtp tracks, but not sequences.
I think that rewrite sequences could have difficulties in case of packet loss and retransmission

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAAEyqM4Xu6s6MfK2kwtMXvQjjEpK22Kcp%2Bm6PSii5Jc9A0fnOg%40mail.gmail.com.