结合实战，浅析GB/T28181（四）——录像回放及控制

1 简介

依据GB/T28181规定，历史视音频回放，主要由三部分组成：基于SIP（rfc3261）的Invite方法实现录像回放会话链路的建立；基于SIP扩展协议（rfc2976）Info实现录像回放控制（即快进，慢放，暂停，开始，拖放等操作）；基于RTP/RTCP的媒体流传输。其过程比实况点播更复杂，本节主要介绍基于SIP及扩展协议的信令交互、和实战对接中碰到的问题及解决思路。

假定本地视频平台为上级SIP域，对方为下级SIP域（硬盘录像机，或下级平台等）。

2 录像查询

在介绍录像回放流程之前，先介绍下录像查询，查询出录像文件之后，才能选择某段文件对其进行回放。

说明：

1:上级域SIP信令网关向下级SIP域服务发送录像查询命令,录像查询命令采用Message方法携带;

2:下级SIP域服务收到命令后返回200 OK;

3:下级SIP域服务将录像文件列表信息，发送给上级域SIP信令网关，发送命令采用Message方法携带；

4:上级域SIP信令网关收到列表消息后，返回200 OK。

有了录像文件列表信息，才可以做下一步操作：录像回放。

3 回放流程

以上流程示意图来自《GBT 28181-2016 公共安全视频监控联网系统信息传输、交换、控制技术要求》文档，按照流程图所示，本地SIP域内的媒体流接收者（客户端）、SIP服务器、媒体服务器，相互之间都存在通讯，皆由SIP信令完成。因为SIP信令交互本身比较复杂，加之交互节点众多，更增加了交互过程的复杂性。为了降低本地SIP域内各模块之间通讯的复杂性，域内模块之间交互，可自定义私有协议来完成，比如HTTP信令。

媒体流接收者（客户端）与SIP服务器之间通过HTTP交互，SIP服务器与媒体服务器之间也通过HTTP交互。SIP服务器除了与域内的媒体流接收者和媒体服务器通讯外，还与下级域的媒体发送者通过SIP完成信令交互。此时，SIP服务器实质上成为了一个SIP信令网关服务，即完成HTTP信令和SIP信令的相互转换和转发。可以用下图来简单示意：

简化后，回放过程的SIP信令交互，我们只需关注SIP信令网关和下级SIP域即可，如下图所示：

说明：

1:上级SIP信令网关向下级SIP域服务发送Invite消息,消息头域中携带 Subject字段,表明回放的视频源ID、发送方媒体流序列号、媒体流接收者ID、接收端媒体流序列号等参数,SDP消息体中s字段为“Playback”代表录像回放，u字段代表回放通道ID和回放类型，t字段代表回放时间段。

2:下级SIP域服务收到SIP信令网关的Invite请求后，回复200 OK响应，携带SDP消息体，消息体中描述了媒体流发送者发送媒体流的IP、端口、媒体格式、SSRC字段等内容，t字段代表回放时间段。

3:SIP信令网关收到下级SIP域服务返回的200 OK响应后,向其发送ACK请求,请求中不携带消息体,完成与下级SIP域服务的Invite会话建立过程。

接着下级域媒体服务将媒体流，直接发送给上级域媒体服务器。

4:SIP信令网关向下级SIP域服务发送回放控制请求INFO消息，消息体格式遵循RTSP部分协议中的要求，可对录像进行快进，慢放等控制；

5:下级SIP服务收到INFO请求后，响应操作并回复200 OK响应；

6: SIP信令网关向下级SIP域服务发送BYE 消息，断开消息1、2、3建立的同下级SIP服务的Invite会话。

7:下级SIP服务收到BYE消息后回复200 OK响应，会话断开，并终止发流。

下边是录像回放控制INFO消息命令简介，详情可参考《GBT 28181-2016 公共安全视频监控联网系统信息传输、交换、控制技术要求》附录B内容。

4 信令抓包

抓包对象：上级SIP信令网关，与下级SIP域服务（硬盘录像机）之间的信令。如果下级域是国标平台等SIP下级域，示例抓包信令也适用。

4.1 录像查询

4.2 录像回放及控制

说明：以上信令均为交互成功的抓包截图。实战中，可作为参考，来分析定位信令交互问题。

5 实战对接常见问题

实战对接中，会碰到各种各样的问题，首先要确保自己发送的录像回放及控制请求，符合国标规范。排查定位对接遇到的问题， 主要依据28181规范和wireshark抓包。定位出来谁的问题，谁修改和解决，以减少扯皮，避免背锅。

5.1 从下级域查询不到录像

第一种情况：向硬盘录像机发送了录像查询请求，但收不到其200 OK应答，如下截图

排查思路：

1，确保硬盘录像机上通道及录像等配置无误；

2，协调厂家技术支持，沟通排查。、

第二种情况：向硬盘录像机发送了录像查询请求，并收到了其200 OK回应。却没收到后续的录像文件列表发送消息，如下截图

排查思路：

1，确保硬盘录像机上通道及录像等配置无误；

2，浏览器登录硬盘录像机，查询当前通道请求时间段内的本地录像，如果本地都查不出来，检测配置；如果本地能查询出来，下一步；

3，确保查询请求消息体XML关键字段无误，比如通道ID“DeviceID”是否匹配，开始和结束时间段是否合适，若以上无误，下一步；

4，协调厂家技术支持，沟通排查。

第三种情况：硬盘录像机返回了录像文件列表消息，但消息体XML解析失败。见下截图

硬盘录像机返回的录像文件列表，name字段中文格式编码不符合gb2312编码，故解析不出来。

5.2 查询的录像断断续续

排查思路：
1，对存储返回的录像文件进行抓包，若类似上面截图的情况，基本可以断定，存储里存的录像，也是断断续续（可浏览器登录存储，查看本地该时间段的录像进行确认）；
2，引起上述问题的原因，存储与摄像机之间的连接不稳定，时而连接，时而中断，如此循环往复，所以存储一会能取到流进行录制，一会儿取不到流。可以排查存储与摄像机之间的网络连接，或者校时是否合适。

5.3 选中录像文件，无法播放

排查思路：

1，根据录像回放Invite请求流程，查看流程是否走完，收流地址:端口，发流地址:端口等参数是否无误；

2，根据下级域发流端口，对其抓包，查看是否收到媒体流RTP包；

3，若收到媒体流RTP包，则要在本级域排查，媒体服务是否将RTP流转发给客户端进行播放，以及是否符合PS国标流规范。

5.4 卡顿、花屏、绿屏

在本地域媒体服务负载范围之内，若出现卡顿、花屏、绿屏这些现象，一般都是由于网络丢包引起的。排查过程主要依据抓包工具wireshark的应用及其分析，基本可以初步判断出大部分问题的原因。

排查思路：

1，复现问题，根据SIP交互信令，获取本地域收流端口；

2，根据收流端口，抓取RTP媒体流包；

3，通过Wireshark，对RTP抓包分析，查看是否存在网络丢包；

4，若无丢包，查看本级域客户端播放库播放时是否流畅。