Interactive diagnostic

WebRTC connection test

Verify a private browser-local peer connection and data-channel message before investigating real call routing or network policy.

Processed locally in this browser

Local peer connection

Verify the browser WebRTC data path

Two local browser peers are created and a small message crosses a data channel. The test uses no camera, microphone, STUN/TURN server, or public-IP discovery.

Browser-only loopbackNot a real call route or NAT-traversal test

Test guide

What this test proves—and what it cannot

The WebRTC test creates two peer connections within this browser and sends a known message across a local data channel. It verifies the core WebRTC engine without requesting media or contacting discovery servers, then clearly separates that result from real-world call routing.

Last reviewed: 2026-09-03

Signals measured

Whether RTCPeerConnection is exposed in the current context
Local offer, answer, ICE candidate, and session-description exchange
Opening a browser-local RTCDataChannel
Delivery of one known loopback message and total setup duration

How the test works

Both peers are created in the same page with an empty ICE-server list.
Offer, answer, and local candidates are exchanged directly in memory.
A small fixed text message is sent after the data channel opens.
Connections are closed after success, failure, or the bounded timeout.

Interpreting the results

SignalWhat it meansNext step

Local data channel passesThe browser completed a basic same-page WebRTC negotiation and message transfer.If calls fail, investigate permission, firewall, VPN, TURN, service status, and the target app.

API is unavailableThis browser or embedded context does not expose RTCPeerConnection.Open a current full browser over HTTPS and compare private or managed policies.

Negotiation times outThe local engine, candidate exchange, browser policy, extension, or context did not complete the bounded test.Retry once, then compare another current browser with extensions limited.

Measurement limits

No STUN or TURN server is contacted, so NAT traversal and relay availability are not tested.
No camera or microphone stream is created, so media permission, codec quality, and device capture are not tested.
Setup duration is a local scheduling sample, not internet latency or call-quality score.

Missing or privacy-reduced detail is not scored as a fault by itself.

Questions about this test

Does this reveal my public or local IP address?

The test does not use STUN/TURN and does not display or persist candidate addresses. Modern browsers may also obscure local host candidates.

Why can this pass while a video call still fails?

A real call adds permissions, devices, codecs, remote servers, NAT traversal, relays, firewall policy, bandwidth, and the service's own application logic.