Sergio Garcia Murillo

Same would happen for `RTCRemoteOutboundRtpStreamStats.remoteTimestamp` and `RTCRemoteOutboundRtpStreamStats.timestamp` the timestamp would represent the time when the stat is created and not the time of when the time was received. So probably...

> RTCInboundRtpStreamStats.timestamp without making some leaps of faith. But we wouldn't need the inbound stats timestamp for anything right? at most the final end 2 end delay would be calculated...

> If we add an explicit metric for this (playoutTimeInReceiverNtp) then no we don't need this timestamp for anything. Yes, I agree. I thought we were speaking about a different...

@henbos are you talking about `browser==simulcast=>SFU--stream->browser` or `browser==simulcast =>browser`

then incoming stream should be a normal RTP stream, either should have an `ssrc` or `mid` to correlate with as any other normal rtp stream, not sure if I understand...

I thought it was about the value `remoteId` of the stats from the incoming stream on the same transceiver in which it was sending simulcast. Regarding correlating the stream received...

@vr000m I don't think any SFU is actually using the CSRCs at all

@vr000m even if they could be used, how would you correlate the information with the appropiate participant and the with it's ssrcs? It would require external coordination. Anyway, if it...

thank you!

should be `Number`