Re: Timestamps in stats

On Jan 8, 2013, at 9:33 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> On 01/08/2013 04:58 PM, Cullen Jennings (fluffy) wrote:
>> I don't  think the single timestamp for stats is going to work. Consider a stat that the remote side only provides once every 10 seconds and a local stat that get updated with every packet sent. If someone requested both of these stats, what timestamp would get returned?
>> 
>> I think the timestamps need to be associated with the stat, not the report.
> That's why there's a timestamp on each stat group. Remote (RTCP-reported) stats are going to be in different groups from local stats. But when you get a #packets and #bytes from the same end of a connection, they should have the same timestamp.

That was a bad example on my part. Let me try again. Lets say browser A receives a RTCP packet with a "JB nominal" (section 4.7.7 rfc 3611) value from the remote side a time stamp X, then shortly after that receives from the remote side ( for the same track, SSRC, etc ) a RTC packet with a different time stamp Y and no "JB nominal" value but does have a "round trip delay" as defined in section 4.7.3 of 3611. After both these RTCP reports are received, the JS queries the stats for this track. It seems like these two measurements came from different times yet. (I just picked these two as random examples, I'm not claiming that we need to support either of these but I suspect that we get to a similar issue with ones that we will choose. )

> 
>> 
>> I'm not seeing how things like all the ICE candidates get reported.
> Which document are you reading?

Oh, it's been a week of reading the wrong spec. What should I be reading ?

Received on Wednesday, 9 January 2013 04:04:59 UTC