Test Devices — Network Requirements
Live phone viewing in Test Devices uses two separate network paths. Understanding the split is the key to getting it working across firewalls and VLANs — and to diagnosing the single most common symptom, a console that sits on "Connecting…" forever.
The two paths
| Path | Carries | Direction | Transport | Endpoint |
|---|---|---|---|---|
| Control plane | The web UI, login, the device list, remote input, test results, and the call setup ("signalling") for a live view | Browser → OmniWeb server | TCP 443 (HTTPS) | The OmniWeb server |
| Media plane | The live screen video itself | Browser ⇄ agent host (the bench the phone is plugged into) | UDP (WebRTC) | The agent host, not the server |
The crucial point: the live video does not flow through the OmniWeb server. Once the server has brokered the connection, the video streams directly between the operator's browser and the agent host over UDP. A network that allows the browser to reach the server but not the agent host will load the UI, show the device list, and then hang on "Connecting…".
Why the media path is direct
Live screen video is sent peer-to-peer with WebRTC over UDP so it survives the lossy, high-latency links typical of remote cell sites far better than relaying it through a central server over TCP. The trade-off is that the operator's browser needs a direct UDP path to the agent host — there is no media relay in the middle to fall back on.
Firewall requirements
For an operator to view phones at a site, both paths must be permitted from the operator's network to the relevant hosts.
Control plane (usually already open)
| Field | Value |
|---|---|
| Action | Permit (stateful) |
| Protocol | TCP |
| Source | Operator / client VLAN(s) |
| Destination | OmniWeb server |
| Destination port | 443 |
If the OmniWeb UI loads at all, this path is already open — no change needed.
Media plane (the one that's usually missing)
| Field | Value |
|---|---|
| Action | Permit (stateful — so return video is allowed automatically) |
| Protocol | UDP |
| Source | Operator / client VLAN(s) — where browsers run |
| Destination | The device-bench host subnet (the agent hosts), e.g. 10.0.20.0/24 |
| Destination ports | 32768–60999 (the default Linux ephemeral range the agent draws media ports from) |
The browser always initiates the media connection, so a stateful permit on client → agent host UDP also allows the agent's return video automatically. No STUN/TURN or other ports are involved.
Do not change port 443 for this. Signalling already rides the control plane; only the UDP media path to the agent hosts needs opening.
Recommended: pin the media port range
Opening the whole ephemeral range (32768–60999) is broad. The agent can instead be configured to draw its media ports from a small fixed range, shrinking the firewall rule to a tidy block:
| Field | Value |
|---|---|
| Action | Permit (stateful) |
| Protocol | UDP |
| Source | Operator / client VLAN(s) |
| Destination | Device-bench host subnet |
| Destination ports | 50000–50100 (pinned range) |
This is the preferred form to hand a network team — 100 ports to one subnet is far easier to approve and audit than the full ephemeral range. The pinned range is set on the agent host; coordinate the exact range with whoever maintains the benches so the firewall rule and the agent configuration match.
Recognising the problem
Symptom: the device console opens, but the screen never appears — it stays on "Connecting…" indefinitely. Everything else works: the fleet list, device details, even remote input setup.
This is almost always the media-plane UDP path being blocked. It is not a TLS/certificate problem and not an MTU problem:
| Suspected cause | Why it's not this | What you'd actually see if it were |
|---|---|---|
| SSL / certificate | The UI, login, device list and signalling all succeed over HTTPS — TLS is clearly working | The page itself would fail to load, or show a certificate warning |
| MTU / fragmentation | MTU only matters once video packets flow; here no video packets ever arrive | Video would connect, then stall or tear — not sit on "Connecting…" |
| Agent / phone down | The device shows online in the fleet with live battery/operator data | The device would be missing from the fleet, or marked offline |
| UDP path blocked ✓ | The browser can reach the server (UI loads) but not the agent host over UDP | Permanent "Connecting…" — exactly this symptom |
A useful tell: the device tile shows the phone as online (so the agent and phone are healthy and the server can see them), yet the live view alone won't start. That combination points squarely at the media-plane firewall path.
Confirming the fix
After the firewall rule is applied, re-open the device console. If the screen appears within a few seconds and the network-quality badge (top-right of the live view) goes green, the media path is working. The badge's stream stats (resolution, FPS, bitrate, packet-loss %, jitter, RTT) confirm video is flowing end-to-end.
If it still hangs, verify with whoever maintains the benches that the firewall rule's destination subnet and ports match the agent hosts and their configured media-port range, and that the rule is applied to the operator's actual source VLAN (a laptop on guest Wi-Fi is a different source than the corporate LAN).
Multiple operator locations
Each operator network that needs to view phones must have the media-plane rule for its own source VLAN. The rule is per source subnet → bench subnet, so adding a new office, VPN pool, or site means adding its subnet as an additional Source on the same UDP permit. Sites whose operators only ever view phones from the bench LAN itself need no inter-VLAN rule at all.