Video streaming security monitoring national standard GB28181 platform EasyGBS has rich video capabilities and flexible deployment. It can be used as a business platform and can also be called by the business management platform as a security monitoring video capability layer. The national standard GB28181 video surveillance EasyGBS platform can provide streaming media access, processing, forwarding and other services, and supports functions such as live video surveillance and live streaming of security video surveillance equipment on the intranet and public network through the national standard GB/T28181 protocol.
Today we will learn about the analysis of GB28181 in the EasyGBS national standard GB28181 video platform.
The GB28181 protocol refers to the national standard GB/T 28181-2016 "Technical Requirements for Information Transmission, Exchange, and Control of Public Security Video Surveillance Networking Systems."
This standard specifies the interconnection structure of public safety video surveillance networking systems, basic requirements and security requirements for transmission, exchange, and control, as well as technical requirements for control, transmission processes, and protocol interfaces. It is a national standard in the field of video surveillance. The signaling layer of the GB28181 protocol uses the SIP (Session Initiation Protocol) protocol.
The streaming media transmission layer uses the Real-time Transport Protocol (RTP) protocol.
Therefore, it can be understood that GB28181 is privatized and customized on the basis of international standards to meet the standardized needs of interconnection transmission of video surveillance network systems. This article aims to explain how to add support for the GB28181 protocol in FFmpeg, so that it can communicate and control devices that support the GB28181 protocol, and realize device registration, keep-alive, and streaming media transmission.
National standard GB28181 protocol: signaling process
National standard GB28181 protocol
The session channel of the GB28181 protocol is actually based on the SIP protocol and is customized on this basis. SIP is a protocol developed by the IETF MMUSIC working group to standardize the creation, modification and termination of interactive user sessions, covering multimedia elements such as video, voice, instant messaging, online games and virtual reality.
In SIP, user agent (User Agent) is a key concept, which refers to a SIP logical network endpoint used to create, send, receive SIP messages and manage SIP sessions. The user agent can send requests as a client (User Agent Client, UAC) or receive and process requests as a server (User Agent Server, UAS). Through user agents, SIP implements communication and session control between users.
SIP user agents can be divided into User Agent Client (UAC) and User Agent Server (UAS). UAC is responsible for creating and sending SIP requests, while UAS is responsible for receiving and processing SIP requests and sending corresponding SIP responses. This division of labor enables the SIP protocol to achieve session control and communication between the two parties.
The SIP protocol often works in conjunction with many other protocols. One of the important protocols is the Session Description Protocol (SDP), which is used to send the content of SIP messages. The SDP protocol describes the streaming details used by the session, such as the IP address and port number used, the codec used, etc. Through the SDP protocol, SIP ensures that participants in the session understand and adapt to the correct media flow parameters to achieve effective communication.
A typical use of SIP is to transport a real-time transport protocol stream of passing messages. In this case, RTP (Real-time Transport Protocol) plays the role of a voice or video carrier. In the GB28181 protocol, networking systems need to establish two channels for video and audio transmission and control: session channels and media streaming channels. The session channel is used to establish sessions between devices and transmit system control commands; while the media streaming channel is used to transmit compressed and encoded video and audio data, in which the streaming media protocol RTP/RTCP is used as the transmission protocol of the media streaming channel. In this way, the GB28181 protocol can effectively transmit video and audio data and perform system control. The specific communication protocol structure diagram in the GB28181 protocol is shown below (communication protocol structure diagram):
register:
In GB28181, a device registers itself by sending a REGISTER request to the SIP server. The message structure of the REGISTER request is the same as specified in the SIP protocol IETF RFC3261, including the request line, header and message body. The request line specifies the method (REGISTER), URI and SIP version; the header includes the SIP address, authentication information, etc.; the message body is empty.
Childcare:
In order to keep the session channel alive, the device needs to periodically send SIP messages to inform the SIP server that it still exists. This SIP message is called a keep-alive message and is implemented using the OPTIONS method. The message structure of the keep-alive message is the same as specified in the SIP protocol IETF RFC3261, including the request line, header and message body. The request line specifies the method (OPTIONS), URI and SIP version; the header includes the SIP address, authentication information, etc.; the message body is empty.
Real-time video and audio on demand:
When the front-end user needs to view the video in real time, he first needs to send an INVITE request to the camera device to invite the device to start transmitting the video stream. The message structure of the INVITE request is the same as specified in the SIP protocol IETF RFC3261, including the request line, header and message body. The request line specifies the method (INVITE), URI and SIP version; the header includes the SIP address, authentication information, codec, etc.; the message body is empty. The device uses a 200 OK response when replying to the INVITE request. Its message structure is the same as specified in the SIP protocol IETF RFC3261, including status line, header and message body. The status line specifies the SIP version and status code (200 OK), and the header includes the SIP address, codec, etc.; the message body contains media stream parameters in the SDP protocol format.
GB 28181: Registration
Registration refers to the working mode in which a device or system registers with a SIP server (SIP UAS) when entering a networked system. In this article, FFmpeg is a SIP server. The device sends a registration request to FFmpeg, and FFmpeg receives the device's registration request. After returning the corresponding reply message, the device registration process is completed. The registration process of challenge-response security technology based on digital digest in GB28181 protocol is as shown in the figure below:
The registration process is described below:
The SIP proxy sends a Register request to the SIP server;
The SIP server sends a response 401 to the SIP proxy, and gives the authentication mechanism and parameters suitable for the SIP proxy in the WWW_Authenticate field of the response header;
The SIP proxy resends the REGISTER request to the SIP server, giving a certificate of trust and including authentication information in the Authorization field of the request;
The SIP server verifies the request. If the identity of the SIP proxy is checked to be legitimate, it sends a success response 200OK to the SIP proxy. If the identity is not legitimate, it sends a denial of service response.
An example of the registered request message content is as follows:
REGISTER sip:34020000002000000001@3402000000 SIP/2.0
Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1371463273
From: sip:34020000001320000003@3402000000;tag=2043466181
To: sip:34020000001320000003@3402000000
Call-ID: 1011047669
CSeq: 1 REGISTER
Contact: sip:[email protected]:5060
Max-Forwards: 70
User-Agent: IP Camera
Expires: 3600
Content-Length: 0The registration request header field parameters are explained as follows:
第1行表明这条SIP消息的方法（Method）是REGISTER，34020000002000000001是SIP服务器的国标ID，国标ID指的是由中心编码(8位) 、行业编码(2位) 、类型编码(3位)和序号(7位)四个码段共20位十进制数字字符构成，具体国标ID的编码方法可以参考GB/T 28181—2016中的附录D。3402000000指的是SIP服务器的域国标ID，SIP/2.0指的是SIP协议版本。
第2行为Via头，Via头中包含了发送请求方的相关信息，后续需要使用这些信息进行回复。SIP/2.0/UDP表示使用的是2.0版本的SIP协议，使用的传输协议是UDP，也可以使用TCP协议。192.168.137.11:5060为请求发送方的IP地址和端口号。Via头中必须包含branch参数，具体值是一个在整个SIP通信过程中不重复的数值。branch是一个事务ID（Transaction ID），用于区分同一个UA所发起的不同Transaction，它不会对未来的request或者是response造成影响，对于遵循IETF RFC3261规范的实现，这个branch参数的值必须用”z9hG4bK”打头. 其它部分是对To， From, Call-ID头域和Request-URI按一定的算法加密后得到。rport字段表示使用rport机制路由响应，即发送的响应时，按照rport中的端口发送SIP响应，也就是说IP和端口均完全遵照从哪里来的，发回哪里去的原则，如果没有rport字段时，服务端的策略是IP使用UDP包中的地址，即从哪里来回哪里去，但是端口使用的是via中的端口，详情见IETF RFC35818。
第3行为From头，From头中包含了请求发送方的逻辑标识，在GB28181协议中是发送请求的设备国标ID和域国标ID信息。tag参数是为了身份认证的，值为随机数字字符。
第4行为To头，To头在SIP协议中是为了标明请求接收方的逻辑标识的，在GB28181协议中填写的是发送请求的设备国标ID和域国标ID信息。
第5行为Call-ID头，Call-ID头是全局唯一的，在同一个session中保持一致，在不同session中不同。
第6行为CSeq头，CSeq头又叫Command Seqence（命令队列），用于标识命令顺序，值为序号+Method，序号部分为无符号整数，最大值为2^31。序号起始值是随机的，后续在同一个session中依次递增，比如发1 REGISTER没返回--->再发2 REGISTER--->没返回--->再发3 REGISTER--->这时返回了2 REGISTER就知道是第2个请求得到了响应。对于ACK和CANCLE中的CSeq与INVITE中的Cseq保持一致。
第7行为Contact头，Contact头包含源的URI信息，用来给响应消息直接和源建立连接用。在GB28181协议中为SIP设备编码@源IP地址端口。
第8行为Max-Forwards头，Max-Forwards头用于设置包最大中转次数，默认是70。
第9行为User-Agent头，User-Agent头用于设置关于UA的信息，用户可以自定义。
第10行为Expires头，Expires头表示超时时间。
第11行为Content-Length头，Content-Length头表示SDP消息的长度，因为REGISTER消息不需要SDP，因此为0。An example of the registered reply message content is as follows. The meaning of each header information is shown above:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1371463273
From: sip:34020000001320000003@3402000000
To: sip:34020000001320000003@3402000000
CSeq: 1 REGISTER
Call-ID: 1011047669
Contact: sip:[email protected]:5060
User-Agent: FFmpeg GB28181 v1.0
Expires: 3600
Content-Length: 0National title 28181: Daycare
When the user agent (UA) discovers that it is working abnormally, it should immediately send status information to the SIP server of the SIP monitoring domain to which it belongs. Similarly, when working normally, status information should be sent regularly to the SIP server of the SIP monitoring domain to which it belongs. In order to realize this function, the MESSAGE method defined in IETF RFC3427 can be used to report status information.
Through periodic status information reporting, status detection between the registration server and the source device can be realized, which is also called the heartbeat mechanism. When the UA sends status information to the SIP server, the server can determine the working status of the device based on the received message, such as whether it is online, whether it is running normally, etc. If the server does not receive status information for a long time, it can be determined that the device may be faulty or unavailable.
When using the MESSAGE method to report status information, you need to construct a corresponding SIP message body and include relevant status information. The specific reporting frequency and content can be configured according to actual needs and agreement provisions.
When constructing a SIP message body, it needs to be encoded according to the specifications of the SIP protocol (IETF RFC3261). The message body can use SIP message headers and message bodies to convey status information. In the SIP message header, you can add custom header fields or use predefined header fields, such as Subject, Content-Type, etc., to indicate the purpose and content type of the message. The message body can carry customized status information, such as device status, error codes, working parameters, etc.
The frequency of submission is determined based on actual needs and agreement provisions. The appropriate reporting frequency can be set based on monitoring requirements and system performance considerations to meet the need for timely monitoring of equipment status. Generally speaking, the reporting frequency can be determined by the agreement between the SIP server of the monitoring domain and the source device.
The content to be submitted is also determined based on the actual situation and the provisions of the agreement. Specifically, it can include the health status of the device, connection quality, alarm information, etc. Depending on the needs, custom message formats and fields can be defined to meet specific monitoring requirements.
In short, when reporting status information by using the MESSAGE method, you need to construct a corresponding SIP message body and include relevant status information in it. The specific reporting frequency and content need to be configured according to actual needs and protocol provisions to meet monitoring requirements and system performance. By implementing the heartbeat mechanism, the status of the device can be monitored in a timely manner and corresponding processing measures can be taken to improve the reliability and stability of the system.
The heartbeat sender and receiver need to uniformly configure the "heartbeat interval" parameter and send heartbeat messages regularly according to the "heartbeat interval". The default heartbeat interval is 60s. The heartbeat sender and receiver need to uniformly configure the "number of heartbeat timeouts" parameter. If heartbeat messages continuously time out and reach the "number of heartbeat timeouts", the other party is considered offline. The default number of heartbeat timeouts is 3. If the heartbeat receiver detects that the heartbeat message has timed out for an agreed-upon number of times while the heartbeat sender is online, it is considered that the heartbeat sender is offline; if the heartbeat sender detects that the heartbeat message has responded to a heartbeat message that has timed out for an agreed-upon number of times while the heartbeat receiver is online, it is considered that the heartbeat sender is offline. The receiver is offline. The specific command flow is as follows:
The command process is described as follows:
(a) The source device sends a device status information reporting command to the SIP server. The device status information reporting command is carried using the MESSAGE method;
(b) The SIP server returns 200 OK after receiving the command.
An example of keep-alive message content is as follows:
MESSAGE sip:34020000002000000001@3402000000 SIP/2.0
Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1066375804
From: sip:34020000001320000003@3402000000;tag=1925919231
To: sip:34020000002000000001@3402000000
Call-ID: 1185236415
CSeq: 20 MESSAGE
Content-Type: Application/MANSCDP+xml
Max-Forwards: 70
User-Agent: IP Camera
Content-Length: 175
<?xml version="1.0" encoding="UTF-8"?>
<Notify>
<CmdType>Keepalive
<SN>1
<DeviceID>34020000001320000003
<Status>OK
<Info>
</Info>
</Notify>Message reply message content example is as follows:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1066375804
From: sip:34020000001320000003@3402000000
To: sip:34020000002000000001@3402000000
CSeq: 20 MESSAGE
Call-ID: 1185236415
User-Agent: FFmpeg GB28181 v1.0
Content-Length: 0National standard 28181: real-time video playback
Video streaming format
GB28181 requires that the transmitted video stream format be PS stream, or H264 stream, or MP4 format.
You can use wireshark to capture packets. The datagram type is RTP PS stream.
The national standard streaming media server is actually responsible for converting PS streams pushed by GB28181 devices or platforms into ES streams, and then providing RTSP, RTMP, FLV, HLS and other formats for distribution.
The difference between PS stream and ES stream
P datagram consists of two parts: header and data. The first part of the header
It is a fixed length of 20 bytes and is required for all IP datagrams. The header includes: total length, identification, MF, DF, and slice offset.
Digital signals actually transmit data streams. Generally, data streams include the following three types:
ES stream (Elementary Stream): Also called elementary stream, it contains continuous code streams of video, audio or data.
PES stream (Packet Elementary Stream): Also called packaged elementary stream, the basic ES stream is divided into data packets of different lengths as needed, and the packet header is added to form a packed elementary stream PES stream.
TS stream: Also called transport stream, it is composed of packets with a fixed length of 188 bytes and contains one or more programs with independent time bases. A program can also contain multiple ES streams of video, audio, and text information; each Each ES stream will be marked with a different PID. In order to analyze these ES streams, TS has some fixed PIDs that are used to send program and ES stream information at intervals: PAT and PMT tables. Suitable for environments with many bit errors
ES is the data stream coming directly from the encoder, which can be an encoded video data stream, an audio data stream, or a general name for other encoded data streams. After the ES stream passes through the PES packager, it is converted into a PES package, and then distributed through RTSP, RTMP, FLV, and HLS formats to achieve broadcasting on multiple terminals such as WEB, mobile phones, PCs, and WeChat.
Propagation mode
The GBT28181 protocol stipulates that the code stream uses RTP packet payload. It is recommended to be PS stream or ES stream. For the transmission of media streams, active tcp and passive tcp are added to the original UDP transmission.
UDP passive
This is a common transmission method. GB28181 streaming media server monitors a single UDP port, and then sends a SIP signaling (INVITE). The SDP it carries contains the port for receiving media. After receiving the signaling, the device parses the port, and then the device actively sends the media to the streaming media through UDP. On the port that the server listens on
Send video stream
TCP passive
There are two types, one is active and the other is passive
For active: The device informs the server of its own media streaming tcp port, and the server actively connects to the port on the device to obtain data. . This scenario has few applications and can be ignored.
For passive: the streaming media server listens to a single TCP port, and then tells the device port through SIP signaling (INVITE), and the device actively sends the video stream to the current streaming media server, which is basically equivalent to a UDP stream.
Live video process
Prerequisite: Registration successful>>>>>>Heartbeat successful>>>>>>Device directory query>>>>>>Real-time video viewing
Server side steps
Regardless of whether it is viewed in TCP or UDP mode, the steps are:
(1) Open the video port
(2) Send real-time video request
(3) Wait for the device to reply 200OK
(4) Send ACK
(5) Play code stream
(6) Stop video request
(7) Close the video port
(8) Ordinary waiting
Packet capture analysis
Test equipment IP: (Haikang Equipment)
Server IP: (local ip)
Real-time video creation_UDP
Step 0: [Server] Open the video port
Step 1: [Server>>Client] Request to play video
INVITE sip:34020000001310000002@4401020049 SIP/2.0
Call-ID: helloVideo
CSeq: 1 INVITE
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: <sip:34020000001110000001@4401020049>
Max-Forwards: 70
Contact: <sip:34020000001310000002@4401020049>
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-bff9-4f3000002
Content-Type: application/sdp
Content-Length: 225v=0
o=34020000001310000002 0 0 IN IP4 192.168.0.60
s=Play
c=IN IP4 192.168.0.60
t=0 0
m=video 6000 RTP/AVP 96 98 97
a=recvonly
a=rtpmap:96 PS/90000
a=rtpmap:98 H264/90000
a=rtpmap:97 MPEG4/90000
y=0100000001
f=Step 2: [Client>>Server]
Reply 100 first
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-bff9-4f3000002
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: <sip:34020000001110000001@4401020049>;tag=5f906952
Call-ID: helloVideo
CSeq: 1 INVITE
Server: Happytime Agent Ver 1.0
Content-Length: 0
再回复200
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-bff9-4f3000002
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: <sip:34020000001110000001@4401020049>;tag=5f906952
Contact: <sip:34020000001110000001@4401020049>
Call-ID: helloVideo
CSeq: 1 INVITE
Max-Forwards: 70
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,UPDATE,INFO
Supported: timer
Session-Expires: 200;refresher=uac
Server: Happytime Agent Ver 1.0
Content-Type: application/sdp
Content-Length: 153v=0
o=34020000001110000001 0 0 IN IP4 192.168.0.107
s=Play
c=IN IP4 192.168.0.107
t=0 0
m=video 19002 RTP/AVP 96
a=rtpmap:96 PS/90000
a=sendonlyStep 3: [Server>>Client] Reply ACK
ACK sip:34020000001310000002@4401020049 SIP/2.0
Call-ID: helloVideo
CSeq: 1 ACK
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: <sip:34020000001110000001@4401020049>
Max-Forwards: 70
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-00003
Content-Length: 0Step 4: Play the stream
Step 5: [Server>>Client] Stop video request
BYE sip:34020000001310000002@4401020049 SIP/2.0
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: sip:34020000001110000001@4401020049;tag=5f906952
CSeq: 2 BYE
Call-ID: helloVideo
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-00004
Max-Forwards: 70
Content-Length: 0Step 6: [Client] responds with 200
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-00004
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: sip:34020000001110000001@4401020049;tag=5f906952
Call-ID: helloVideo
CSeq: 2 BYE
Server: Happytime Agent Ver 1.0
Content-Length: 0Step 7: [Server] Close the video port
EasyGBS national standard video cloud service platform has rich video capabilities and flexible deployment. It can be used as a business platform and can also be called by the business platform as a video capability layer. The platform has been implemented in a large number of projects, such as Mingchuliangzao, Ping An Village, Xueliang Project, etc. This ends the analysis of the GB28181 protocol in the national standard video platform EasyGBS national standard platform.
