WebRTC connectivity test
Published
Find out whether this network lets your browser make direct WebRTC connections. The test collects the connection candidates your browser can offer, shows their type and timing, and explains the verdict. Your addresses are displayed here and are never sent to ChatLite.
- Host candidates
- —
- Server-reflexive (srflx)
- —
- Relay
- —
- First srflx after
- —
- Gathering time
- —
| Type | Protocol | Address | Port | Found after |
|---|
Addresses are shown only on this screen. This page sends nothing to ChatLite. To learn your public address your browser sends STUN requests to Google's public STUN servers, as every WebRTC call does.
What the test does
A WebRTC connection between two browsers starts with a search for possible network paths. Each possible path is called an ICE candidate. This test starts that search in your browser, using the same three public STUN servers that ChatLite uses, and watches which candidates appear and how quickly. It then compares what it saw with the patterns that usually let a direct connection work or fail. No call is made and no other person takes part, so the result describes your side of the connection only.
How to read the results
Host candidates
A host candidate is an address on your own device or local network, such as a Wi-Fi address. Browsers often replace the real address with a random name ending in .local, which only computers on the same network can resolve. That protects your privacy and is not a fault. Host candidates are enough for two devices on the same network, but not for two devices on different networks.
Server-reflexive (srflx) candidates
A srflx candidate is your public address as a STUN server sees it, that is, the address and port your router assigned to your traffic. This is the candidate that lets someone outside your network reach you. If you have at least one, STUN works and UDP gets out. The test also compares the public ports reported by the different STUN servers. When they match, your router uses the same public port whoever you talk to, which is the friendly case. When they differ, the router picks a new port per destination, which is harder for a direct connection.
Relay candidates
A relay candidate is an address on a TURN server that forwards traffic when no direct path works. This test deliberately does not use a TURN server, so the relay count should be zero. A relay is the safety net for strict networks, but it costs bandwidth for whoever runs it, which is why many free services do not offer one for everybody, and ChatLite does not guarantee a relay will be available.
Timing
Most networks answer the first STUN request in well under a second. If the first srflx candidate arrives after several seconds, or the test stops at the time limit, packets are being dropped or delayed. That points to a congested connection, a firewall that inspects traffic or a VPN that adds distance.
The verdict
The verdict is a judgement from your side only. A good result does not promise that every call connects, because the other person's network matters as much as yours. A poor result does not mean calls are impossible; it means they may depend on a relay server.
What to do about a poor result
- Turn off a VPN or proxy and run the test again. Many VPNs force traffic through a server in another country and change which candidates appear.
- Try another network, such as a phone hotspot. If the result is good there, your first network blocks or restricts UDP. The article on video calls at work or school explains what to ask your network administrator.
- Check browser extensions that limit WebRTC. Some privacy extensions hide candidates or force the connection through a proxy; they are the usual reason for a result with no candidates.
- Look for a browser or system policy. On managed computers an administrator may switch WebRTC off.
- Restart the router. Rarely, a router that has been up for a long time handles many UDP mappings badly.
Browser differences
All current desktop and mobile browsers support the calls this test uses, but they differ in what they show. Many current browsers hide local addresses behind .local names. Some browsers list the STUN server that produced a candidate and some do not, and the error details for failed STUN requests also vary. Firefox in a strict privacy mode, and some privacy-focused browsers, may restrict WebRTC and show few or no candidates. If your result differs between browsers on the same computer, the browser rather than the network is the cause.
Privacy: where your addresses go
The page makes no web request of its own and has no code that stores or transmits a candidate. It does ask your browser to talk to STUN servers, because that is the only way to learn a public address. Those servers belong to Google and see the request from your network just as they do for any WebRTC call. ChatLite's servers see nothing from this page. The table of addresses exists only in the open tab; the checkbox hides most of each address so you can take a screenshot to ask for help, and the copy button builds a summary that leaves the addresses out.
Frequently asked questions
Is my IP address sent to ChatLite?
No. The addresses are displayed on your screen and nothing is sent to ChatLite. Your browser contacts Google's public STUN servers, which is what WebRTC needs in order to learn a public address.
Why are there zero relay candidates?
Because the test does not use a TURN server. Relay candidates exist only when a TURN server is configured and reachable.
The result is good, but my call failed. Why?
A call needs a path between both networks. The other person's network, a firewall in between, or a camera problem can still prevent it. Try the camera and microphone test too.
Is it safe to show my addresses to a support person?
Public and local addresses reveal roughly where you are and how your network is laid out, so share them only with someone you trust. The mask option and the summary button are there for that reason.
References
Official documentation used to check this article. Pages are maintained by their owners and may change.
Reviewed against ChatLite's current behavior on .