Tsahi Levent-Levi explains where getStats() reports bytesSent/bytesReceived in WebRTC. He identifies three places to inspect: inbound RTP/outbound RTP (per-RTP-stream media bytes and header bytes), the transport object (aggregates all RTP/RTCP and adds SRTP/DTLS overhead), and the candidate pair (the active ICE connection, including ICE/STUN traffic). The video clarifies which metric to check depending on whether you want per-stream media counts or aggregated connection-level counts.
Chapters
Send bytes, received bytes, send packets, received packets. Where do we get these numbers exactly from? And which of the getstats objects do we need to look at in order to understand what it is that we're sending and receiving in WebRTC? So let's look at it. We've got two objects to look at. This is the incoming inbound RTP and the outbound rtp. On these objects we can find things that would allow us to understand how much we're sending and receiving. There's also the transport object. A single transport object might have multiple inbound RTP and outbound RTP objects associated to them. And then there is a candidate pair. A candidate pair is the ICE connection, if it's the active one that we are using to actually send and receive data. So the transport is a kind of, let's call it, virtual object that holds the inbound and outbound rtp, which is actually actual RTP stream streams that are being sent. And the candidate pair takes care of the ICE connection that we've got for sending and receiving the media. Let's look at what's going to happen here. If we look at the inbound RTP and outbound rtp, what they store are the individual RTP stream bytes. Send bytes and receive bytes are the actual media that we're going to send. And then there's send bytes, sorry, header bytes sent and header bytes received, which are the same things but for the headers of the rtp. So on the inbound RTP and outbound rtp there is a distinction between the actual media that we're sending to the header of that media. Then there is the transport. On the transport, what we're actually getting for sent and received bytes would be everything. That's going to be all of the RTP and the RTCP streams. And then there's the SRTP encoding that is an overhead. On top of RTP and srtp, there are a few bytes there that are being added. And there's also the dtls part. Okay, so we've got more. In the transport layer, it aggregates all of the inbound and output RTPs and then does all of the calculations to add the additional stuff. What can you find on the candidate pair? Well, all of the above, including all of the ICE communications, usually the stand traffic that is being sent the packets to maintain the connection to the STAN server opened at all times. So if you're looking at which send bytes and receive bytes to look at, check out, where do you need to go to the inbound and outbound RTP to the transport or to the candidate pair. Thank you. If you want to learn more about WebRTC, go follow me at Bloggeek Me.