GB28181基础知识学习总结

GB28281标准要解决的问题：

• 用于解决音视频监控领域中，不同厂家生产的不同平台和不同产品之间的互通协议问题。

• 在GB28181协议推出之前，不同厂家的不同产品往往都有自己的解决方案和通信协议，因为基本上监控平台与摄像头、DVR等设备之间只能在厂家内部达成对接协议互通。

• GB28181协议的解决方式就是由国家部门牵头（各大监控平台和设备产品厂商参与）制定一个统一的对接协议框架和标准，所有厂家生产的产品和开发的平台要在这个生态中销售，就必须遵守GB28181的游戏规则，按照GB28181协议规定的接口和对接方式进行实现。这样就可以实现不同厂家的不同产品在使用过程中的无缝对接。

• GB28181协议的定义和实施中存在的问题：
• GB28181标准在具体通信协议的细节定义上存在不够明晰和严谨的地方，不同厂家在实现GB28181标准的过程中存在一定程度的自我解读和实现，这样最终的结果往往就是：在同一个GB28181规范的前提下，其中的部分实现细节由行业中较大的厂家来决定，中小型厂家按照大型厂商的实现和定义方式来进行适配和对接。

监控平台需要实现的主要业务的分类：

• 等待接收下游设备的连接请求，以及连接建立后的keepalive消息；

• 获取该平台下接入的设备信息；
• 一个GB28181平台下游可以连接另外一个GB28181平台，从而形成一个上下级级联的结构；

• 获取平台下某个接入设备的实时流；

• 获取平台下某个接入设备之前某个时间的录像回放；

• 设备远程控制，例如云台控制、语音对讲等；

GB28181基础：

• GB28181协议在各种不同设备和服务之间的通信，是基于UDP的SIP协议进行实现的；

• 拓扑结构：上级，下级；

• 视频流的传输使用推流的方式来实现，由下级推到上级；

• 上级需要访问下级的视频流的时候，向下级发送一条消息告知接收视频流的IP和端口，下级收到以后就向指定的IP和端口推流；

• 当上级不需要再接收这个视频流的时候，就向下级发送一条BYE指令通知下级停止发送，下级收到后就会停止发送。

• 使用推模式很好的一点就是：可以方便的实现内网的视频流推送到外网的流媒体服务器上。

• GB28181要求传输的视频流格式是PS流，或者H.264裸流以及MP4格式，其中PS流和H.264裸流比较常见。

音视频推流方面的通信结构和基本流程：

• 媒体流发送者：可以考虑是一个远端部署的摄像头或者DVR，用于向指定的流媒体服务器发送图像流；

• SIP服务器：负责进行设备管理和在不同的服务/终端节点之间转发消息；

• 媒体服务器：媒体流发送者会把自己的音视频流推送到媒体服务器上，用于接收来自前端设备推送的音视频流，同时可以用于为媒体流接收者提供拉流播放的接口，相当于是一个流媒体中转服务器；实际上SIP服务器和媒体服务器可以部署在同一个服务器硬件上；

• 媒体流接收者：真正需要访问和播放音视频流的通信节点，不会直接与媒体流发送者进行通信，而是通过媒体服务器来进行整体的管理和中转；

• 媒体流接收者即真正需要访问摄像头实时流的服务器，向SIP服务器发送一个Invite Message来请求指定摄像头的实时流数据；

• SIP服务器收到后向媒体服务器发送一个Invite Message，查询该流媒体服务器能够支持的媒体类型；

• 流媒体服务器收到后会以SDP的形式返回给SIP服务器；

• SIP服务器继续向媒体流发送者也就是摄像头发送一个Invite Message，在其中通过SDP的形式包含流媒体服务器的IP、端口以及支持的流媒体类型格式信息；

• 媒体发送者确认以上Invite Message以后，就开始向上面SDP中包含的媒体服务器的IP、端口推送自己的实时音视频流；

• 然后SIP服务器就向媒体流接收者返回一个确认消息，表示已经成功通知媒体发送者向流媒体服务器推送Streaming；

• 然后媒体流接收者就可以从流媒体服务器上来获取自己想要申请的摄像头的实时流并解码播放了；

• 当媒体流接收者需要停止接收Streaming的时候，就向SIP Server发送一个BYE消息；

• SIP Server则分别向流媒体服务器和媒体发送者分别发送BYE消息，停止推流。整个业务流程完成。

• 注意：从以上流程图中可以看到，四种角色之间的交互流程稍显繁琐和多余，实际上在对接的过程中可以省略掉其中一些不必要的确认步骤。

其他：

• 在GB28181功能的具体实现上，可以基于PJSIP开源库来方便的实现与SIP服务器之间的SIP协议通信功能；

参考资料：

• GB28181国检推流

• GB28181视频教程第一集（基础知识）

• GB28181视频教程第二集（推流上）