记一次Gb28181视频流异常的排查

        我司在对接HW大厂的国标28181平台时发现，回放录像时，其中某些通道的回放视频时只能播放5秒左右，视频流就停止了，很是奇怪，客户要求排查。

        翻看我们软件后台的日志发现，在接收视频流时出现了问题。我们在取流时使用的是rtp over tcp的方式，这种方式是一包rtp的前面有2个字节表示rtp数据包的大小。

        在接收一段时间后，日志显示接收到的rtp头的version字段不对，接收流程报错退出，停止收流。很显然是接收流不对，不是严格按照2字节头+rtp包的格式来发流。

        为了更有效的向客户说明情况，最好是通过抓包，并分析抓包结果向客户解释。因为我们是要分析视频流数据，所以抓包就需要抓下级平台国标sip协议和流数据的所有数据，不能只抓协议数据。

        拿到运维提供的抓包数据，就要开始一步一步剥离流数据并分析。

        使用wireshark将抓包数据打开。

        第一步，要明确出问题的通道的国标id是多少。

        在过滤器里通过“sip”关键字，让数据列表只显示sip数据，找到对应id的invite数据，比如下图，我们需要找的是19068510451318107156的invite数据。

我们通过查看invite和回复数据得到如下对话信息

callid 937788855
下级sip服务 10.11.146.110
上级sip服务 10.0.66.28
ssrc 1200006959 
发送 3504  接受7001 tcp
流发送ip 10.11.146.124

        这里我提一嘴，下级平台l流发送ip是10.11.146.124，不是sip服务 10.11.146.110，可见这个平台流和sip服务时不同的主机，应该是个不小的平台项目了，实际客户也是接入了1800路视频。不过这个不是我们这里关注点。

        第二部就是改寻找对应的视频流了。

       我们用 tcp.port == 3504 and ip.src==10.11.146.124再过滤一下数据。就过滤出了出错的流数据。然后通过 追踪流-》tcp将数据导出。

这样，我们就得到了rtp over tcp的数据流文件。

        第三步，分析得到的rtp数据，看看出错点在哪里

        这里我用了自己写的rtp ps数据分析工具分析了一下，发现了错误点。

可见最后打印出的rtp包数据头部数据显然和上面的数据包不一样。解析第一个version字段就不对了。所以我们怀疑是上一包的数据长度不够引起了错位

        第4步，在wireshark里找出错的包。

        上一包数据的开头是05 6e 80 60 cc 34 d9 87 d8 98 47 86 a7 2f 36，我们通过对这段数据的搜索（使用ctrl+f出现搜索界面）。在wireshark里找到对应的tcp帧。

如下图所见在编号13973的数据包，该包的长度为774

在该包接近结尾画红线的地方，此处为新的一包rtp数据的起始，值为：

05 6e 80 60 cc 34 d9 87 d8 98 47 86 a7 2f 36

其中05 6e 代表的意义是该包长度为：0x056e=1390。表明其后应有1390长的数据。

此处距编号13973的数据包结束还有265字节，那么在接下来的13974的数据包应有1390-256=1125字节

接下来看编号13974的数据包，该包的开头为：

05 6e 80 60 cc 9a d9 87

这个数据也是新的一包rtp数据起始。不是上面的包需要的1125字节

由此判断，上一个数据包发送发生错误，导致数据错乱