Definition
GB28181 ("Technical Requirements for Information Transmission, Exchange, and Control of Security Video Surveillance Networking Systems") is China's public security video surveillance national standard, specifying signaling (SIP) and media (RTP) interactions between platforms, devices, and clients. Video edge analysis devices support GB28181 cascading access to public security video surveillance platforms, enabling integrated access with RTSP and ONVIF cameras.
Protocol Architecture
GB28181 is based on SIP signaling and RTP/RTCP media transmission. Signaling includes device registration, directory query, real-time on-demand, historical playback, PTZ control, subscription notifications, etc. Media supports PS encapsulation, video encoding in H.264/H.265, and audio in G.711/AAC. UDP/TCP transmission is supported, capable of NAT traversal. Platform-to-device and platform-to-platform cascading is possible, enabling multi-level networking. Device codes, platform codes, and administrative divisions must comply with national standard coding specifications.
Use Cases
Public safety video monitoring platforms such as those for public security, traffic, urban management, and emergency response use GB28181 to achieve device access and platform cascading. Front-end cameras, NVRs, and video gateways register to the platform as SIP clients; the platform acts as a SIP server to manage devices and distribute video. Video edge analysis devices (such as AI boxes) can pull RTSP or ONVIF camera videos, and after analysis, report them to the public security platform in GB28181 format, achieving unified access for intelligent analysis results and original video.
Comparison with ONVIF
ONVIF is an international network video interface standard, focusing on device discovery, configuration, and streaming; GB28181 is a Chinese national standard, focusing on platform cascading and public security networking. Most cameras support ONVIF; public security platforms require GB28181. Video gateways can convert ONVIF/RTSP devices to GB28181 devices to access national standard platforms.
National IDs and catalog subscription
Registration, the catalog, live invite, playback, and pan-tilt all travel as signaling. Picture and sound travel on a separate media path. The length and the meaning of each segment of the device ID, the platform ID, and the channel ID have to follow the coding rules of the platform being joined. If an ID is duplicated, the device that registers later pushes the earlier one off, or the platform refuses the new registration. The catalog is not a static table. After the platform subscribes, the device sends a notification when a channel changes. If channel online status is placed only in the first registration and never notified again, the platform keeps showing the old state. A live invite needs signaling to succeed first, and then media sent to the address and port that were negotiated. Successful signaling does not mean a picture is already on the screen.
The conditions are that both sides agree in advance on identity, password, heartbeat period, and how media is encapsulated. Media is often a program stream, and the coding format has to be one the platform can decode. Transport may be datagrams or a byte stream. A byte stream has to handle frames stuck together. Datagrams have to handle reordering and loss. In a cascade, the lower platform is a device toward the upper platform, and channel numbers have to be mapped again under the rules the upper platform assigned. The lower platform's original numbers cannot be sent up unchanged. Too large a clock offset makes a registration or a signaling message look like a replay and get dropped.
Registration keepalive and media ports
If the heartbeat stops and the registration is not removed, the platform still shows the device online, and nobody is listening on the media port when an invite arrives. A wrong password or domain is a refused registration, and on site it is easy to call that a network failure. A device behind address translation that changes only the signaling port, and does not map the media port, has normal signaling and a black picture. A multi-channel device that registers only the device ID, and prepares no ID for each channel, has an empty catalog, and the platform cannot invite one channel.
Playback and live invite are different sessions. Reusing the live stream's port for playback mixes the two pictures. Pan-tilt control depends on the channel number. A mapping that is off by one moves the neighboring camera. If the time burned into the picture comes from the encoder's local clock, and signaling time comes from the platform, a recording search will not match the time on the picture. A gateway bringing in another video interface has to build a catalog that follows the rules. Do not assume an external name can be used as the ID. After a disconnect, register again and refresh the catalog. Restoring only the media socket leaves channel state on the platform at the previous result.
Playback sessions and where the clock comes from
A live invite and a historical playback are two sessions. Neither the port nor the identity can be reused. After they are reused the two pictures mix, and the platform still shows the invite as successful. The time range of playback follows the device's recording index. If the index time and the time overlaid on the picture come from different clocks, the clip that was found will not match the picture. Set the clock when the system is idle. Do not write a time jump into a file that is being recorded during an invite.
Catalog notifications have to include a channel going online and offline. Reporting status only at registration means a later unplug is never updated. Keep a cascade map of the lower platform's original number against the number the upper platform assigned, so it is possible to trace which camera it was. A wrong password and a network that is down have to be separate lines in the log. When the media port is not mapped, signaling is completely normal and the picture is black. Look at the address negotiation, not at another registration restart. After the link returns, register again and push the catalog. Restoring the old media socket is not enough.
The channel ID has to be the same value in the platform, in the catalog, and in the media negotiation. If the catalog uses a new ID and the invite still uses the old one, signaling finds the wrong channel or fails outright. When one channel of a multi-channel device goes offline, update only that channel. Do not refresh the whole device registration as entirely offline. Give the start and end of a recording search a time zone, or an explicit local time, so daylight-saving time or a clock set does not shift the result by an hour. Confirm the media encapsulation and the coding format in the invite answer. A gateway should not start pushing a stream before that confirmation. The heartbeat period should be shorter than the hold time of the network address translation, or the mapping disappears between two heartbeats. When a registration is refused, record the reason phrase. A network that is down and an authentication failure are handled in completely different ways.