结合实战，浅析GB/T28181（三）——实况点播

目录

1 简介

2 点播流程

3 信令抓包

4 实战对接常见问题

4.1 Invite请求，收到4XX回应

4.2 Invite请求，收到5XX回应

4.3 摄像机在线，点播无视频图像

4.4 卡顿、花屏、绿屏

4.5 同路视频，客户端播放正常，大屏花屏

---

1 简介

实时视音频点播，主要由两部分组成：基于SIP的信令交互和基于RTP/RTCP的媒体流传输。整个过程比较复杂，本节主要介绍基于SIP的信令交互及实战对接中碰到的问题和解决思路。

假定本地视频平台为上级SIP域，对方为下级SIP域（可以是视频平台，或硬盘录像机，或网络摄像机，或视频解码器、或视频网关等）。

2 点播流程

 以上流程示意图来自《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字段为“Play”代表实时点播。

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

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

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

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

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

3 信令抓包

抓包对象：上级SIP信令网关，与下级SIP域服务（网络摄像机）之间的信令。

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

4 实战对接常见问题

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

4.1 Invite请求，收到4XX回应

 说明：

开流请求中，当收到对方4XX错误码应答时，一般都是对方平台或设备有问题。可能的原因：

SIP模块存在bug，或功能支持不完善；

配置不合适，比如摄像机达到连接数上限（上图中486错误码），或者没有开启视频点播权限等。

4.2 Invite请求，收到5XX回应

 5XX错误码应答消息，其原因同样需要协调对方来配合调查和整改。

4.3 摄像机在线，点播无视频图像

排查思路：

1，检查本域内该路摄像机实况点播的配置是否合适，如果合适，下一步；

2，抓包工具，抓取本级SIP域，和对方SIP域的信令包，确认SIP信令是否交互正常，并完成交互流程。如果交互正常，下一步；

3，抓包工具，根据本级域媒体服务收流端口，在媒体服务器上，对收流端口过滤，抓取下级域发送过来的RTP媒体流包，确认是否收到下级域的媒体流包；

4，如果没收到媒体流包，那么协商对方域排查。需对方同时抓包，确认其是否将媒体流发送出去了；如果对方已经发送，那么就是在中间网络环节，媒体流包被丢弃。此时应排查下级域到本级域的媒体链路网络是否连通；

5，如果收到下级域的媒体流包了，分析媒体流包格式是否符合国标PS流规范要求，视频参数：分辨率、视频帧率、码流、视频编码格式（H264等）是否符合约定的要求；

6，如果视频流格式和参数没问题，检查客户端是否收到视频流并正常播放。有的环境下，客户机防火墙会阻挡正常接收视频流，需关闭防火墙才能正常接收。

4.4 卡顿、花屏、绿屏

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

排查思路：

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

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

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

以下为某路视频花屏RTP抓包分析截图，可以看到，丢包率已经高达40.13%了，不花屏才怪。

4.5 同路视频，客户端播放正常，大屏花屏

对同一路视频，若客户端播放正常，说明本地域接收到的视频流正常，不存在丢包。那么就要重点调查从本地域媒体服务，到解码器之间的网络是否存在丢包了，其排查思路与4.4一样。不同的是，这里同时可以抓取媒体服务发送出去的RTP流包，和解码器接收到的RTP流包，对比分析是否存在丢包。