Summary of GB28181 Basics

Problems Solved by the GB28181 Standard:

• Addresses protocol interoperability issues between platforms and products from different manufacturers in the audio and video surveillance domain.
• Prior to the introduction of the GB28181 protocol, different manufacturers used proprietary solutions and communication protocols. Consequently, interoperation between surveillance platforms and devices like IP cameras or DVRs was effectively restricted within individual vendor ecosystems.
• GB28181 solves this issue through a unified protocol framework and standard led by government authorities (with participation from major surveillance platforms and device manufacturers). Any manufacturer selling products or developing platforms within this market ecosystem must comply with GB28181 rules, implementing interfaces and connection methods strictly as defined by the protocol. This enables seamless interoperability across different manufacturers’ products during actual deployment.
• Issues in the definition and implementation of the GB28181 standard:
  • The standard contains certain ambiguities and a lack of rigor regarding detailed communication protocol specifications. As a result, manufacturers often interpret and implement parts of the standard independently. This frequently leads to a situation where, despite sharing the overarching GB28181 specification, specific implementation details are effectively dictated by major industry players, while small and medium manufacturers adapt their systems to conform to those larger vendors’ implementations.

Core Business Functionalities Required for Surveillance Platforms:

• Listening for connection requests from downstream devices and processing keepalive messages after connections are established.
• Retrieving device information connected under the platform.
  • A downstream GB28181 platform can be connected to another GB28181 platform, forming a hierarchical, multi-level cascading architecture.
• Fetching real-time video/audio streams from connected devices under the platform.
• Retrieving historical video recording playback from connected devices for a specified timeframe.
• Remote device control, such as PTZ (Pan-Tilt-Zoom) control, two-way audio intercom, etc.

GB28181 Fundamentals:

• Communication between various devices and services in the GB28181 protocol is implemented using SIP over UDP.
• Topology: Parent (superior) node, Child (subordinate) node.
• Video stream transmission uses a “push” model, where streams are pushed from child nodes to parent nodes.
• When a parent node needs to access a video stream from a child node, it sends a message specifying the destination IP address and port for receiving the stream. Upon receiving this message, the child node begins pushing the stream to the specified IP and port.
• When the parent node no longer needs the video stream, it sends a BYE command to notify the child node to stop sending, and the child node terminates transmission upon receipt.
• A major advantage of using the push model is that it easily enables pushing video streams from a local private network (LAN) to a media server on an external public network (WAN).
• GB28181 requires the video stream format to be Program Stream (PS), raw H.264 elementary stream, or MP4 format, with PS streams and raw H.264 streams being the most common.

Communication Architecture and Basic Workflow for Streaming:

Under the GB28181 protocol framework, the operations involving request, push, and relay of audio/video streams are divided into four primary roles (multiple roles may be deployed on the same physical server):

• Media Stream Sender: Typically a remotely deployed IP camera or DVR used to transmit image streams to a designated media server.
• SIP Server: Responsible for device management and routing/forwarding control messages between different services or endpoints.
• Media Server: Receives audio/video streams pushed from front-end devices (Media Stream Senders) and provides stream pulling interfaces for Media Stream Receivers. It essentially acts as a streaming relay server. In practice, the SIP Server and Media Server can be deployed on the same server hardware.
• Media Stream Receiver: The end communication node that actually requests and plays audio/video streams. It does not communicate directly with the Media Stream Sender; instead, all interactions and relaying are managed through the Media Server.

The complete workflow initiated by a Media Stream Receiver requesting an audio/video stream is as follows:

• The Media Stream Receiver (the server that actually needs access to the live camera stream) sends an Invite message to the SIP Server to request real-time stream data from a specific camera.
• Upon receiving the request, the SIP Server sends an Invite message to the Media Server to query the media types supported by the streaming server.
• The Media Server responds to the SIP Server using SDP (Session Description Protocol).
• The SIP Server forwards an Invite message to the Media Stream Sender (the camera), embedding SDP content containing the Media Server’s IP address, port, and supported media format details.
• After acknowledging the Invite message, the Media Stream Sender begins pushing its live audio/video stream to the Media Server IP and port specified in the SDP.
• The SIP Server then returns a confirmation message to the Media Stream Receiver, indicating that the Media Sender has been successfully instructed to push the stream to the Media Server.
• The Media Stream Receiver can then pull the requested camera stream from the Media Server to decode and play it.
• When the Media Stream Receiver needs to stop receiving the stream, it sends a BYE message to the SIP Server.
• The SIP Server sends BYE messages to both the Media Server and the Media Stream Sender to stop stream pushing. The complete business process is finished.
• Note: As seen from the workflow diagram above, the interactions among the four roles are somewhat verbose. In actual integration scenarios, some unnecessary confirmation steps can be simplified or omitted.

Additional Notes:

• For the concrete implementation of GB28181 features, the open-source PJSIP library can be easily used to handle SIP protocol communication with the SIP server.

References:

• GB28181 National Inspection Streaming Push
• GB28181 Video Tutorial Episode 1 (Basics)
• GB28181 Video Tutorial Episode 2 (Streaming Push - Part 1)