DEV Community: Tsahi Levent-Levi

How to Read a webrtc-internals Dump, Section by Section

Tsahi Levent-Levi — Thu, 18 Jun 2026 12:56:27 +0000

When a WebRTC call goes bad, the browser already recorded what happened. Chrome keeps a live record of every peer connection at chrome://webrtc-internals, and you can export it to a JSON dump. The problem is that the dump is dense, undocumented, and easy to misread. This is a field guide to reading one by hand: what each section is, what to look at first, and the failure signatures that tell you where the call broke.

It assumes you have a dump already. If you do not: open chrome://webrtc-internals in a new tab, then in another tab start a WebRTC session, reproduce the issue, then go back to the webrtc-internals tab and use Create a dump at the top to download the .json. (In production you usually get these from a user's support ticket. Ask them to capture it while the call is bad - or have it collected automatically in your system, though that's for another time).

The shape of a dump

A dump has two top-level parts:

getUserMedia calls. Every microphone and camera request, with the constraints asked for and what the browser returned. This is where you confirm the call even had the right media to begin with
One block per RTCPeerConnection. Each block has the connection config (ICE servers), an event log (a timestamped list of signaling and ICE state changes), and stats graphs (every getStats() metric sampled over the life of the call)

Read them in that order. Most people jump straight to the graphs and miss that the call never negotiated in the first place.

1. The getUserMedia section: did you get the media you asked for?

Each entry shows the requested constraints and the resolved track. Two quick checks:

Asked for video, got audio only? A constraint failed or a permission was denied. The rest of the call will look "broken" but the root cause is here
Resolution or frame rate lower than requested? The device could not satisfy the constraint and the browser silently downgraded. Worth knowing before you blame the network

Besides that, knowing the device brand (what microphone and webcam) sometimes sheds additional light that can be highly relevant to your problem at hand.

2. The connection config: is there a TURN server at all?

In the peer connection block, look at the iceServers config. If there is no turn: entry, the call can only connect when both sides have a direct path. On real networks (corporate firewalls, symmetric NAT, mobile), that fails a meaningful fraction of the time. A missing or misconfigured TURN server is one of the most common production failures, and it is invisible unless you look here.

The rest of the data needed to debug and troubleshoot connections will be found in the event log and the candidate-pair table (below).

3. The event log: how far did negotiation get?

The event log is the timeline. Read it top to bottom and watch two state machines:

Signaling: setLocalDescription and setRemoteDescription firing in order, ending in stable. If you never reach stable, the offer/answer exchange broke (often an SDP or m-line mismatch). No media will flow, no matter what the network looks like
ICE connection state: the sequence you want is new to checking to connected to completed. The failure signatures:
- Stuck in checking, then failed: connectivity. The two sides could not find a working path. Go to the candidate pairs (next section)
- connected then disconnected then back: an unstable network mid-call, not a setup problem
- completed cleanly: negotiation is fine. Your problem is media quality, not connectivity. Skip to section 5, but first stop to check what the active candidate pair looks like in the next section

4. The selected candidate pair: how did the call connect (or not)?

Filter the stats for candidate-pair and find the nominated/selected pair. The local and remote candidate types tell a story:

host to host: direct local network. Best case
srflx (server-reflexive): connected through NAT via STUN. Normal
relay: the call is going through your TURN server. It works, but it costs you bandwidth and adds latency. If most of your calls are relay, that is a finding
No selected pair at all: ICE failed. Cross-reference the config (section 2): if there were no relay candidates and the network needed one, that is your answer

Other things you can figure out here are is this a UDP, TCP or TLS relay? Were TURN pairs ever exchanged in the process properly? Things that are important to understand the dynamics of how things got connected (if at all).

On the selected pair, currentRoundTripTime is your real network latency. Anything consistently above ~300ms will be felt as lag.

5. The RTP stats: where the quality actually lives

This is the part most people mean when they say "read the dump." Look at inbound-rtp (media you received) and outbound-rtp (media you sent), per track. The metrics that matter, and what they mean when they go wrong:

packetsLost / packet loss rate. Rising loss on inbound means the network dropped data on the way to you. A few percent is survivable; sustained double digits is not
jitter. Variation in packet arrival timing. High jitter forces the jitter buffer to grow, which you hear as delay or robotic audio
framesPerSecond, frameWidth/frameHeight. If these drop mid-call, the video encoder is shedding quality to cope with something. The next metric tells you what
qualityLimitationReason (on outbound video). This is the single most useful field in the dump for a video call. bandwidth means the network could not carry the bitrate, so the encoder dropped resolution or frame rate. cpu means the machine could not encode fast enough. none means the encoder was unconstrained and the problem is elsewhere
freezeCount / totalFreezesDuration (inbound video). Directly counts the visible freezes the user experienced. If this climbs, the user saw the call stutter
nackCount, pliCount, firCount. Retransmission and keyframe requests. Spikes here track loss and decode trouble
Audio: concealmentEvents, insertedSamplesForDeceleration. The audio equivalent of freezes. Rising concealment is the network hiding gaps, which the user hears as choppy audio

6. The graphs: read the shape over time

Every metric above is also plotted over the life of the call. The shape is the diagnosis:

Bitrate that climbs then collapses, with qualityLimitationReason: bandwidth: congestion. The call ran out of network and BWE backed off
Packet loss spiking at intervals while RTT stays flat: bursty loss (Wi-Fi interference, a saturated uplink), not pure congestion
Resolution stair-stepping down while CPU is pinned: an underpowered device, not the network
Everything flat and healthy but the user still complained: look back at sections 3 and 4. The media was fine; the call may have taken too long to connect, or connected over a slow relay

Putting it together

The method is always the same: confirm the media exists (1-2), confirm the call negotiated and connected (3-4), then read the RTP stats and graphs to separate network problems (loss, jitter, RTT) from media problems (qualityLimitationReason: cpu, resolution drops) from connectivity problems (ICE failed, all-relay). Most "bad call" tickets resolve to one of those three buckets, and the dump tells you which.

Doing this by hand for every ticket gets old fast, which is the honest reason tools exist. If you would rather not parse JSON, rtcStats reads a webrtc-internals dump and surfaces the same findings automatically: it flags the observations above, scores the call's experience, and explains in plain language what went wrong. Upload the dump in the browser and you get the read without the manual pass. Either way, now you know what the tool is looking at, because it is the same six sections.

The open source piece of rtcStats enables you to systematically collect all webrtc-internals-like dumps (we call them rtcstats files) in your WebRTC deployment, so that each and every call is counted, logged and analyzed.

6 Essential WebRTC Security Best Practices for 2025

Tsahi Levent-Levi — Sat, 28 Dec 2024 20:28:04 +0000

Want to secure your WebRTC applications in 2025? Start here. WebRTC ensures encrypted, real-time communication, but its security depends on proper implementation. Here are the 6 key practices to keep your WebRTC communications safe:

Use Secure Signaling Protocols: Protect the handshake process with HTTPS and WSS.
Apply End-to-End Encryption (E2EE): Ensure privacy with DTLS and SRTP, plus forward secrecy.
Restrict Access with Controls: Implement Role-Based Access Control (RBAC) for permissions.
Keep Software Updated: Regularly update WebRTC components to patch vulnerabilities.
Conduct Security Audits: Perform penetration tests, code reviews, and vulnerability scans.
Configure Firewalls Correctly: Secure NAT traversal and limit traffic to essential ports.

These steps protect against threats like man-in-the-middle attacks, signaling leaks, and server vulnerabilities. Stay proactive to ensure secure and reliable WebRTC communication.

Is WebRTC a security risk?

https://youtu.be/76oHtlSmUNs

1. Use Secure Signaling Protocols

Secure signaling protocols are a critical part of WebRTC security, serving as the initial defense against threats. While WebRTC automatically encrypts media streams, the signaling phase requires additional protection using HTTPS and WSS (WebSocket Secure) protocols.

These protocols safeguard the handshake process where peers exchange connection details. By leveraging TLS encryption, HTTPS and WSS secure sensitive data like ICE candidates, session descriptions, and authentication tokens during transmission.

For example, video conferencing platforms rely on HTTPS and WSS to shield session details, blocking unauthorized access and preventing man-in-the-middle attacks. To enhance signaling security, consider the following steps:

Set up TLS certificates on your servers
Implement token-based authentication to confirm user identities
Regularly check certificate expiration dates to avoid service disruptions

Secure signaling isn't optional - it's essential. Any weakness in this area can compromise the entire communication channel, no matter how strong the other security measures are.

While signaling protocols protect initial exchanges, encryption ensures the privacy and integrity of the media streams themselves.

2. Apply End-to-End Encryption

As cyber threats continue to evolve, end-to-end encryption (E2EE) remains a critical layer of WebRTC security. WebRTC uses DTLS for secure connection setup and SRTP to protect media streams, adhering to IETF standards.

One of the standout features of E2EE is forward secrecy. This generates a fresh encryption key for every session, ensuring that even if current keys are compromised, past communications can't be decrypted. This helps shield sensitive data from unauthorized access, eavesdropping, and tampering.

To ensure E2EE is implemented correctly:

Use DTLS-SRTP for exchanging keys securely.
Block any unencrypted connections.
Conduct regular audits of your encryption protocols.

While WebRTC simplifies encryption by enabling it automatically, developers must still focus on proper implementation and ongoing security checks. For example, in group calls, media servers will be involved in the communications - they will be privy to the media flowing through them unless application level E2EE is employed.

Something to remember is that encryption protects data during transmission, but pairing it with strong authentication ensures only authorized users can access your WebRTC application.

3. Restrict Access with Controls

After setting up strong authentication, access controls add an extra layer of security by managing what authenticated users can do within your WebRTC application. Using Role-Based Access Control (RBAC), you can assign specific permissions to different user roles - like administrators, moderators, and participants - to limit access based on their responsibilities.

For instance, administrators might handle user and session management, moderators could oversee participants and shared content, and participants would only access basic communication tools. This setup minimizes the chances of unauthorized actions.

To make your access controls even more effective, take these steps: define user permissions clearly, enforce session timeouts to block unauthorized access, and log session activities to monitor potential risks. For applications dealing with sensitive data, you can implement access controls that consider factors like user location, device type, and time of access, offering more tailored security without sacrificing ease of use.

Lastly, remember that keeping your WebRTC software updated is key to patching vulnerabilities before they can be exploited. Regular updates are just as important as role-based restrictions.

4. Keep Software Updated

Updating your WebRTC software is a key step in preventing attackers from exploiting known vulnerabilities. Older versions often have security gaps that hackers can use, so staying up-to-date is critical for safeguarding your systems.

Set up a system to handle updates efficiently. This can include automated update checks, keeping an eye on vendor advisories, and carefully tracking version changes. Pay special attention to updating encryption modules, key exchange protocols, and media server configurations to quickly address potential security risks.

If managing updates in-house feels overwhelming, consider using managed WebRTC services. These services handle updates for you, keeping your system secure without requiring a dedicated security team. This is especially helpful for organizations with limited resources. Make sure to regularly check your system against the latest vendor versions as part of your overall security routine.

Encryption protocols like SRTP and DTLS-SRTP should also be updated regularly to stay aligned with current security standards. Keeping all components - such as signaling protocols - in sync with the latest updates helps protect against new threats.

5. Conduct Security Audits

Performing regular security audits is crucial for identifying weaknesses in your WebRTC system. This process uses a mix of automated scans and manual testing to ensure thorough protection. Since WebRTC relies on real-time data exchange, audits help address potential risks before they can impact sensitive communications.

Security audits typically focus on three main areas:

Penetration Testing: Simulates real-world attacks to identify vulnerabilities in signaling protocols, encryption setups, and authentication systems.
Code Reviews: Examines source code to catch security flaws early. Key areas to review include:
- Signaling protocol implementations
- Encryption module settings
- Authentication processes
- Access control systems
Vulnerability Scanning: Combines automated tools with manual checks to detect security gaps in your WebRTC infrastructure. This dual approach ensures more thorough coverage than automation alone.

For complex applications, audits should be conducted quarterly or twice a year. Additionally, perform targeted assessments after major updates or changes to your WebRTC setup. This ensures that new features or modifications adhere to security standards.

The most notable vendor doing such vulnerability and penetration testing for VoIP and WebRTC is likely Enable Security - be sure to subscribe to their newsletter for more security advice around communication technologies.

While audits are key to identifying risks, don’t overlook the importance of properly configured firewalls to block unauthorized access.

6. Configure Firewalls Correctly

Getting your firewalls set up the right way is critical for keeping WebRTC communications secure. A poorly configured firewall can open the door to attacks, putting real-time communication at risk.

For developers, this is mostly about making sure port 443 is what you use for all media traffic on your TURN servers, and then making your IP addresses “friendly” to your customers.

For IT managers who wish to allow communications through their infrastructure? Read below.

Port Management and Access Control

When managing ports, stick to the essentials. Allow WebRTC traffic only through ports 80 and 443 to ensure functionality while blocking unauthorized access.

It would be best if you also allow UDP traffic through ephemeral port range (most WebRTC applications will use ports higher than 10,000 for media). You can whitelist the specific TURN and media servers if needed.

For enterprise setups, consider using Application-Level Gateways (ALGs) within your firewall.

Monitoring and Maintenance

Keeping your firewall configuration up-to-date is just as important as setting it up. Follow these steps to stay secure:

Weekly Rule Reviews: Regularly audit and adjust rules to eliminate unnecessary permissions.
Traffic Analysis: Keep an eye on WebRTC traffic for anything unusual that could signal a breach.
Access Logging: Maintain detailed logs for all WebRTC-related traffic to aid in security audits.

Make sure your firewall setup integrates smoothly with tools like intrusion detection systems (IDS) and security information and event management (SIEM) platforms. This layered approach works hand-in-hand with encryption and access controls to strengthen your defenses.

Lastly, avoid using public networks for WebRTC sessions whenever possible. Even the best-configured firewall can't fully protect against the risks of unsecured connections.

What’s next?

As we move into 2025, focusing on strong WebRTC security measures is more important than ever. Key practices like secure signaling, encryption, authentication, and access controls are essential for building a reliable communication system. Regular updates and audits help protect against new vulnerabilities.

WebRTC's security largely depends on how well it is implemented. This highlights the need to stay alert and to understand the technology when developing WebRTC applications. Consistent maintenance along with active monitoring can help safeguard your systems from potential risks.

Securing WebRTC is an ongoing process. Staying informed and proactive ensures your WebRTC applications are better equipped to handle evolving threats.

For deeper insights into WebRTC security, check out BlogGeek.me or consider enrolling in the WebRTC security course for practical training.