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 Stream

  • 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


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 browser

Example of a local stream on 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. 

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 computer, 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. 

Example DNS lookup for a camera:

$ nslookup 350611fe-f1f4-4634-b0ef-62e015d1701d.camera.verkada-lan.com
Non-authoritative answer:
Name: 350611fe-f1f4-4634-b0ef-62e015d1701d.camera.verkada-lan.com

Private IP of the camera matches 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 SD 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:

Did this answer your question?