GB28181协议--GB28181协议简介

jimte_pro

已于 2024-09-24 15:09:49 修改

阅读量2.3w

点赞数 26

分类专栏：音视频基础文章标签：视频处理音视频

于 2021-11-30 18:28:59 首次发布

本文链接：https://blog.csdn.net/jisuanji111111/article/details/121634199

版权

音视频基础专栏收录该内容

20 篇文章 22 订阅

订阅专栏

GB28181是中国公共安全视频监控联网系统的技术标准，解决了平台间互通问题。它规定了系统的互联结构、传输控制要求，并定义了SIP、SDP、RTP/RTCP等通信协议。标准支持设备注册注销、实时点播、控制、报警通知、信息查询等功能，确保了不同设备间的互操作性。

摘要由CSDN通过智能技术生成

1、GB/T 28181 —2016协议简介

近年来，国内视频监控应用发展迅猛，系统接入规模不断扩大，涌现了大量平台提供商，平台提供商的接入协议各不相同，终端制造商需要给每款终端维护提供各种不同平台的软件版本，造成了极大的资源浪费。各地视频大规模建设后，省级、国家级集中调阅，对重特大事件通过视频掌握现场并进行指挥调度的需求逐步涌现，然而不同平台间缺乏统一的互通协议。在这样的产业背景下，基于终端标准化、平台互联互通的需求，GB/T28181应运而生。 GB28181标准规定了公共安全视频监控联网系统(以下简称联网系统) 的互联结构, 传输、交换、控制的基本要求和安全性要求, 以及控制、传输流程和协议接口等技术要求。

2、GB28181框架

SIP 监控域互联结构示意图如下图所示：
在这里插入图片描述
GB28181的联网方式分为级联和互联方式，级联方式可以详细分为信令级联和媒体级联，下图分别为信令级联和媒体级联方式：
信令级联：

媒体级联：

互联：
信令安全路由网关之间是平级关系, 需要共享对方SIP 监控域的监控资源时, 由信令安全路由网关向目的信令安全路由网关发起, 经目的信令安全路由网关鉴权认证后方可进行平级系统间通信。
信令互联：
在这里插入图片描述
媒体互联：

3、GB28181通信结构

联网系统内部进行视频、音频、数据等信息传输、交换、控制时, 遵循的通信协议的结构如下图所示：
在这里插入图片描述
联网系统在进行视音频传输及控制时应建立两个传输通道: 会话通道和媒体流通道。会话通道用于在设备之间建立会话并传输系统控制命令; 媒体流通道用于传输视音频数据, 经过压缩编码的视音频流采用流媒体协议 RTP/RTCP 传输。
其中使用的具体协议如下所述：
（1）会话初始协议：
安全注册、实时视音频点播、历史视音频的回放等应用的会话控制采用RFC 3261 （SIP协议）规定Register、Invite 等请求和响应方法实现, 历史视音频回放控制采用SIP 扩展协议IETF RFC2976 规定的INFO 方法实现, 前端设备控制、信息查询、报警事件通知和分发等应用的会话控制采用 SIP 扩展协议IETF RFC3428 规定的 Message 方法实现。
（2）会话描述协议
联网系统有关设备之间会话建立过程的会话协商和媒体协商应采用RFC4566 （SDP协议）协议描述, 主要内容包括会话描述、媒体信息描述、时间信息描述。会话协商和媒体协商信息应采用SIP 消息的消息体携带传输。
（3）控制描述协议
联网系统有关前端设备控制、报警信息、设备目录信息等控制命令应采用监控报警联网系统控制描述协议(MANSCDP) 描述，联网系统控制命令应采用SIP 消息 Message 的消息体携带传输。
（4）媒体回放控制协议
历史视音频的回放控制命令应采用监控报警联网系统实时流协议(MANSRTSP) , 实现设备在端到端之间对视音频流的正常播放、快速、暂停、停止、随机拖动播放等远程控制。历史媒体的回放控制命令采用SIP 消息Info 的消息体携带传输。
（5）媒体传输和媒体编解码协议
媒体流在联网系统IP 网络上传输时应支持 RTP 传输, 媒体流发送源端应支持控制媒体流发送峰值功能。 RTP 的负载应采用如下两种格式之一: 基于 PS 封装的视音频数据或视音频基本流数据。媒体流的传输应采用RFC3550 规定的 RTP 协议, 提供实时数据传输中的时间戳信息及各数据流的同步; 应采用RFC 3550 规定的 RTCP 协议, 为按序传输数据包提供可靠保证, 提供流量控制和拥塞控制。

4、GB28181具体功能

GB28181协议规定支持的功能有如下几项：

（1）注册和注销

应支持设备或系统进入联网系统时向SIP 服务器进行注册登记的工作模式。如果设备或系统注册不成功, 宜延迟一定的随机时间后重新注册。基本注册即采用RFC3261 规定的基于数字摘要的挑战应答式安全技术进行注册, 基本注册流程如下图所示：
在这里插入图片描述
注册流程描述如下:
（a）SIP 代理向SIP 服务器发送 Register 请求;
（b）SIP 服务器向 SIP 代理发送响应401, 并在响应的消息头 WWW_Authenticate 字段中给出适合SIP 代理的认证体制和参数;
（c）SIP 代理重新向SIP 服务器发送 Register 请求, 在请求的 Authorization 字段给出信任书,包含认证信息;
（d）SIP 服务器对请求进行验证, 如果检查出 SIP 代理身份合法, 向 SIP 代理发送成功响应200 OK, 如果身份不合法则发送拒绝服务应答。

基于数字证书的双向认证注册：
在这里插入图片描述
信令流程描述如下:
（a）SIP UA 向 SIP 服务器发送 Register 请求, 消息头域中携带 SIP UA 安全能力。增加 Authorization头字段,Authorization 的值为 Capability, 参数algorithm 的值分为三部分, 中间以逗号分割。第一部分为非对称算法描述, 取值为 RSA; 第二部分为摘要算法描述, 取值为MD5/SHA-1/SHA-256 中的一个或者多个; 第三部分为对称算法的描述, 取值为 DES/3DES/SM1 中的一个或者多个。
（b）SIP 服务器向SIP UA 发送一个挑战响应401, 响应的消息头域 WWW-Authenticate 取值为Asymmetric, 参数nonce 分为两部分a 和b 两部分, algorithm 的值取SIP UA 安全能力中的算法。
（c）IP UA 收到401 响应后, 得到nonce 中的a 和b 两部分。首先用SIP UA 私钥解密b, 得到结果c, 对结果c 用401 响应中algorithm 指定的算法做摘要, 得到结果d, 用sip 服务器公钥解密a, 得到结果d’ , 与结果d 进行匹配, 如果相匹配则信任该结果, 否则丢弃。 SIP UA 重新向SIP 服务器发送 Register 请求，Authorization 取值为 Asymmetric, 参数nonce 的值与上面（b）中的相同;response 的值为用本消息中algorithm 指明的算法对[c+nonce]做摘要的结果。
（d）SIP 服务器对请求进行验证, 如果检查 SIP UA 身份合法, 向 SIP UA 发送成功响应 200 OK, 如果身份不合法则发送拒绝服务应答。

注销流程：
在这里插入图片描述
注销流程描述如下:
（a）SIP 代理向SIP 服务器发送 Register 请求,Expires 字段的值为0, 表示SIP 代理要注销;
（b）SIP 服务器向 SIP 代理发送响应401, 并在响应的消息头 WWW_Authenticate 字段中给出适合SIP 代理的认证体制和参数;
（c）SIP 代理重新向SIP 服务器发送 Register 请求, 在请求的 Authorization 字段给出信任书,包含认证信息,Expires 字段的值为0;
（d）SIP 服务器对请求进行验证, 如果检查出 SIP 代理身份合法, 向 SIP 代理发送成功响应200 OK, 如果身份不合法则发送拒绝服务应答。

（2）实时视音频点播

应支持按照指定设备、指定通道进行图像的实时点播, 支持多用户对同一图像资源的同时点播。
实时视音频点播的SIP 消息应通过本域或其他域的SIP 服务器进行路由、转发, 目标设备的实时视音频流宜通过本域内的媒体服务器进行转发。实时视音频点播采用SIP 协议(IETF RFC3261) 中的Invite 方法实现会话连接, 采用 RTP/RTCP协议(IETF RFC3550) 实现媒体传输。实时视音频点播的信令流程分为客户端主动发起和第三方呼叫控制两种方式, 联网系统可选择其中一种或两种结合的实现方式。第三方呼叫控制的第三方控制者宜采用背靠背用户代理实现, 有关第三方呼叫控制见IETF RFC3725。
在这里插入图片描述
其中, 信令1、8、9、10、11、12 为SIP 服务器接收到客户端的呼叫请求后通过 B2BUA 代理方式建立媒体流接收者与媒体服务器之间的媒体流信令过程, 信令2 ~ 7 为SIP 服务器通过三方呼叫控制建立媒体服务器与媒体流发送者之间的媒体流信令过程, 信令13~16 为媒体流接收者断开与媒体服务器之间的媒体流信令过程, 信令17 ~20 为 SIP 服务器断开媒体服务器与媒体流发送者之间的媒体流信令过程。
命令流程描述如下:
（a）媒体流接收者向SIP 服务器发送Invite 消息, 消息头域中携带 Subject 字段, 表明点播的视频源ID、发送方媒体流序列号、媒体流接收者ID、接收端媒体流序列号等参数,SDP 消息体中s 字段为“Play”代表实时点播。
（b）SIP 服务器收到Invite 请求后, 通过三方呼叫控制建立媒体服务器和媒体流发送者之间的媒体连接。向媒体服务器发送Invite 消息, 此消息不携带SDP 消息体。
（c）媒体服务器收到SIP 服务器的Invite 请求后, 回复200 OK 响应, 携带SDP 消息体, 消息体中描述了媒体服务器接收媒体流的IP、端口、媒体格式等内容。
（d）SIP 服务器收到媒体服务器返回的200 OK 响应后, 向媒体流发送者发送Invite 请求, 请求中携带消息3 中媒体服务器回复的200 OK 响应消息体,s 字段为“Play”代表实时点播, 增加y 字段描述SSRC 值,f 字段描述媒体参数。
（e）媒体流发送者收到SIP 服务器的Invite 请求后, 回复200 OK 响应, 携带SDP 消息体, 消息体中描述了媒体流发送者发送媒体流的IP、端口、媒体格式、SSRC 字段等内容。
（f）SIP 服务器收到媒体流发送者返回的200 OK 响应后, 向媒体服务器发送 ACK 请求, 请求中携带消息5 中媒体流发送者回复的200 OK 响应消息体, 完成与媒体服务器的Invite 会话建立过程。
（g）SIP 服务器收到媒体流发送者返回的200 OK 响应后, 向媒体流发送者发送 ACK 请求, 请求中不携带消息体, 完成与媒体流发送者的Invite 会话建立过程。
（h）完成三方呼叫控制后,SIP 服务器通过B2BUA 代理方式建立媒体流接收者和媒体服务器之间的媒体连接。在消息1 中增加SSRC 值, 转发给媒体服务器。
（i）媒体服务器收到Invite 请求, 回复200 OK 响应, 携带SDP 消息体, 消息体中描述了媒体服务器发送媒体流的IP、端口、媒体格式、SSRC 值等内容。
（j）SIP 服务器将消息9 转发给媒体流接收者。
（k）媒体流接收者收到200 OK 响应后, 回复 ACK 消息, 完成与SIP 服务器的Invite 会话建立过程。
（l）SIP 服务器将消息11 转发给媒体服务器, 完成与媒体服务器的Invite 会话建立过程。
（m）媒体流接收者向SIP 服务器发送 BYE 消息, 断开消息1、10、11 建立的同媒体流接收者的Invite 会话。
（n）SIP 服务器收到 BYE 消息后回复200 OK 响应, 会话断开。
（o）SIP 服务器收到 BYE 消息后向媒体服务器发送 BYE 消息, 断开消息8、9、12 建立的同媒体服务器的Invite 会话。
（p）媒体服务器收到 BYE 消息后回复200 OK 响应, 会话断开。
（q）SIP 服务器向媒体服务器发送 BYE 消息, 断开消息2、3、6 建立的同媒体服务器的Invite会话。
（r）媒体服务器收到 BYE 消息后回复200 OK 响应, 会话断开。
（s）SIP 服务器向媒体流发送者发送 BYE 消息, 断开消息4、5、7 建立的同媒体流发送者的Invite 会话。
（t）媒体流发送者收到 BYE 消息后回复200 OK 响应, 会话断开。