Let's get you back online.

If the disconnects happen at a consistent interval (say, every 60 or 120 seconds), it's almost always network equipment - not the device:

• Firewalls, proxies, and intrusion-detection systems often terminate idle connections. Ask your IT team to allow persistent connections to *.viam.com.
• If your firewall performs SSL/TLS inspection, exempt *.viam.com and *.viam.cloud - the device uses certificate pinning, which inspection breaks.
• An IP address conflict (another device using the same static IP) causes the same symptom - your IT team can check for duplicates.
• Try a different switch port early - a failing port can take the device down where no device-side change helps.
• Designate an on-site contact who can check the status light, reseat the Ethernet, and power-cycle - an unnoticed drop can sit for weeks until someone requests footage.

The VMS discovers cameras on its local network automatically. If some or all are missing:

• Check the cameras are on the same subnet as the device - discovery is same-subnet only and doesn't cross VLANs or routed boundaries. Cross-subnet cameras need documented IPs and routing, or the device moved to a port on the camera network.
• Behind an Eagle Eye bridge, cameras are invisible to everything else until Eagle Eye support enables QL Stream (per-camera local RTSP on their recorder - their support does it in minutes).
• Analog cameras on coax behind a DVR will never be discovered - check whether the DVR itself exposes RTSP before troubleshooting anything else.
• Confirm RTSP streaming is enabled on each camera - it's often disabled by default, especially on Verkada (enable in Command) and Meraki MV (enable per camera in the dashboard).
• Verify the camera model actually supports RTSP. Battery-powered and consumer cameras (Ring, Arlo, Blink, Nest) do not - see the compatibility table.

This is almost always credentials or a stream limit:

• Double-check the RTSP username and password you shared with CompScience - the camera login is usually different from the NVR login, the mobile app login, and any cloud account.
• If the password contains special characters (!, @, #, *, ...), send it to us exactly as-is and flag it - special characters need careful handling in stream URLs.
• If credentials were recently rotated, send us the new ones so we can update the device remotely.
• Cameras wired directly into an NVR sometimes aren't visible on the network at all - your NVR may need to be set to expose RTSP streams to the LAN. We can walk your provider through it.
• NVRs often serve RTSP on a non-standard port - check the NVR's network settings for its RTSP port. It's frequently not the default 554, and it's never the web-interface port.
• Verkada cameras allow at most 2 concurrent RTSP streams, and their RTSP service starts on demand - a first connection attempt that fails and then succeeds on retry is normal.
• Meraki MV uses TCP port 9000 for RTSP rather than the standard 554 - make sure nothing on the LAN blocks it.
• Every stream failing auth right after an outage was fixed? Credentials often get rotated during the fix - re-confirm them before calling the site healthy.
• Single-vendor fleets often share one credential set, so rotating one camera's password breaks every user. Don't rotate - have IT create a dedicated VMS user scoped to our cameras.
• A mysteriously short camera list usually means the VMS user's security group is incomplete.
• Re-stream proxies rarely sit on 554: DW Spectrum defaults to 7001, Eagle Eye QL Stream is 8554 and local-only, UNV NVRs often use 9090, and UniFi Protect uses 7441 with a token generated in the Protect UI.
• Verkada's high-res endpoint can stream HEVC, which shows up as grey frames - fall back to the low-res H.264 endpoint.

If VLC on a laptop plays the stream but the device times out, the difference is who's asking - the two don't have the same network identity. Two causes, often together:

• Two IP ranges on one switch. Cameras on one range (192.168.0.x), the internet router on another (192.168.1.x), same physical wire. If the device only got an address on the router's range, it can't reach the cameras. We can dual-home the device remotely - just tell us both ranges.
• NVR IP allow-lists. Many recorders silently drop connections from any IP not on their allow-list: the NVR looks completely unreachable to the device while working fine for approved PCs. Have your NVR admin add the device's IP to the allow-list.

The device pulls multiple camera streams simultaneously, so local bandwidth matters more than internet speed:

• Confirm at least 100 Mbps of local network capacity between the device and the cameras.
• Check for the device or cameras sitting on older 10/100 switches or daisy-chained links.
• Check the negotiated link speed on the device's switch port - stuck at 10 Mbps on gigabit gear, and unfixed by cable swaps, points at the port or the switch itself.
• Set streams to 1080p or 2K - 4K overloads the connection, and a clean 720p analyzes better than an artifacted 1080p. Stream resolution is separate from local recording quality.
• On multi-day captures, 4K also saturates the device's storage - the symptom is reboot loops plus upload failures partway through. Dropping every stream to 1080p fixes it.

• Exports need at least 10 Mbps of internet upload. If your uplink is thinner, uploads will lag behind recording.
• Tell us your actual operating hours and we'll align both windows - record during business hours, upload after. The VMS runs whatever schedule fits your operation.
• Sites on a single thin link (say, one 10 Mbps line for the whole facility) can run a strict overnight-only window - uploads from 8pm to 5am and nothing during the day.

The device's management connection uses WebRTC. In locked-down networks:

• A TURN relay fallback keeps all traffic outbound even when direct WebRTC is blocked - no firewall changes needed in most cases.
• As a last resort, opening inbound port 8080 to the device restores management access.
• Telltale at strict sites: the device shows ONLINE but remote sessions hang forever - long-lived connections are being killed by an idle-timeout or inspection policy. Tell us if you see this.
• Forward proxies, air-gapped camera subnets, and strict egress filtering are workable but need engineering review - email us before install day so we can plan the approach.

On multi-site networks (MPLS, SD-WAN), the classic cause is the device pulling camera feeds from the wrong site - RTSP runs continuously, so cross-site feeds add sustained Mbps. The symptom: constant heavy download on the firewall plus a site-wide slowdown.

• Keep each device on the same gateway and local network as the cameras it pulls, so camera traffic never leaves the site.
• Double-check device-to-camera assignments after any renames or reconfiguration - swapped device names quietly sending one site's cameras to another site's device is exactly how this happens.
• If an inter-site link is congested anyway, ask us - we can cap the device's bandwidth or pin it to a backup link while the assignments get sorted.

The VMS is happy to move, but two things commonly break:

• New subnet: if the device no longer shares a subnet with the cameras, discovery and streaming stop until routing is configured.
• New firewall: re-confirm the outbound rules from the IT checklist on the new network.
• Power-cycle the device after any switch-port or VLAN move, even when the config looks right - stale switch state can block reachability that no device-side change fixes.

After a move, just plug it back in - power, then Ethernet - and it reconnects automatically once the network allows it.