Verkada RTSP, ONVIF and Command Connector: Choose the Right Connection

Find the right troubleshooting path

Use these observations to narrow the cause; they are not a definitive diagnosis.

Work through the checks

1. 1

   Write down the source, destination and required features

   Identify camera manufacturer/model, the application that should display video and whether you need live video, history, audio, analytics or PTZ control. Confirm each required capability in the relevant compatibility documentation. Do not infer that a working live image guarantees every feature or recording workflow.

   Reference: Prepare for a Command Connector Deployment (opens in a new tab)
2. 2

   For video leaving Verkada, check RTSP eligibility

   Use the current per-model RTSP table. The reference excludes CR63-E and CR63-TE remote cameras and limits supported cameras to two concurrent RTSP streams. The stream uses local RFC 1918 private addressing; this is not a public cloud playback link.

   Reference: Low-Latency RTSP Streaming (opens in a new tab)
3. 3

   Configure a narrowly scoped RTSP test

   A Site Admin can open the camera’s Settings > Device and enable RTSP with dedicated credentials. Copy the generated SQ or HQ URL and replace its password placeholder privately in the approved client. RTSP traffic is unencrypted: restrict client access and isolate the path. Do not port-forward 8554 to the internet.

   Reference: Low-Latency RTSP Streaming (opens in a new tab)
4. 4

   For cameras entering Command, plan the Connector deployment

   Inventory each non-Verkada model, firmware, stream count and credentials. Consult the hardware compatibility list and confirm the applicable ONVIF Profile S or RTSP path. Size the Connector for resolution, codec, retention and channels, including licensing per video stream. Check cameras hidden behind an NVR’s internal switch before assuming they are reachable.

   Reference: Prepare for a Command Connector Deployment (opens in a new tab)
5. 5

   Prepare a stable camera-to-Connector path

   Use the same LAN, stable camera addresses through static configuration or DHCP reservations, and the model’s required local ports. Dynamic NAT or L3 translation between the devices is unsupported. The onboarding reference distinguishes ONVIF web access and RTSP access; do not copy outbound Verkada port 8554 into a third-party-camera rule without checking that camera.

   Reference: Add a non-Verkada camera to a Command Connector (opens in a new tab)
6. 6

   Add one representative channel and verify it

   In Command, open Devices, select the Connector and use Connected Channels > Add Cameras. Follow the documented discovery, manual-IP or CSV flow for the selected camera type. Test one representative model before bulk import. Check the applicable codec, resolution and frame settings; do not infer that an ONVIF logo guarantees every model/firmware combination.

   Reference: Add a non-Verkada camera to a Command Connector (opens in a new tab)
7. 7

   Troubleshoot the path that actually failed

   For a non-Verkada camera, run the Connector’s Connectivity Test with that camera’s IP and relevant port. A successful port test is not proof of correct credentials or a decodable stream. Compare live video and recorded history separately, then check the required features. Preserve the exact error and test configuration for support.

   Reference: Troubleshooting a Command Connector (opens in a new tab)

Verify the result

For outbound RTSP, verify the authorized client can play the expected stream and that unrelated clients have no access. For Connector ingestion, verify each channel’s live view, new recorded history and the features in the acceptance list. Document the stream direction, model, codec and software versions.

If the issue remains

Provide the two endpoints, integration direction, camera firmware, Connector model if used, codec, ports tested and exact error. Redact passwords from RTSP URLs and diagnostic screenshots. Recheck compatibility before expanding a pilot to the rest of the site.