Network Preflight for a Live 4All Event
Validate DNS, HTTPS, secure WebSockets, latency, loss, bandwidth, proxies, and backup connectivity.
Written By 4ALL.LIVE
Last updated About 1 month ago
Prove the venue network can sustain all operator, caption, translation, ASL, viewer, and desktop output paths.
Best for: Network engineers, production IT, and lead operators.
Before you start
Network/security changes require authorization from the venue or organization.
- Use a non-production reproduction when possible.
- Record current configuration before changes.
- Keep an independent confidence monitor and fallback.
- Inventory operator, interpreter, desktop app, viewer, and receiver locations.
- Estimate concurrent audio/video/viewer bandwidth plus headroom.
- Know proxy, SSL inspection, captive portal, VLAN, and firewall ownership.
Step by step
- Use wired Ethernet for production sources and validate a physically independent backup.
- Confirm system DNS and HTTPS access to the 4All application, help/status, authentication, assets, and approved provider endpoints.
- Run 4All Preflight and require the Transcript v3 secure WebSocket hello/ping/pong check to pass.
- Test remote-control, display, ASL/LiveKit, translation/STT provider, XPression, and Encoder paths actually used.
- Measure sustained upload/download, round-trip time, jitter, and packet loss under realistic venue load.
- Verify proxies and TLS inspection preserve long-lived wss:// connections and do not rewrite media traffic.
- Document allowed outbound TCP 443 and every local/LAN protocol port for desktop integrations; SRT/RIST normally use agreed UDP ports.
- Fail over to backup connectivity in rehearsal and verify recovery order.
What success looks like: Every required production path passes under load with a tested backup and named network owner.
Check your setup
- Preflight realtime WebSocket passes.
- No captive portal/idle timeout appears.
- Bandwidth headroom remains.
- Receiver-side monitoring survives the planned topology.
Troubleshooting
- HTTPS works/WSS fails: inspect proxy/firewall idle timeout and upgrade handling.
- High jitter/loss: use wired path or engineered contribution protocol.
- Works on hotspot: venue network policy is likely the cause.
- Local desktop port blocked: create least-scope host/firewall rule.
Security and operational notes
Important: Do not publish a universal allow-list without confirming the current deployment and providers. Validate exact production endpoints with 4All support/IT.