8.4 RTCStats Dictionary

An RTCStats dictionary represents the stats object constructed by inspecting a specific monitored object. The RTCStats dictionary is a base type that specifies as set of default attributes, such as timestamp and type. Specific stats are added by extending the RTCStats dictionary.

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 bytesSent and packetsSent 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 RTCStats-derived dictionary.

  1. WebIDLdictionary RTCStats {
  2. required DOMHighResTimeStamp timestamp;
  3. required RTCStatsType type;
  4. required DOMString id;
  5. };

Dictionary RTCStats Members

timestamp of type DOMHighResTimeStamp

The timestamp, 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), timestamp 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.

type of type RTCStatsType

The type of this object.

The type attribute MUST be initialized to the name of the most specific type this RTCStats dictionary represents.

id of type DOMString

A unique id that is associated with the object that was inspected to produce this RTCStats object. Two RTCStats objects, extracted from two different RTCStatsReport objects, MUST have the same id if they were produced by inspecting the same underlying object.

Stats ids MUST NOT be predictable by an application. This prevents applications from depending on a particular user agent’s way of generating ids, since this prevents an application from getting stats objects by their id unless they have already read the id of that specific stats 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 RTCStatsType, and the dictionaries derived from RTCStats that they indicate, are documented in [WEBRTC-STATS].