視頻電話典型故障解析

許南希

摘 要：視頻電話業務是一種點到點的視頻通信業務，它能利用電話網雙向實時傳輸通話雙方的圖像和語音信號。隨著芯片技術、傳輸技術、視頻編解碼技術和集成電路技術不斷發展并日趨成熟，適合商用和民用的視頻電話走進了現代人們的日常辦公和生活中。本文主要以在電話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）是通訊傳輸的一個術語。通信允許數據在兩個方向上同時傳輸。我們平時所說的十兆以太網、百兆以太網、千兆以太網，甚至新近出現的萬兆以太網，都是指在一個回路上的網絡帶寬，即單向（最大）帶寬?，F在的雙絞線網絡使用兩對線分別用于數據的發送和接收，也就是說具有兩個回路。既然雙絞線有兩個回路，那么是不是說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