
A short technical walkthrough (Tsahi Levent-Levi with Philipp Hancke) demonstrating Chrome's WebRTC Internals as a runtime debugging/monitoring tool. They show how WebRTC Internals exposes per-peer-connection information (ICE/candidates, TURN, connection/signaling state), an event log of API calls, and getStats-format tables and graphs; they also describe downloading the internals dump and loading it into an offline dump importer for review and graphing.
Chapters
How do you go and monitor things in WebRTC? Chrome gives us a very powerful tool which is called WebRTC internals. It's a tab that you can open inside Chrome alongside the actual call. Do that before you start a session. There you'll find a lot of the statistics, events, APIs and other things that are important to understand what goes in a WebRTC call. Let's go and look at the WebRTC internal session that we're actually running now to record this call on Streamyard.
Yes. So if you open WordPress internals, you will see it's a page with different sub tabs which are shown here. So one that you typically start with is the getusermedia and Get Display Media tab, which has information on all the calls you made to these APIs. Then you have one tab per peer connection. And let me click on that. That switches the view. You can see it goes to different connections. So you see the port here changed, looks very similar. This one was added later, so it has more information. And the first problem you have here is which of these connections do you need to look at? That depends on your application as a problem you're seeing.
Okay, so we've got three of them, which means that streamyard uses three different connections, possibly a few for uploading and a few for downloading the data. We know that there are such applications. What can we see inside each one of the peer connections, though?
Inside each of the peer connections you have how the peer connection is configured. Here we see turn servers that are being used. Some things like ICE transport policy and bundle policy. We see the state of the peer connection. Here is connection state, overall connection state and signaling state. We see what the iscandidate pair that is currently being used is. So that tells you the local and remote IP address. Useful if you need to dump stuff in Wireshark and Filter. We also see the ISE candidate grid. And that is not expanded by default, but can be expanded because it is going to be pretty huge.
Okay, and we have a separate video for that.
Correct.
Okay. Then the list of API calls here, that's the event log.
Yes, we have a separate video for that as well. And this is one where it gets important that you open the page before the connection gets made. Because if we look at this here, we get all the calls that were made on this connection which was established before we opened webvrecine Tunnels. We don't get those events, we get the current state, but no more.
Yes. Here we see only five events that are actually history versus the Other one where we see a lot more events that took place because this we didn't collect it on time.
Correct.
Okay, what else do we have here? I see that there is a stats table.
Yes. In this one we have stats being shown as it's the same objects we get from get stats. This is basically a dump of that format.
We have a video about what exactly is a certificate and codec and candidate pair and local candidate and inbound rtp. And all of these different types of objects and what they say, mean and do.
Yes. And you can filter them. Like if you only want to look at inbound rtp, you only get those. Yep.
And then if you open one of them.
Yes. So the select candidate pair is shown in bold to make it easy to find. If you expand that, you will see graphs for this candidate pair.
And again the graphs will start from the moment you opened the WebRTC internals tab, not before.
Yes. You can see that here on packets received. There's a huge jump here, which is when we started collecting.
Yep. Okay, good. So that's what we've got in WebRTC internals. And this we can do during runtime. What if I want to take this and then send it to someone to review from time to time I send you such files, for example, to look.
Yes. What you do then is to create a WordPress internal stamp. And I will typically, if you come to me with a problem, I'll be like, show me your PRC internal stamp. You can download that one and then you go to my stump importer.
Then there is a link for that below this video.
Yes. Then you can pick the file that you just downloaded, import it and you will see something that's very similar to WebRCY in terms of the. To webert in terms of information, but the layout is different.
And I think what's different is that this is done offline. So I don't have the real time updates that I have on WebRTC internals. Which means that if you scroll down, what we get is the. Instead of seeing tables of statistics, we only have the graphs for them.
Yes. So, for example, here we have the graphs, we have the updates to the peer connection and we have the candidate palette. We've picked the right one, which I think is this one. Yes. Then you can hear you get a single graph because the library that is being used is a bit more powerful than what WordPress internals ships. And you can see things like calculated stuff WordPress internals does. And the good thing about the dump reporter, you can just turn off all data and just look at the graph you want. In this case, bytes received, bytes sent. You can zoom in to a certain range and do whatever you want with that.
Okay, so what we did was look at WebRTC internals, understand what are the components inside that data, that we have downloaded the file and looked at the same data using the dump importer. And these are the powerful tools that we've got in WebRTC in order to be able to monitor and debug the applications that we're building. Okay, thank you for that, people.
Thank you.
More from Tsahi

Meta rebuilt AV1 for mobile scale. Should smaller teams follow? | Chats with Arin









