Local streaming is where the feed from the camera is forwarded directly to the accessing device, rather than the stream being accessed from the cloud. This feature reduces the amount of traffic sent and received from the internet. When viewing a camera’s stream, the camera will automatically attempt to transition to local stream mode.

Requirements for Local Streaming

  • Accessing device must be able to reach the private IP of the camera

  • TCP Port 4100 needs to be open - bi-directionally between client and camera

  • No proxies between client and camera

  • Whitelist the following domains

*.camera.verkada-lan.com
update.control.verkada.com
api.control.verkada.com
relay.control.verkada.com
index.control.verkada.com
firmware.control.verkada.com

How Local Streaming Works

  1. The camera’s DNS record needs to be registered

  2. Command instructs the computer to attempt to establish a local stream with the camera

  3. The computer requests the camera’s DNS record

  4. The computer establishes a secure connection with the camera

  5. The camera’s feed is sent directly to the computer

Example of a local stream on a browser

Example of a local stream on the Verkada Command App

Example of a remote stream on Verkada Command App

Process Breakdown

The camera’s DNS record is Registered

When the camera connects to Verkada Command, it shares its metadata including its private IPv4 address. Verkada uses this data to provision a public type A DNS record with the private IP address of the camera. Local DNS servers can now resolve requests for the Fully Qualified Domain Name (FQDN) of the camera. This DNS record is utilized for local streaming. 

Acquiring a camera's FQDN

  1. Go to cameras live-stream

  2. Right-click anywhere and click Inspect and locate the network tab

  3. Filter results by the name of "ping" and refresh the page

  4. The ping traffic will contain the FQDN of the camera you are looking at

Process for Transitioning to Local Streaming

When the camera’s live stream is accessed, the computer will try to change to local streaming. If the private IP address of the camera is reachable from the device, as well as the proper domains are allowed on the network, the computer will establish an HTTPS connection with the camera to directly get the live feed.

1. When a camera feed is accessed, Command will direct the computer to establish a connection to the FQDN of the camera.

2. The accessing device will send out a standard DNS request (UDP port 53) for the FQDN of the camera.

3. DNS resolves the FQDN to provide the private IP address of the camera to the accessing device.

$nslookup nslookup f6a11892a0028432434c8d15f43edf5f.19.camera.verkada-lan.com                       
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: f6a11892a0028432434c8d15f43edf5f.19.camera.verkada-lan.com
Address: 192.168.1.101

The private IP of the camera matches the settings from Verkada command:

4. The device attempts to establish an HTTPS session over port 4100. If the device cannot reach the private IP of the camera, the process terminates here and the stream does not transition to local. 

If the private IP of the camera is reachable, the TCP session is initiated. The SSL handshake occurs (TLS 1.2) and the HTTPS session is established. This ensures traffic is encrypted and secure. From this connection, the SQ live feed of the camera will be accessed.

Browser display of request on port 4100:

Packet Capture showing TCP handshake for the camera’s private IP on port 4100:

TLS Key Exchange showing the publicly signed certificate presented by the camera:

5. Once the secure connection is established, the video is sent from the camera to the client:


Visit Training Center for bite-sized video tutorials on how to accomplish role-based tasks in Command.

Did this answer your question?