Before shipping it, separate protocol facts, product promises, and operating cost. Mixing those layers produces confident but incorrect decisions. Each allocation generally consumes a relayed transport address, making the port range a hard capacity limit. Multiple public IPs expand combinations but need headroom.
TURN is a metered shared relay, not merely an ICE URL. Operate short-lived authorization, allocation concurrency, byte accounting, regional capacity, and abuse response while preserving UDP, TCP, and TLS reachability.
The parts that make the design practical
Start from facts the data and protocol can guarantee, then decide what the interface may promise. Each rule below needs an owner, a bound, and a compatibility policy rather than an oral convention from one review.
- Provision 1.5–2x peak allocation capacity, set min/max ports explicitly, open the same range at cloud and host layers, and monitor allocation failure plus utilization.
- Bound every input by size, count, and time, returning a stable actionable error code when a budget is exceeded.
- Treat cleanup as protocol behavior: timers, handles, queues, and temporary data must be safely releasable in every terminal state.
The delivery standard for Sizing the TURN Relay Port Range for Capacity and Firewalls 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.
Keep false assumptions out of production
Prioritize faults that silently preserve false facts: the interface looks recovered while a queue, permission, or counter has diverged. The defect often appears only on the next action.
- Opening only 3478 lets authentication succeed while relay traffic is dropped, and a narrow range fails with allocation errors only at peak.
- A stale response arriving after a new task can overwrite healthy state or restart cancelled work without version fencing.
- Ideal-size tests miss large files, long sessions, and concurrency that cross hidden limits and cause cascading failure.
What the release gate should inspect
Observe both endpoints, persisted records, and operational signals during verification. One button state or one successful response cannot prove the complete loop.
- Fill 50, 80, 95, and 100 percent of ports under dual stack and restart; observe allocation success, alert thresholds, reclamation, and errors.
- Run one hundred start, fail, retry, and cancel cycles; handles, listeners, queues, and temporary data must return to baseline.
- Use fault injection to prove alerts precede user reports and operators can locate the failing phase from bounded evidence.
The result must be correct, recoverable, and explainable. If any part depends on refreshing the page or an engineer guessing, the protocol loop remains incomplete.