结合实战，浅析GB/T28181（十）——媒体流保活

1 问题现象

在实际项目对接过程中，我们有时会碰到这样的问题：视频正在播放着，突然停止了。然后ping一下，也能ping通！下级平台或上级平台看起来也在线，看起来不是网络的问题。这到底咋回事呢？一时摸不着头脑，懵逼了。不要急，我们一起来看看今天要讨论的主题——媒体流保活。

2 规范定义

先看看GB28181-2016（附录M）和GB28181-2022（附录K），对媒体流保活的规范定义，宏观上确立一个概念。

两版规范对媒体流保活机制的规定没变。看完规范定义后，您可能有个新的问题：这与《结合实战，浅析GB/T 28181（一）——注册保活》一文中描述的保活，是一样的吗？

不一样。

前者是28181设备或下级平台，与本地28181平台之间的SIP信令保活，用来检测对方信令链接是否在线；

后者是28181设备或下级平台，与本地28181平台流媒体服务器之间的媒体流保活，用来检测对方媒体链路是否掉线。

请注意：信令链路与媒体流链路保活是不同的，二者从字面意思上容易混淆。

了解了它们的不同，那么在28181监控平台中，通过什么方法来实现媒体流保活呢？

3 RTCP保活

在28181视频传输过程中，我们通常基于RTP实时传输视音频流，但RTP并不保证服务质量，服务质量由RTP的姊妹协议——RTCP来提供。RTP会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包，即Sender Report和Receiver Report，这些数据包中不封装视音频流数据。RTCP基于UDP来传送数据。UDP是无链接不可靠的，所以通信双方无法及时判断对方何时掉线。关于RTP/RTCP以及RTSP的详细定义和说明，您可自行查阅网上资料，本文不再过多描述。下面举例说明RTCP数据包是怎么工作的。

当上级平台向下级平台播放了某路摄像机实时视频后，假定其对应的媒体流链路如下所示：

摄像机发流地址	本地媒体收流地址	本地媒体发流地址	上级媒体收流地址
192.168.1.100:10020	192.168.1.195:17306	192.168.1.195:43010	192.168.1.10:20054

用wireshark抓取该链路对应的正常RTCP包如下：

由抓包分析总结，下级平台与上级平台媒体流保活有以下特点：

1. 下级平台媒体服务周期性向上级平台媒体服务发送RTCP保活请求，比如抓包截图中有3组请求应答RTCP，时间间隔是40秒；
2. 上级平台媒体服务收到下级平台媒体服务RTCP保活请求后，向下级平台发送请求回应消息；
3. 下级平台媒体服务发流地址是192.168.1.195:43010，发流端口43010，那么该媒体链路对应的RTCP发送端口是发流端口号加1，即43011；
4. 上级平台媒体服务收流地址是192.168.1.10:20054，收流端口20054，那么该媒体链路对应的RTCP接收端口是收流端口号加1，即20055。

4 小结

知道了RTCP保活工作过程和特点后，当再遇到正在播放的视频突然停止时，我们就多了一个排查思路：通过Wireshark抓包，查看媒体链路的RTCP保活包是否正常。

实际项目对接时，上级平台和下级平台一般都需要开启各自的流媒体保活功能。