视频电话典型故障解析

许南希

摘 要：视频电话业务是一种点到点的视频通信业务，它能利用电话网双向实时传输通话双方的图像和语音信号。随着芯片技术、传输技术、视频编解码技术和集成电路技术不断发展并日趋成熟，适合商用和民用的视频电话走进了现代人们的日常办公和生活中。本文主要以在电话IP专网为传输通道的条件下用视频话机进行点对点视频通话时出现的卡顿现象为例，梳理处理思路，详细剖析故障。

关键词：视频电话；专网；传输；带宽；分辨率

在大型企业的电话IP专网的支持下，视频通话得以实现。但是在实际应用中，有一部分视频通话经常出现卡顿、马赛克等现象，有时候甚至严重影响正常的通话交流。这种故障情况相对复杂，影响的因素非常多，要做到能快速定位故障，必须建立在对传输网、数据通信、网络设备等知识全面、系统的了解之上，从网络的整体角度来分析、解决问题。下面我就对该故障处理思路和方法进行深入的剖析。

首先要确定网络结构和故障的影响范围。本例中网络拓扑结构为星型结构，中心点同95个分支点通过以太网专线直连。在95个分支点中，只有45个分支点的话机进行视频通话时图像流畅，声音清晰，其中有将近50个分支点在点对点视频通话过程中存在图像卡顿、马赛克的现象，音频通话略有延迟，经查这些分支点开通的以太网专线的带宽均为2M。

在视频通话的过程中可以打开查看状态选项进行实施观察，发现视频通话无论是接收还是发送，都采用的是H.264编码720p分辨率，网络延迟在50ms之内属于正常范围，视频帧率为25Hz左右，视频速率（码率）为2Mbps，而丢包率达到了20%以上，那么可以断定这么大的丢包率是造成卡顿的主因吗？

接下来，我们来做一下理论的分析：分辨率720P解码最大码率2Mbps视频需要的带宽到底是多少呢？720P视频单帧大小约为80kbps，视频帧数在25帧时，所需带宽为80kbps*25=2000kbps，约为2Mbps，和话机显示实时码率基本一致，而视频通话需要同时有接收和发送双向的视频流，故发码流所需带宽+收码流所需带宽不低于4000kbps，即4Mbps的带宽。那么目前开通的2Mbps全雙工的以太网专线是不是可以支持4Mbps的双向视频流呢？

全双工（Full Duplex）是通讯传输的一个术语。通信允许数据在两个方向上同时传输。我们平时所说的十兆以太网、百兆以太网、千兆以太网，甚至新近出现的万兆以太网，都是指在一个回路上的网络带宽，即单向（最大）带宽。现在的双绞线网络使用两对线分别用于数据的发送和接收，也就是说具有两个回路。既然双绞线有两个回路，那么是不是说2Mbps双绞线网络的实际带宽就是4Mbps呢？实际上并非如此，这要看这两个回路是否处于“全双工”工作状态，即发送线对和接收线对同时在工作。就像双向车道一样，车辆流量的计算应是两个方向的车辆流量之和，网络带宽的计算也是如此。联通2Mbps带宽专线如果同时接收和发送视频流，那么应该是每个方向占用1Mbps。

根据上述分析，发现目前视频通话实际需要至少4Mbps的带宽，而实际却只有2Mbps，无法满足要求，故产生大量丢包导致卡顿。针对于目前的这种情况，保持视频分辨率720p不变，将话机的码流改为1Mps，发现帧率掉到了10帧左右，但丢包率仅为1%，单向视频速率显示也为1000Kbps左右，基本解决了在2Mb链路上视频通话出现的卡顿现象。

在OSI七层结构中的上三层属于业务层面，在同样的配置和环境下其他单位的视频通话都正常应排除业务层面的问题，应把关注点放到网络层、传输层甚至是链路层和物理层。仔细观察视频通话中的网络状态，持续存在大量的丢包，使用移动电脑替换本端话机用9600字节的大包ping对端的IP话机1000次，丢包率达到10%～15%，这说明丢包发生在传输链路上，对于以太网专线电路持续存在丢包的常见因素都有哪些呢？我们来逐项进行排查分析：

（1）业务量大，配置带宽不够。

话机已经将视频码流改成1Mbps，何况分支点A还是10Mbps电路，不存在带宽不够的影响，排除。

（2）网络中存在流量控制，或业务量过大的时候对端设备不响应流控造成丢包。

电话专网的网络中没有采用流控限制，排除。

（3）网内存在广播风暴或者病毒。

如果网内存在广播风暴或者病毒，那受影响的不应仅仅是这两路视频通话受影响，而且视频通话应该是建立不起来的而不是单纯的丢包，排除。

（4）网线或者光纤跳线出现故障或质量不好。

经过分段ping两端话机地址的方法，发现从核心交换机ping远端话机不丢包，ping中心点的测试话机有10%—15%的丢包，将丢包点定位在中心点的建筑内。为了彻底排除问题，更换了中心点里核心交换机至楼层交换机的光纤，还更换了楼层交换机至话机的所有网线跳线，这时再使用移动电脑替换本端话机用9600字节的大包ping对端的IP话机1000次，丢包率为0，线路已上不存在丢包现象，然而视频通话的故障现象依旧存在没有变化。既然底层链路没问题，业务配置也没问题，那么丢包到底是怎么发生的呢？我们继续往下排查。

（5）端口模式和对端设备不匹配，造成工作在异常状态。

当上层的业务和下层的链路都没问题时，就要着重考虑两者的匹配情况了，而两者匹配最直接的位置就是网络接口。在检查网络交换机配置时发现和传输对接的端口模式是Auto（自协商），状态是100M半双工，将接口模式手动改成100M全双工模式后测试，发现分支点A的视频通话卡顿现象消失，通话质量良好，但是分支点B的视频通话依旧存在卡顿丢包故障。

（6）专线传输设备或板卡出现问题。

既然端口模式已经匹配，那么就只能从传输链路和IP话机的配置上找更深层的匹配问题了。这时我们又做了一个测试，将视频通话720p的分辨率改成4CIF模式，其他配置不变，发现故障现象消除，改回720p后丢包又再次出现，这说明H.264的视频编码协议720p这种分辨率对于传输链路上的某些参数是有一定要求的。

H.264的基本流由一系列NALU（Network Abstraction Layer Unit）组成，不同的NALU数据量各不相同。对于每一个NALU，根据其包含的数据量的不同，其大小也有差异。在IP网络中，当要传输的IP 报文大小超过最大传输单元MTU（Maximum Transmission Unit）时就会产生IP分片情况。在以太网环境中可传输的最大IP报文（即最大传输单元Maximum Transmission Unit，简称MTU）的大小为1500字节。如果发送的IP数据包大于MTU，数据包就会被拆开来传送，这样就会产生很多数据包碎片，增加丢包率，降低网络速度。对于视频传输而言，若RTP（实时传输协议， Real-time Transport Protocol）包大于MTU而由底层协议任意拆包，可能会导致接收端播放器的延时播放甚至无法正常播放。因此对于大于MTU的NALU单元，必须进行拆包处理。进一步讲，如果使用720p的分辨率进行视频通话时，传输链路上的MTU值如果设置小于视频数据帧的最大值，就极有可能会丢包丢帧甚至业务不通。

上述这种故障情况并不太常见，特别是几个故障一起出现，极大的增加了处理的困难性和复杂性。但是只要保持思路清晰，逐项排查，多层面多专业进行理论分析，多总结，归纳掌握一套系统的方法，才能不断提升解决问题的能力，在维护中提高故障处理的效率。

参考文献

[1] 糜正琨.IP网络电话技术[M]，人民邮电出版社，2000

[2] 李乌江.RTP在远程视频传输中的应用研究[D]，哈尔滨工程大学， 2008