GB/T 28181 video surveillance networking

GB/T 28181 includes registration, signalling and media exchange. Check the edition, device roles and supported flows for each side of the integration.

Overview#

GB/T 28181 is China's national interoperability framework for networking video surveillance systems. It defines a SIP domain control plane for registration, discovery, catalog exchange, session establishment, events, and related management, together with media carriage conventions. It is a different interoperability family from ONVIF: a device or platform supporting one doesn't thereby conform to the other.

Standards status#

Status is verified from China's national standard records as at 25 August 2026.

GB and GB/T have different regulatory meaning: GB identifies a mandatory national standard, while GB/T identifies a recommended national standard. Legal applicability, transition rules, sector rules, and certification obligations require competent local interpretation.

Architecture and roles#

front-end device / lower platform
        │ register, keepalive, catalog, events, control signaling
        ▼
SIP server and video-surveillance platform
        │ routing, federation, resource and policy context
        ▼
peer or upper-level platform

negotiated media source  ───── RTP/media path ─────>  media receiver

Common roles include front end devices, SIP servers, media servers, lower and upper level platforms, and clients. A product can combine several roles. Record each role separately because registration, catalog ownership, signalling routing, media origination, recording, and authorisation can be owned by different components.

GB/T 28181 identifiers participate in a hierarchical administrative/domain model. They are protocol routing and resource identifiers, not cryptographic proof of a device, organization, location, or operator. Bind every accepted identifier to authenticated peer configuration and an owned inventory.

Control plane model#

The protocol uses SIP mechanisms for session and message exchange, with GB/T 28181 defined bodies, identifiers, and procedures. Typical functions include:

• registration and expiry management;
• keepalive and online/offline supervision;
• device and resource catalog query/notification;
• live view and playback session establishment;
• event and alarm notification;
• device information and status queries;
• recording search and retrieval coordination;
• control requests for supported devices and resources;
• platform cascade and resource sharing.

SIP transaction success proves only the corresponding signalling milestone. It doesn't prove that a camera produced usable video, a recorder retained evidence, a control took physical effect, an event reached an operator, or an upper platform persisted the result.

Catalog and identity handling#

Treat catalog data as versioned, reconciled inventory rather than an append only list.

• Preserve the source platform, administrative domain, resource identifier, resource type, parent relationship, reported status, and observation time.
• Validate identifier length and character constraints from the exact edition; never derive authorisation solely from an identifier prefix.
• Detect duplicate identifiers across peers and reject ambiguous ownership.
• Reconcile additions, removals, renames, moves, and transient offline state without silently deleting audit history.
• Keep display names and free text out of access control decisions and escape them before logs or user interfaces.
• Model a cascaded platform separately from the resources it advertises; the advertising peer isn't necessarily the media source.

Large catalogs require bounded message size, element count, nesting, pagination or batching behaviour, processing time, and retry load. A catalog refresh must not starve event or keepalive processing.

Session and media boundary#

Session establishment commonly uses SIP with SDP to negotiate a media path, while RTP carries media according to the edition and implementation profile. Keep these layers distinct:

1. SIP authenticates and authorises the requested session within the control plane.
2. SDP describes the proposed media parameters and endpoints.
3. RTP transports the selected payload.
4. Codec, program stream, timestamp, and playback behaviour follow the exact standard edition and peer capability.
5. The receiving application verifies that usable media corresponds to the intended resource and request.

Don't infer payload format, codec, transport protection, source address, or recording semantics from a familiar port or product label. Constrain negotiated addresses to approved media networks to prevent server side request forgery, reflection, and cross tenant media access. See RTSP, RTP, RTCP, and SDP for the generic media layer boundaries; GB/T 28181 specific rules remain authoritative.

Events, control, and time#

Preserve event category, source identifier, occurrence time, receive time, sequence/correlation context, reported state, and raw bounded evidence. Model initial alarm, update, acknowledgement, and recovery as separate domain events where the applicable message vocabulary supports them. Network silence isn't a restoration.

Control requests can include high impact camera, platform, or alarm functions. Apply per resource and per action authorisation, reason capture, audit, expiry, and an explicit result model. Never retry an ambiguous physical or privacy impacting command blindly.

Time affects registration expiry, replay detection, event ordering, recording search, and evidentiary correlation. Record time source, time zone/offset handling, synchronisation health, clock changes, and each system's receive time. Don't overwrite source timestamps with ingestion time.

Security architecture#

GB/T 28181 interoperability isn't, by itself, a complete security profile. Apply GB 35114-2017 and any current sector, cryptography, product, and deployment requirements that govern the system.

• Authenticate platforms and devices using the approved national/profile mechanisms; a claimed SIP identity or source address is insufficient.
• Maintain separate trust for platform federation, device access, operator actions, and media retrieval.
• Protect signalling and media according to the applicable standards and deployment profile; never assume base RTP is confidential or authentic.
• Store private keys and symmetric keys in controlled cryptographic storage, with unique scope, rotation, revocation, recovery, and audit.
• Reject downgrade to a weaker or unauthenticated mode unless an approved legacy boundary explicitly requires it.
• Segment front end devices, SIP services, media services, management, storage, and cross domain gateways.
• Bound SIP, XML/message bodies, SDP, catalog entries, media packets, decoded frames, recording results, and decompressed data before allocation.
• Rate limit registration, authentication failure, catalog refresh, query, session setup, and event storms per authenticated peer and tenant.

National cryptographic algorithms, products, or conformity rules must be implemented from the current normative sources by appropriately qualified teams. Algorithm names alone don't establish secure key lifecycle, correct certificate validation, or conformity.

Safe gateway pattern#

For cross domain or ONVIF to GB/T 28181 integration, use a policy enforcing gateway rather than a transparent protocol bridge. The gateway should:

• terminate and independently authenticate each trust domain;
• map owned resource identities explicitly;
• authorise each function at the target and validate the translated message;
• normalise and bound metadata while retaining source evidence;
• prevent upstream peers from supplying unrestricted callback or media destinations;
• distinguish delivery, protocol acknowledgement, media availability, and physical outcome;
• expose only the minimum approved catalog, event, stream, and control capability.

There is rarely a lossless one to one mapping between profile features, event taxonomies, recording searches, and control semantics. Document every lossy or unsupported mapping.

Verification evidence#

A review or acceptance record should include:

• exact standard editions and applicable national/security obligations;
• product models, software/firmware, implemented roles, and conformity evidence;
• identifier allocation and administrative domain ownership;
• registration expiry, keepalive, reconnect, cascade, and clock behaviour;
• bounded catalog reconciliation, duplicates, removals, and large response handling;
• session negotiation, payload/codec, endpoint constraints, media loss, and restart recovery;
• event duplication, ordering, recovery, replay, and evidence retention;
• authentication, authorisation, cryptographic profile, key lifecycle, and downgrade handling;
• gateway mapping and negative authorisation cases;
• clear separation between signalling acknowledgement and verified media or operational outcome.

Use synthetic resources on an isolated, non operational topology for protocol verification. Live surveillance, recording, alarm, or control acceptance requires the system owner, applicable authority, privacy safeguards, and an approved site test plan.

Primary sources#

• Standardization Administration of China, GB/T 28181-2022 national standard record, status reviewed 25 August 2026.
• Standardization Administration of China, GB/T 28181-2016 national standard record, abolished status reviewed 25 August 2026.
• State Administration for Market Regulation, GB 35114-2017 national standard record, status reviewed 25 August 2026.
• Standardization Administration of China, GB/T 43026-2023 national standard record, status reviewed 25 August 2026.

The national standard records establish publication and lifecycle status. Obtain the complete current Chinese texts and applicable conformity rules before implementation or procurement.

Section overview · Wiki home