前言
GB28181协议是视频监控领域的国家标准，本文将解析如何在FFmpeg中增加对GB28181协议的支持，使其可以与支持GB28181协议的设备进行通信与控制，实现设备的注册、保活以及流媒体的传输。
本文内容由复旦大学软件工程硕士z7-iReview总结，极为精练。有需要可关注其博客，内有更多关于28181协议的文章内容。
1.背景介绍
GB28181协议指的是国家标准GB/T 28181—2016《公共安全视频监控联网系统信息传输、交换、控制技术要求》。
该标准规定了公共安全视频监控联网系统的互联结构， 传输、交换、控制的基本要求和安全性要求， 以及控制、传输流程和协议接口等技术要求，是视频监控领域的国家标准。
GB28181协议信令层面使用的是SIP（Session Initiation Protocol）协议。流媒体传输层面使用的是实时传输协议（Real-time Transport Protocol，RTP）协议。
因此可以理解为GB28181是在国际通用标准的基础之上进行了私有化定制以满足视频监控联网系统互联传输的标准化需求。本文旨在说明在FFmpeg中增加对GB28181协议的支持，使其可以与支持GB28181协议的设备进行通信与控制，实现设备的注册、保活以及流媒体的传输。
无理工科基础的安防工程师，看到这里就可以了，知道28181是个啥就行了。想进一步了解28181可继续阅读
2.国标GB28181协议：信令流程
2.1 国标GB28181协议
GB28181协议会话通道实际上使用的是SIP协议，并且在SIP协议的基础之上做了些私有化处理。SIP是一个由IETF MMUSIC工作组开发的协议，作为标准被提议用于创建，修改和终止包括视频，语音，即时通信，在线游戏和虚拟现实等多种多媒体元素在内的交互式用户会话。
SIP中一个比较重要的概念是用户代理（User Agent），指的是一个SIP逻辑网络端点，用于创建、发送、接收SIP消息并管理一个SIP会话。
SIP用户代理又可分为用户代理客户端UAC（User Agent Client）和用户代理服务端UAS（User Agent Server）。UAC创建并发送SIP请求，UAS接收处理SIP请求，发送SIP响应。
SIP协议会与许多其它的协议协同工作，如SIP报文内容发送会话描述协议（Session Description Protocol，SDP）,SDP协议描述了会话所使用流媒体细节，如：使用哪个IP端口，采用哪种编解码器等等。
SIP的一个典型用途是：SIP会话传输一些简单的经过报文的实时传输协议流，RTP本身才是语音或视频的载体。在GB28181协议中，联网系统在进行视音频传输及控制时应建立两个传输通道: 会话通道和媒体流通道。会话通道用于在设备之间建立会话并传输系统控制命令; 媒体流通道用于传输视音频数据， 经过压缩编码的视音频流采用流媒体协议RTP/RTCP传输。GB28181协议中具体通信协议结构图如下图（通信协议结构图）所示：
详细可参考国标GB28181需求文档：链接: https://pan.baidu.com/s/1aqlF6mQPNUE4KMIUf3JU8A?pwd=jb6v 提取码: jb6v
会话通道中，注册、实时视音频点播、历史视音频的回放等应用的会话控制采用SIP协议IETF RFC3261中规定的REGISTER、INVITE等请求和响应方法实现， 历史视音频回放控制采用SIP扩展协议IETF RFC29765规定的INFO方法实现，前端设备控制、信息查询、报警事件通知和分发等应用的会话控制采用SIP扩展协议IETF RFC34287规定的MESSAGE方法实现。下面详细介绍下注册、保活和实时视音频点播的SIP消息结构。
2.2 国标28181：注册
注册指的是设备或系统进入联网系统时向SIP服务器（SIP UAS）进行注册登记的工作模式，在本文中FFmpeg即为一个SIP服务器，设备向FFmpeg发送注册请求，FFmpeg在接收到设备的注册请求后返回相应的回复消息，则完成设备注册流程。GB28181协议中基于数字摘要的挑战应答式安全技术进行注册流程如下图（ 基本注册流程示意图）所示：
详情可参考国网技术要求文档：【附录B.1注册】链接: https://pan.baidu.com/s/1_bn-K2CML_OPxQRO4VDdhQ?pwd=6sb9 提取码: 6sb9
其他优秀文章的GB28181的实现，可以查阅主页文章：
注册流程描述如下:
- SIP代理向SIP服务器发送Register请求;
- SIP服务器向SIP代理发送响应401，并在响应的消息头WWW_Authenticate字段中给出适合SIP代理的认证体制和参数;
- SIP代理重新向SIP服务器发送REGISTER请求， 在请求的Authorization字段给出信任书，包含认证信息;
- SIP服务器对请求进行验证，如果检查出SIP代理身份合法，向SIP代理发送成功响应200OK，如果身份不合法则发送拒绝服务应答。
注册的请求消息内容范例如下：
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:34020000001320000003@192.168.137.11:5060 Max-Forwards: 70 User-Agent: IP Camera Expires: 3600 Content-Length: 0
注册请求头域参数解释如下：
第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。
注册的回复消息内容范例如下，各头信息含义见上面：
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:34020000001320000003@192.168.137.11:5060 User-Agent: FFmpeg GB28181 v1.0 Expires: 3600 Content-Length: 0
2.3 国标28181：保活
当UA发现工作异常时， 应立即向本SIP监控域的SIP服务器发送状态信息; 无异常时，应定时向本SIP监控域的SIP服务器发送状态信息。状态信息报送采用IETF RFC3427中定义的方法MESSAGE实现。通过周期性的状态信息报送，实现注册服务器与源设备之间的状态检测即心跳机制。
心跳发送方、接收方需统一配置“心跳间隔”参数，按照“心跳间隔”定时发送心跳消息，默认心跳间隔60s。心跳发送方、接收方需统一配置“心跳超时次数”参数，心跳消息连续超时达到“心跳超时次数”则认为对方下线，默认心跳超时次数3次。心跳接收方在心跳发送方上线状态下检测到心跳消息连续超时达到商定次数则认为心跳发送方离线; 心跳发送方在心跳接收方上线状态下检测到心跳消息响应消息连续超时达到商定次数则认为心跳接收方离线。具体命令流程如下图（保活命令流程图）：
命令流程描述如下:
(a) 源设备向SIP服务器发送设备状态信息报送命令。设备状态信息报送命令采用MESSAGE方法携带;
(b) SIP服务器收到命令后返回200 OK。
保活消息内容范例如下：
ESSAGE 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消息头Content-type头为Content-type: Application/MANSCDP+xml。状态信息报送命令采用MANSCDP（监控报警联网系统控制描述协议，Monitoringand Alarming Network System Control Description Protocol）协议格式定义， 详细描述见【GB/T 28181—2016中A.2.5状态信息报送】。状态信息报送命令应包括命令类型(CmdType)、设备/系统编码(DeviceID)、是否正常工作(Status)等， 采用MESSAGE方法的消息体携带。Message消息的成功和错误应答均无消息体，
Message回复消息内容范例如下：
IP/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 国标28181：实时视频播放
视频流格式
GB28181要求传输的视频流格式为PS流，或者H264流，或者MP4格式。
可以用wireshark抓包，数据报类型是RTP的PS流
国标流媒体服务器其实就是负责将GB28181设备或者平台推送的PS流转成ES流，然后提供RTSP、RTMP、FLV、HLS等格式进⾏分发。
PS流和ES流的区别
P数据报有⾸部和数据两部分组成的，⾸部的前⼀部
分是固定长度20字节，是所有IP数据报必须具有的。⾸部包括：总长度、标识、MF、DF、⽚偏移。
数字信号实际传送的是数据流，⼀般数据流包括以下三种：
- ES流(Elementary Stream)：也叫基本码流，包含视频、⾳频或数据的连续码流。
- PES流(Packet Elementary Stream)：也叫打包的基本码流，是将基本的码流ES流根据需要分成长度不等的数据包，并加上包头就形成了打包的基本码流PES流。
- TS流：也叫传输流，是由固定长度为188字节的包组成，含有独⽴时基的⼀个或多个program, ⼀个program⼜可以包含多个视频、⾳频、和⽂字信息的ES流; 每个ES流会有不同的PID标⽰，为了可以分析这些ES流, TS有⼀些固定的PID⽤来间隔发送program和ES流信息的表格: PAT和PMT表。适⽤于误码较多的环境
ES 是直接从编码器出来的数据流，可以是编码过的视频数据流，⾳频数据流，或其他编码数据流的统称。 ES 流经过PES 打包器之后，被转换成 PES 包，再通过RTSP、RTMP、FLV、HLS格式分发出去，实现WEB、⼿机、PC、微信等多终端的播。
传播方式
GBT28181协议规定码流使用RTP包负载，推荐为PS流，也可以是ES流，对于媒体流的传输在原有UDP传输的基础中，增加了主动tcp和被动tcp的方式。
- UDP被动
这个是普遍的传输方式。GB28181流媒体服务器监听单个UDP端口，然后发送一个SIP信令(INVITE)，其携带的SDP中包含了接收媒体的端口设备端收到信令后，解析该端口，然后设备主动通过UDP向流媒体服务端监听的那个端口上发送视频流
- TCP被动
有两种，一种是主动，一种是被动
对于主动： 设备端告知服务端自己的媒体流tcp端口，服务端主动去连接设备端的该端口，获取数据。。这种场景应用较少，可以忽略
对于被动：流媒体服务器监听单个TCP端口，然后通过SIP信令(INVITE)告诉设备端口，设备主动向当前流媒体服务端发送视频流，基本等同于UDP流。
实时视频流程
前提：注册成功>>>>>>心跳成功>>>>>>设备目录查询>>>>>实时视频观看
服务端步骤
不管是TCP方式看，还是UDP方式看，其步骤都为：
- 打开视频端口
- 发送实时视频请求
- 等待设备回复200OK
- 发送ACK
- 播放码流
- 停止视频请求
- 关闭视频端口
- 普通等待
抓包分析
测试设备IP：192.168.0.9（海康NVR设备）
服务端IP：192.168.0.28（本地ip）
实时视频建立_UDP
第零步：【服务端】打开视频端口
第一步：【服务端>>客户端】请求播放视频
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=
第二步：【客户端>>服务端】
先回复100
IP/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: 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
第三步：【服务端>>客户端】回复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
第四步：播放码流
第五步：【服务端>>客户端】停止视频请求
YE 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
第六步：【客户端】回应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
第七步：【服务端】关闭视频端口
3.SIP协议
SIP（Session initialization Protocol，会话初始协议）是由IETF（Internet Engineering Task Force，因特网工程任务组）制定的多媒体通信协议。
它是一个基于文本的应用层控制协议，用于创建、修改和释放一个或多个参与者的会话。SIP 是一种源于互联网的IP 语音会话控制协议，具有灵活、易于实现、便于扩展等特点。SIP（Session Initiation Protocol）是一种类似于http协议的纯文本应用层协议。SIP可以用来控制会话的建立、取消、关闭等操作。主要可以实现以下功能：
- 用户定位：检查终端用户的位置，用于通信；
- 用户有效性：检查用户参与会话的意愿程度；
- 用户能力：检查媒体和媒体参数；
- 建立会话：“振铃”，在呼叫和被叫方同时建立会话的参数；
- 会话管理：包括会话的传输和终止，修改会话参数以及请求服务
目前相关设备供应商和业务供应商联合成立了一个关于SIP的论坛：http://www.sipforum.org，为SIP的发展提供一个自由讨论、展现新思维的发展平台
3.1 概念讲述
3.1.1 SIP request
请求是SIP中一个最基本的概念之一，每一次关于SIP的操作都需要发送请求。
3.1.2 SIP response
回复和请求在SIP中一般都是成对出现，回复中的内容是对端关于请求的处理结果。
3.1.3 Transaction
SIP协议是一种事务型协议。transaction的概念建立在请求和回复之上，一个请求和相关的最终回复就组成了一个transaction。（不包括关于ACK的处理）由于在一次通话建立到结束的过程中，会有多个Transaction，所以需要对Transaction进行唯一性标记，在SIP中对Transaction进行唯一标记的是branch参数
3.1.4 TU
在具备Transaction的概念之后，就出现了Transaction user的概念，Transaction架构在Transaction 上，能够对Transaction进行管理。
3.1.5 Client Transaction 和Server Transaction
有了Transaction的概念之后，针对请求和回复的不同就出现了client Transaction和server Transaction。CT指的是请求发起者所具有的Transaction的部分，ST是请求的接受者所具有的部分。
3.1.6 用户代理 UA（User Agent）
UA指的是一个用户实体。
3.1.7 UAC和UAS用户代理服务器端（User Agent Server）
实际发起请求的用户实体就是UAC，实际接收请求进行处理的用户实体就是UAS。
3.1.8 INVITE
特殊请求。SIP协议中最关键的请求。用于发起会话。
3.1.9 session
session，在收到对应的INVITE请求的2xx回复之后，完成建立。在下一次INVITE请求的2xx回复发送或者收到后进行修改，唯一一种结束方式为发送或者收到bye请求。
3.2.0 dialog
dialog的概念和session的概念类似，不同的是dialog是针对信令交互的一种概念，而session是对实际媒体发送和接收流程的描述。dialog的建立时间也是在接收到信令的200 OK回复之后，结束也是在发送或者接收到bye请求之后。
3.2 SIP的结构
在SIP协议中主要包含以下几种逻辑上的角色：UA、Proxy Server、 Register/Location Server、Redirect Server。
- UA：用户代理（User Agent）类似于http协议中浏览器的角色，是用户操作的终端界面，用户代理需要符合SIP协议的要求，但是结合其他的协议根据不同的应用场景，会有不同的实现逻辑。比如，SIP协议结合H.323VoIP协议可以实现软件电话功能。用户代理分为UAC（UA Client）和UAS（UA Server）两种逻辑实体，UAC发送SIP Request并接受Response，UAS接收SIP Request并返回Response，一个物理设备既可以是UAC同时也可以是UAS。
- Proxy Server：代理服务器的作用主要是转发Request和Response给其他的Proxy Server或者UA，Proxy Server分为有状态代理服务器（Stateful Proxy）和无状态代理服务器（Stateless Proxy），前者会保留一次通信事务的状态，通过一个有限状态机来控制转发操作，而后者不保存状态，只是实现透明的转发操作。
- Registration/Location Server：注册和定位服务器用于登记和定位UA，在线的UA会定时的向Registration服务器发送SIP消息来表明UA当前的位置（如IP地址、端口号等），Registration服务器会将该信息存入数据库（或者散列表）中，当其他UA向该UA发送request时就能获得该UA的位置。
- Redirect Server：用于重定向，在逻辑上相当于一个特殊功能的UA。
3.3 SIP方法
在SIP的REQUEST中，核心的方法（method）定义了6种：INVITE、ACK、BYE、CANCEL、OPTIONS和REGISTER。
- INVITE消息用于发起一个新的会话；
- ACK消息用于完成会话的建立；
- BYE消息用于结束一个会话；
- CANCEL消息用于取消一个请求（一般是针对INVITE）；
- OPTIONS消息用于查询服务器的能力；
- REGISTER消息用于发送注册请求消息。
SIP请求的类型，也称作SIP方法。RFC3261 中定义了六种方法。另外八种方法有独立的RFC扩展描述。如INFO、NOTIFY等等。
各方法含义可参考：SIP请求方法
也可移步SIP开发手册：链接: https://pan.baidu.com/s/1GFCHYqumPrd5ORhyCfJAew?pwd=yxj1 提取码: yxj1
3.4 SIP协议格式
SIP消息采用[ISO 10646]文本方式编码，分为两类：请求消息和响应消息。
请求消息：客户端为了激活按特定操作而发给服务器的SIP消息。
响应消息：用于对请求消息进行响应，指示呼叫的成功或失败状态。
每条SIP消息由以下三部分组成：起始行（ Start Line）/ 状态行（Status-Line），SIP头，消息体；请求消息和响应消息都包括SIP头字段和SIP消息字段。
起始行（ Start Line）/ 状态行（Status-Line）
每个SIP消息由起始行开始。起始行传达消息类型（在请求中是方法类型，在响应中是响应代码）与协议版本。起始行可以是一请求行（请求）或状态行（响应） 。
请求消息
请求消息整体格式如图：
其中：起始行格式：命令名称+目标URI+sip协议版本
请求消息包括以下几种请求命令：
响应消息
响应消息的起始行为状态行（Status-Line），状态行由协议版本、状态码和状态原因短语组成，各个部分之间用一个空格字符进行分隔。下面介绍其中的状态码。
SIP协议中共定义了6类状态码，其中状态码的第1位数字用于指示响应类型，后两位数字表示具体响应。下面用“1xx”标识状态码为“100-199”之间的响应。
- 1xx：临时响应，表示请求消息正在被处理；
- 2xx：成功响应，表示请求已被成功接收，完全理解并被接受；
- 3xx：重定向响应，表示需采取进一步以完成该请求；
- 4xx：客户机错误，表示请求消息中包含语法错误信息或服务器无法完成客户机请求；
- 5xx：服务器错误，表示服务器无法完成合法请求；
- 6xx：全局故障，表示任何服务器无法完成该请求；
响应消息整体格式如图：
其中：起始行格式：sip协议版本+响应返回码+描述性短句
响应消息是从100 - 699的返回码，分别表示不同的意义。
消息返回码可查看：SIP协议格式
SIP 头
SIP头域详情可查阅：https://blog.csdn.net/qui910/article/details/122683453
用来传递消息属性和修改消息意义。它们在语法和语义上与 HTTP 头域相同（实际上有些头就是借自 HTTP ），并且总是保持格式： <名字 >:<值>。
样例：
下表是描述的是SIP头格式中的各种Key值，可以大略分为4类：General通用头域，Request请求头域，Response响应头域，Entity实体域。
| 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 |
具体详细可参考：SIP协议-04 SIP头域
消息体
用于描述被初始的会话（例如，在多媒体会话中包括音频和视频编码类型，采样率等）。消息体能够显示在请求与响应中。
SIP 清晰区别了在 SIP 起始行和头中传递的信令信息与在 SIP范围之外的会话描述信息。可能的消息体类型就包括本文将要描述的SDP会话描述协议、还有基于xml的消息体。
4.SDP协议
SDP全称是Session Description Protocol，翻译过来就是描述会话的协议。主要用于两个会话实体之间的媒体协商。
SDP描述由许多文本行组成，文本行的格式为<类型>=<值>，表示为key=value;
SIP负责建立和释放会话，一般来说，会话中包含相关的媒体，比如视频和音频。媒体数据是由SDP描述的。SDP一般不单独使用，它与SIP配合使用时会放到SIP协议的body中。会话建立时，需要媒体协商，双方才能确定对方的媒体能力以及交换媒体的数据(这就是sdp的工作)。
那为什么要去发这个描述文本呢，主要是为了解决参与会话的各成员之间能力不对等的问题，如果参加本次通话的成员都支持高质量的通话，但是我们没有去进行协议，为了兼容性，使用的都是普通质量的通话格式，这样就很浪费资源了。所以SDP的作用还是很有必要的。
在SIP协议的包含的内容是SDP时，应该把Content-Type设置成application/sdp。SDP协议于RFC4566中发布。
样例：
4.1 SDP简介
SDP是会话描述协议的缩写，是描述流媒体初始化参数的格式，由IETF作为RFC 4566颁布。流媒体是指在传输过程中看到或听到的内容，SDP包通常包括以下信息：
会话信息
- 会话名和目的。
- 会话活动时间。
由于参与会话的资源是受限制的，因此包括以下附加信息是非常有用的。
- 会话使用的带宽信息。
- 会话负责人的联系信息。
媒体信息
- 媒体类型，例如视频和音频。
- 传输协议，例如RTP/UDP/IP和H.320。
- 媒体格式，例如H.261视频和MPEG视频。
- 多播地址和媒体传输端口（IP多播会话）。
- 用于联系地址的媒体和传输端口的远端地址（IP单播会话）。
SDP描述由许多文本行组成，文本行的格式为<类型>=<值>，<类型>是一个字母，<值>是结构化的文本串，其格式依<类型>而定。“=”两侧不允许有空格，一个值中的多个参数用空格分隔。
4.2 SDP协议格式
SDP会话描述由一个会话级描述（session_level description）和多个媒体级描述（media_level description）组成。会话级（session_level）的作用域是整个会话。其位置是从’v=’行开始到第一个媒体描述为止。媒体级（media_level）描述是对单个的媒体流进行描述（例如传送单个音频或者视频的vlc sdp文件只有短短的几句话，从m=开始，这其实就是个媒体机描述），其位置是从’m=’行开始到下一个媒体描述为止。总之，除非媒体部分重载，会话级的值是各个媒体的缺省默认值（就是说媒体级描述其实也是一个会话级描述，只不过没写出来的会话级描述参数都用的缺省值）。
详细可参考：SDP格式详解
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实例
# 请求视频流
INVITE sip:00000000001310018021@192.168.40.66:7100 SIP/2.0
Via: SIP/2.0/UDP 192.168.40.55:7100;rport;branch=z9hG4bK2480933505
From: <sip:120105110228023020@192.168.40.55:7100>;tag=2249831759
To: <sip:00000000001310018021@192.168.40.66:7100>
Call-ID: 821763613 // Call-ID：使用该字段标识一路视频
CSeq: 20 INVITE
Contact: <sip:120105110228023020@192.168.40.55: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:120105110228023020@192.168.40.55:7100>;tag=2249831759
To: <sip:00000000001310018021@192.168.40.66: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:120105110228023020@192.168.40.55:7100>;tag=2249831759
To: <sip:00000000001310018021@192.168.40.66:7100>;tag=2885333649
Call-ID: 821763613
CSeq: 20 INVITE
Contact: <sip:161128022553273720@192.168.40.66: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.信令服务、流媒体服务参考地址
信令服务：https://github.com/648540858/wvp-GB28181-pro
流媒体服务：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
参考文献
[1] GB/T 28181—2016. 安全防范视频监控联网系统信息传输, 交换, 控制技术要求[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.
