引入

乱序、卡顿、视频质量无法忍受，您是否也为此类问题苦恼过?是否也曾为此一筹莫展？本文通过某客户ME8000+MG6050组网情况下视频会议卡顿问题处理，剖析了问题出现的原因及排除步骤，并总结了三种问题解决方案，最后对此三种解决方案进行了比较。

问题缘起

某客户使用H3C视频会议系统出现图像停顿严重及无法观看部分会场现象。为保障客户会议顺利召开，H3C一线工程师前往现场进行排查。最初怀疑客户网络拥塞导致丢包，因此通过ping及ftp下载测试，发现线路“质量良好”并未出现严重丢包现象。问题出在哪里？为了迅速定位问题，与客户沟通网络结构发现：客户的省到市的链路使用的是友商路由器将8个2M进行捆绑！莫非是因为线路捆绑导致RTP包乱序？

苦苦思索

 如果是因为RTP包乱序导致，那么最简单的定位手段就是抓包！经现场抓包分析：各地市上传到总队MCU的数据包存在严重的乱序甚至丢包现象。此种情况对于实时视频而言是致命的，也是导致此次问题的根本原因。

为了进一步定位问题，经与客户协商采用如下两种测试：

1 局域网内的设备召开会议并抓包以确认H3C设备发出时并未出现乱序现象。

2 通过广域网召开省-市会议并抓包，乱序数据包数量为：326（乱序包占40%左右），而且不同省-市会议抓包，都有不同程度的数据包乱序现象，出现乱序现象可以定位是网络设备导致。

深入探索

MP捆绑后报文在MP口的多条线路上进行负载分担，当不同的2M线路传输时延不一致时会导致不同的分配在接收端到达顺序不一致，若接受设备无法进行数据包保序而采用先到先发策略的话，H3C设备收到的数据将存在乱序。另外一种情况是因为在MP口上针对每个数据包将被分为若干小包在不同2M上负载分担，部分设备可能会由于分片保序功能较差而导致数据包丢失。视频会议的实时性要求设备在收到码流的时候需要立即进行解码处理，而网络中的乱序可能导致部分数据包无法按时到达设备（如系统等待报文完全接收后再进行解码，将增加会议时延，不适合交互式的会议使用），这样就导致系统在解码过程中出现丢包从而出现会议过程视频停顿的问题。

解决之道

1 终端处开启NAA

H3C设备有一个功能NAA，此功能可以在网络丢包/乱序情况在5%-10%的情况下予以保序。此方案的好处就是可以不用管网络上的其他设备，仅在终端侧配置即可，且配置简单。但如果网络丢包/乱序情况比较严重时如本案中45%乱序，此方案改善效果并不明显。并且启用NAA后还将引入额外的时延，偶尔会出现视频不流畅等现象。

2 开启网络设备保序功能

上文讲述了MP捆绑后报文在MP口被分片为若干小包并在多条线路上进行负载分担。如果网络设备在MP口不保序的话，在每条2M线路时延不一致的情况下必将导致数据包乱序。H3C设备如SR88等在MP口是严格保序的，这种设备是不会引入乱序的。但也有许多设备并不支持此项功能，如本案中友商设备！因此本案中无法通过此方案解决。

3 更改网络结构

根据实际的网络情况及客户视频会议应用，本案中无法采用方案2，并且由于乱序严重采用方案1也无法有效缓解视频卡顿现象。通过与客户沟通，其真实使用时视频业务码率在1.5M，此时建议客户更改网络结构：从多条捆绑线路中分离单独一条2M线路，其余线路捆绑，使用静态路由（也可使用动态路由）方式使两条线路互做备份。即单独一条2M线路主跑视频业务，同时在没有视频会议的情况下可以为业务系统提供带宽，其他线路作为本2M线路的视频业务备份！此方案的优势在于充分利用现有带宽资源。修改后测试相关局点效果明显改善，视频流畅、语音清晰，并且通过抓包发现没有出现乱序情况。

三种解决方案的对比

总结

在实际应用的过程中通过广域网互联时出现E1捆绑使用的情况比较多，此类问题是较为常见的一种情况，其实经过多路径负载分担的网络也可能出现类似的问题，并且视频会议系统是一套系统工程，在开局阶段首先要保障有良好的网络带宽，具体排查阶段可以综合使用多种方案以求得较佳的视频效果。