Respond to RRTR with DLRR

[kvasilye]

Send DLRR in response to RRTR

Usefulness: subscribers can measure their RTT

https://datatracker.ietf.org/doc/html/rfc3611#section-4.4

https://datatracker.ietf.org/doc/html/rfc3611#section-4.5

[algesten]

Hey @kvasilye thanks for look at this.

I think there's a problem which was already there before this PR. The ssrc() in the RRTR is a remote SSRC, and it's already routed as if it is local. That in turn affects this PR shape. It should be stored on session and we send a response as soon as we can.

[kvasilye]

I think you mean that the RRTR's SSRC may not necessarily be one of ours that we're publishing with, correct?

Let me work on fixing this.

[kvasilye]

Fixed - there is now a map of SSRC -> most recently received RRTR where the SSRC values don't have to match any of our publish SSRC values.

This map is flushed in the timeout method, but only when we have just queued up a Sender Report. This allows the DLRR to be combined with the sender report, so there is still only one outgoing packet.

Without checking for the pending Sender Report - meaning the DLRR was sent as its own RTCP packet - the bwe test started to under-estimate and fail.

[algesten]

A couple of things.

Also, a pre-existing outbound RRTR issue in StreamRx::create_extended_receiver_report() sets the XR originator SSRC to self.ssrc, which is the remote media source SSRC. That should be local I think.

[kvasilye]

Updated:

1. Moved LastRrtr struct after the Session struct
2. Changed pending_rrtrs from HashMap to VecDeque — FIFO order, deduplicates by SSRC in place, capped at 300 entries, consumes at most 50 per DLRR report (matching libwebrtc's approach)
3. Moved constants to the top alongside the other module-level constants

[kvasilye]

Also, a pre-existing outbound RRTR issue in StreamRx::create_extended_receiver_report() sets the XR originator SSRC to self.ssrc, which is the remote media source SSRC. That should be local I think.

In this pull request, str0m is the publisher - and the remote SFU is the subscriber.

Since str0m is the publisher, it sends DLRR in response to the SFU's RRTR, and thus the SSRC should be str0m's no?

Sending RRTR (as your comment says) would be the opposite - 1) str0m is the subscriber and wants to measure the RTT by sending RRTR 2) the SFU is the publisher and will reply with DLRR.

I'm not concerned about the "str0m is the subscriber" case in this pull request but could take a look in a separate follow-up pull request if you wanted a complete RTRR / DLRR implementation for both modes.

[algesten]

Yeah. That's what I mean. The RRTR sender side is the opposite direction and can be a separate fix.

It does affect the test in this PR though. The test uses str0m to create the RRTR, so it gets the remote SSRC from that existing bug. That means it doesn't actually test that an RRTR with an unrelated remote SSRC is handled.

But yeah, whatevs, we can do another PR for that.

[kvasilye]

@algesten what's the plan now?

Any plans to merge this given that you already approved?

[kvasilye]

Thank you Martin.

I'll submit a new, separate PR to fix the sending SSRC.

[kvasilye]

Oh wait looks like you already fixed that:

8855f4e

When can we expect a new release tag?