Short YouTube demo (Tsahi Levent-Levi with Philipp Hancke) showing how to inspect ICE candidates and identify the active WebRTC connection using the browser's webrtc-internals and using a downloaded dump file opened with the dump importer. The transcript explains where to find peer-connection configuration (TURN servers, ICE/bundle/RTCP policies), how to read the candidate-pair grid (protocol, bytes sent/received, RTT, candidate types, ports, priorities), and how to locate the active pair both in the live internals UI and in the dump importer for troubleshooting.
Chapters
Time to look at ISE connectivity, how sessions get connected, how to troubleshoot and debug issues when they don't. We're going to do that twice, once on WebRTC internals and once on the dump file itself using the dump importer. Philipp, going over to you, let's look at WebRTC internals in the browser. And one thing to notice is that we're actually doing it on the session that we're on, which is recording through Streamyard.
Yes. So what you see typically in WordPress internals is a number of internal tabs, one for get display media and get user media, which shows all the get user media and get display media calls with their individual constraints that are passed in and the tracks that we get out of that. For example, here we see, we have. We're sharing the screen. So we see get display media, call this, tap audio and you see the constraints, frame rate 30 and so on. Other thing we see is one tab for each connection. We have three of them here. That's how Streamyard works. So let's look at the first one. What we see here at the top is how the peer connection is configured. So we see the turn service, we see the ICE transport policy, bundle policy, RTCP MAX policy and escalated pool size. What we see below that is how the session is behaving. When we look at the connection states exposed by the peer connection signaling states, we see the active ICE candidate pair that is being used to send data. And below that we have the button that expands the EYES candidate grid. Okay. It is folded by default because it's getting pretty big at times.
Yep. And they have a lot of turn servers configured here. So there are likely going to be a lot of pairs that we need to go and check and see.
Yes. So let me expand that by clicking on it. And as you can see, it's a fairly large thing and it takes up a whole 4k screen. So what we see here is for each candidate pair we have the state of the pair. We know what protocol is being used, typically udp, but sometimes it can be tcp. We see the number of bytes sent and bytes received. So done. Requests, responses. You see here that there's not much else being sent. This is a current round trip time. It's the time the last data was received. And the last update to the candidate.
Pair is actually three rows. There is a darker row and then two rows below that which are the local and the remote.
Yes. So some information. You can also find a get stats on the candidate pair, some information you get from the candidate object itself, either the local candidate or the remote candidates. Okay. And we see here we get the IP address, we get the local and remote port, we get the local remote candidate type, and we get the priority, which if you, like me, you can actually understand what it does.
And I can also see that we've got the local candidate, the same one multiple times. Let me see, not this one, the second one. 34.29.
Yes, this one.
Yes, true.
So we have this one twice. Because if you look at the URL here, once, this is coming. Oh, this is twice coming from the turntcp server. That's interesting. What is going on there?
Okay, so this is exactly one of the things that you can actually see in these files. So I now know all of the candidates. I know that it tried these through the connectivity checks and decided to use the first one, which was the srf, Alex and host candidates. And this is the active connection for me. Okay, anything else that is interesting for us here?
I mean, if the connection works, this grid is not showing you much interesting things. If the connection doesn't work, then it gets important because then it allows you to debug what failed.
Okay. Okay, now let's see the same thing, but using the dump importer.
Yes, Let me first export the dump, downloading it. And let me switch to the dump importer. Yes. The first thing you need to do is you pick your file, which in this case is the one I just downloaded. And you will see it looks fairly similar to Workplace Internals, but it uses doesn't use this tab view, it uses a different way to display the connections. Okay, so what we see here is all the getusermedia calls, similar to WebProc internals in terms of what's being shown, but present differently. Not that interesting. So we're going to fold this one and here we see the actual connection. Like in WordPress internals you have the configuration with all the things that are there, you have the states and then you have the actual grid. And this is the same you see in WebRC internals, it isn't sorted as nicely. So what we see here, this one was at the top in WordPress internals. Here it's somewhere in the middle.
Yes. And we know that it is active based on the number of bytes sent and received. In a way, yes.
We can also look at this transport which has a selected candidate pair id. And then this one, we search for that one, it's this one. So this is the one currently being used as. That's the time when the dump was downloaded.
Okay, so here's what we did. We've opened WebRTC internals. Before we started this session, you looked at the file and you showed us how to look at the candidates and see that we've got different turn servers in the configuration. We found out that we didn't use a turn server because we searched for the active connection, then downloaded the file and did the exact same thing just using the dump importer. So the information is there for you to look at if you just want it and need it for your troubleshooting. Okay, thank you.
