Confusing round trip time defintion in remote-outbound-rtp

[k0nserv]

The definition for roundTripTime, totalRoundTripTime, and roundTripTimeMeasurements in remote-outbound-rtp are all, seemingly, incorrect. They refer to the DLRR report block of Sender Reports(SR) but reference extended RTCP reports(defined in RFC3611). This is correct, insofar that DLRR is defined in RFC3611, but as far as I can tell it's not the case that DLRR blocks are contained within Sender Reports as the text implies. Because of this confusion it's unclear how these stats are supposed to be implemented. Further, I'm not sure if webrtc mandates the use of RTCP XR.

Example:

Estimated round trip time for this SSRC based on the latest RTCP Sender Report (SR) that contains a DLRR report block as defined in [RFC3611]. The Calculation of the round trip time is defined in section 4.5. of [RFC3611]. If the latest SR does not contain the DLRR report block, or if the last RR timestamp in the DLRR report block is zero, or if the delay since last RR value in the DLRR report block is zero, the round trip time is left undefined.

Emphasis mine

It seems like the intention is to use DLRR report blocks in all instances that mention Sender Reports(SR) and that those mentions of SR are errors.

Please advise

[fippo]

DLRR is a block type of XRs and can't be part of a SR (I think... the structure is too different). It can come together with a SR as part of a compound packet which may explain the confusion.

The correct thing should be

Estimated round trip time for this SSRC based on the latest RTCP Extended Report (XR) that contains a DLRR report block as defined in [RFC3611]. The Calculation of the round trip time is defined in section 4.5. of [RFC3611]. If the latest XR does not contain the DLRR report block, or if the last RR timestamp in the DLRR report block is zero, or if the delay since last RR value in the DLRR report block is zero, the round trip time is left undefined.

[k0nserv]

Right, so for:

Dictionary RTCRemoteOutboundRtpStreamStats Members

The content ought to be:

localId of type DOMString

The localId is used for looking up the local RTCInboundRtpStreamStats object for the same SSRC.

remoteTimestamp of type DOMHighResTimeStamp

remoteTimestamp, of type DOMHighResTimeStamp [HIGHRES-TIME], represents the remote timestamp at which these statistics were sent by the remote endpoint. This differs from timestamp, which represents the time at which the statistics were generated or received by the local endpoint. The remoteTimestamp, if present, is derived from the NTP timestamp in an RTCP Sender Report (SR) block, which reflects the remote endpoint's clock. That clock may not be synchronized with the local clock.

reportsSent of type unsigned long long

Represents the total number of RTCP Extended Report(XR) DLRR blocks received for this SSRC.

roundTripTime of type double

Estimated round trip time for this SSRC based on the latest RTCP Extended Report (XR) that contains a DLRR report block as defined in [RFC3611]. The Calculation of the round trip time is defined in section 4.5. of [RFC3611]. If the latest RTCP Extended Report (XR) does not contain the DLRR report block, or if the last RR timestamp in the DLRR report block is zero, or if the delay since last RR value in the DLRR report block is zero, the round trip time is left undefined.

totalRoundTripTime of type double

Represents the cumulative sum of all round trip time measurements in seconds since the beginning of the session. The individual round trip time is calculated based on the DLRR report block in the RTCP Extended Report (XR) [RFC3611], hence undefined roundtrip times are not added. The average round trip time can be computed from totalRoundTripTime by dividing it by roundTripTimeMeasurements.

roundTripTimeMeasurements of type unsigned long long

Represents the total number of RTCP Extended Report (XR) blocks received for this SSRC that can derive a valid round trip time according to [RFC3611] and the above. This counter will not increment if the roundTripTime is undefined.

(Changes in bold)

I don't think I quite understand reportsSent. I guess it should still be SR, but how would the receiving end know how many SRs have been sent, shouldn't it say "received"?

[alvestrand]

A report block should normally always start with an SR or RR. That might be the source of the confusion. Invoking @vr000m as the RTCP XR expert.

[fippo]

since this was a bit complicated to enable even here is a pcap (zipped) rrtr-dllr.zip produced from Chrome when enabling RRTR

[k0nserv]

There's another question here:

Does the specification(webrtc or webrtc-stats) mandate the use of extended reports with DLRR blocks? I've never seen this negotiated in SDP and the implementation of webrtc I'm working on doesn't emit them currently.