許南希

摘 要：視頻電話業(yè)務是一種點到點的視頻通信業(yè)務，它能利用電話網(wǎng)雙向?qū)崟r傳輸通話雙方的圖像和語音信號。隨著芯片技術、傳輸技術、視頻編解碼技術和集成電路技術不斷發(fā)展并日趨成熟，適合商用和民用的視頻電話走進了現(xiàn)代人們的日常辦公和生活中。本文主要以在電話IP專網(wǎng)為傳輸通道的條件下用視頻話機進行點對點視頻通話時出現(xiàn)的卡頓現(xiàn)象為例，梳理處理思路，詳細剖析故障。

關鍵詞：視頻電話；專網(wǎng)；傳輸；帶寬；分辨率

在大型企業(yè)的電話IP專網(wǎng)的支持下，視頻通話得以實現(xiàn)。但是在實際應用中，有一部分視頻通話經(jīng)常出現(xiàn)卡頓、馬賽克等現(xiàn)象，有時候甚至嚴重影響正常的通話交流。這種故障情況相對復雜，影響的因素非常多，要做到能快速定位故障，必須建立在對傳輸網(wǎng)、數(shù)據(jù)通信、網(wǎng)絡設備等知識全面、系統(tǒng)的了解之上，從網(wǎng)絡的整體角度來分析、解決問題。下面我就對該故障處理思路和方法進行深入的剖析。

首先要確定網(wǎng)絡結構和故障的影響范圍。本例中網(wǎng)絡拓撲結構為星型結構，中心點同95個分支點通過以太網(wǎng)專線直連。在95個分支點中，只有45個分支點的話機進行視頻通話時圖像流暢，聲音清晰，其中有將近50個分支點在點對點視頻通話過程中存在圖像卡頓、馬賽克的現(xiàn)象，音頻通話略有延遲，經(jīng)查這些分支點開通的以太網(wǎng)專線的帶寬均為2M。

在視頻通話的過程中可以打開查看狀態(tài)選項進行實施觀察，發(fā)現(xiàn)視頻通話無論是接收還是發(fā)送，都采用的是H.264編碼720p分辨率，網(wǎng)絡延遲在50ms之內(nèi)屬于正常范圍，視頻幀率為25Hz左右，視頻速率（碼率）為2Mbps，而丟包率達到了20%以上，那么可以斷定這么大的丟包率是造成卡頓的主因嗎？

接下來，我們來做一下理論的分析：分辨率720P解碼最大碼率2Mbps視頻需要的帶寬到底是多少呢？720P視頻單幀大小約為80kbps，視頻幀數(shù)在25幀時，所需帶寬為80kbps*25=2000kbps，約為2Mbps，和話機顯示實時碼率基本一致，而視頻通話需要同時有接收和發(fā)送雙向的視頻流，故發(fā)碼流所需帶寬+收碼流所需帶寬不低于4000kbps，即4Mbps的帶寬。那么目前開通的2Mbps全雙工的以太網(wǎng)專線是不是可以支持4Mbps的雙向視頻流呢？

全雙工（Full Duplex）是通訊傳輸?shù)囊粋€術語。通信允許數(shù)據(jù)在兩個方向上同時傳輸。我們平時所說的十兆以太網(wǎng)、百兆以太網(wǎng)、千兆以太網(wǎng)，甚至新近出現(xiàn)的萬兆以太網(wǎng)，都是指在一個回路上的網(wǎng)絡帶寬，即單向（最大）帶寬。現(xiàn)在的雙絞線網(wǎng)絡使用兩對線分別用于數(shù)據(jù)的發(fā)送和接收，也就是說具有兩個回路。既然雙絞線有兩個回路，那么是不是說2Mbps雙絞線網(wǎng)絡的實際帶寬就是4Mbps呢？實際上并非如此，這要看這兩個回路是否處于“全雙工”工作狀態(tài)，即發(fā)送線對和接收線對同時在工作。就像雙向車道一樣，車輛流量的計算應是兩個方向的車輛流量之和，網(wǎng)絡帶寬的計算也是如此。聯(lián)通2Mbps帶寬專線如果同時接收和發(fā)送視頻流，那么應該是每個方向占用1Mbps。

根據(jù)上述分析，發(fā)現(xiàn)目前視頻通話實際需要至少4Mbps的帶寬，而實際卻只有2Mbps，無法滿足要求，故產(chǎn)生大量丟包導致卡頓。針對于目前的這種情況，保持視頻分辨率720p不變，將話機的碼流改為1Mps，發(fā)現(xiàn)幀率掉到了10幀左右，但丟包率僅為1%，單向視頻速率顯示也為1000Kbps左右，基本解決了在2Mb鏈路上視頻通話出現(xiàn)的卡頓現(xiàn)象。

在OSI七層結構中的上三層屬于業(yè)務層面，在同樣的配置和環(huán)境下其他單位的視頻通話都正常應排除業(yè)務層面的問題，應把關注點放到網(wǎng)絡層、傳輸層甚至是鏈路層和物理層。仔細觀察視頻通話中的網(wǎng)絡狀態(tài)，持續(xù)存在大量的丟包，使用移動電腦替換本端話機用9600字節(jié)的大包ping對端的IP話機1000次，丟包率達到10%～15%，這說明丟包發(fā)生在傳輸鏈路上，對于以太網(wǎng)專線電路持續(xù)存在丟包的常見因素都有哪些呢？我們來逐項進行排查分析：

（1）業(yè)務量大，配置帶寬不夠。

話機已經(jīng)將視頻碼流改成1Mbps，何況分支點A還是10Mbps電路，不存在帶寬不夠的影響，排除。

（2）網(wǎng)絡中存在流量控制，或業(yè)務量過大的時候?qū)Χ嗽O備不響應流控造成丟包。

電話專網(wǎng)的網(wǎng)絡中沒有采用流控限制，排除。

（3）網(wǎng)內(nèi)存在廣播風暴或者病毒。

如果網(wǎng)內(nèi)存在廣播風暴或者病毒，那受影響的不應僅僅是這兩路視頻通話受影響，而且視頻通話應該是建立不起來的而不是單純的丟包，排除。

（4）網(wǎng)線或者光纖跳線出現(xiàn)故障或質(zhì)量不好。

經(jīng)過分段ping兩端話機地址的方法，發(fā)現(xiàn)從核心交換機ping遠端話機不丟包，ping中心點的測試話機有10%—15%的丟包，將丟包點定位在中心點的建筑內(nèi)。為了徹底排除問題，更換了中心點里核心交換機至樓層交換機的光纖，還更換了樓層交換機至話機的所有網(wǎng)線跳線，這時再使用移動電腦替換本端話機用9600字節(jié)的大包ping對端的IP話機1000次，丟包率為0，線路已上不存在丟包現(xiàn)象，然而視頻通話的故障現(xiàn)象依舊存在沒有變化。既然底層鏈路沒問題，業(yè)務配置也沒問題，那么丟包到底是怎么發(fā)生的呢？我們繼續(xù)往下排查。

（5）端口模式和對端設備不匹配，造成工作在異常狀態(tài)。

當上層的業(yè)務和下層的鏈路都沒問題時，就要著重考慮兩者的匹配情況了，而兩者匹配最直接的位置就是網(wǎng)絡接口。在檢查網(wǎng)絡交換機配置時發(fā)現(xiàn)和傳輸對接的端口模式是Auto（自協(xié)商），狀態(tài)是100M半雙工，將接口模式手動改成100M全雙工模式后測試，發(fā)現(xiàn)分支點A的視頻通話卡頓現(xiàn)象消失，通話質(zhì)量良好，但是分支點B的視頻通話依舊存在卡頓丟包故障。

（6）專線傳輸設備或板卡出現(xiàn)問題。

既然端口模式已經(jīng)匹配，那么就只能從傳輸鏈路和IP話機的配置上找更深層的匹配問題了。這時我們又做了一個測試，將視頻通話720p的分辨率改成4CIF模式，其他配置不變，發(fā)現(xiàn)故障現(xiàn)象消除，改回720p后丟包又再次出現(xiàn)，這說明H.264的視頻編碼協(xié)議720p這種分辨率對于傳輸鏈路上的某些參數(shù)是有一定要求的。

H.264的基本流由一系列NALU（Network Abstraction Layer Unit）組成，不同的NALU數(shù)據(jù)量各不相同。對于每一個NALU，根據(jù)其包含的數(shù)據(jù)量的不同，其大小也有差異。在IP網(wǎng)絡中，當要傳輸?shù)腎P 報文大小超過最大傳輸單元MTU（Maximum Transmission Unit）時就會產(chǎn)生IP分片情況。在以太網(wǎng)環(huán)境中可傳輸?shù)淖畲驣P報文（即最大傳輸單元Maximum Transmission Unit，簡稱MTU）的大小為1500字節(jié)。如果發(fā)送的IP數(shù)據(jù)包大于MTU，數(shù)據(jù)包就會被拆開來傳送，這樣就會產(chǎn)生很多數(shù)據(jù)包碎片，增加丟包率，降低網(wǎng)絡速度。對于視頻傳輸而言，若RTP（實時傳輸協(xié)議， Real-time Transport Protocol）包大于MTU而由底層協(xié)議任意拆包，可能會導致接收端播放器的延時播放甚至無法正常播放。因此對于大于MTU的NALU單元，必須進行拆包處理。進一步講，如果使用720p的分辨率進行視頻通話時，傳輸鏈路上的MTU值如果設置小于視頻數(shù)據(jù)幀的最大值，就極有可能會丟包丟幀甚至業(yè)務不通。

上述這種故障情況并不太常見，特別是幾個故障一起出現(xiàn)，極大的增加了處理的困難性和復雜性。但是只要保持思路清晰，逐項排查，多層面多專業(yè)進行理論分析，多總結，歸納掌握一套系統(tǒng)的方法，才能不斷提升解決問題的能力，在維護中提高故障處理的效率。

參考文獻

[1] 糜正琨.IP網(wǎng)絡電話技術[M]，人民郵電出版社，2000

[2] 李烏江.RTP在遠程視頻傳輸中的應用研究[D]，哈爾濱工程大學， 2008