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包如下:
由抓包分析总结,下级平台与上级平台媒体流保活有以下特点:
- 下级平台媒体服务周期性向上级平台媒体服务发送RTCP保活请求,比如抓包截图中有3组请求应答RTCP,时间间隔是40秒;
- 上级平台媒体服务收到下级平台媒体服务RTCP保活请求后,向下级平台发送请求回应消息;
- 下级平台媒体服务发流地址是192.168.1.195:43010,发流端口43010,那么该媒体链路对应的RTCP发送端口是发流端口号加1,即43011;
- 上级平台媒体服务收流地址是192.168.1.10:20054,收流端口20054,那么该媒体链路对应的RTCP接收端口是收流端口号加1,即20055。
4 小结
知道了RTCP保活工作过程和特点后,当再遇到正在播放的视频突然停止时,我们就多了一个排查思路:通过Wireshark抓包,查看媒体链路的RTCP保活包是否正常。
实际项目对接时,上级平台和下级平台一般都需要开启各自的流媒体保活功能。