Testing WebRTC Peer-to-Peer Connection Quality Without Cloud Relay Servers

How CapyToolkit’s P2P Tester opens a zero-cloud connection

WebRTC opens a direct data channel between two browsers without involving any relay server, as long as ICE finds a viable host or server-reflexive candidate.¹² The tool uses ICE to discover the best available path; most often it travels directly through your home router after a STUN server is briefly queried to discover your public-facing IP and port mappings. Once both peers have exchanged their connection descriptions, packets travel directly from one browser to the other. A third server never carries the data in that scenario, which keeps every result anchored to the actual path your ISP and routers enforce.

Under the hood, this is a two-step dance called the offer-answer loop. One browser becomes the initiator and generates an offer SDP, a structured text blob listing codec preference and transport settings, plus the initial set of ICE candidates gathered so far; with Trickle ICE, candidates continue to arrive incrementally as the browser discovers more paths.³ The other browser receives that blob, generates an answer SDP with its own candidates, and sends it back. Both sides paste. Neither side uploads. No backend, no signaling server, no persistent storage. If you take away one thing, let it be this: a remote server only touches your session during the STUN queries that discover candidate addresses. Everything after that stays local.

Zero-cloud design is a commitment. When a TURN relay sits between peers, it absorbs latency spikes, packet loss, and ISP jitter in its own backhaul, so the path you measure becomes the relay’s path rather than yours.⁴ Proving a connection works end-to-end means you know how your network behaves on a real P2P call, game session, or remote desktop link without the relay sanitizing the numbers.

Zero-cloud design shapes CapyToolkit’s ethos across the entire suite. The P2P Network Tester is one expression of that commitment; the rest of the tools follow the same path: no server computation, no upload, no account. To understand how this local-first approach operates in practice, consider how the signaling layer avoids introducing its own transport assumptions

WebRTC traffic never touches a cloud relay

ICE, in other words Interactive Connectivity Establishment, the WebRTC standard for discovering and ranking direct browser-to-browser network paths, routes traffic through the most direct available candidate.² The STUN probe briefly contacts public servers to discover your public IP and surface your candidate addresses, then retreats; those servers receive binding requests but relay no media or application data.⁵

The copy-paste SDP exchange is ICE signaling moved out of band. Normal WebRTC uses a WebSocket or HTTP endpoint to ferry session descriptions between peers; here you paste them by hand. That eliminates the signaling server and the account and server storage that go with it. No upstream service archives snapshots. SDP still travels through a chat, an email, or a link, so some data transfer happens outside the browser. ICE candidate gathering also generates its own network traffic beyond idle browsing; STUN requests reach public servers, and those probe round-trips add a fingerprint an empty tab does not produce.⁵

Manual signaling and the two-browser setup

To begin, one tab opens as the initiator and clicks “Start Session,” then waits for ICE candidates to appear before generating an SDP offer. Once candidates populate, the initiator copies the offer and sends it out-of-band to their partner. The second tab joins with “Join Session,” pastes the incoming offer, fabricates an answer SDP, and copies it back. Copy, paste, connect. The live dashboard takes over from there.

Once the SDP exchange closes, both browsers know how to reach one another. An email, a chat message, any channel you prefer gets the blobs in place. No backend is involved after that single manual handoff.

When the dashboard shows more packets sent than received, that gap is real dropped traffic, not a simple display artifact. Packets go directly from browser to browser with no relay smoothing the count, so the metric reflects the true end-to-end delivery rate on your actual network path.

Live dashboard metrics and what they actually tell you

Opening the dashboard is where the manual handoff ends and machine precision takes over. Every 100 ms, each browser sends a small probe packet to the other. Current RTT shows the most recent round-trip. Average RTT shows the running window. Minimum and maximum show the extremes, giving you a concrete spread rather than a smoothed average that hides spikes.

Jitter sits right next to RTT for a reason. Two connections with the same average latency can feel completely different. A call with 30 ms average RTT and 2 ms jitter handles audio and video well; every packet arrives near its expected slot. The same 30 ms average with 20 ms jitter means packets arrive at unpredictable intervals, which forces the receiver to buffer more aggressively and introduces decoding gaps. The difference between a clear webcam and freeze frames is jitter efficiency in that connection.

Jitter instrumentation picks up the hard-to-see failure mode. A raw ping call reports a single average RTT and obscures the per-probe variance that makes jitter tracking meaningful. A TURN relay amortizes jitter by queuing packets at the relay’s own ingress buffer, which looks like flawless delivery to the receiver until you ask for a data path not forced through a relay.⁴ Measure the same path p2p and the relay-operated view diverges quickly.

Machine-to-machine transparency and what it eliminates

The tool uses RFC 3550’s definition of jitter, specified in the RTP standard that defines the exponential weighted moving average formula for measuring inter-arrival delay, as an exponential weighted moving average of inter-arrival timestamps rather than a simple standard deviation.⁶ EWMA gives recent samples more weight and surfaces a degradation spike immediately, whereas a standard deviation approach would dilute the spike across a longer window and let a real problem look like background variance. The RFC formula defines jitter incrementally as:

J(i) = J(i-1) + (|D(i-1,i)| - J(i-1)) / 16

where D is the difference between successive arrival and send-time pairs, and J is the running estimate of the deviation.

The sparkline paints red against the RTT accent line at the exact probe position where a simulated or real drop occurred. Setting the Simulated Loss slider to 3% produces visual markers indistinguishable from an actual 3% packet drop; structurally the same, not merely similar, because the synthetic dropout fires the same color trigger. Prior exercise with the slider teaches you what that red region means before it appears in production.

The other transparency increment is more practical. Latency and loss figures can be copied from the tool directly into a run-book or incident note. A desktop hogging its packet buffer or a router with thin QoS support does not conceal actual loss; the chart surfaces it regardless. The same draw appears whether it comes from a dropped probe on the wire or from the simulated slider, and both fire the same unambiguous red marker at that drop position on the sparkline.

Latency and jitter thresholds at a glance

Low jitter makes the whole metric favorable and high jitter makes it irredeemable in a gaming or VoIP session. The table below pairs practical service tiers with measurable latency and jitter bands; the latency bands align with VoIP planning guidance, while the jitter bands are operational targets rather than a hard ITU limit.⁷

Latency Range	Characterization	Jitter Band	Jitter Frame	What to Do
Below 50 ms	Excellent	Below 5 ms	Stable	No action needed; connection is fit for VoIP, gaming, screen-share
50–150 ms	Playable	5–30 ms	Occasional drops	Acceptable for moderate-resolution video; monitor audio for gaps; gaming is tolerable
Above 150 ms	Problematic	Above 30 ms	Constant buffering	Gaming thresholds are reached; screen share uses compress-and-frame-drop simulation; test whether the peer is behind a relay

Good RTT paired with terrible jitter signals a specific asymmetry. The forward and return latency may both read at 40 ms on a standard page, but if jitter is sitting at 25 ms, the one-way path introduces inconsistent delay on outbound and inbound probes at the same time. That combination usually points to ISP routing instability or a congested shared peering node rather than geographic distance. For peer-to-peer testing, high jitter alongside good RTT is the signal that a path is disqualified for time-sensitive use even though the raw latency number looks tolerable.

Diagnosing whether a path is asymmetric requires reading both the minimum and maximum RTT alongside the jitter value. If minimum RTT sits well below the 50 ms threshold but jitter is high, the outbound path is clean while the return path is unstable. A single clean direction does not qualify the path. A large gap between min and max RTT with no shared midway range signals an unbalanced route that should be tested more carefully with longer probes.

Symmetric NAT breaks direct connections: this is what that looks like on-screen

Symmetric NAT is a restrictive router behavior that enforces unique port mappings. For every unique destination, the router assigns an entirely separate outbound port. Consequently, a home router with a single external IP may map your browser to two different outbound ports when reaching two different peers; the remote peer’s STUN server then receives a different public port for each destination, and that prevents the direct-hole mapping that symmetric peers need.⁴ Without a TURN relay in the path, symmetric NAT blocks end-to-end connections from both directions.

Reading NAT failure messages before you retry

The p2p-tester distinguishes symmetric NAT failure from a simple timeout by reporting the final ICE Candidate Type. A result reading “relay” after a connection attempt means a TURN server was configured and ICE exhausted direct-host and server-reflexive candidates, so it fell through to that configured fallback. Without a TURN server in the configuration, the “relay” candidate type never appears, so the absence or presence of that candidate is diagnostic in itself: the tool will simply fail to connect rather than switch paths to a relay you do not have. STUN peers never share the same port mapping for different destinations; without a relay, the connection will time out when the router cannot map the incoming punch-through. When relay appears under a server-relay scenario, you know the gap is structural: the connection cannot tunnel through the router’s port mappings, and retrying the same offer will not change the outcome.

Symptoms and fixes when STUN cannot punch through

Symmetric NAT failure sits alongside reinforced routing blocks as a common source of direct-connection failure. Corporate networks frequently silently drop UDP traffic to any destination not on an approved list, which prevents STUN probes from reaching the public IP discovery step entirely. Carrier-grade NAT places many subscribers behind a single shared public IP and prevents direct inbound connections, so multiple users must route through a relay service to receive unsolicited inbound data.⁸ Multi-tenant residential connections share the same restriction as an oversubscribed wireless router. VPN offloading can also break STUN classification by presenting the VPN tunnel’s external IP rather than your base connection, which produces a relay candidate regardless of what your actual base NAT is. Corporate micro-segmentation services and some mobile operator firewalls introspect or sandbox UDP segments, meaning even a correctly classified open NAT can be rendered moot by a network policy layer.

Firewall config is the most common fix. Many vendor routers prioritize connection entries for inbound UDP, so a quick restart or disabling symmetric NAT handling in the advanced panel lets ICE renegotiate a mapping without manual changes. Modern browsers insert mDNS host candidates during ICE gathering to avoid exposing local IPs on the wire; regardless of network type these candidates rewrite the interface appearance and can mask addresses on overlapping subnets.¹ If the STUN probe still fails after a restart, confirm that the router’s WAN-to-LAN NAT table has not run out of sessions from another device. CapyToolkit’s approach reflects this zero-cloud philosophy: no remote relay stores or forwards traffic during the test, and CapyToolkit’s full collection of browser-based developer and network tools that require no account, no upload, and no server round-trips covers the same local-first philosophy across every tool in the suite.

The six-step working test walkthrough

Copy-paste sounds technical until you’ve run it once. Follow these six steps and the dashboard starts on both browsers.

1. Wait for the STUN probe to complete. Then copy the generated offer. Opening the second tab gives you the answer later.

2. Open two browser tabs to the same browser-based P2P connection tester that measures direct WebRTC latency and jitter without any relay server. In the first, click “Start Session.” The offer SDP appears in its own text area. Copy it into the other tab.

3. In the second tab, click “Join Session.” Paste the offer SDP into the join form and click “Generate Answer.” Copy the answer SDP that appears.

4. Back in the first tab, paste the answer and click “Connect.” The dashboard resolves and transitions to CONNECTED.

5. Check Current and Average RTT values as probes arrive: below 10 ms for same-subnet LAN, 50–150 ms for cross-region ISP peering, above that for wide-area routes.

6. Adjust the Simulated Loss and Artificial Latency sliders to test degraded conditions. The Simulated Loss slider drops packets at the send source; at 5%, it replicates a congested cellular link. Artificial Latency adds padding per probe to approximate a high-delay long-haul path.

When nothing connects and you are not sure why

Compare the p2p tool result against a server-based ping to pin down where the gap sits. If server ping looks healthy but the p2p session times out, the midpoint is blocking direct traffic; your ISP may route P2P traffic differently than it routes protocol-favored datacenter packets. A corporate firewall that allows TCP-based services while dropping UDP is the most common explanation in this failure class. Check whether anonymous-whitelist or ipset rules are active on your local gateway for the STUN server IP range.

A path that only succeeds when relayed is not a signal to retry the direct approach. It signals a hard routing block: your local network, or the remote peer’s, is structurally incapable of direct UDP exchange. Symmetric NAT and mandatory corporate port forests make that failure invariant across retries. A VPN tunnel can introduce the same effect if both peers are tunneled into a managed relay subnet that itself prevents direct UDP. Some overlays re-encapsulate WebRTC traffic and break end-to-end NAT traversal. Check the peer’s report or the dashboard readout before retrying to know which variant to diagnose.

The faster path also cannot tolerate asymmetric bandwidth ceilings. A gigabit ISP backhaul on one side meeting a Wi-Fi 4 ingress on the other caps the feasible throughput at the lower link’s ceiling. The dashboard surfaces that directly in the packet loss measure. Running a speed test from both directions before or during a test session gives you the bandwidth delta that explains whether instability traces to the p2p path itself, or just to one peer’s connection ceiling.

Sources

1. 1.

   W3C Web Real-Time Communications Working Group, “WebRTC: Real-Time Communication in Browsers,” w3.org, October 2024. https://www.w3.org/TR/2024/REC-webrtc-20241008/

2. 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://datatracker.ietf.org/doc/html/rfc8445

3. 3.

   E. Ivov, J. Uberti, and P. Saint-Andre, “Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol,” RFC 8838, IETF, January 2021. https://datatracker.ietf.org/doc/html/rfc8838

4. 4.

   R. Mahy, P. Matthews, and J. Rosenberg, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” RFC 5766, IETF, April 2010. https://www.rfc-editor.org/info/rfc5766/

5. 5.

   M. Petit-Huguenin, G. Salgueiro, J. Rosenberg, D. Wing, R. Mahy, and P. Matthews, “Session Traversal Utilities for NAT (STUN),” RFC 8489, IETF, February 2020. https://www.ietf.org/rfc/rfc8489.txt

6. 6.

   H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” RFC 3550, IETF, July 2003. https://www.rfc-editor.org/info/rfc3550/

7. 7.

   ITU-T, “G.114: One-way transmission time,” itu.int, May 2003. https://www.itu.int/rec/T-REC-G.114-200305-I/en

8. 8.

   M. Ford, M. Boucadair, A. Durand, P. Levis, and P. Roberts, “Issues with IP Address Sharing,” RFC 6269, IETF, June 2011. https://www.ietf.org/rfc/rfc6269.txt