許南希

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

參考文獻(xiàn)

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

[2] 李烏江.RTP在遠(yuǎn)程視頻傳輸中的應(yīng)用研究[D]，哈爾濱工程大學(xué)， 2008