文/刘圣宁

案例背景

某省高级人民法院实施了全省规模的二三级网视讯会议部署，全网几十台H3C MG6060视讯终端（下文简称终端）几乎遍布全省所有县市法院单位。网络采用树型组网方式，在省院和所有市院分别布置一台H3C ME8000（下文简称MCU）和一台终端,其余县院只布置一台终端，。各地市法院的MCU辖管当地县市终端，并与省院MCU进行互控级联。承载视讯会议的网络，由运营商负责统一提供，承载方式为MSTP。实际组网情况如图1所示：

http://www.h3c.com.cn/res/201012/23/20101223_1139157_image001_705334_30008_0.png图1 某省高级人民法院视讯会议系统结构图

当召开全省会议时，若开启会议字幕或多画面功能，主会场的图像出现明显停顿的现象。根据以往经验判断，图像停顿现象基本都是由于视讯终端接收丢包导致，查看了主会场终端的统计信息显示终端接收码流并不丢包，只是视频帧率不稳定，有时满25帧，有时只有10帧。

同时，几乎所有的县市分会场都纷纷反馈其观看图像存在停顿，部分分会场还存在声音断续的现象。在此种情况下，整套视讯会议系统已不能满足客户的日常使用，虽然关闭字幕及多画面功能后，图像停顿问题能明显好转，但也不能完全解决。

问题排查

1. 确认问题现象

由于全网涉及十余台MCU级联，近百台终端入会，故需要通过分段分块、化繁为简的方法来对故障现象进行确认和分析。具体方法是将每个地市MCU所辖区域作为一个独立的整体，通过召开不同类型的会议，来确认影响视频会议效果的因素是在视频会议设备侧还是网络侧。步骤如下：

A、首先使用省中心的MCU召开会议，只包括地市的终端不包括县市终端，并且不采用MCU级联的方式，通过WEB查看各地市终端的统计信息并无丢包，且无论使用字幕和多画面功能，图像声音均正常。说明省到市的网络承载不存在问题；

B、使用各地市的MCU，单独召集本辖区内的所有县市终端入会。在此会议模式下，部分地区仍无丢包且会议效果正常，部分地区却出现了严重的丢包现象，且会议中视频出现停顿，根据丢包程度的不同，主要有以下两种类型：：

b1、辖区内只有部分县市终端存在丢包，通过web查看丢包率在3%-5%，未开启字幕时图像略微停顿，开启字幕后图像严重停顿，对该类地区定义为M地区。

b2、所有县市终端均存在丢包，丢包率达10%-50%，无论是否开启字幕图像都严重停顿，帧率有时只有几帧，对该类地区定义为N地区。

C、对M地区测试，使用本地区MCU召集会议，启用字幕和多画面，剔除存在接收丢包的会场，图像不停顿。立即呼入丢包会场，所有会场接收图像立刻出现停顿。这说明全网的图像停顿就是因为有终端接收丢包，并且丢包的会场会影响到不丢包的会场的图像效果。而对于N类地区来说，所有终端都严重丢包，所以图像几乎停滞，说明丢包的会场越多，丢包越厉害，图像停顿就越严重。

D、针对M和N地区内有丢包的会场，进行局域网的点对点测试，使用安装有H3C Topview软件视频终端的PC与MG6060硬件终端直接通过网线对联，通过测试，该种情况下不丢包，说明丢包的产生是在传输链路和传输设备上。

通过以上步骤的测试，可以得出结论：图像的停顿是由于会议中有终端接收图像丢导致，丢包与视讯设备本身无关，丢包产生于传输网络或传输设备。

2. 故障现象原理分析

在图像编解码算法中，媒体流中的视频图像是有I帧、P帧、B帧几种不同的视频帧组合而成。

• I帧是关键帧，其它类型的视频帧以I帧为基础进行图像变化部分的编码，，I帧包含了一副图像的完整信息，其数据量很大，一般只在视讯终端刚加入会议、MCU切换广播会场、终端或MCU接收丢包等情况下产生。。
• P帧是一种以I帧或其它P帧为参考值、对图像的变化量进行编码的视频帧，其数据量较小，会议中一般以传送P帧为主。
• B帧是以P帧为基础对图像运动预测进行的编码的双向预测帧，在视讯会议中并不常用。

在多点会议中，当有大量的终端接收数据产生丢包时，这些终端就会向MCU产生大量的I帧请求，MCU如果不响应则这些丢包终端由于没有I帧作为参考帧，就会无法解码或者出现花屏。而如果MCU不断的响应I帧，就会出现大量的I帧数据。受会议带宽的约束，I帧一般只能达到10帧/秒或者更少（I帧数据量庞大，若达到25帧/秒，会严重超出会议带宽，从而造成更多丢包），而低于20帧/秒的视频效果会直接给人造成图像停顿的感觉由于MCU编码的I帧是广播给全网所有终端的，因此无论是丢包会场还是非丢包会场，都会出现图像停顿现象。

因此，解决问题的根本是需要排查当前网络的丢包原因，而不能通过减少I帧的编码频率来规避。

3. 排查内部局域网

首先从局域网开始排查。对于局域网而言，引起丢包的原因通常有：

• 网络设备端口协商失败导致接口丢包；
• 防火墙对RTP码流处理能力不足导致丢包；
• 交换设备处理性能不足自身丢包；
• 网线过长或质量较差受电磁干扰丢包等。

针对局域网丢包问题的排查方法往往不需要通过抓包的手段，查看交换机及路由器的interface统计信息，以及设备的连接情况一般就可以定位。如图2所示。

http://www.h3c.com.cn/res/201012/23/20101223_1139158_image002_705334_30008_0.png图2 局域网排查内容

通过上述排查发现，部分县院的局域网确实存在丢包问题，主要体现在以下几个方面：

A、交换机与路由器（也包括视讯终端与交换机）连接用的端口，一端强制100M/full，另一端自适应，导致有不断的inputerror和outputerror。对于该类问题，调整各设备相连接的端口为自适应后解决。

B、部分县院在交换机与终端之间连接了HUB或防火墙，由于HUB属于半双工设备，防火墙对RTP实时流处理性能不足，导致存在较多丢包，改变连接方式后解决。

C、部分县院使用较长网线进行网络的延伸，有的达到了100米，由于电信号的严重衰减，导致了存在大量的丢包，该问题更换网线后解决。

4. 排查运营商网络接入层

局域网存在的问题排查完毕后，还有较多地市存在大量的丢包问题没有解决，根据网络拓扑情况（如图3所示），需要进一步排查运营商提供的接入网是否存在问题。排查时应重点考虑三个方面：接入设备的端口协商、网络接入带宽以及网络传输质量。通过排查，丢包问题主要几种在以下几点：

A、很多县市的接入路由器与电信的接入设备端口协商都存在问题，有大量的inputerror和outputerror，原因是运营商对端口进行了强制，而接入路由器却为自适应。两端统一参数，协商后解决。

B、部分县市接入设备的端口协商排查并无问题，且终端点对点呼叫正常，会议中若只有少量终端也正常，但若召集多点会议便存在大量丢包，故初步判断其出口带宽存在问题。在市院向运营商接入设备使用FTP和NETIQ打流量测试，发现部分市院的出口带宽只有10M，无法满足多点会议要求。调整线路带宽后，多点会议正常召开。

http://www.h3c.com.cn/res/201012/23/20101223_1139159_image003_705334_30008_0.png图3 运营商网络层次结构图

5. 排查运营商承载网

排查完局域网、接入网以后，大部分局点的丢包问题已得到良好解决，会议的图像效果也得到了很好的改善，但少量局点仍然存在持续的丢包，因此需要继续排查运营商的承载网质量。

由于运营商承载网对用户不透明，所以一般只能通过抓包来判断其是否存在问题，可通过码流的流向进行分段抓包，从而判断丢包的位置。在该网络中从县到市不丢包，而市到县存在较大丢包。故抓包选取的位置为市核心路由器的出口以及运营商承载网的出口在抓取市核心路由器发出的码流的同时抓取从运营商承载网出口转发的报文，根据报文的变化情况来判断运营上承载网是否存在问题。通过抓包发现，市核心路由器转发出的码流无任何丢包，而从运营商承载网出口的抓取的报文已存在丢包，故判断运营商承载网存在线路问题。后经运营商排查其MSAP设备端口存在问题，更换后丢包问题彻底解决。如图4所示。

http://www.h3c.com.cn/res/201012/23/20101223_1139160_image004_705334_30008_0.png图4 运营商网承载网丢包的排查方法

6. 问题解决

通过汇总，该网络中的丢包问题主要集中在以下几点：

A、 终端、交换机、路由器等设备端口协商存在不匹配的问题。

B、 使用HUB或防火墙等设备接入视讯系统，该类设备对RTP处理能力不足造成丢包；

C、 广域网链路出口带宽不足，导致拥塞产生丢包；

D、 运营商承载网络内部设备端口存在问题，导致承载网持续丢包；

通过对几个典型地区的排查，并找到问题根源，把相关处理经验应用到其他节点，其他节点的问题也得到了快速的解决。至此，整个视讯会议系统恢复正常，图像停滞，声音断续的问题的不再出现。

总结

视讯会议系统的音视频效果与网络承载质量息息相关。在大型视讯会议系统组网中，由于传输设备及传输线路的更为复杂，网络侧引入的问题可能性就更大，丢包、乱序、拥塞等问题时有发生。为检测网络质量，人们通常习惯使用Ping命令进行测试，而RTP与ICMP协议原理不同，Ping命令无法测试网络传输RTP码流的真实情况。处理问题时，首先要采用分段分块、化繁为简的方法将测试系统最小化并将故障复现；其次要考虑每一台网络设备、每一个设备端口甚至每一根网线所造成的影响；最后要选用专业的测试软件和测试方法来进行分析，问题就会迎刃而解。