Note that while stats names are standardized, any given implementation may be using experimental values or values not yet known to the Web application. Thus, applications MUST be prepared to deal with unknown stats.
Statistics need to be synchronized with each other in order to yield reasonable values in computation; for instance, if and are both reported, they both need to be reported over the same interval, so that “average packet size” can be computed as “bytes / packets” - if the intervals are different, this will yield errors. Thus implementations MUST return synchronized values for all stats in an -derived dictionary.
Dictionary Members
timestamp
of type DOMHighResTimeStamp
The , of type DOMHighResTimeStamp
, associated with this object. The time is relative to the UNIX epoch (Jan 1, 1970, UTC). For statistics that came from a remote source (e.g., from received RTCP packets), represents the time at which the information arrived at the local endpoint. The remote timestamp can be found in an additional field in an RTCStats
-derived dictionary, if applicable.
The type of this object.
The attribute MUST be initialized to the name of the most specific type this RTCStats
dictionary represents.
id
of type DOMString
A unique that is associated with the object that was inspected to produce this RTCStats
object. Two objects, extracted from two different RTCStatsReport
objects, MUST have the same id if they were produced by inspecting the same underlying object.
User agents are free to pick any format for the id as long as it meets the requirements above.
Note
A user agent can turn a predictably generated string into an unpredictable string using a hash function, as long as it uses a salt that is unique to the peer connection. This allows an implementation to have predictable ids internally, which may make it easier to guarantee that stats objects have stable ids across getStats() calls.
The set of valid values for , and the dictionaries derived from RTCStats that they indicate, are documented in [WEBRTC-STATS].