The dangerous implementation is not one that never works. It is one that works in a demo and loses its boundaries under real networks and real data volume. Symmetric mapping creates a different external port per destination. A STUN-derived port may not accept packets from a peer even though the candidate looks valid.
Network diagnostics separates observed facts from inference. Candidate type, selected route, and stage timing describe connectivity; complete IP addresses or one probe are unnecessary and insufficient evidence.
Engineering boundaries and tradeoffs
This capability crosses clients, networks, and servers, so a local optimization can create a system failure. Decisions must constrain both endpoints, persisted truth, and operating budgets together.
- Compare mappings across independent STUN servers as a signal, avoid fragile port prediction, and allow ready relay candidates after a bounded ICE check.
- Give state one owner, a version, and terminal states; callbacks may mutate only the version that created them.
- Retries need an idempotency key, backoff, and deadline; after the deadline create a new task instead of reviving old callbacks.
The delivery standard for Why Symmetric NAT Defeats Reusable STUN Mappings is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
How it fails in production
Production failures often appear when two individually valid actions overlap. Inspect stale messages, duplicate effects, exhausted resources, and mixed versions instead of patching only the current stack frame.
- Waiting for every direct timeout before TURN adds many seconds, while forcing relay from a NAT label can miss valid paths.
- Refresh and network change start two recovery paths, and duplicate side effects look like two genuine user actions.
- Ideal-size tests miss large files, long sessions, and concurrency that cross hidden limits and cause cascading failure.
Turn testing into a closed loop
A release gate combines deterministic regression, randomized timing, and real browser pairs. Preserve the seed and state trace from every failure as a permanent replay case.
- Measure checks, final paths, and serial-versus-parallel relay policy across endpoint-independent, address-dependent, and endpoint-dependent NATs.
- Race refresh, cancel, timeout, and remote completion in one scheduling window; assert one terminal state and one side effect.
- Cover direct, relayed, weak-network, background-tab, and mobile paths; do not rely on averages or one successful screenshot.
The release standard is practical: the normal path is fast, abnormal paths converge, recovery never overrides an explicit user decision, and operators can diagnose faults from limited, privacy-safe evidence.