Your Zoom call dies mid-sentence. Your Slack huddle drops the moment someone shares their screen. Meet cuts to audio-only for no obvious reason. You restart the app, reboot your router, even switch to mobile data, and nothing improves. The real problem sits on the specific path your call data travels between two browsers, invisible to any speed test you run. After reading this, you will know how to run a browser-based P2P connectivity test, read each metric it outputs, and pinpoint whether the culprit is your NAT type, packet loss, jitter, or relay routing before you file another support ticket.
How Peer-to-Peer Video Calls Travel Over Your Network
Rather than traveling over a single pipeline, a video call weaves its data through a complex chain of local adapters, intermediate routers, and competing ISPs before reaching your partner’s screen. Because every single hop along this path presents a potential bottleneck, any delay compounds instantly. By sending continuous probe packets across this exact route, your browser captures the latency added by each physical connection point. Depending on your router’s security policies, NAT traversal decides whether those packets travel directly or through a slower relay.
Tracing through each connection stage reveals exactly how your call data behaves under pressure. First, your browser contacts a STUN server to discover its public IP, then shares those gathered credentials with its remote peer over a pre-arranged signaling channel. Once both engines possess these handshake tokens, they initiate direct ICE connectivity checks. When those direct paths fail to punch through local firewalls, the browsers fall back to a TURN relay server to bridge traffic. Each transition point surfaces a different failure mode.
- Browser contacts
STUNserver to discover its public IP and port.1 - Signaling exchange shares offer and answer
SDPblobs between peers. - Both sides run
ICEconnectivity checks against all gathered candidate addresses.2 - Failed direct checks fall back to a
TURNrelay server that bridges traffic.2
A server-based ping test measures only the first hop of this journey, from your browser to a datacenter much closer than the remote peer. The result looks clean while the actual four-hop P2P path drops packets and introduces jitter. This gap explains the most confusing symptom: an 8-millisecond ping to your ISP’s speed-test server at the same time a 220-millisecond jitter metric appears on a video call. The two numbers are not contradictory because they measure two completely different paths. While this structured handshake works perfectly under ideal network conditions, standard server diagnostics often mask the bottlenecks that occur during live WebRTC sessions.
What a speed test does not measure
Speed tests measure the path from your device to a nearby datacenter, typically over a direct backbone route with no NAT traversal required. A result of 8 milliseconds round-trip to that server tells you nothing about what happens when your call data must punch through your router’s NAT, cross both ISPs, and arrive at a peer on a different network. Because standard browser-based speed tests utilize TCP or WebSocket handshakes over a structured server backbone, they bypass the raw UDP path that WebRTC uses for real-time media streams, leaving local firewall rules and packet jitter completely invisible. Consequently, you can run a perfect speed test and still experience significant jitter on a video call because the problem sits on the P2P leg of the journey, not the datacenter leg.
CapyToolkit’s test for peer-to-peer latency, jitter, and packet loss between two browsers opens a real WebRTC data channel and measures every hop your call data takes. Every millisecond it records includes NAT traversal, both ISP routes, and any relay overhead. That measurement is what matters when you press the call button. browser-based tools that process everything locally remove the need to grant diagnostic software network-level permissions you would rather not hand out.
A router that lets you actually control NAT traversal, UPnP, and QoS is the hardware change most likely to stop a call from falling back to a relay. The table below compares routers that expose that control, from a budget multi-WAN box to Wi-Fi 7, sorted by price and wireless standard.
Running a P2P Connectivity Test from Your Browser
The P2P Network Tester takes about thirty seconds to set up and requires no account or browser permission beyond the default WebRTC access every modern browser already grants. Open the page and the STUN probe runs automatically; within a few seconds your public IP, NAT type, and ICE candidate type appear without you clicking anything. The test then asks which role you want to play: initiator or joiner.
The initiator clicks “Start Session” and receives an offer SDP blob formatted as a text string. That blob contains all the negotiation data the remote browser needs to respond: ICE candidates gathered so far, the chosen DTLS fingerprint, and the media description. Copy it and send it to whoever will join your test. The joiner pastes that blob into the “Paste Partner’s Offer” field and clicks “Generate Answer.” The joiner copies the resulting answer blob and sends it back. The initiator pastes the answer and clicks “Connect.” Once the ICE state flips to connected, the live dashboard starts immediately with RTT, jitter, and packet loss updating every 100 milliseconds.
That copy-paste exchange is not a workaround for missing backend infrastructure. It is a deliberate privacy choice. No CapyToolkit server ever sees the SDP blobs during the session. The blobs travel through whatever channel you choose (email, chat, a note on a shared screen) and the two browsers negotiate directly. From the site’s perspective, the only data that leaves your browser during the entire session is the brief STUN request that reveals your public IP, which the WebRTC protocol requires. WebRTC protocols documented in detail by MDN cover the full specification if you want the complete reference.
When a call fails to connect, the error panel explains why. Most ICE failures trace back to symmetric NAT on one side, which means no amount of retrying resolves the issue. You have to change the network configuration. Knowing that before you spend ten minutes reconnecting gives you a better starting point for debugging session.
What the STUN probe reveals on first load
The STUN probe contacts public STUN servers on page load and returns two values you need: your public IP address and your NAT classification. The tool reports whether your router behaves as an Open (Full Cone) NAT, a Moderate (Restricted Cone) NAT, or a Strict (Symmetric) NAT, because the classification directly determines whether a direct peer-to-peer connection is possible.3 An Open or Moderate NAT allows inbound packets from an unknown peer after you have sent an outbound packet, which means the hole-punching WebRTC relies on will usually succeed. A Strict NAT only allows return traffic for connections you have already established, which blocks the inbound checks the remote peer sends during the ICE phase.
RFC 3489 originally defined NAT types, and they remain the practical taxonomy most tools use to classify router behavior today.3 Knowing your NAT type before you start the full test cuts down the number of things you have to investigate. If the STUN probe shows symmetric NAT, you already know symmetric NAT causes video call failures before you ever run a full session. If NAT type looks fine, you can focus on the live metrics instead of hunting through router settings.
Reading the Metrics: What Each Number Actually Tells You
Once connected, the live dashboard displays five metrics that together describe the quality of the path: average RTT, jitter, packet loss, packets sent versus received, and ICE candidate type.4 Each metric answers a different question about your network, and none of them is more important than the others by default.
RTT (round-trip time) measures how long a probe packet takes to travel to the remote peer and back. An average below 80 milliseconds on an internet connection is normal; under 1 millisecond over physical Ethernet, or below 2 to 5 milliseconds on local Wi-Fi, is typical on the same LAN. When average RTT stays consistently high across multiple tests, the culprit is usually the geographic distance between the ISPs or a congested router on one side.
Jitter measures the variation between consecutive RTT samples. A stable connection reads jitter under 5 milliseconds; values above 10 milliseconds correlate with audio buffering, video freeze, and input lag in games. The tool smooths jitter using the RFC 3550 EWMA formula with a smoothing factor of one sixteenth, which dampens momentary spikes but surfaces a consistently unstable path.5 High jitter kills call quality faster than high raw latency because audio codecs compensate by buffering, and that buffer is what you hear as a delayed voice.
Packet loss counts the percentage of probe packets that never returned an echo within 2 seconds. Zero percent is the goal, though wireless links tolerate 1 to 2 percent before audio drops out. The tool distinguishes simulated loss from real loss using the dashboard’s visual markers, so you can tell at a glance whether a spike came from your loss slider or from the actual network.
ICE candidate type tells you which path the connection ultimately took. A host candidate means both browsers are on the same local network. An srflx candidate means direct NAT traversal succeeded and traffic flows directly between the peers. A relay candidate means traffic routes through a TURN server, adding 40 to 80 milliseconds of overhead per hop. This single field gives you more diagnostic signal than all the other fields combined because it tells you whether the connection architecture is healthy before you even look at latency numbers. When you run a peer-to-peer jitter test on the actual network path, not just to a server, the jitter metric carries that path-specific context from the outset. A test of the three metrics that determine video call quality measured over WebRTC presents all values on one dashboard so you can correlate them at a single glance.
For your next diagnostic session, use this quick baseline matrix to interpret each field at a glance:
| Metric | Normal range | Abnormal cause | First action |
|---|---|---|---|
Average RTT | < 80 ms internet | Cross-continental ISP path, congested router | Check NAT type first |
| Jitter | < 5 ms | Wi-Fi interference, CPU overload on router | Switch to 5 GHz or wired |
| Packet loss | 0% | ISP congestion, bad cable, Wi-Fi channel overlap | Test on wired to isolate |
| ICE candidate type | srflx or host | Symmetric NAT, missing UPnP | Change router NAT type |
Your network is what makes a call freeze, but once the path is clean the camera decides how you actually look. The webcams below span a reliable budget upgrade to a 4K option.
The Four Most Likely Culprits Behind Bad Calls
Symmetric NAT is the most common reason a WebRTC call routes through a relay when it should not. Your router assigns a different source port to every outbound connection to a different destination, which means the remote peer’s ICE connectivity check cannot predict which port to target.6 The consequence is a failed direct punch and an automatic fallback to TURN relay, adding 40 to 80 milliseconds to every packet. Symmetric NAT is the default on many carrier-grade CGNAT setups and corporate firewalls, while most home routers ship with an Open NAT mode that avoids the problem entirely. If your NAT type consistently shows Strict, you can check your NAT type and understand why your router blocks direct connections in the browser without installing anything.
Packet loss behaves differently depending on where the drop originates. Wi-Fi interference inflates jitter and produces a pattern where RTT stays stable while individual packets disappear. ISP congestion or a damaged cable shows up as both rising RTT and steady missing packets. The fastest way to distinguish between the two is to run the test once on Wi-Fi and once on a wired connection to the same router. If wired loss drops to zero, the interference sits inside your local wireless segment. If wired loss stays high, your ISP or the physical line is the culprit.
High jitter causes more audible damage than equivalent raw latency. When an audio codec encounters unstable delivery timing, it fills the gaps by extending the decode buffer. The listener hears a delayed and stuttering voice, not a clean but slightly lagged one. Video codecs handle jitter differently but still produce visible artifacts when the buffer cannot keep up with the arrival pattern. Jitter under 5 milliseconds is essentially unnoticeable; anything above 15 milliseconds forces the codec to buffer more aggressively and the consequences compound over time.
Relay routing is the fallback state when direct connectivity fails, and it is the most avoidable degradation in this list. A TURN server exists precisely to broker connections that NAT and firewalls would otherwise block, which means its presence signals a broken direct path somewhere upstream. Once your connection routes through a relay, every packet adds 40 to 80 milliseconds of overhead regardless of how good the underlying link is. The fact that the connection works at all is a win in hostile network environments, but if you want call quality close to what a wired LAN delivers, relay should be a temporary state you resolve by fixing the upstream NAT or firewall.
The four causes behind most bad calls and how to address each:
- Symmetric
NATon your router — enableUPnPorNAT-PMP, place the device inDMZas a diagnostic, or request a public IP from your ISP. - Packet loss — rule out the cable first by testing wired, isolate Wi-Fi interference by switching channels, and test at off-peak hours to confirm ISP congestion.
- High jitter — move to the
5 GHzband, reduce client-to-router distance, or switch to Ethernet for the ground truth. - Relay routing — fix upstream
NATor firewall on the side showing “relay” candidate type soICEselects a direct path.
Why the culprit changes depending on who you call
Testing with one partner tells you only half the story. Because call quality sits on a shared path through both networks and at least one ISP, relay routing on one side degrades quality for both callers regardless of how clean the other side is. When both ends carry symmetric NAT, the relay overhead compounds and the degradation becomes obvious within the first two minutes. A browser packet loss test isolates individual connection variables cleanly so you can determine exactly which side carries the anomalous metric and fix that side first.
Server Tools vs. Peer-to-Peer Tools: Why the Measurements Diverge
Server-based ping and traceroute measure the path from your browser to a datacenter with no NAT traversal and a direct backbone route back. The P2P test traverses a completely different path: both home routers, both ISPs, wherever the NAT hairpin happens. Latency measured on the P2P path is always higher than a server ping for the same connection, and that difference is itself useful diagnostic information.
To calibrate the two, compare your server ping against your P2P RTT. A clean server ping below 20 milliseconds combined with P2P RTT above 80 milliseconds points to a congested home network or slow local router. A server ping above 80 milliseconds combined with high P2P jitter means the ISP-side network is the bottleneck. The two tests measure different things, and both results matter for a complete picture. When you run the test with the same partner twice, once on your home Wi-Fi and once on a cellular connection, the resulting metrics expose the variable that actually matters most by comparing path latency, jitter profile, and candidate type between sessions.
When the ISP speed test and the call quality disagree
The ISP speed test runs against a server on the ISP’s own backbone. Your P2P partner may sit on a different ISP entirely, which forces traffic through public peering exchanges that the speed test never touches. When the speed test shows clean numbers and your P2P metric shows degraded quality, the misalignment is the peering route, not your home setup. That distinction tells you whether to call your ISP or start rearranging your home network.
The single fastest way to settle the Wi-Fi-versus-network question is to take Wi-Fi out of the equation. Plug into a wired link and run the test again; if the freeze disappears, the problem was local wireless interference all along.
Troubleshooting Steps to Restore a Stable Connection
Stop troubleshooting the wrong device first. Run the test with two different partners and compare the results. If both tests show the same anomaly on your side, your network is the problem and all repair efforts belong there. If only one partner combination shows problems, the remote peer is the culprit and nothing you do to your router will fix it. This step prevents hours of router changes that never resolve anything. Run the test side-by-side: open two browser windows, assign one as the initiator and the other as the joiner, and record the metrics from both perspectives before assuming anything.
Next, resolve symmetric NAT. Start by enabling UPnP or NAT-PMP on your home router, which lets the browser open inbound ports automatically without manual port forwarding.7 Place your machine in the router DMZ as a temporary diagnostic to rule out other firewall rules interfering. If DMZ works but normal NAT mapping still shows Strict, contact your ISP and request a public IP or a residential block instead of carrier-grade NAT. Once the STUN probe shifts from Strict to Open or Moderate, re-run the full test to confirm the improvement. The change should also move your ICE candidate type from relay to srflx, which is the actual signal that NAT traversal improved.
Next, reduce Wi-Fi jitter. Switch the testing device to the 5 GHz band, disable 2.4 GHz on high-traffic networks, or move the device closer to the router with fewer walls between them. A wired Ethernet connection eliminates Wi-Fi as a variable entirely and gives you a clean baseline to compare against the wireless numbers. If wired jitter drops below 5 milliseconds and wireless stays above 10, your wireless segment is the problem, not your ISP. The router CPU load also matters: an overloaded consumer router on a crowded channel introduces jitter even on the wired side.
Next, fix packet loss. Rule out a bad cable by connecting the device directly to the modem and running the test again. If loss drops to zero, the cable was the problem. If it stays above zero, test at off-peak hours to identify ISP congestion: packet loss that disappears during late-night or early-morning hours confirms ISP-side oversubscription. Consider switching from a shared Wi-Fi channel to one with fewer neighbors, because channel overlap causes collisions that the retransmission layer marks as loss. If wired loss still stays above zero after all local variables are isolated, report the issue to your ISP with the exact loss percentage and time of day so they have actionable data.
Next, check for relay routing. If ICE candidate type shows “relay” with an RTT above 80 milliseconds, either side is behind symmetric NAT or a firewall blocking UDP hole-punching. Resolve NAT on the affected side before enabling TURN, because the relay is only a workaround for an unresolved direct path. Once the relay is working, do not leave it as a permanent configuration: every video call routed through a relay adds 40 to 80 milliseconds per hop compared to a direct connection, which translates to perceptible audio delay and video stutter. A gaming P2P latency test can help you determine whether lag comes from the ISP path, NAT type, or relay routing so you know which variable to fix next.
Finally, confirm each fix by running the test again after every change and recording the before-and-after metrics in a short note. The test resets when you click “Start Over,” so screenshot both states. Changing two variables at once makes it impossible to know which one actually solved the problem and guarantees you will repeat the wrong change. Change one variable at a time and retest immediately.
- 1.
J. Rosenberg, R. Mahy, P. Matthews, and D. Wing, “Session Traversal Utilities for NAT (STUN),” RFC 5389, IETF, October 2008. https://www.rfc-editor.org/rfc/rfc5389.html
- 2.
A. Keranen, C. Holmberg, and J. Rosenberg, “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal,” RFC 8445, IETF, July 2018. https://www.rfc-editor.org/rfc/rfc8445.html
- 3.
J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, “STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs),” RFC 3489, IETF, March 2003. https://datatracker.ietf.org/doc/rfc3489/
- 4.
Julie Griffin and Ravleen Kaur, “VoIP call quality: 9 ways to improve quality issues,” twilio.com, March 2025. https://www.twilio.com/en-us/blog/insights/best-practices/voip-call-quality
- 5.
H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” RFC 3550, IETF, July 2003. https://datatracker.ietf.org/doc/rfc3550/
- 6.
“Network address translation,” Wikipedia, accessed July 2026. https://en.wikipedia.org/wiki/Network_address_translation
- 7.
“NAT Port Mapping Protocol,” Wikipedia, accessed July 2026. https://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol
