What a binding response tells you
STUN can let a client learn the mapped address that a server observes and supports connectivity checks within mechanisms such as ICE. It is a tool used by NAT traversal systems, not a complete NAT traversal solution on its own. A successful binding response means the client exchanged STUN traffic with that server. It does not guarantee that another peer can send media to the learned address through the same NAT and firewall policy.
Common misinterpretations
A public-looking server-reflexive candidate does not mean a public port is universally reachable. NAT mapping and filtering behavior can depend on the destination. A separate TURN relay may still be needed when direct candidate pairs cannot connect. Do not infer the active media route from a configured STUN URL. The application may select a host, server-reflexive or relay pair. Use actual selected-pair evidence and byte counters to determine what happened on this call.
A bounded investigation
Check whether candidate gathering produces the expected result, whether the candidate reaches the peer and whether checks on the resulting pairs succeed. Repeat on a second network without changing the application version to isolate network dependence. If STUN is reachable but calls fail only on restrictive networks, inspect relay availability rather than repeatedly swapping public STUN servers. Keep the tested server, transport, observed address family and time in the support record. A repeatable observation makes the next investigation useful; a screenshot saying only that STUN is configured does not.
Watch the explanation
Tsahi Levent-Levi and Philipp Hancke connect host, server-reflexive and relay candidates to the browser events that expose them. The narrated example distinguishes gathering from signaling.
Read applicability and editorial notes →Watch this video here
A 2025 browser API walkthrough. Candidate exposure, timings and mDNS behavior depend on browser and permissions. Review used the available transcript and primary references; audio and screen readability remain unverified.
The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.