GB28181

foreword

The GB28181 protocol is a national standard in the field of video surveillance. This article will analyze how to add support for the GB28181 protocol in FFmpeg, so that it can communicate and control with devices that support the GB28181 protocol, and realize device registration, keep alive and streaming media transmission .

1. Background introduction

The GB28181 protocol refers to the national standard GB/T 28181-2016 "Public Security Video Surveillance Networking System Information Transmission, Exchange, and Control Technical Requirements".

This standard stipulates the interconnection structure of the public security video surveillance networking system, the basic requirements and security requirements for transmission, exchange, and control, as well as the technical requirements for control, transmission process, and protocol interface. It is a national standard in the field of video surveillance. The GB28181 protocol signaling level 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 general standards to meet the standardized requirements for interconnection and transmission of video surveillance networking systems. This article aims to explain the addition of support for the GB28181 protocol in FFmpeg, so that it can communicate and control with devices that support the GB28181 protocol, and realize device registration, keep alive and streaming media transmission.

2. National standard GB28181 protocol: signaling process

2.1 National standard GB28181 protocol

The GB28181 protocol session channel actually uses the SIP protocol, and some privatization has been done on the basis of the SIP protocol. SIP is a protocol developed by the IETF MMUSIC working group and proposed as a standard for creating, modifying and terminating interactive user sessions including multiple multimedia elements such as video, voice, instant messaging, online games and virtual reality.

A relatively important concept in SIP is User Agent (User Agent), which refers to a SIP logical network endpoint for creating, sending, receiving SIP messages and managing a SIP session.

SIP user agent can be divided into user agent client UAC (User Agent Client) and user agent server UAS (User Agent Server). UAC creates and sends SIP requests, UAS receives and processes SIP requests, and sends SIP responses.

The SIP protocol will work with many other protocols, such as the Session Description Protocol (SDP) for sending SIP message content. The SDP protocol describes the details of the streaming media used in the session, such as: which IP port to use, which encoding to use decoder and so on.

A typical use of SIP is: the SIP session transmits some simple real-time transport protocol streams through messages, and RTP itself is the carrier of voice or video. In the GB28181 protocol, the networked system should establish two transmission channels when performing video and audio transmission and control: a session channel and a media stream channel. The session channel is used to establish a session between devices and transmit system control commands; the media stream channel is used to transmit video and audio data, and the compressed video and audio stream is transmitted using the streaming media protocol RTP/RTCP. The specific communication protocol structure diagram in the GB28181 protocol is shown in the following figure (communication protocol structure diagram):

For details, please refer to the national standard GB28181 requirements document: Link: https://pan.baidu.com/s/1aqlF6mQPNUE4KMIUf3JU8A?pwd=jb6v Extraction code: jb6v

In the session channel, the session control of applications such as registration, real-time video and audio on demand, and historical video and audio playback is implemented using the request and response methods such as REGISTER and INVITE specified in the SIP protocol IETF RFC3261, and the historical video and audio playback control uses the SIP extension protocol IETF RFC29765 The specified INFO method is implemented, and the session control of applications such as front-end equipment control, information query, alarm event notification and distribution is implemented using the MESSAGE method specified in the SIP extension protocol IETF RFC34287. The following is a detailed introduction to the SIP message structure of registration, keep alive and real-time video and audio on demand.

2.2 National Standard 28181: Registration

Registration refers to the working mode of registering with the SIP server (SIP UAS) when the device or system enters the networked system. In this article, FFmpeg is a SIP server. The device sends a registration request to FFmpeg, and FFmpeg receives the registration request of the device After returning the corresponding reply message, the device registration process is completed. The registration process of the challenge-response security technology based on the digital abstract in the GB28181 protocol is shown in the following figure (schematic diagram of the basic registration process):

For details, please refer to the State Grid Technical Requirements Document: [Appendix B.1 Registration] link: https://pan.baidu.com/s/1_bn-K2CML_OPxQRO4VDdhQ?pwd=6sb9 Extraction code: 6sb9

For the implementation of GB28181 of other excellent articles, you can refer to the homepage article:

1. GB28181 Streaming Media Series Articles

2. The first chapter is a series of articles on registering to the higher platform

3. sip (gb28181) signaling interaction - video on demand and playback

The registration process is described as follows:

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 system and parameters suitable for the SIP proxy in the WWW_Authenticate field of the response message header;
The SIP proxy sends a REGISTER request to the SIP server again, and gives a letter of trust in the Authorization field of the request, including authentication information;
The SIP server verifies the request. If it is found that the identity of the SIP agent is legal, it sends a successful response of 200 OK to the SIP agent. If the identity is not legal, 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: 0

The 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。

The content of the registered reply message is as follows, and the meaning of each header information is as 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: 0

2.3 Country mark 28181: childcare

When the UA finds that the work is abnormal, it should immediately send status information to the SIP server in the SIP monitoring domain; if there is no abnormality, it should send status information to the SIP server in the SIP monitoring domain regularly. Status information reporting is implemented using the method MESSAGE defined in IETF RFC3427. Through periodic status information reporting, the status detection between the registration server and the source device, that is, the heartbeat mechanism, is realized.

The heartbeat sender and receiver need to configure the "heartbeat interval" parameter uniformly, and send heartbeat messages regularly according to the "heartbeat interval". The default heartbeat interval is 60s. The heartbeat sender and receiver need to configure the "heartbeat timeout times" parameter uniformly. If the heartbeat messages continuously time out and reach the "heartbeat timeout times", the other party will be considered offline. The default heartbeat timeout times are 3 times. When the heartbeat receiver detects that the heartbeat message has continuously timed out for the agreed number of times when the heartbeat sender is online, the heartbeat sender is considered offline; Receiver is offline. The specific command flow is as follows (keep alive command flow chart):

The command flow is described as follows:

(a) The source device sends a device status information report command to the SIP server. The device status information report command is carried by the MESSAGE method;

(b) The SIP server returns 200 OK after receiving the command.

An example of the content of the keep-alive message 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>

The Content-type header of the MESSAGE message is Content-type: Application/MANSCDP+xml. The status information reporting command adopts the MANSCDP (Monitoring and Alarming Network System Control Description Protocol) protocol format definition. For a detailed description, see [A.2.5 Status Information Reporting in GB/T 28181-2016]. The status information reporting command should include the command type (CmdType), device/system code (DeviceID), whether it is working normally (Status), etc., and is carried in the message body of the MESSAGE method. The success and error responses of the Message message have no message body, and the content of the Message reply message 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: 0

2.4 National Standard 28181: Real-time video playback

video stream format

GB28181 requires the transmitted video stream format to be PS stream, or H264 stream, or MP4 format.

You can use wireshark to capture packets, and 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

The P datagram consists of two parts: the header and the data, and the previous part of the header

Minutes are a fixed length of 20 bytes and are mandatory for all IP datagrams. The header includes: total length, logo, MF, DF, slice offset.

What the digital signal actually transmits is a data stream, and the general data stream includes the following three types:

ES stream (Elementary Stream): also called elementary stream, which contains continuous stream of video, audio or data.
PES stream (Packet Elementary Stream): also called packaged basic code stream, is to divide the basic code stream ES stream into data packets of different lengths according to needs, and add the packet header to form a packaged basic code 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 video, audio, and text information ES streams; each ES stream will have a different PID mark, in order to analyze these ES streams, TS has some fixed PIDs to send program and ES stream information tables at intervals: PAT and PMT tables. Suitable for environments with many bit errors

ES is the data stream directly from the encoder, which can be an encoded video data stream, audio data stream, or 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 realize multi-terminal broadcasting such as WEB, mobile phone, PC, and WeChat.

Propagation mode

The GBT28181 protocol stipulates that the code stream uses RTP packet load, and it is recommended to be PS stream or ES stream. For the transmission of media stream, the active tcp and passive tcp methods are added on the basis of the original UDP transmission.

UDP passive

This is a common transmission method. The GB28181 streaming media server listens to a single UDP port, and then sends a SIP signaling (INVITE). The SDP carried in it contains the port receiving the media. Send the video stream on the port that the server listens to

TCP Passive

There are two types, one is active and the other is passive

Active: The device informs the server of its own media stream tcp port, and the server actively connects to the port on the device to obtain data. . This scenario is rarely used 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 video streams to the current streaming media server, which is basically equivalent to UDP streams.

Live Video Process

Premise: Register successfully >>>>>>Heartbeat success>>>>>>Device catalog query>>>>>Real-time video viewing

server steps

Regardless of whether it is viewed by TCP or UDP, the steps are:
(1) Open the video port
(2) Send a real-time video request
(3) Wait for the device to reply 200OK
(4) Send ACK
(5) Play the code stream
(6) stop video request
(7) close video port
(8) normal wait

Packet analysis

Test equipment IP: 192.168.0.9 (Hikang NVR equipment)
server IP: 192.168.0.28 (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: 225

v=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

Reply 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: 153

v=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=sendonly

Step 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: 0

Step 4: Play code stream

Step 5: [Server >> Client] Stop the 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: 0

Step 6: [Client] Response 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: 0

Step 7: [Server] Close the video port

3. SIP protocol

SIP (Session initialization Protocol, Session Initiation Protocol ) is a multimedia communication protocol formulated by IETF (Internet Engineering Task Force, Internet Engineering Task Force).

It is a text-based application-layer control protocol for creating, modifying, and releasing sessions with one or more participants. SIP is an IP voice session control protocol originating from the Internet. It is flexible, easy to implement, and easy to expand. SIP (Session Initiation Protocol) is a plain text application layer protocol similar to the http protocol. SIP can be used to control operations such as establishment, cancellation, and closure of sessions. Mainly the following functions can be realized:

User location: check the location of the end user for communication;
User Validity: checks the willingness of the user to participate in the session;
User Capabilities: Check Media and Media Parameters;
Establish a session: "Ring", a parameter to establish a session at the same time as the calling party and the called party;
Session management: including session transmission and termination, modifying session parameters and requesting services

At present, relevant equipment suppliers and business suppliers have jointly established a forum about SIP: http://www.sipforum.org to provide a development platform for free discussion and new thinking for the development of SIP

3.1 Concept description

3.1.1 SIP request

Request is one of the most basic concepts in SIP, and every operation about SIP needs to send a request.

3.1.2 SIP response

Reply and request generally appear in pairs in SIP, and the content in the reply is the result of processing the request by the peer end.

3.1.3 Transaction

The SIP protocol is a transactional protocol. The concept of transaction is based on request and reply, and a request and related final reply constitute a transaction. (Not including the processing of ACK) Since there will be multiple Transactions in the process from the establishment to the end of a call, it is necessary to uniquely mark the Transaction. The branch parameter uniquely marks the Transaction in SIP

3.1.4 TU

After having the concept of Transaction, the concept of Transaction user appeared. Transaction is built on Transaction and can manage Transaction.

3.1.5 Client Transaction 和Server Transaction

With the concept of Transaction, client Transaction and server Transaction appear for the difference between request and reply. CT refers to the Transaction part owned by the request initiator, and ST is the part owned by the request recipient.

3.1.6 User Agent UA (User Agent)

UA refers to a user entity.

3.1.7 UAC and UAS User Agent Server (User Agent Server)

The user entity that actually initiates the request is the UAC, and the user entity that actually receives the request for processing is the UAS.

3.1.8 INVITE

special request. The most critical request in the SIP protocol. Used to initiate a session.

3.1.9 session

The session is established after receiving the 2xx response of the corresponding INVITE request. After the 2xx response of the next INVITE request is sent or received, it will be modified. The only way to end it is to send or receive a bye request.

3.2.0 dialog

The concept of dialog is similar to that of session, except that dialog is a concept for signaling interaction, while session is a description of the actual media sending and receiving process. The establishment time of the dialog is also after receiving the 200 OK reply of the signaling, and the end is also after sending or receiving the bye request.

3.2 Structure of SIP

The SIP protocol mainly includes the following logical roles: UA, Proxy Server, Register/Location Server, and Redirect Server.

UA: User Agent (User Agent) is similar to the role of the browser in the http protocol. It is the terminal interface operated by the user. The user agent needs to meet the requirements of the SIP protocol, but combined with other protocols according to different application scenarios, there will be different implementations logic. For example, the SIP protocol combined with the H.323VoIP protocol can realize the software phone function. The user agent is divided into two logical entities, UAC (UA Client) and UAS (UA Server). UAC sends SIP Request and receives Response, and UAS receives SIP Request and returns Response. A physical device can be both UAC and UAS.
Proxy Server: The role of the proxy server is mainly to forward Request and Response to other Proxy Servers or UAs. Proxy Servers are divided into Stateful Proxy and Stateless Proxy. The former will retain a communication transaction The forwarding operation is controlled by a finite state machine, and the latter does not save the state, but only realizes the transparent forwarding operation.
Registration/Location Server: The registration and location server is used to register and locate the UA. The online UA will periodically send SIP messages to the Registration server to indicate the current location of the UA (such as IP address, port number, etc.), and the Registration server will send the information Stored in the database (or hash table), when other UA sends a request to the UA, the location of the UA can be obtained.
Redirect Server: used for redirection, logically equivalent to a UA with special functions.

3.3 SIP method

In SIP's REQUEST, six core methods are defined: INVITE, ACK, BYE, CANCEL, OPTIONS, and REGISTER.

The INVITE message is used to initiate a new session;
The ACK message is used to complete the establishment of the session;
The BYE message is used to end a session;
The CANCEL message is used to cancel a request (usually for INVITE);
The OPTIONS message is used to query the capabilities of the server;
The REGISTER message is used to send a registration request message.

The type of SIP request, also known as the SIP method. There are six methods defined in RFC3261. The other eight methods have independent RFC extension descriptions. Such as INFO, NOTIFY and so on.

For the meaning of each method, please refer to: SIP request method

You can also move to the SIP development manual: Link: https://pan.baidu.com/s/1GFCHYqumPrd5ORhyCfJAew?pwd=yxj1 Extraction code: yxj1

3.4 SIP protocol format

SIP messages are encoded in [ISO 10646] text and are divided into two categories: request messages and response messages.

Request message: A SIP message sent by the client to the server in order to activate a specific operation.

Response message: used to respond to the request message, indicating the success or failure status of the call.

Each SIP message consists of the following three parts: Start Line (Start Line)/Status Line (Status-Line), SIP header, and message body; both request messages and response messages include SIP header fields and SIP message fields.

Start Line/Status-Line

Each SIP message begins with a start line. The start line conveys the message type (method type in a request, response code in a response) and protocol version. The start line can be a request line (request) or a status line (response).

request message

The overall format of the request message is as follows:

Among them: start line format:命令名称+目标URI+sip协议版本

The request message includes the following request commands:

response message

The initial behavior of the response message is the status line (Status-Line). The status line consists of the protocol version, status code and status reason phrase, and each part is separated by a space character. The status codes are described below.

The SIP protocol defines 6 types of status codes. The first digit of the status code is used to indicate the response type, and the last two digits indicate the specific response. The following uses "1xx" to identify responses with status codes between "100-199".

1xx: Provisional response, indicating that the request message is being processed;
2xx: Successful response, indicating that the request has been successfully received, fully understood and accepted;
3xx: Redirect response, indicating that further steps are required to complete the request;
4xx: client error, indicating that the request message contains syntax error information or the server cannot complete the client request;
5xx: server error, indicating that the server cannot complete a legitimate request;
6xx: Global failure, indicating that no server can complete the request;

The overall format of the response message is as follows:

Among them: start line format:sip协议版本+响应返回码+描述性短句

The response message is a return code from 100 - 699, which have different meanings.

The message return code can be viewed: SIP protocol format

SIP header

For details of the SIP header field, please refer to: https://blog.csdn.net/qui910/article/details/122683453

It is used to transfer message properties and modify message meaning. They are syntactically and semantically identical to HTTP header fields (in fact some headers are borrowed from HTTP), and always maintain the format: <name>:<value>.

Example:

The following table describes the various Key values in the SIP header format, which can be roughly divided into 4 categories: General general header field, Request request header field, Response response header field, and Entity entity field.

General	Request	Response	Entity
Accept	Authorization	Allow	Content-encoding
Accept-encoding	Contact	Proxy-authenticate	Content-length
Accept-language	Hide Retry-after	Content-type
Call-ID	Max-forwards	Server
Contact	Organization	Unsupported
Cseq	Priority	Warning
Date	Proxy-authorization	WWW-authenticate
Encryption	Proxy-require
Expires	Route
From	Require
Record-route	Response-key
Timestamp	Subject
To	User-agent
Via

For details, please refer to: SIP protocol-04 SIP header field

message body

Used to describe the session being initiated (for example, in a multimedia session including audio and video encoding types, sampling rates, etc.). Message bodies can be displayed in requests and responses.

SIP clearly distinguishes the signaling information conveyed in the SIP start line and header from the session description information outside the scope of SIP. Possible message body types include the SDP session description protocol described in this article, as well as xml-based message bodies.

4. SDP agreement

The full name of SDP is Session Description Protocol, which translates to a protocol that describes sessions . It is mainly used for media negotiation between two session entities.

The SDP description consists of many text lines, the format of the text line is <type>=<value>, expressed as key=value;

SIP is responsible for establishing and releasing sessions. Generally speaking, sessions contain related media, such as video and audio. Media data is described by SDP. SDP is generally not used alone, it will be put into the body of the SIP protocol when it is used in conjunction with SIP. When a session is established, media negotiation is required so that both parties can determine each other's media capabilities and exchange media data (this is the job of sdp).

Then why do you want to send this description text? It is mainly to solve the problem of unequal capabilities among the members participating in the conversation. If the members participating in this call support high-quality calls, but we have not made an agreement, for the sake of compatibility sex, all of them use normal-quality call formats, which is a waste of resources. So the role of SDP is still very necessary.

When the content contained in the SIP protocol is SDP, the Content-Type should be set to application/sdp. The SDP protocol was released in RFC4566.

Example:

4.1 Introduction to SDP

SDP is the abbreviation of Session Description Protocol, which is a format for describing streaming media initialization parameters, and is promulgated by IETF as RFC 4566. Streaming media refers to what is seen or heard during transmission, and SDP packets usually include the following information:

session information

Session name and purpose.
Session active time.

Since resources to participate in a session are limited, it is useful to include the following additional information.

Bandwidth information used by the session.
Contact information for the session leader.

media information

Media type, such as video and audio.
Transport protocols such as RTP/UDP/IP and H.320.
Media formats such as H.261 video and MPEG video.
Multicast address and media transport port (IP multicast session).
The remote address of the media and transport port used to contact the address (IP unicast session).

The SDP description consists of many text lines, the format of which is <type>=<value>, where <type> is a letter, and <value> is a structured text string whose format depends on <type>. Spaces are not allowed on both sides of "=", and multiple parameters in a value are separated by spaces.

4.2 SDP protocol format

The SDP session description consists of a session-level description (session_level description) and multiple media-level descriptions (media_level description). The scope of the session level (session_level) is the entire session. Its position is from the 'v=' line to the first media description. The media level (media_level) description is a description of a single media stream (for example, a vlc sdp file that transmits a single audio or video has only a few short sentences, starting with m=, which is actually a description of a media machine), and its location is From the 'm=' line to the next media description. In short, unless the media part is overloaded, the session-level value is the default default value of each media (that is to say, the media-level description is actually a session-level description, but the session-level description parameters that are not written out use the default value) .

For details, please refer to: Detailed Explanation of SDP Format

v= （协议版本）
o= （所有者/创建者和会话标识符）
s= （会话名称）
i=* （会话信息）
u=* （URI 描述）
e=* （Email 地址）
p=* （电话号码）
c=* （连接信息 ― 如果包含在所有媒体中，则不需要该字段）
b=* （带宽信息）
一个或更多时间描述（如下所示）：

z=* （时间区域调整）
k=* （加密密钥）
a=* （0个或多个会话属性线路）
0个或多个媒体描述（如下所示）
时间描述

t= （会话活动时间）
r=* （0或多次重复次数）
媒体描述

m= （媒体名称和传输地址）
i=* （媒体标题）
c=* （连接信息 — 如果包含在会话层则该字段可选）
b=* （带宽信息）
k=* （加密密钥）
a=* （0个或多个会话属性线路）

4.3 SDP example

# 请求视频流
INVITE sip:[email protected]:7100 SIP/2.0
Via: SIP/2.0/UDP 192.168.40.55:7100;rport;branch=z9hG4bK2480933505
From: <sip:[email protected]:7100>;tag=2249831759
To: <sip:[email protected]:7100>
Call-ID: 821763613                // Call-ID：使用该字段标识一路视频
CSeq: 20 INVITE
Contact: <sip:[email protected]:7100>
Content-Type: Application/SDP
Max-Forwards: 70
User-Agent: NCG V2.6.0.299938
Subject: 00000000001310018021:0,120105110228023020:0
Content-Length:   239

v=0
o=00000000001310018021 0 0 IN IP4 192.168.40.55
s=Play                        //Play标识为点播请求   Playback标识回播请求
c=IN IP4 192.168.40.55            //192.168.40.55:音视频流目的地址
t=0 0                        //t行第一参数为视频开始时间  第二个参数为结束时间    t = 0 0表示实时视音频点播
m=video 5552 RTP/AVP 96 97 98   //video:表示请求音视频流  audio：表示请求音频流  5522:音视频流目的端口  RTP/AVP:视频流使用协议 96 97 98:客户端支持码流格式
a=rtpmap:96 PS/90000
a=rtpmap:97 MPEG4/90000
a=rtpmap:98 H264/90000
a=recvonly
a=streamMode:MAIN
y=0999999999

# 返回100 trying
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.40.55:7100;rport=7100;branch=z9hG4bK2480933505
From: <sip:[email protected]:7100>;tag=2249831759
To: <sip:[email protected]:7100>
Call-ID: 821763613
CSeq: 20 INVITE
User-Agent: NCG V2.6.0.299938
Content-Length: 0

# 携带sdp返回 200
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.40.55:7100;rport=7100;branch=z9hG4bK2480933505
From: <sip:[email protected]:7100>;tag=2249831759
To: <sip:[email protected]:7100>;tag=2885333649
Call-ID: 821763613
CSeq: 20 INVITE
Contact: <sip:[email protected]:7100>
Content-Type: Application/SDP
User-Agent: NCG V2.6.0.299938
Content-Length:   165

v=0
o=00000000001310018021 0 0 IN IP4 192.168.40.55
s=Play                
c=IN IP4 192.168.40.66    //192.168.40.66:音视频流源地址      注：视音频源与目的地址不局限于级联服务器本身
t=0 0
m=video 5268 RTP/AVP 96     // video:表示请求视频流  audio：表示请求音频流  5268:音视频流源端口  RTP/AVP:视频流使用协议 96:服务端所选择的码流格式   音视频所使用端口统一使用偶数端口   port+1为rtcp端口
a=rtpmap:96 PS/90000
a=sendonly
y=0100005268

SDP字段说明：

v字段：协议版本
o字段：-
a字段：a=rtpmap:<payload type> <encoding name>/<clock rate>  [/<encoding parameters>] 中的<encoding name>,利用该属性携带编码器厂商名称。该属性表明该流为某厂商编码器编码且是不符合gb28181规定的媒体流，符合国标的媒体流不需要该属性。
例如：a=rtpmap:96 DAHUA/90000
    a=rtpmap:96 HIKVISION/90000
a字段有下列格式：
a字段可携带倍数参数，用于文件下载时控制下载速度。格式： a=downloadspeed：下载倍数（整型）
a字段可携带文件大小参数，用于文件下载时的进度计算。格式： a=filesize:文件大小 （单位：Byte）
a字段可携带setup、connection作为TCP连接协商参数。 a=setup：TCP连接方式（表示本SDP发送者在建立RTP over TCP连接时是主动还是被动发起TCP连接，“active”为主动，“passive”为被动）
a字段可携带SVC参数，用于视频传输时的分辨率或者帧频控制。a=svcspace：空域编码方式 【取值整型。 0：不使用  1：1级增强  2：2级增强  3：3级增强 】  a = svctime：时域编码方式

s字段：表示请求媒体流的操作类型，“Play”标识为点播请求   “Playback”标识回播请求   “Download”表示文件下载  “Talk”表示语音对讲；
u字段：u行应填写视音频文件的URL。该URL的取值有两种：简捷方式和普通方式。简捷方式直接采用产生该历史媒体的媒体源（如某个摄像头）的设备ID以及相关参数，参数用“：”分隔；普通方式采样http://储存设备ID[/文件夹]*/文件名；
m字段：描述媒体的媒体类型、端口、传输层协议、负载类型等内容。媒体类型采样“video”标识视频或者视音频混合内容，采样“audio”标识传输音频内容；传输方式采用“RTP/AVP”标识传输层协议为 RTP over UDP，采用“TCP/RTP/AVP”标识传输层协议为RTP over TCP；
t字段：当回放或者下载时，t行值为开始时间，结束时间，采样“ ”分隔；
y字段：十进制整数字符串，标识SSRC值。其中第一位为历史或者实时媒体流的标识位，0为实时，1为历史；第2位到第6位取20位SIP监控域ID之中的4-8位作为域标识；第7-10位作为域内媒体流标识，是一个与当前域内产生的媒体流SSRC值后4位不充分的四位十进制整数；
f字段：f=v/编码格式/分辨率/帧率/码率类型/码率大小  a/编码格式/码率大小/采样率    其中v表示video   a表示audio

5. Signaling service, streaming media service reference address

Signaling service: https://github.com/648540858/wvp-GB28181-pro

Streaming media service: GitHub - ZLMediaKit/ZLMediaKit: WebRTC/RTSP/RTMP/HTTP/HLS/HTTP-FLV/WebSocket-FLV/HTTP-TS/HTTP-fMP4/WebSocket-TS/WebSocket-fMP4/GB28181/SRT server and client framework based on C++11

references _

[1] GB/T 28181—2016. Information transmission, exchange, and control technical requirements for security and prevention video surveillance networked systems [D]. , 2016.

[2] Rosenberg J, Schulzrinne H, Camarillo G, et al. RFC3261: SIP: session initiation protocol[J]. 2002.

[3] Casner S, Frederick R, Jacobson V, et al. RFC 3550, RTP: A Transport Protocol for Real-Time Applications[J]. Network Working Group, 2003.

[4] Handley M, Jacobson V, Perkins C. RFC 4566: SDP: session description protocol[J]. 2006.

[5] Donovan S. IETF RFC 2976 the SIP INFO Method[J]. 2000.

[6] RFC3428 I. SIP extension for instant messaging[J]. 2002.

[7] Rosenberg J, Schulzrinne H. IETF RFC 3581[J]. An Extension to the Session Initiation, 2003.

[8] Rec I. H. 222.0| ISO/IEC 13818-1: 2000[J]. Information Technology—Generic coding of moving pictures and associated audio—Part, 1.

[9] Hoffman D, Fernando G, Goyal V, et al. RFC2250: RTP payload format for MPEG1/MPEG2 video[J]. 1998.