Add clarification that inbound-rtp.bytesReceived includes retransmissions. about webrtc-stats HOT 6 CLOSED

Related issue: #751

from webrtc-stats.

Not sure if we are consistent with RFC though since we made it so that "bytesSent includes RTX" and the RTX could be sent over a separate SSRC if separate RTX stream is supported.

from webrtc-stats.

There is some confusion here about whether or not probes need/should be included. I suspect they should be included on both send and receive side - but I'm not sure what we do today. @fippo can you help break down the current state of things?

Edit: Especially what the state of the probes are as those seem to account for a large percentage of overall traffic

from webrtc-stats.

The overall definition of "this SSRC" should probably be "this SSRC and all the SSRCs related to it such as retransmissions or FEC" in a lot of places. This relationship is commonly defined via ssrc-group, not sure if JSEP in its "we don't need SSRCs" narrative actually solves that problem or not.

The spec seems fine apart from pointing out that "This includes retransmissions" for inbound-rtp which is easy to fix, I'll do a PR.

RTX probes (for which we don't have an actual spec definition, whoops) are a bit tricky. They look like retransmitted packets on the receiver (one can try to be smart but given the lack of a spec that is a bad idea). Which means they will get accounted for differently, on outbound-rtp they might get accounted for as padding (maybe, like padding probes).
This means that retransmittedPacketsReceived may be nonzero even when there is no packet loss. That is a bit asymmetric but ok and according to the definition.

from webrtc-stats.

If I may quote you @fippo running https://jsfiddle.net/fippo/hvpxf5L0/3/ with and without https://webrtc-review.googlesource.com/c/src/+/295260 which did modify inbound-rtp counters:

with this patch yields (--force-fieldtrials=WebRtcStatsReportIdl/Disabled/ helps)
SENT outbound-rtp p=58066 h=5980 packetsSent=98 retransmittedPacketsSent=0
SENT transport p=66422 h=undefined packetsSent=103 retransmittedPacketsSent=undefined
RECV inbound-rtp p=58066 h=5980 packetsReceived=98 retransmittedPacketsReceived=21
RECV transport p=66422 h=undefined packetsReceived=103 retransmittedPacketsReceived=undefined

while without it the following (from a different connection)
SENT outbound-rtp p=83872 h=3536 packetsSent=108 retransmittedPacketsSent=0
SENT transport p=89814 h=undefined packetsSent=112 retransmittedPacketsSent=undefined
RECV inbound-rtp p=78714 h=2536 packetsReceived=97 retransmittedPacketsReceived=undefined
RECV transport p=89814 h=undefined packetsReceived=112 retransmittedPacketsReceived=undefined

from webrtc-stats.

If I may quote you @fippo running https://jsfiddle.net/fippo/hvpxf5L0/3/

The fiddle demonstrates that after stopping a transceiver and waiting a bit for things to settle we should have roughly the same number of inbound-rtp packetsReceived as we have on outbound-rtp packetsSent.

from webrtc-stats.