When a fleet manager clicks "Live View" on their dashcam dashboard and the video appears — sometimes instantly, sometimes after 6 to 15 seconds — they are seeing the result of a protocol chain that most of them have never thought about. Understanding that chain explains why data sovereignty for dashcam footage is harder to achieve than it sounds.
What JT/T 1078 is
JT/T 1078 is a Chinese national standard for vehicle video surveillance, published by the Ministry of Transport of the People's Republic of China. It defines how dashcam hardware encodes and transmits video and audio over a TCP connection. Virtually all AI dashcams sold in India — Hikvision, Dahua, Gosuncn, Queclink, and their white-label derivatives — implement JT/T 1078 as the transport protocol for live video.
The standard itself is publicly available and technically open. The problem is implementation complexity. Parsing JT/T 1078 correctly requires handling custom binary framing, managing device registration handshakes, dealing with stream multiplexing across channels, and converting the H.264/H.265 output to something a web browser can display.
Why most vendors use an OEM cloud API instead
Writing a JT/T 1078 parser is significant engineering work. Most Indian telematics vendors are integrators — they take Chinese dashcam hardware and build a dashboard on top of it. The path of least resistance is to use the device manufacturer's cloud SDK, which handles the protocol parsing on the OEM's own servers and exposes a simpler API.
The consequence is that the live video stream goes: dashcam device → OEM TCP server (typically in Shenzhen, Singapore, or Hong Kong) → OEM SDK API → Indian vendor's application server → browser. The Indian vendor's dashboard is genuinely Indian-built. The video pipeline it sits on top of is not.
The Indian vendor is not hiding anything, in most cases — they simply have not implemented the protocol themselves and are not aware of what the OEM retains. The OEM SDK is a black box to them.
The latency consequence
The OEM API round-trip — India → Shenzhen → India — introduces 6 to 15 seconds of latency on a good day. For a fleet manager watching a live feed to verify a driver's behaviour or respond to an SOS event, this is operationally significant. Eight seconds is the difference between a preventable incident and an after-the-fact report.
How a direct pipeline works
When the JT/T 1078 parser runs on your own infrastructure, the video path is: dashcam device → your TCP server (parsing JT/T 1078 directly) → media relay → WebRTC → browser. No foreign hop. Latency drops to under 2 seconds because the video is being decoded on the server closest to the client and delivered via WebRTC, which is designed for low-latency real-time media.
- ▸Device connects to your server via TCP on port 7200 (JT/T 1078 standard port)
- ▸Server parses the binary framing, extracts H.264/H.265 NAL units
- ▸Video is pushed into a media relay (RTSP/SRT internally)
- ▸Browser receives a WebRTC stream — sub-2 second latency, no plugin required
What this means for data sovereignty
If you implement the protocol yourself, you choose where the TCP server runs. It can run on Veytra's managed Indian servers, your own AWS India region, or your own on-premise infrastructure. The dashcam device does not care — it makes a TCP connection to whatever IP address you configure.
This is the architectural difference between a compliance posture that is genuine and one that is aspirational. A policy document saying "we process data in India" means nothing if the live video stream is going through a Shenzhen API to get decoded. The only way to know for certain is to own the parser.