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 the client and the camera
No proxies between the client and the 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
The camera’s DNS record needs to be registered
Command instructs the computer to attempt to establish a local stream with the camera
The computer requests the camera’s DNS record
The computer establishes a secure connection with the camera
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
Go to cameras live-stream
Right-click anywhere and click Inspect and locate the network tab
Filter results by the name of "ping" and refresh the page
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.