Local streaming is where the feed from a Verkada 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 automatically attempts to transition to local stream mode.
Requirements for local streaming
The accessing device must be able to reach the camera's private IP.
Transport Control Protocol (TCP) Port 4100 must be open—bidirectionally, between the client and the camera.
No proxies can be present between the client and the camera.
See Required Network Settings for Cameras for allowlisted domains.
How local streaming works
The camera’s domain name system (DNS) record needs to be registered.
Verkada 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.
Step 1: Camera’s DNS record is registered
When the camera connects to 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.
Get a camera's FQDN
In Verkada Command, go to All Products > Cameras > camera's live stream.
Right-click anywhere, click Inspect and locate the Network tab.
Filter results with
pingand refresh the page.The ping traffic contains the FQDN of the camera you are viewing.
Example: Get a camera's FQDN
Step 2: Transition to local streaming
When the camera’s live stream is accessed, the computer tries to change to local streaming. If the private IP address of the camera is reachable from the device and the proper domains are allowed on the network, the computer establishes an HTTPS connection with the camera to directly get the live feed.
Step 3: Computer requests the camera’s DNS record
When a camera feed is accessed, Command directs the computer to establish a connection to the FQDN of the camera.
The accessing device sends out a standard DNS request (UDP port 53) for the FQDN of the camera.
DNS resolves the FQDN to provide the private IP address of the camera to the accessing device.
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.
The private IP of the camera matches these settings from Command:
Step 4: Computer establishes a secure connection with the camera
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 is 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:
Step 5: Camera’s feed is sent directly to the computer
Once the secure connection is established, the camera sends the video to the client:
Example views of how local stream works
Below are examples of 3 views of how local stream works: local (browser), local (Command), and remote (Command):
View | Example |
Local stream on a browser |  |
Local stream on Command |  |
Remote stream on Command |  |
Learn more
Visit the Verkada Training Center for bite-sized video tutorials on how to accomplish role-based tasks in Command
Need more help? Contact Verkada Support