SRTCP index reset after renegotiation in M67?

[Lorenzo Miniero]

Hi all,

I noticed something weird while testing Chrome M67 with Janus. I started getting weird srtp_err_status_replay_fail errors for incoming SRTCP packets after a renegotiation. Specifically, the errors start appearing for SRTCP packets related to SSRCs that stay the same: e.g., if you add video to an audio-only PeerConnection, you get a new video SSRC but the audio SSRC stays the same, and trying to process the related SRTCP packets after the new offer/answer exchange causes the error; if you just update the session without touching anything at all (e.g., just for the purpose of an ICE restart), the same thing happens for both audio and video, as in that case both SSRCs remain the same.

I noticed that the errors didn't occur forever, but only for a short time, which was pretty much in line with how much time passed between the PeerConnection creation and the renegotiation, which made me suspect an SRTCP index reset of some sort: basically, my guess was that once the index gets to X+1, where X is the last index used before the renegotion occurred, no clash occurs in the SRTCP world anymore, and so the error goes away.

As a test I printed the SRTCP index for incoming packets, and I could indeed confirm that after a renegotiations they start from 1 again. This did NOT happen in M66 and previous versions. Was this intentional, or is this a regression? If intentional, what was the rationale, considering it breaks RTCP for SSRCs that don't change? I tried looking for an open issue on the tracker, but couldn't find any: if this is a bug, I can open a new one.

Thanks,

Lorenzo

[Taylor Brandstetter]

This is definitely not intended behavior; we should fix this and merge into M67.

I looked into it a bit and believe I found the cause; see last comment on this bug. Thanks for investigating and providing such detailed info.

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b92b8781-5c89-4ad4-8bc7-c2c0a397f1ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lorenzo Miniero]

Thanks for looking into it, I'll keep track of the issue you mentioned!

Lorenzo

Il giorno giovedì 19 aprile 2018 23:48:28 UTC+2, Taylor Brandstetter ha scritto:

This is definitely not intended behavior; we should fix this and merge into M67.

I looked into it a bit and believe I found the cause; see last comment on this bug. Thanks for investigating and providing such detailed info.

On Thu, Apr 19, 2018 at 8:26 AM, Lorenzo Miniero <lmin...@gmail.com> wrote:

Hi all,

I noticed something weird while testing Chrome M67 with Janus. I started getting weird srtp_err_status_replay_fail errors for incoming SRTCP packets after a renegotiation. Specifically, the errors start appearing for SRTCP packets related to SSRCs that stay the same: e.g., if you add video to an audio-only PeerConnection, you get a new video SSRC but the audio SSRC stays the same, and trying to process the related SRTCP packets after the new offer/answer exchange causes the error; if you just update the session without touching anything at all (e.g., just for the purpose of an ICE restart), the same thing happens for both audio and video, as in that case both SSRCs remain the same.

I noticed that the errors didn't occur forever, but only for a short time, which was pretty much in line with how much time passed between the PeerConnection creation and the renegotiation, which made me suspect an SRTCP index reset of some sort: basically, my guess was that once the index gets to X+1, where X is the last index used before the renegotion occurred, no clash occurs in the SRTCP world anymore, and so the error goes away.

As a test I printed the SRTCP index for incoming packets, and I could indeed confirm that after a renegotiations they start from 1 again. This did NOT happen in M66 and previous versions. Was this intentional, or is this a regression? If intentional, what was the rationale, considering it breaks RTCP for SSRCs that don't change? I tried looking for an open issue on the tracker, but couldn't find any: if this is a bug, I can open a new one.

Thanks,

Lorenzo

--

---
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.