網(wǎng)絡(luò)視頻會(huì)議丟包問題的排查及解決分析方法

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

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

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

1.案例背景

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

在項(xiàng)目實(shí)施初期便發(fā)現(xiàn)有3個(gè)旗縣局點(diǎn)掉包嚴(yán)重，使得市局視訊網(wǎng)關(guān)MCU ME5000不斷的發(fā)送異常報(bào)文，導(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ù)量很大，一般只在視訊終端剛加入會(huì)議、MCU切換廣播會(huì)場、終端或MCU接收丟包等情況下產(chǎn)生。。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5問題解決

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

3. 結(jié)束語

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

參考文獻(xiàn)：

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

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

作者簡介：

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