Some questions about RTC Statistics

I’m going to provide some in app useful information about the user connectivity status. At the same time I need to store some structured stats logs in the server side for reporting and analyzing purposes. Here’re some question came in my mind:

  • Does client stats differ from the stats by server? Which one to use for the client?
  • Why there is no availableOutgoingBitrate while RTCIceCandidatePairStats provides that?
  • What is the difference between availableIncomingBitrate and maxIncomingBitrate?
  • Can roundTripTime be interpreted as latency?
  • How score is calculated?

Server stats are generated by mediasoup as stated in the documentation. Client side stats are those generated by the PeerConnection. mediasoup-client does not modify them at all.

Taking this into account, can you rephrase your other questions by specifying whether you mean server or client stats in each of them?

Particularly for a specific producer or consumer, do client and server stats share the same result (meaningfully and not necessarily equal in their values)? And if yes is there any advantages using server stats rather client stats for client reporting?

I’m not sure, probably both. Please you enlighten me.

  • Does client stats differ from the stats by server? Which one to use for the client?

No preference. Use whichever suits better your needs. In the server you have the server stats, in the client you have the client stats. Or you can retrieve the server stats in the client, etc. No preference.

Not related to mediasoup. Ask in Chrome forum/tracker (assuming that’s Chrome).

  • What is the difference between availableIncomingBitrate and maxIncomingBitrate ?

Assuming you mean mediasoup server WebRtcTransport stats:

  • Can roundTripTime be interpreted as latency?

Yes, but there is lot of information about that in webrtc-stats or by looking for “roundTripTime” in Google.

  • How score is calculated?

Particularly for a specific producer or consumer, do client and server stats share the same result (meaningfully and not necessarily equal in their values)? And if yes is there any advantages using server stats rather client stats for client reporting?

They are supposed to provide similar values in matching fields, yes. Of course, “out” direction in client becomes “in” direction in server and vice-versa.

1 Like

hey mkh, I found it useful to use the server stats, and send those over to the client for displaying information due to the fact that mediasoup is calculating the server side so they’re consistent.

If you use the client side stats, those are calculated by the client’s browser and you’ll have to handle the fact that not all browsers report the same information.

I don’t remember the specifics in the report but one thing I was trying to do was get the bitrate and frame rate on the client side, and firefox made that really easy as it included both fields but on chrome I had to manually calculate the bit rate I believe.

There’s some stats code in this simple demo, in case it’s helpful:


I figured out that there is no availableIncomingBitrate in the stats generated by mediasoap. Am I missing some thing? If not then why it’s been documented?

I was hoping I had it also for producer but it seems I don’t. :frowning:

Lag or latency is one of the common issues in network connectivity but it seems roundTripTime has no role in calculating the score.

Hi @swoobie
Good point :ok_hand: I just have performance concerns about getting stats for hundreds or thousands of streams in the server.

Thanks @kwindla for sharing the code :pray:

I figured out that there is no availableIncomingBitrate in the stats generated by mediasoap. Am I missing some thing? If not then why it’s been documented?

There is availableIncomingBitrate and availableOutgoingBitrate. Anyway we do not document all those fields. They mean the same as in the spec.

  • Can roundTripTime be interpreted as latency?
    I was hoping I had it also for producer but it seems I don’t. :frowning:

Work ir progress: calculate sender rtt by yangjinecho · Pull Request #314 · versatica/mediasoup · GitHub

Lag or latency is one of the common issues in network connectivity but it seems roundTripTime has no role in calculating the score .

RTT depends on where the peers are located. No, we do not use RTT for calculating those scores.

Okay I can see availableIncomingBitrate only in the producer transport stats but not in the consumer transport, and there is no availableOutgoingBitrate neither in the producer transport nor in the consumer transport:

[{ bytesReceived: 1340,
    bytesSent: 154766,
    dtlsState: 'connected',
    iceRole: 'controlled',
    iceSelectedTuple:
     { localIp: '192.168.1.100',
       localPort: 10074,
       protocol: 'udp',
       remoteIp: '192.168.1.10',
       remotePort: 53028 },
    iceState: 'completed',
    maxIncomingBitrate: 1500000,
    recvBitrate: 1264,
    sendBitrate: 587464,
    timestamp: 137721243,
    transportId: '341efb55-4a86-4a97-b06a-8ffae7341308',
    type: 'webrtc-transport',
}]

Great :+1:

As far as a WebRtcTransport is sending at least a video to the remote endpoint, there is availableOutgoingBitrate in the transport stats.

You can verify it in the mediasoup demo.

In the client stats yes but not in the server stats.

What do you think @ibc?

I really mean “in the server stats”:

Use with caution.