论文部分内容阅读
【摘 要】本文针对视频会议中遇到的最典型的丢包问题进行了具体分析，并结合实际案例提出了分级分层次的排查问题、解决的问题的方法。
【关键词】网络视频会议；丢包；排查
在视频会议项目中，广域网部分都是由运营商来承建。一旦视频会议中出现因为网络丢包造成的图像或者声音效果不理想时，运营商方面除了通过ICMP协议中的ping包检查他们线路之外，基本没有其他更合适的解决办法。并且当此网络上其他的非实时业务还在比较正常运行的时候，大家容易将问题归结到视频会议系统的设备上。事实上，这类问题的原因一般是出在网络这一层面。本文以一个典型案例来说明，出现因丢包而导致网络视频会议效果不理想时，对这种问题的排查分析方法。
1.案例背景
在内蒙古某市工商管理局实施的网络视频会议项目中，视频会议主会场采用的是某视频设备生产商的视讯终端MG6050和视讯网关MCU ME5000且这两个设备都位于市局。13个旗县的终端MG6050通过运营商的MSTP网络与市局相连。如图1所示。
在项目实施初期便发现有3个旗县局点掉包严重，使得市局视讯网关MCU ME5000不断的发送异常报文，导致市局观看自己的图像以及下联旗县局的图像有很严重的停顿、马赛克现象。旗县局观看市局图像同样停顿现象及马赛克现象也很严重。在图像编解码算法中，媒体流中的视频图像是有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个旗县局点中1个比较正常了，另外2个的问题现象稍有好转，能看到主流图像，但是图像停滞现象仍然很明显。在后续的系统联调中发现，近1/3局点的主流图像有不同程度的停顿和停滞。在市局和这些问题局点进行点对点测试，各个局点都有一些丢包，一般丢包率在1%～3%左右，最严重的甚至可以达到10%。
随着联调工作的进行，丢包局点数目还在不断增加，在13个旗县局中有10个旗县局的视讯数据存在丢包。这些丢包局点有一个相同特征：市局到旗县下行不丢包，旗县到市局上行丢包，其中音频数据和视频数据都存在丢包现象。更加值得注意的是，各个局点的丢包程度不固定随时变化，没有规律可循，例如上午情况稍好一些，下午就变的比较严重。在这种情况下，客户召开视频会议的效果很不理想，不仅图像冻结现象严重，声音也是时断时续。
2. 网络视频会议问题排查分析方法
2.1确认问题现象
通过召开部同类型的网络视频会议，确认影响视频会议效果的因素是视频会议设备侧还是网络侧。操作步骤如下：
1、通过市局的视讯网关MCU ME5000召集纯转发会议，广播主会场，通过Web界面管理的方式登录到各旗县局点视讯终端MG6050上看会议状态信息，发现无丢包现象发生且图像解码流畅，说明从市局视讯网关到各旗县局视讯终端的下行数据是正常的。
2、在此会议中切换广播旗县会场，在主会场终端观看图像效果，发现图像出现停顿及马赛克现象，说明各旗县到市局的上行存在丢包或者视讯网关转发丢包问题。
3、结束MCU会议，市局与旗县视讯终端进行点对点呼叫，通过Web界面管理的方式登录到双方终端来查看双方接收丢包情况，发现旗县接收无丢包现象，而市局有明显丢包，这样排除MCU转发丢包的可能性，确认是由于网络丢包造成的（终端编码正常，因此终端发送不存在丢包）。
通过上述三步测试，确认传输网络存在丢包，且基本只有上行丢包，而下行正常。以下对丢包进行进一步分析：
1、分别统计在1.5Mbps、768Kbps、256Kbps宽带下，进行点对点呼叫方式的丢包情况，发现随着带宽的降低，丢包无明显改善，只是丢包总数逐渐减少，这说明丢包不是由于线路传输带宽不足造成的。
2、分别比较H.263和H.264、4CIF和CIF在点对点呼叫方式下的丢包情况，发现基本相同，这说明丢包与视频协议格式无关。
3、配置终端MTU值（MTU可在800～1500之间调整），所谓的MTU是只在网络中允许传输的最大数据单元的大小，再次呼叫进行对比，发现MTU较小时丢包情况无改善，这说明丢包与MTU值无关；
4、通过两端报文（分别在市局和区县交换机上抓取区县终端发送的报文，这样区县侧抓到的报文时完整的，而在市局侧抓到的存在丢包，是否丢包可通过RTP报文的sequence number是否连续来判断），发现丢包并不存在规律，丢包的报文大小与时机无规律。
通过上述分析得出以下结论：报文的丢弃无规律，与视频会议终端的系统配置无关，丢包由线路传输造成。 2.2排查内网及运营商接口网络
确认问题原因是在网络部分之后，下一步工作就从内部网络开始，往外逐步排查问题。
判断内网是否存在丢包的方法是：分别在给旗县交换机出口、市局接入路由器入口、市局终端接入交换机入口配置镜像端口，并通过抓包软件结合镜像端口输出的数据捕获旗县发往市局的报文。具体方法是先不呼叫，在各抓包节点先启动抓包软件，然后两点建立呼叫，持续约1分钟后挂断呼叫，再通知各抓包节点停止捕获数据，这样可以保证各节点在不丢包情况下抓取的报文总数相同。通过分析，在相同的呼叫中，旗县出口无丢包；市局入口和终端接入交换机入口的丢包数相同。由此可以判断市局和旗县局组成的内网中无丢包问题存在。
另外，工商管理局内网与运营商网络之间通过光电转换器连接，通过查看市局接入路由器和旗县接入交换机端口信息，未发现端口工作模式以及工作速率不匹配等问题，确认光电转换器工作正常。
2.3排查运营商网络接入层
此案例中，运营商的网络接入情况如图2所示，于是分别以接入节点1、节点2-1、节点2-2作为抓包节点，通过抓包确认，发现这几个接入层机房均不存在丢包。测试方法与排查客户内网方法相同，分别在三个节点处及市局入口抓取从渝中发往市局的报文，发现节点2-1和节点2-2的报文均无丢包，接入节点1入口和市局入口丢包报文情况相同，由此判断丢包应该在承载网上。
图2 运营商网络层次结构图
2.4排查运营商承载网
首先排查承载网络中的核心交换机和核心路由器，但由于抓包核心网上数据量太大，此前的抓包定位方法不方便使用，因此接入一台测试终端。先以接在核心交换机上测试为例，首先测试终端与旗县局进行点对点呼叫，结果是双向无丢包；再使用测试终端与市局进行点对点呼叫，结果存在单向丢包，这样说明问题不在核心交换机上。按照此方法再次测试核心路由器，结果发现测试终端与区县互通时，区县终端接收正常即下行正常，而测试终端接收存在持续丢包即上行有丢包。通过在核心路由器上做进出端口流量统计（通过ACL对源地址和目的地址进行精确匹配）时发现该核心路由器存在转发丢包，经过查看路由器的配置发现，其网络拥塞情况下的丢包策略使得其在网络流量过大时，将MG6050的报文被丢弃。最终通过修改路由器的拥塞避免配置后双向通信恢复正常。
2.5问题解决
通过对一个局点的排查分析，找到问题根源并解决。其余局点的问题也进行同样的处理。至此，该工商管理局网络视频会议系统正常运行，图像冻结、马赛克现象全部消失，会议效果得到了大幅度提升。
3. 结束语
视讯会议系统的音视频效果与网络承载质量息息相关。在大型视讯会议系统组网中，由于传输设备及传输线路的更为复杂，网络侧引入的问题可能性就更大，丢包、乱序、拥塞等问题时有发生。为检测网络质量，人们通常习惯使用Ping命令进行测试，而RTP与ICMP协议原理不同，Ping命令无法测试网络传输RTP码流的真实情况。处理问题时，首先要采用分段分块、化繁为简的方法将测试系统最小化并将故障复现；其次要考虑每一台网络设备、每一个设备端口甚至每一根网线所造成的影响；最后要选用专业的测试软件和测试方法来进行分析，只要理清思路，最终一定能够准确的定位问题并找到解决问题的办法。
参考文献：
[1] 曹庆华.网络测试与故障诊断实验教程[M].北京：清华大学出版社，2006.
[2] 谭浩强.计算机网络教程[M].北京：电子工业出版社，2005.
作者简介：
新宇，男，1976年生，蒙古族，职称：助理工程师，主要研究方向：计算机网络。
【关键词】网络视频会议；丢包；排查
在视频会议项目中，广域网部分都是由运营商来承建。一旦视频会议中出现因为网络丢包造成的图像或者声音效果不理想时，运营商方面除了通过ICMP协议中的ping包检查他们线路之外，基本没有其他更合适的解决办法。并且当此网络上其他的非实时业务还在比较正常运行的时候，大家容易将问题归结到视频会议系统的设备上。事实上，这类问题的原因一般是出在网络这一层面。本文以一个典型案例来说明，出现因丢包而导致网络视频会议效果不理想时，对这种问题的排查分析方法。
1.案例背景
在内蒙古某市工商管理局实施的网络视频会议项目中，视频会议主会场采用的是某视频设备生产商的视讯终端MG6050和视讯网关MCU ME5000且这两个设备都位于市局。13个旗县的终端MG6050通过运营商的MSTP网络与市局相连。如图1所示。
在项目实施初期便发现有3个旗县局点掉包严重，使得市局视讯网关MCU ME5000不断的发送异常报文，导致市局观看自己的图像以及下联旗县局的图像有很严重的停顿、马赛克现象。旗县局观看市局图像同样停顿现象及马赛克现象也很严重。在图像编解码算法中，媒体流中的视频图像是有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个旗县局点中1个比较正常了，另外2个的问题现象稍有好转，能看到主流图像，但是图像停滞现象仍然很明显。在后续的系统联调中发现，近1/3局点的主流图像有不同程度的停顿和停滞。在市局和这些问题局点进行点对点测试，各个局点都有一些丢包，一般丢包率在1%～3%左右，最严重的甚至可以达到10%。
随着联调工作的进行，丢包局点数目还在不断增加，在13个旗县局中有10个旗县局的视讯数据存在丢包。这些丢包局点有一个相同特征：市局到旗县下行不丢包，旗县到市局上行丢包，其中音频数据和视频数据都存在丢包现象。更加值得注意的是，各个局点的丢包程度不固定随时变化，没有规律可循，例如上午情况稍好一些，下午就变的比较严重。在这种情况下，客户召开视频会议的效果很不理想，不仅图像冻结现象严重，声音也是时断时续。
2. 网络视频会议问题排查分析方法
2.1确认问题现象
通过召开部同类型的网络视频会议，确认影响视频会议效果的因素是视频会议设备侧还是网络侧。操作步骤如下：
1、通过市局的视讯网关MCU ME5000召集纯转发会议，广播主会场，通过Web界面管理的方式登录到各旗县局点视讯终端MG6050上看会议状态信息，发现无丢包现象发生且图像解码流畅，说明从市局视讯网关到各旗县局视讯终端的下行数据是正常的。
2、在此会议中切换广播旗县会场，在主会场终端观看图像效果，发现图像出现停顿及马赛克现象，说明各旗县到市局的上行存在丢包或者视讯网关转发丢包问题。
3、结束MCU会议，市局与旗县视讯终端进行点对点呼叫，通过Web界面管理的方式登录到双方终端来查看双方接收丢包情况，发现旗县接收无丢包现象，而市局有明显丢包，这样排除MCU转发丢包的可能性，确认是由于网络丢包造成的（终端编码正常，因此终端发送不存在丢包）。
通过上述三步测试，确认传输网络存在丢包，且基本只有上行丢包，而下行正常。以下对丢包进行进一步分析：
1、分别统计在1.5Mbps、768Kbps、256Kbps宽带下，进行点对点呼叫方式的丢包情况，发现随着带宽的降低，丢包无明显改善，只是丢包总数逐渐减少，这说明丢包不是由于线路传输带宽不足造成的。
2、分别比较H.263和H.264、4CIF和CIF在点对点呼叫方式下的丢包情况，发现基本相同，这说明丢包与视频协议格式无关。
3、配置终端MTU值（MTU可在800～1500之间调整），所谓的MTU是只在网络中允许传输的最大数据单元的大小，再次呼叫进行对比，发现MTU较小时丢包情况无改善，这说明丢包与MTU值无关；
4、通过两端报文（分别在市局和区县交换机上抓取区县终端发送的报文，这样区县侧抓到的报文时完整的，而在市局侧抓到的存在丢包，是否丢包可通过RTP报文的sequence number是否连续来判断），发现丢包并不存在规律，丢包的报文大小与时机无规律。
通过上述分析得出以下结论：报文的丢弃无规律，与视频会议终端的系统配置无关，丢包由线路传输造成。 2.2排查内网及运营商接口网络
确认问题原因是在网络部分之后，下一步工作就从内部网络开始，往外逐步排查问题。
判断内网是否存在丢包的方法是：分别在给旗县交换机出口、市局接入路由器入口、市局终端接入交换机入口配置镜像端口，并通过抓包软件结合镜像端口输出的数据捕获旗县发往市局的报文。具体方法是先不呼叫，在各抓包节点先启动抓包软件，然后两点建立呼叫，持续约1分钟后挂断呼叫，再通知各抓包节点停止捕获数据，这样可以保证各节点在不丢包情况下抓取的报文总数相同。通过分析，在相同的呼叫中，旗县出口无丢包；市局入口和终端接入交换机入口的丢包数相同。由此可以判断市局和旗县局组成的内网中无丢包问题存在。
另外，工商管理局内网与运营商网络之间通过光电转换器连接，通过查看市局接入路由器和旗县接入交换机端口信息，未发现端口工作模式以及工作速率不匹配等问题，确认光电转换器工作正常。
2.3排查运营商网络接入层
此案例中，运营商的网络接入情况如图2所示，于是分别以接入节点1、节点2-1、节点2-2作为抓包节点，通过抓包确认，发现这几个接入层机房均不存在丢包。测试方法与排查客户内网方法相同，分别在三个节点处及市局入口抓取从渝中发往市局的报文，发现节点2-1和节点2-2的报文均无丢包，接入节点1入口和市局入口丢包报文情况相同，由此判断丢包应该在承载网上。
图2 运营商网络层次结构图
2.4排查运营商承载网
首先排查承载网络中的核心交换机和核心路由器，但由于抓包核心网上数据量太大，此前的抓包定位方法不方便使用，因此接入一台测试终端。先以接在核心交换机上测试为例，首先测试终端与旗县局进行点对点呼叫，结果是双向无丢包；再使用测试终端与市局进行点对点呼叫，结果存在单向丢包，这样说明问题不在核心交换机上。按照此方法再次测试核心路由器，结果发现测试终端与区县互通时，区县终端接收正常即下行正常，而测试终端接收存在持续丢包即上行有丢包。通过在核心路由器上做进出端口流量统计（通过ACL对源地址和目的地址进行精确匹配）时发现该核心路由器存在转发丢包，经过查看路由器的配置发现，其网络拥塞情况下的丢包策略使得其在网络流量过大时，将MG6050的报文被丢弃。最终通过修改路由器的拥塞避免配置后双向通信恢复正常。
2.5问题解决
通过对一个局点的排查分析，找到问题根源并解决。其余局点的问题也进行同样的处理。至此，该工商管理局网络视频会议系统正常运行，图像冻结、马赛克现象全部消失，会议效果得到了大幅度提升。
3. 结束语
视讯会议系统的音视频效果与网络承载质量息息相关。在大型视讯会议系统组网中，由于传输设备及传输线路的更为复杂，网络侧引入的问题可能性就更大，丢包、乱序、拥塞等问题时有发生。为检测网络质量，人们通常习惯使用Ping命令进行测试，而RTP与ICMP协议原理不同，Ping命令无法测试网络传输RTP码流的真实情况。处理问题时，首先要采用分段分块、化繁为简的方法将测试系统最小化并将故障复现；其次要考虑每一台网络设备、每一个设备端口甚至每一根网线所造成的影响；最后要选用专业的测试软件和测试方法来进行分析，只要理清思路，最终一定能够准确的定位问题并找到解决问题的办法。
参考文献：
[1] 曹庆华.网络测试与故障诊断实验教程[M].北京：清华大学出版社，2006.
[2] 谭浩强.计算机网络教程[M].北京：电子工业出版社，2005.
作者简介：
新宇，男，1976年生，蒙古族，职称：助理工程师，主要研究方向：计算机网络。