【摘 要】本文針對視頻會議中遇到的最典型的丟包問題進(jìn)行了具體分析，并結(jié)合實際案例提出了分級分層次的排查問題、解決的問題的方法。

【關(guān)鍵詞】網(wǎng)絡(luò)視頻會議；丟包；排查

在視頻會議項目中，廣域網(wǎng)部分都是由運營商來承建。一旦視頻會議中出現(xiàn)因為網(wǎng)絡(luò)丟包造成的圖像或者聲音效果不理想時，運營商方面除了通過ICMP協(xié)議中的ping包檢查他們線路之外，基本沒有其他更合適的解決辦法。并且當(dāng)此網(wǎng)絡(luò)上其他的非實時業(yè)務(wù)還在比較正常運行的時候，大家容易將問題歸結(jié)到視頻會議系統(tǒng)的設(shè)備上。事實上，這類問題的原因一般是出在網(wǎng)絡(luò)這一層面。本文以一個典型案例來說明，出現(xiàn)因丟包而導(dǎo)致網(wǎng)絡(luò)視頻會議效果不理想時，對這種問題的排查分析方法。

1.案例背景

在內(nèi)蒙古某市工商管理局實施的網(wǎng)絡(luò)視頻會議項目中，視頻會議主會場采用的是某視頻設(shè)備生產(chǎn)商的視訊終端MG6050和視訊網(wǎng)關(guān)MCU ME5000且這兩個設(shè)備都位于市局。13個旗縣的終端MG6050通過運營商的MSTP網(wǎng)絡(luò)與市局相連。如圖1所示。

在項目實施初期便發(fā)現(xiàn)有3個旗縣局點掉包嚴(yán)重，使得市局視訊網(wǎng)關(guān)MCU ME5000不斷的發(fā)送異常報文，導(dǎo)致市局觀看自己的圖像以及下聯(lián)旗縣局的圖像有很嚴(yán)重的停頓、馬賽克現(xiàn)象。旗縣局觀看市局圖像同樣停頓現(xiàn)象及馬賽克現(xiàn)象也很嚴(yán)重。在圖像編解碼算法中，媒體流中的視頻圖像是有I幀、P幀、B幀幾種不同的視頻幀組合而成。

I幀是關(guān)鍵幀，其它類型的視頻幀以I幀為基礎(chǔ)進(jìn)行圖像變化部分的編碼，，I幀包含了一副圖像的完整信息，其數(shù)據(jù)量很大，一般只在視訊終端剛加入會議、MCU切換廣播會場、終端或MCU接收丟包等情況下產(chǎn)生。。

P幀是一種以I幀或其它P幀為參考值、對圖像的變化量進(jìn)行編碼的視頻幀，其數(shù)據(jù)量較小，會議中一般以傳送P幀為主。

B幀是以P幀為基礎(chǔ)對圖像運動預(yù)測進(jìn)行的編碼的雙向預(yù)測幀，在視訊會議中并不常用。

在多點會議中，當(dāng)有大量的終端接收數(shù)據(jù)產(chǎn)生丟包時，這些終端就會向MCU產(chǎn)生大量的I幀請求，MCU如果不響應(yīng)則這些丟包終端由于沒有I幀作為參考幀，就會無法解碼或者出現(xiàn)花屏。而如果MCU不斷的響應(yīng)I幀，就會出現(xiàn)大量的I幀數(shù)據(jù)。受會議帶寬的約束，I幀一般只能達(dá)到10幀/秒或者更少（I幀數(shù)據(jù)量龐大，若達(dá)到25幀/秒，會嚴(yán)重超出會議帶寬，從而造成更多丟包），而低于20幀/秒的視頻效果會直接給人造成圖像停頓的感覺由于MCU編碼的I幀是廣播給全網(wǎng)所有終端的，因此無論是丟包會場還是非丟包會場，都會出現(xiàn)圖像停頓現(xiàn)象。經(jīng)查看入會終端的會議狀態(tài)統(tǒng)計信息，發(fā)現(xiàn)網(wǎng)絡(luò)丟包很嚴(yán)重。

因此，解決問題的根本是需要排查當(dāng)前網(wǎng)絡(luò)的丟包原因，而不能通過減少I幀的編碼頻率來規(guī)避。

項目實施結(jié)束后，原先掉包嚴(yán)重的3個旗縣局點中1個比較正常了，另外2個的問題現(xiàn)象稍有好轉(zhuǎn)，能看到主流圖像，但是圖像停滯現(xiàn)象仍然很明顯。在后續(xù)的系統(tǒng)聯(lián)調(diào)中發(fā)現(xiàn)，近1/3局點的主流圖像有不同程度的停頓和停滯。在市局和這些問題局點進(jìn)行點對點測試，各個局點都有一些丟包，一般丟包率在1%～3%左右，最嚴(yán)重的甚至可以達(dá)到10%。

隨著聯(lián)調(diào)工作的進(jìn)行，丟包局點數(shù)目還在不斷增加，在13個旗縣局中有10個旗縣局的視訊數(shù)據(jù)存在丟包。這些丟包局點有一個相同特征：市局到旗縣下行不丟包，旗縣到市局上行丟包，其中音頻數(shù)據(jù)和視頻數(shù)據(jù)都存在丟包現(xiàn)象。更加值得注意的是，各個局點的丟包程度不固定隨時變化，沒有規(guī)律可循，例如上午情況稍好一些，下午就變的比較嚴(yán)重。在這種情況下，客戶召開視頻會議的效果很不理想，不僅圖像凍結(jié)現(xiàn)象嚴(yán)重，聲音也是時斷時續(xù)。

2. 網(wǎng)絡(luò)視頻會議問題排查分析方法

2.1確認(rèn)問題現(xiàn)象

通過召開部同類型的網(wǎng)絡(luò)視頻會議，確認(rèn)影響視頻會議效果的因素是視頻會議設(shè)備側(cè)還是網(wǎng)絡(luò)側(cè)。操作步驟如下：

1、通過市局的視訊網(wǎng)關(guān)MCU ME5000召集純轉(zhuǎn)發(fā)會議，廣播主會場，通過Web界面管理的方式登錄到各旗縣局點視訊終端MG6050上看會議狀態(tài)信息，發(fā)現(xiàn)無丟包現(xiàn)象發(fā)生且圖像解碼流暢，說明從市局視訊網(wǎng)關(guān)到各旗縣局視訊終端的下行數(shù)據(jù)是正常的。

2、在此會議中切換廣播旗縣會場，在主會場終端觀看圖像效果，發(fā)現(xiàn)圖像出現(xiàn)停頓及馬賽克現(xiàn)象，說明各旗縣到市局的上行存在丟包或者視訊網(wǎng)關(guān)轉(zhuǎn)發(fā)丟包問題。

3、結(jié)束MCU會議，市局與旗縣視訊終端進(jìn)行點對點呼叫，通過Web界面管理的方式登錄到雙方終端來查看雙方接收丟包情況，發(fā)現(xiàn)旗縣接收無丟包現(xiàn)象，而市局有明顯丟包，這樣排除MCU轉(zhuǎn)發(fā)丟包的可能性，確認(rèn)是由于網(wǎng)絡(luò)丟包造成的（終端編碼正常，因此終端發(fā)送不存在丟包）。

通過上述三步測試，確認(rèn)傳輸網(wǎng)絡(luò)存在丟包，且基本只有上行丟包，而下行正常。以下對丟包進(jìn)行進(jìn)一步分析：

1、分別統(tǒng)計在1.5Mbps、768Kbps、256Kbps寬帶下，進(jìn)行點對點呼叫方式的丟包情況，發(fā)現(xiàn)隨著帶寬的降低，丟包無明顯改善，只是丟包總數(shù)逐漸減少，這說明丟包不是由于線路傳輸帶寬不足造成的。

2、分別比較H.263和H.264、4CIF和CIF在點對點呼叫方式下的丟包情況，發(fā)現(xiàn)基本相同，這說明丟包與視頻協(xié)議格式無關(guān)。

3、配置終端MTU值（MTU可在800～1500之間調(diào)整），所謂的MTU是只在網(wǎng)絡(luò)中允許傳輸?shù)淖畲髷?shù)據(jù)單元的大小，再次呼叫進(jìn)行對比，發(fā)現(xiàn)MTU較小時丟包情況無改善，這說明丟包與MTU值無關(guān)；

4、通過兩端報文（分別在市局和區(qū)縣交換機(jī)上抓取區(qū)縣終端發(fā)送的報文，這樣區(qū)縣側(cè)抓到的報文時完整的，而在市局側(cè)抓到的存在丟包，是否丟包可通過RTP報文的sequence number是否連續(xù)來判斷），發(fā)現(xiàn)丟包并不存在規(guī)律，丟包的報文大小與時機(jī)無規(guī)律。

通過上述分析得出以下結(jié)論：報文的丟棄無規(guī)律，與視頻會議終端的系統(tǒng)配置無關(guān)，丟包由線路傳輸造成。

2.2排查內(nèi)網(wǎng)及運營商接口網(wǎng)絡(luò)

確認(rèn)問題原因是在網(wǎng)絡(luò)部分之后，下一步工作就從內(nèi)部網(wǎng)絡(luò)開始，往外逐步排查問題。

判斷內(nèi)網(wǎng)是否存在丟包的方法是：分別在給旗縣交換機(jī)出口、市局接入路由器入口、市局終端接入交換機(jī)入口配置鏡像端口，并通過抓包軟件結(jié)合鏡像端口輸出的數(shù)據(jù)捕獲旗縣發(fā)往市局的報文。具體方法是先不呼叫，在各抓包節(jié)點先啟動抓包軟件，然后兩點建立呼叫，持續(xù)約1分鐘后掛斷呼叫，再通知各抓包節(jié)點停止捕獲數(shù)據(jù)，這樣可以保證各節(jié)點在不丟包情況下抓取的報文總數(shù)相同。通過分析，在相同的呼叫中，旗縣出口無丟包；市局入口和終端接入交換機(jī)入口的丟包數(shù)相同。由此可以判斷市局和旗縣局組成的內(nèi)網(wǎng)中無丟包問題存在。

另外，工商管理局內(nèi)網(wǎng)與運營商網(wǎng)絡(luò)之間通過光電轉(zhuǎn)換器連接，通過查看市局接入路由器和旗縣接入交換機(jī)端口信息，未發(fā)現(xiàn)端口工作模式以及工作速率不匹配等問題，確認(rèn)光電轉(zhuǎn)換器工作正常。

2.3排查運營商網(wǎng)絡(luò)接入層

此案例中，運營商的網(wǎng)絡(luò)接入情況如圖2所示，于是分別以接入節(jié)點1、節(jié)點2-1、節(jié)點2-2作為抓包節(jié)點，通過抓包確認(rèn)，發(fā)現(xiàn)這幾個接入層機(jī)房均不存在丟包。測試方法與排查客戶內(nèi)網(wǎng)方法相同，分別在三個節(jié)點處及市局入口抓取從渝中發(fā)往市局的報文，發(fā)現(xiàn)節(jié)點2-1和節(jié)點2-2的報文均無丟包，接入節(jié)點1入口和市局入口丟包報文情況相同，由此判斷丟包應(yīng)該在承載網(wǎng)上。

圖2 運營商網(wǎng)絡(luò)層次結(jié)構(gòu)圖

2.4排查運營商承載網(wǎng)

首先排查承載網(wǎng)絡(luò)中的核心交換機(jī)和核心路由器，但由于抓包核心網(wǎng)上數(shù)據(jù)量太大，此前的抓包定位方法不方便使用，因此接入一臺測試終端。先以接在核心交換機(jī)上測試為例，首先測試終端與旗縣局進(jìn)行點對點呼叫，結(jié)果是雙向無丟包；再使用測試終端與市局進(jìn)行點對點呼叫，結(jié)果存在單向丟包，這樣說明問題不在核心交換機(jī)上。按照此方法再次測試核心路由器，結(jié)果發(fā)現(xiàn)測試終端與區(qū)縣互通時，區(qū)縣終端接收正常即下行正常，而測試終端接收存在持續(xù)丟包即上行有丟包。通過在核心路由器上做進(jìn)出端口流量統(tǒng)計（通過ACL對源地址和目的地址進(jìn)行精確匹配）時發(fā)現(xiàn)該核心路由器存在轉(zhuǎn)發(fā)丟包，經(jīng)過查看路由器的配置發(fā)現(xiàn)，其網(wǎng)絡(luò)擁塞情況下的丟包策略使得其在網(wǎng)絡(luò)流量過大時，將MG6050的報文被丟棄。最終通過修改路由器的擁塞避免配置后雙向通信恢復(fù)正常。

2.5問題解決

通過對一個局點的排查分析，找到問題根源并解決。其余局點的問題也進(jìn)行同樣的處理。至此，該工商管理局網(wǎng)絡(luò)視頻會議系統(tǒng)正常運行，圖像凍結(jié)、馬賽克現(xiàn)象全部消失，會議效果得到了大幅度提升。

3. 結(jié)束語

視訊會議系統(tǒng)的音視頻效果與網(wǎng)絡(luò)承載質(zhì)量息息相關(guān)。在大型視訊會議系統(tǒng)組網(wǎng)中，由于傳輸設(shè)備及傳輸線路的更為復(fù)雜，網(wǎng)絡(luò)側(cè)引入的問題可能性就更大，丟包、亂序、擁塞等問題時有發(fā)生。為檢測網(wǎng)絡(luò)質(zhì)量，人們通常習(xí)慣使用Ping命令進(jìn)行測試，而RTP與ICMP協(xié)議原理不同，Ping命令無法測試網(wǎng)絡(luò)傳輸RTP碼流的真實情況。處理問題時，首先要采用分段分塊、化繁為簡的方法將測試系統(tǒng)最小化并將故障復(fù)現(xiàn)；其次要考慮每一臺網(wǎng)絡(luò)設(shè)備、每一個設(shè)備端口甚至每一根網(wǎng)線所造成的影響；最后要選用專業(yè)的測試軟件和測試方法來進(jìn)行分析，只要理清思路，最終一定能夠準(zhǔn)確的定位問題并找到解決問題的辦法。

參考文獻(xiàn)：

[1] 曹慶華.網(wǎng)絡(luò)測試與故障診斷實驗教程[M].北京：清華大學(xué)出版社，2006.

[2] 譚浩強(qiáng).計算機(jī)網(wǎng)絡(luò)教程[M].北京：電子工業(yè)出版社，2005.

作者簡介：

新宇，男，1976年生，蒙古族，職稱：助理工程師，主要研究方向：計算機(jī)網(wǎng)絡(luò)。