GB28181/SIP/SDP protocol

Preface

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 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 " 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.

2. National standard GB28181 protocol: signaling process

2.1 National Standard GB28181 Agreement

The GB28181 protocol session channel actually uses the SIP protocol, and some privatization processing is done based on 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 a variety of multimedia elements including video, voice, instant messaging, online gaming and virtual reality.

One of the more important concepts in SIP is User Agent, which refers to a SIP logical network endpoint and is used to create, send, receive SIP messages and manage a SIP session.

SIP user agents 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 works together with many other protocols, such as the SIP message content sending Session Description Protocol (SDP). The SDP protocol describes the details of the streaming media used in the session, such as: which IP port is used, which encoding is used decoder and so on.

A typical use of SIP is: SIP sessions transmit some simple real-time transmission 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: session channel and media streaming channel. The session channel is used to establish sessions between devices and transmit system control commands; the media stream channel is used to transmit video and audio data. The compressed and encoded video and audio streams are transmitted using the streaming media protocol RTP/RTCP. The specific communication protocol structure diagram in the GB28181 protocol is shown below (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 REGISTER, INVITE and other request and response methods specified in the SIP protocol IETF RFC3261. The historical video and audio playback control uses the SIP extended protocol IETF RFC29765. The specified INFO method is implemented, and the session control of applications such as front-end device 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 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 the GB28181 protocol is shown in the figure below (schematic diagram of 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 other excellent articles on the implementation of GB28181, you can check the homepage article:

1.GB28181 Streaming Media Series Articles

2. Chapter 1: Registering to the superior platform series of articles

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

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:

1. REGISTER sip:34020000002000000001@3402000000 SIP/2.0

2. Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1371463273

3. From: sip:34020000001320000003@3402000000;tag=2043466181

4. To: sip:34020000001320000003@3402000000

5. Call-ID: 1011047669

6. CSeq: 1 REGISTER

7. Contact: sip:[email protected]:5060

8. Max-Forwards: 70

9. User-Agent: IP Camera

10. Expires: 3600

11. Content-Length: 0

The registration request header field parameters are explained as follows:

1. 第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. 第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. 第3行为From头，From头中包含了请求发送方的逻辑标识，在GB28181协议中是发送请求的设备国标ID和域国标ID信息。tag参数是为了身份认证的，值为随机数字字符。

4. 第4行为To头，To头在SIP协议中是为了标明请求接收方的逻辑标识的，在GB28181协议中填写的是发送请求的设备国标ID和域国标ID信息。

5. 第5行为Call-ID头，Call-ID头是全局唯一的，在同一个session中保持一致，在不同session中不同。

6. 第6行为CSeq头，CSeq头又叫Command Seqence（命令队列），用于标识命令顺序，值为序号+Method，序号部分为无符号整数，最大值为2^31。序号起始值是随机的，后续在同一个session中依次递增，比如发1 REGISTER没返回--->再发2 REGISTER--->没返回--->再发3 REGISTER--->这时返回了2 REGISTER就知道是第2个请求得到了响应。对于ACK和CANCLE中的CSeq与INVITE中的Cseq保持一致。

7. 第7行为Contact头，Contact头包含源的URI信息，用来给响应消息直接和源建立连接用。在GB28181协议中为SIP设备编码@源IP地址端口。

8. 第8行为Max-Forwards头，Max-Forwards头用于设置包最大中转次数，默认是70。

9. 第9行为User-Agent头，User-Agent头用于设置关于UA的信息，用户可以自定义。

10. 第10行为Expires头，Expires头表示超时时间。

11. 第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:

1. SIP/2.0 200 OK

2. Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1371463273

3. From: sip:34020000001320000003@3402000000

4. To: sip:34020000001320000003@3402000000

5. CSeq: 1 REGISTER

6. Call-ID: 1011047669

7. Contact: sip:[email protected]:5060

8. User-Agent: FFmpeg GB28181 v1.0

9. Expires: 3600

10. Content-Length: 0

2.3 National title 28181: Daycare

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

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 (keep-alive command flow chart):

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:

1. MESSAGE sip:34020000002000000001@3402000000 SIP/2.0

2. Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1066375804

3. From: sip:34020000001320000003@3402000000;tag=1925919231

4. To: sip:34020000002000000001@3402000000

5. Call-ID: 1185236415

6. CSeq: 20 MESSAGE

7. Content-Type: Application/MANSCDP+xml

8. Max-Forwards: 70

9. User-Agent: IP Camera

10. Content-Length: 175

12. <?xml version="1.0" encoding="UTF-8"?>

13. <Notify>

14. <CmdType>Keepalive

15. <SN>1

16. <DeviceID>34020000001320000003

17. <Status>OK

18. <Info>

19. </Info>

20. </Notify>

The MESSAGE message header Content-type header is Content-type: Application/MANSCDP+xml. The status information reporting command is defined in the MANSCDP (Monitoring and Alarming Network System Control Description Protocol) protocol format. For 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. Neither the success nor the error response of the Message message has a message body. An example of the message content of the Message reply is as follows:

1. SIP/2.0 200 OK

2. Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1066375804

3. From: sip:34020000001320000003@3402000000

4. To: sip:34020000002000000001@3402000000

5. CSeq: 20 MESSAGE

6. Call-ID: 1185236415

7. User-Agent: FFmpeg GB28181 v1.0

8. Content-Length: 0

2.4 National 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, logo, MF, DF, 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 a continuous stream 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 contain multiple videos, audios, and text information. ES flow; each ES flow will be marked with a different PID. In order to analyze these ES flows, TS has some fixed PIDs used to send program and ES flow information at intervals: PAT and PMT tables. Suitable for environments with many bit errors

ES is the data stream that comes directly from the encoder. It can be an encoded video data stream, an audio data stream, or a collective 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. Send video stream on the port that the server listens on

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: 192.168.0.9 (Haikang 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

1. INVITE sip:34020000001310000002@4401020049 SIP/2.0

2. Call-ID: helloVideo

3. CSeq: 1 INVITE

4. From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111

5. To: <sip:34020000001110000001@4401020049>

6. Max-Forwards: 70

7. Contact: <sip:34020000001310000002@4401020049>

8. Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-bff9-4f3000002

9. Content-Type: application/sdp

10. Content-Length: 225

12. v=0

13. o=34020000001310000002 0 0 IN IP4 192.168.0.60

14. s=Play

15. c=IN IP4 192.168.0.60

16. t=0 0

17. m=video 6000 RTP/AVP 96 98 97

18. a=recvonly

19. a=rtpmap:96 PS/90000

20. a=rtpmap:98 H264/90000

21. a=rtpmap:97 MPEG4/90000

22. y=0100000001

23. f=

Step 2: [Client>>Server]

Reply 100 first

1. SIP/2.0 100 Trying

2. Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-bff9-4f3000002

3. From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111

4. To: <sip:34020000001110000001@4401020049>;tag=5f906952

5. Call-ID: helloVideo

6. CSeq: 1 INVITE

7. Server: Happytime Agent Ver 1.0

8. Content-Length: 0

Reply 200 again

1. SIP/2.0 200 OK

2. Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-bff9-4f3000002

3. From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111

4. To: <sip:34020000001110000001@4401020049>;tag=5f906952

5. Contact: <sip:34020000001110000001@4401020049>

6. Call-ID: helloVideo

7. CSeq: 1 INVITE

8. Max-Forwards: 70

9. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,UPDATE,INFO

10. Supported: timer

11. Session-Expires: 200;refresher=uac

12. Server: Happytime Agent Ver 1.0

13. Content-Type: application/sdp

14. Content-Length: 153

16. v=0

17. o=34020000001110000001 0 0 IN IP4 192.168.0.107

18. s=Play

19. c=IN IP4 192.168.0.107

20. t=0 0

21. m=video 19002 RTP/AVP 96

22. a=rtpmap:96 PS/90000

23. a=sendonly

Step 3: [Server>>Client] Reply ACK

1. ACK sip:34020000001310000002@4401020049 SIP/2.0

2. Call-ID: helloVideo

3. CSeq: 1 ACK

4. From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111

5. To: <sip:34020000001110000001@4401020049>

6. Max-Forwards: 70

7. Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-00003

8. Content-Length: 0

Step 4: Play the stream

Step 5: [Server>>Client] Stop video request

1. BYE sip:34020000001310000002@4401020049 SIP/2.0

2. From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111

3. To: sip:34020000001110000001@4401020049;tag=5f906952

4. CSeq: 2 BYE

5. Call-ID: helloVideo

6. Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-00004

7. Max-Forwards: 70

8. Content-Length: 0

Step 6: [Client] responds with 200

1. SIP/2.0 200 OK

2. Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-00004

3. From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111

4. To: sip:34020000001110000001@4401020049;tag=5f906952

5. Call-ID: helloVideo

6. CSeq: 2 BYE

7. Server: Happytime Agent Ver 1.0

8. Content-Length: 0

Step 7: [Server] Close the video port

3.SIP protocol

SIP (Session initialization Protocol) is a multimedia communication protocol developed by the IETF (Internet Engineering Task Force).

It is a text-based application layer control protocol used to create, modify and release sessions with one or more participants. SIP is an IP voice session control protocol originated 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 the establishment, cancellation, closing and other operations of sessions. It can mainly achieve the following functions:

User location: Check the end user’s location for communication;

User validity: Check the user's willingness to participate in the session;

User capabilities: Check media and media parameters;

Establishing a session: "Ring", a parameter that establishes a session between the calling and the called party at the same time;

Session management: including session transmission and termination, modifying session parameters and requesting services

At present, relevant equipment suppliers and service 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 introduction

3.1.1 SIP request

Request is one of the most basic concepts in SIP. Every operation on SIP requires sending a request.

3.1.2 SIP response

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

3.1.3 Transaction

The SIP protocol is a transactional protocol. The concept of transaction is based on request and reply. A request and related final reply constitute a transaction. (Excluding ACK processing) Since there will be multiple Transactions from the establishment to the end of a call, the Transaction needs to be uniquely marked. The only way to mark the Transaction in SIP is the branch parameter.

3.1.4 TU

After having the concept of Transaction, the concept of Transaction user emerged. Transaction is structured on Transaction and can manage Transaction.

3.1.5 Client Transaction 和Server Transaction

With the concept of Transaction, client Transaction and server Transaction appear based on the differences between requests and responses. CT refers to the part of the Transaction owned by the request initiator, and ST refers to the part owned by the recipient of the request.

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 and processes it is the UAS.

3.1.8 INVITE

Special Requests. 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 reply to the corresponding INVITE request. Modify it after the 2xx reply of the next INVITE request is sent or received. 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. The difference is 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 is similar to the role of a browser in the http protocol. It is the terminal interface for user operations. The user agent needs to comply with the requirements of the SIP protocol, but when combined with other protocols, there will be different implementations based on different application scenarios. logic. For example, the SIP protocol combined with the H.323VoIP protocol can realize the software phone function. User agents are divided into two logical entities: UAC (UA Client) and UAS (UA Server). UAC sends SIP Request and accepts Response. UAS receives SIP Request and returns Response. A physical device can be both UAC and UAS.

Proxy Server: The main function of the proxy server is to forward Request and Response to other Proxy Servers or UAs. Proxy Server is divided into stateful proxy server (Stateful Proxy) and stateless proxy server (Stateless Proxy). The former will retain a communication transaction. The state controls the forwarding operation through a finite state machine, which does not save the state but only implements transparent forwarding operations.

Registration/Location Server: The registration and location server is used to register and locate the UA. The online UA will regularly send SIP messages to the Registration server to indicate the UA's current location (such as IP address, port number, etc.), and the Registration server will send this information Store it in the database (or hash table), and the location of the UA can be obtained when other UA sends a request to the UA.

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;

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 server's capabilities;

The REGISTER message is used to send registration request messages.

The type of SIP request, also called the SIP method. Six methods are defined in RFC3261. The other eight methods are described in separate RFC extensions. Such as INFO, NOTIFY, etc.

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 mode 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/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 opening line conveys the message type (method type in requests, response code in responses) and protocol version. The starting 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: starting line format: command name + target URI + sip protocol version

The request message includes the following request commands:

response message

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

A total of 6 types of status codes are defined in the SIP protocol. 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 need to be taken 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 legitimate requests;

6xx: Global failure, indicating that any server cannot complete the request;

The overall format of the response message is as follows:

Among them: starting line format: sip protocol version + response return code + descriptive phrase

The response message is a return code from 100 - 699, each representing different meanings.

The message return code can be viewed: SIP protocol format

SIP header

Details of the SIP header field can be found at: https://blog.csdn.net/qui910/article/details/122683453

Used to transfer message attributes 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 four categories: General header field, Request header field, 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 type, sample rate, etc.). The message body can be displayed in requests and responses.

SIP clearly distinguishes between signaling information conveyed in the SIP start line and headers and session description information outside the scope of SIP. Possible message body types include the SDP session description protocol to be described in this article, and XML-based message bodies.

4.SDP protocol

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

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

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

Then why should we send this description text? It is mainly to solve the problem of unequal capabilities among the members participating in the conversation. If all the members participating in this call support high-quality calls, but we have not carried out an agreement, for the sake of compatibility gender, using ordinary quality call formats, which is a waste of resources. Therefore, the role of SDP is still necessary.

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

Example:

4.1 Introduction to SDP

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

session information

Session name and purpose.

Session active time.

Since resources participating 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 types 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 ports used to contact the address (IP unicast session).

The SDP description consists of many text lines. The format of the text line is <type>=<value>, <type> is a letter, and <value> is a structured text string, and its format depends on <type>. No spaces are allowed on either side 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 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 describes a single media stream (for example, a vlc sdp file that transmits a single audio or video only has a few sentences, starting with m=, which is actually a media machine description), and its location is Starting from the 'm=' line and ending with the next media description. In short, unless the media part is overloaded, the session-level value is the default value of each media (that is, 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

1. v= （协议版本）

2. o= （所有者/创建者和会话标识符）

3. s= （会话名称）

4. i=* （会话信息）

5. u=* （URI 描述）

6. e=* （Email 地址）

7. p=* （电话号码）

8. c=* （连接信息 ― 如果包含在所有媒体中，则不需要该字段）

9. b=* （带宽信息）

10. 一个或更多时间描述（如下所示）：

12. z=* （时间区域调整）

13. k=* （加密密钥）

14. a=* （0个或多个会话属性线路）

15. 0个或多个媒体描述（如下所示）

16. 时间描述

18. t= （会话活动时间）

19. r=* （0或多次重复次数）

20. 媒体描述

22. m= （媒体名称和传输地址）

23. i=* （媒体标题）

24. c=* （连接信息 — 如果包含在会话层则该字段可选）

25. b=* （带宽信息）

26. k=* （加密密钥）

27. a=* （0个或多个会话属性线路）

4.3 SDP examples

1. # 请求视频流

2. INVITE sip:[email protected]:7100 SIP/2.0

3. Via: SIP/2.0/UDP 192.168.40.55:7100;rport;branch=z9hG4bK2480933505

4. From: <sip:[email protected]:7100>;tag=2249831759

5. To: <sip:[email protected]:7100>

6. Call-ID: 821763613 // Call-ID：使用该字段标识一路视频

7. CSeq: 20 INVITE

8. Contact: <sip:[email protected]:7100>

9. Content-Type: Application/SDP

10. Max-Forwards: 70

11. User-Agent: NCG V2.6.0.299938

12. Subject: 00000000001310018021:0,120105110228023020:0

13. Content-Length: 239

15. v=0

16. o=00000000001310018021 0 0 IN IP4 192.168.40.55

17. s=Play //Play标识为点播请求 Playback标识回播请求

18. c=IN IP4 192.168.40.55 //192.168.40.55:音视频流目的地址

19. t=0 0 //t行第一参数为视频开始时间 第二个参数为结束时间 t = 0 0表示实时视音频点播

20. m=video 5552 RTP/AVP 96 97 98 //video:表示请求音视频流 audio：表示请求音频流 5522:音视频流目的端口 RTP/AVP:视频流使用协议 96 97 98:客户端支持码流格式

21. a=rtpmap:96 PS/90000

22. a=rtpmap:97 MPEG4/90000

23. a=rtpmap:98 H264/90000

24. a=recvonly

25. a=streamMode:MAIN

26. y=0999999999

28. # 返回100 trying

29. SIP/2.0 100 Trying

30. Via: SIP/2.0/UDP 192.168.40.55:7100;rport=7100;branch=z9hG4bK2480933505

31. From: <sip:[email protected]:7100>;tag=2249831759

32. To: <sip:[email protected]:7100>

33. Call-ID: 821763613

34. CSeq: 20 INVITE

35. User-Agent: NCG V2.6.0.299938

36. Content-Length: 0

38. # 携带sdp返回 200

39. SIP/2.0 200 OK

40. Via: SIP/2.0/UDP 192.168.40.55:7100;rport=7100;branch=z9hG4bK2480933505

41. From: <sip:[email protected]:7100>;tag=2249831759

42. To: <sip:[email protected]:7100>;tag=2885333649

43. Call-ID: 821763613

44. CSeq: 20 INVITE

45. Contact: <sip:[email protected]:7100>

46. Content-Type: Application/SDP

47. User-Agent: NCG V2.6.0.299938

48. Content-Length: 165

50. v=0

51. o=00000000001310018021 0 0 IN IP4 192.168.40.55

52. s=Play

53. c=IN IP4 192.168.40.66 //192.168.40.66:音视频流源地址 注：视音频源与目的地址不局限于级联服务器本身

54. t=0 0

55. m=video 5268 RTP/AVP 96 // video:表示请求视频流 audio：表示请求音频流 5268:音视频流源端口 RTP/AVP:视频流使用协议 96:服务端所选择的码流格式 音视频所使用端口统一使用偶数端口 port+1为rtcp端口

56. a=rtpmap:96 PS/90000

57. a=sendonly

58. y=0100005268

60. SDP字段说明：

62. v字段：协议版本

63. o字段：-

64. a字段：a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>] 中的<encoding name>,利用该属性携带编码器厂商名称。该属性表明该流为某厂商编码器编码且是不符合gb28181规定的媒体流，符合国标的媒体流不需要该属性。

65. 例如：a=rtpmap:96 DAHUA/90000

66. a=rtpmap:96 HIKVISION/90000

67. a字段有下列格式：

68. a字段可携带倍数参数，用于文件下载时控制下载速度。格式： a=downloadspeed：下载倍数（整型）

69. a字段可携带文件大小参数，用于文件下载时的进度计算。格式： a=filesize:文件大小 （单位：Byte）

70. a字段可携带setup、connection作为TCP连接协商参数。 a=setup：TCP连接方式（表示本SDP发送者在建立RTP over TCP连接时是主动还是被动发起TCP连接，“active”为主动，“passive”为被动）

71. a字段可携带SVC参数，用于视频传输时的分辨率或者帧频控制。a=svcspace：空域编码方式 【取值整型。 0：不使用 1：1级增强 2：2级增强 3：3级增强 】 a = svctime：时域编码方式

73. s字段：表示请求媒体流的操作类型，“Play”标识为点播请求 “Playback”标识回播请求 “Download”表示文件下载 “Talk”表示语音对讲；

74. u字段：u行应填写视音频文件的URL。该URL的取值有两种：简捷方式和普通方式。简捷方式直接采用产生该历史媒体的媒体源（如某个摄像头）的设备ID以及相关参数，参数用“：”分隔；普通方式采样http://储存设备ID[/文件夹]*/文件名；

75. m字段：描述媒体的媒体类型、端口、传输层协议、负载类型等内容。媒体类型采样“video”标识视频或者视音频混合内容，采样“audio”标识传输音频内容；传输方式采用“RTP/AVP”标识传输层协议为 RTP over UDP，采用“TCP/RTP/AVP”标识传输层协议为RTP over TCP；

76. t字段：当回放或者下载时，t行值为开始时间，结束时间，采样“ ”分隔；

77. y字段：十进制整数字符串，标识SSRC值。其中第一位为历史或者实时媒体流的标识位，0为实时，1为历史；第2位到第6位取20位SIP监控域ID之中的4-8位作为域标识；第7-10位作为域内媒体流标识，是一个与当前域内产生的媒体流SSRC值后4位不充分的四位十进制整数；

78. f字段：f=v/编码格式/分辨率/帧率/码率类型/码率大小 a/编码格式/码率大小/采样率 其中v表示video a表示audio

5. Signaling service and 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. Technical requirements for information transmission, exchange, and control of security video surveillance network 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.