RTCRemoteInboundRtpStreamStats - plus alignment with outbound

[hamishwillee]

This adds docs for RTCRemoteInboundRtpStreamStats , a stats object/dictionary you can get by iterating a RTCStatsReport.

It is not very exciting. Largely following the same patterns as the other docs.

This shares some common properties with RTCRemoteOutoundRtpStreamStats. There have been some changes to align those.

This is part of the ongoing work to finished RTC stats, which was started in #27028

[github-actions]

Preview URLs (25 pages)

• /en-US/docs/Glossary/Jitter
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/codecId
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/fractionLost
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/id
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/jitter
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/kind
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/localId
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/packetsLost
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/packetsReceived
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/roundTripTimeMeasurements
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/roundTripTime
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/ssrc
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/timestamp
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/totalRoundTripTime
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/transportId
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/type
• /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats
• /en-US/docs/Web/API/RTCRemoteOutboundRtpStreamStats/codecId
• /en-US/docs/Web/API/RTCRemoteOutboundRtpStreamStats/kind
• /en-US/docs/Web/API/RTCRemoteOutboundRtpStreamStats/localId
• /en-US/docs/Web/API/RTCRemoteOutboundRtpStreamStats/roundTripTimeMeasurements
• /en-US/docs/Web/API/RTCRemoteOutboundRtpStreamStats/ssrc
• /en-US/docs/Web/API/RTCRemoteOutboundRtpStreamStats/totalRoundTripTime
• /en-US/docs/Web/API/RTCRemoteOutboundRtpStreamStats/transportId
• /en-US/docs/Web/API/RTCRemoteOutboundRtpStreamStats

Flaws (6)

Note! 20 documents with no flaws that don't need to be listed. 🎉

URL: /en-US/docs/Web/API/RTCRemoteOutboundRtpStreamStats/localId
Title: RTCRemoteOutboundRtpStreamStats: localId property
Flaw count: 2

• macros:
  • /en-US/docs/Web/API/RTCSentRtpStreamStats/packetsSent does not exist
  • /en-US/docs/Web/API/RTCSentRtpStreamStats/bytesSent does not exist

---

URL: /en-US/docs/Web/API/RTCRemoteOutboundRtpStreamStats/kind
Title: RTCRemoteOutboundRtpStreamStats: kind property
Flaw count: 1

• macros:
  • /en-US/docs/Web/API/RTCCodecStats/codec does not exist

---

URL: /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/packetsLost
Title: RTCRemoteInboundRtpStreamStats: packetsLost property
Flaw count: 1

• macros:
  • /en-US/docs/Web/API/RTCInboundRtpStreamStats/packetsLost does not exist

---

URL: /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/packetsReceived
Title: RTCRemoteInboundRtpStreamStats: packetsReceived property
Flaw count: 1

• macros:
  • /en-US/docs/Web/API/RTCInboundRtpStreamStats/packetsReceived does not exist

---

URL: /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/jitter
Title: RTCRemoteInboundRtpStreamStats: jitter property
Flaw count: 1

• macros:
  • /en-US/docs/Web/API/RTCInboundRtpStreamStats/jitter does not exist

External URLs (2)

URL: /en-US/docs/Web/API/RTCRemoteInboundRtpStreamStats/fractionLost
Title: RTCRemoteInboundRtpStreamStats: fractionLost property

• https://datatracker.ietf.org/doc/html/rfc3550 (3 times) (Note! This may be a new URL 👀)

---

URL: /en-US/docs/Glossary/Jitter
Title: Jitter

• https://en.wikipedia.org/wiki/Packet_delay_variation (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2024-08-02 00:45:52)

[hamishwillee]

NOTE, I am confused here. For context RTCRemoteInboundRtpStreamStats are statistics from the remote system about inbound stream stats. In other words, the local end sent some information to the remote end. The remote end has reported some information back to say what it received.

So for remote inbound stats my understanding is that you're getting the packetsReceived as measured at the remote end. This will simply be all received packets since the beginning of the session including retransmissions.
This contrasts with RTCInboundRtpStreamStats.packetsRecieved which is the local end calculating stats for the inbound stream.

But the spec states for packetsReceived:

packetsReceived of type unsigned long long

Total number of RTP packets received for this SSRC. This includes retransmissions. At the receiving endpoint, this is calculated as defined in [RFC3550] section 6.4.1. At the sending endpoint the packetsReceived is estimated by subtracting the Cumulative Number of Packets Lost from the Extended Highest Sequence Number Received, both reported in the RTCP Receiver Report, and then subtracting the initial Extended Sequence Number that was sent to this SSRC in a RTCP Sender Report and then adding one, to mirror what is discussed in Appendix A.3 in [RFC3550], but for the sender side. If no RTCP Receiver Report has been received yet, then return 0.

IF we assume that by "receiving endpoint" we mean "whatever is calculating the packets received" then this works because a receiver just counts what packets it got - and that is then way we got back from the remote end in this report.

I THINK the bit about "at the sending endpoint ..." is irrelevant. I.e. you might calculate the packetsRecieved in that way at the sender, but that has nothing to do with this data we are reporting.

[hamishwillee]

Note that all of this is my "guess/evaluation" based on the RFC info and appending linked in the next section. All the spec says is that it is calculated as per those spec links. I have interpreted that to mean that the property contains the 8 bit unsigned integer in the RR/SR "fraction loss" field. That is calculated by 8 bit shifting a number so the fraction is now the number.

It all sounds rational, but I can't prove it. I've tried a bunch of examples out and they all give me a value of zero :-( (which is what you get if there is no loss OR if the loss is negative).

[hamishwillee]

@wbamberg Yet another one to look at. I will probably continue working on it to update RTCRemoteOutoundRtpStreamStats if you don't review it soon, as they have more common behaviour. But if you do start reviewing I'll stop that.

[wbamberg]

ah right, so the quicker I review it the smaller it'll be? :)

[hamishwillee]

@wbamberg Yes :-). I'll be pausing if you review this earlier so that neither of us have a moving target for the "common" changes that are in this PR. But I'm not back until Friday. No huge urgency.

[wbamberg]

@hamishwillee , I have started on this.

[pepelsbey]

@hamishwillee hey! Do you think we can still pull this through?

[hamishwillee]

@pepelsbey I've been putting this off as "not a priority". I've merged most of the suggestions but I want to have another look at it on Friday. Will is on holiday, so it is not urgent unless you want to review it?

[pepelsbey]

Will is on holiday, so it is not urgent unless you want to review it?

Thank you! As you said, it’s not a priority, so I’d leave it to Will since he’s already familiar with it.

[hamishwillee]

@wbamberg I have accepted your suggestions and addressed all the issues you raised. No urgency, but this is ready for a new review when you are.

Addressed!

[wbamberg]

Thanks Hamish!

3 typo suggestions, but approving anyway so you can merge if you accept them :).

[hamishwillee]

Thanks very much @wbamberg - appreciate your patience and help with these. One day I may be finished with all of these and we can both have a deep sign of relief.

[wbamberg]

ha yes I admit to a feeling of dread when I see one of these 🤣