host candidate
One of your own network interfaces. Browsers now hide these behind .local names so a web page cannot map your internal network.
Runs in your browser against two public STUN servers. No media is requested, so this never touches your microphone or camera.
The useful thing to know is whether your NAT gives the same external port to different destinations. If it does, peer-to-peer media usually connects directly. If every destination gets a different port, nothing can predict it and calls need a relay. Telling those apart requires two vantage points — one server can only tell you that UDP works at all.
One of your own network interfaces. Browsers now hide these behind .local names so a web page cannot map your internal network.
Server-reflexive: how a server on the internet sees you. Its presence proves outbound UDP works, which is the first thing to establish.
Media forwarded through a TURN server. We do not run one, so relay cannot be tested here — and we say so rather than reporting its absence as a fault.
Your NAT keeps one external port per internal socket regardless of destination. The best case: direct media, lower latency, no relay in the path.
Endpoint-independent mapping: both STUN servers reported the same external port, so a peer can be told where to send audio and it will arrive. Direct media will usually connect, which is the best outcome — no relay, lower latency, less to go wrong.
A different port per destination — usually called a symmetric NAT — means nothing outside can predict the port, so direct peer-to-peer media will often fail and calls need a TURN relay. Most business firewalls behave this way, and it is not a fault. What it does mean is that a relay is a requirement rather than a fallback, so the question to ask a VoIP provider is whether they operate TURN, and on which ports.
No external candidate at all means outbound UDP is being blocked. Calls will have to fall back to TCP or TLS relaying, which adds latency, and some systems will not work at all. This is the result worth acting on: it is usually a firewall policy, and usually one nobody intended to apply to voice.
A note on what this is not: it is not a WebRTC leak test. Those exist to warn VPN users that a browser may reveal their real address, and the mDNS obfuscation browsers now apply to local candidates has made most of that concern obsolete. If your srflx address differs from what you expect, that is worth a look — but this page is about whether calls will connect.
It means your NAT allocates a different external port for each destination, so an outside peer cannot be told in advance where to send media. It is not bad — most business firewalls work this way, and it is arguably more secure. It does mean calls need a TURN relay rather than connecting directly, so your VoIP provider has to operate one.
Browsers deliberately hide internal addresses behind mDNS names so a web page cannot enumerate your network. It is a privacy feature, it works as intended, and it does not affect calls — WebRTC resolves those names between the two peers.
No, and it is not a finding about your network. Relay candidates come from a TURN server, and we do not operate one, so there was never anything to find. If the result says you need a relay, ask your VoIP provider whether they run TURN — this page cannot tell you.
No. The test opens a data channel, which is enough to make the browser gather candidates, and never requests media. Nothing prompts for permission and nothing is recorded.
It matters if you intend to use a browser-based phone or a meeting tool, because both depend on it. Every current browser supports WebRTC, so a negative result here means an extension or a policy has disabled it — which is worth knowing before someone tries to take a call.