Philipp Hancke

I might be digressing to the :unicorn: of a ssrc collision a bit ("if there is a collision what should be the impact") but this has impact on the question...

> Having stats appear based on whether SSRCs are known seems worse than both the spec and Chrome today. But this is exactly what Chrome does. Which is slightly harmful...

in a discussion with @henbos about cache invalidation I noticed that "has received a packet" (or the first) is not something we would like to cause a cache invalidation because...

@dontcallmedom can you generate an IPR link please and take a look at the respec woes? Worked with 27 [here](https://github.com/w3c/webrtc-stats/actions/runs/1426923166), breaks with 28 now. Probably need to blow some dust...

actually the inconsistency is a bit bigger: https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface is missing: url, relayProtocol [https://w3c.github.io/webrtc-stats/#icecandidate-dict*](https://w3c.github.io/webrtc-stats/#icecandidate-dict*) is missing: foundation, component, relatedAddress, relatedPort, usernameFragment I don't have a use-case for the missing candidate stats...

aha... url is apparently surfaced in onicecandidate: https://w3c.github.io/webrtc-pc/#rtcpeerconnectioniceevent I don't think that is implemented by anyone even?

*bump*

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

since this was a bit complicated to enable even here is a pcap (zipped) [rrtr-dllr.zip](https://github.com/w3c/webrtc-stats/files/9462319/rrtr-dllr.zip) produced from Chrome when enabling RRTR

Nice catch! For PLI and FIR this is simply the count of the RTCP packets with the types defined in those sections. For NACK it is a bit more complicated...