▲
　　圖1 煙草公司視頻會議系統(tǒng)結(jié)構(gòu)圖
　　在項目實施初期便發(fā)現(xiàn)有3個區(qū)縣局點掉包嚴重，使得視訊會議MCU不斷的發(fā)送異常報文，導致市局觀看自己的圖像有很嚴重的停頓，區(qū)縣觀看市局圖像停頓現(xiàn)象也很嚴重。經(jīng)察看入會終端的會議狀態(tài)統(tǒng)計信息，發(fā)現(xiàn)網(wǎng)絡丟包很嚴重。
　　項目實施結(jié)束后，原先掉包嚴重的3個局點中1個比較正常了，另外2個的問題現(xiàn)象稍有好轉(zhuǎn)，能看到主流圖像，但是圖像停滯現(xiàn)象明顯。在后續(xù)的系統(tǒng)聯(lián)調(diào)中發(fā)現(xiàn)，近1/3局點的圖像有不同程度的停頓和停滯。在市局和這些問題局點進行點對點測試，各個局點都有一些丟包，一般在1%-3%左右，最嚴重的達到6%。
　　隨著聯(lián)調(diào)的進行，丟包局點數(shù)目還在不斷增加，幾乎達到3/4。這些丟包局點有一個相同特征：市局到區(qū)縣下行不丟包，區(qū)縣到市局上行丟包(音頻和視頻包都有被丟棄);。更加值得注意的是，各個局點的丟包程度不固定隨時變化，沒有規(guī)律可循，例如上午情況稍好點，下午就變差了。
　　在這種情況下，客戶召開視頻會議的效果很不理想，不僅圖像凍結(jié)現(xiàn)象嚴重，聲音也是斷斷續(xù)續(xù)的。

　　視頻會議問題排查分析方法
　　1. 確認問題現(xiàn)象通過召開不同類型的會議，確認影響視頻會議效果的因素是在視頻會議設備側(cè)還是網(wǎng)絡側(cè)。操作步驟如下：
　　a、 通過MCU召集純轉(zhuǎn)發(fā)會議，廣播主會場，通過WEB登錄到各區(qū)縣局點終端上查看會議狀態(tài)信息，發(fā)現(xiàn)無丟包，圖像解碼流暢，說明MCU到各區(qū)縣的下行正常;
　　b、 在此會議中切換廣播區(qū)縣會場，在主會場終端觀看圖像效果，發(fā)現(xiàn)圖像停頓，說明各區(qū)縣到市局的上行存在丟包或者MCU轉(zhuǎn)發(fā)丟包;
　　c、 結(jié)束MCU會議，市局與區(qū)縣終端點對點呼叫，通過WEB登錄雙方終端來查看雙方接收丟包情況，發(fā)現(xiàn)區(qū)縣接收無丟包，而市局有明顯丟包，這樣排除MCU轉(zhuǎn)發(fā)丟包的可能性，確認是由于網(wǎng)絡丟包造成的(終端編碼正常，因此終端發(fā)送不存在丟包)。
　　通過上述三步測試，確認傳輸網(wǎng)絡存在丟包，且基本只有上行丟包，而下行正常。以下對丟包進行進一步分析：
　　Ø 分別統(tǒng)計1.5M、768K、256K帶寬下的點對點呼叫下的丟包情況，發(fā)現(xiàn)隨著帶寬的降低，丟包無明顯改善，只是丟包總數(shù)逐漸減少，這說明丟包不是由于線路傳輸帶寬不足造成;
　　Ø 分別比較H.263和H.264、4CIF和CIF點對點呼叫下的丟包情況，發(fā)現(xiàn)基本相同，這說明丟包與視頻協(xié)議格式無關(guān);
　　Ø 配置終端MTU值(MTU可在800～1500之間調(diào)整)，再次呼叫進行對比，發(fā)現(xiàn)MTU較小時丟包情況無改善，這說明丟包與MTU值無關(guān)。
　　Ø 通過兩端報文(分別在市局和區(qū)縣交換機上抓取區(qū)縣終端發(fā)送的報文，這樣區(qū)縣側(cè)抓到的報文是完整的，而在市局側(cè)抓到的存在丟包，是否丟包可通過RTP報文的sequence
number是否連續(xù)來判斷)，發(fā)現(xiàn)丟包并不存在規(guī)律，丟包的報文大小與時機無規(guī)律。
　　通過上述分析得出以下結(jié)論：報文的丟棄無規(guī)律，與視頻會議終端的系統(tǒng)配置無關(guān)，丟包由線路傳輸造成。
　　2. 排查內(nèi)網(wǎng)及運營商接口網(wǎng)絡確認問題原因是在網(wǎng)絡側(cè)之后，下一步工作就從企業(yè)內(nèi)網(wǎng)開始，往外逐步排查問題。
　　判斷內(nèi)網(wǎng)是否存在丟包的方法是：分別在區(qū)縣交換機出口、市局接入路由器入口、市局終端接入交換機入口抓取由區(qū)縣發(fā)往市局的報文。如圖2所示，具體方法是先不呼叫，在各抓包節(jié)點先啟動抓包工具，然后兩點建立呼叫，持續(xù)約1分鐘后掛斷呼叫，再通知各抓包節(jié)點停止抓包，這樣可以保證各節(jié)點在不丟包情況下抓取的報文總數(shù)相同。通過分析，相同的呼叫中，區(qū)縣出口無丟包;市局入口和終端接入交換機入口的丟包數(shù)相同。由此判斷客戶內(nèi)網(wǎng)無丟包。

▲
　　圖2 排查局域網(wǎng)丟包情況時的拓撲結(jié)構(gòu)圖
　　另外，煙草內(nèi)網(wǎng)與運營商網(wǎng)絡之間通過光電轉(zhuǎn)換器連接，通過查看接入路由器/交換機端口信息，未發(fā)現(xiàn)半雙工問題，確認光電轉(zhuǎn)換器工作正常。
　　3. 排查運營商網(wǎng)絡接入層此案例中，運營商的網(wǎng)絡接入情況如圖3所示，于是分別以接入節(jié)點1、節(jié)點2-1、節(jié)點2-2作為抓包節(jié)點，通過抓包確認，發(fā)現(xiàn)這幾個接入層機房均不存在丟包。測試方法與排查客戶內(nèi)網(wǎng)方法相同，分別在三個節(jié)點處及市局入口抓取從渝中發(fā)往市局的報文，發(fā)現(xiàn)節(jié)點2-1和節(jié)點2-2的報文均無丟包，接入節(jié)點1入口和市局入口丟包報文情況相同，由此判斷丟包點應該在承載網(wǎng)上。

▲
　　圖3 運營商網(wǎng)絡層次結(jié)構(gòu)圖
　　4. 排查運營商承載網(wǎng)承載網(wǎng)的核心網(wǎng)拓撲如圖4所示：

▲
　　圖4 運營商承載網(wǎng)核心網(wǎng)絡拓撲圖
　　首先排查核心交換機和核心路由器，但由于抓包核心網(wǎng)上數(shù)據(jù)量太大，此前的抓包定位方法不方便使用，因此接入一臺測試終端。先以接在核心交換機上測試為例，首先測試終端與區(qū)縣點對點呼叫，結(jié)果是雙向無丟包;再使用測試終端與市局點對點呼叫，結(jié)果存在單向丟包，這樣就說明問題不在核心交換機上。按照此方法再次測試核心路由器，結(jié)果發(fā)現(xiàn)測試終端與區(qū)縣互通時，區(qū)縣終端接收正常(下行正常),而測試終端接收存在持續(xù)丟包(上行有丟包)。通過在核心路由器上做進出端口流量統(tǒng)計(通過ACL對源地址和目的地址進行精確匹配)時發(fā)現(xiàn)該核心路由器存在轉(zhuǎn)發(fā)丟包，經(jīng)過查看路由器的配置發(fā)現(xiàn)，其網(wǎng)絡擁塞情況下的丟包策略使得其在網(wǎng)絡流量過大時，將MG6060的報文被丟棄。最終通過修改路由器上的擁塞避免配置后雙向通信恢復正常。
　　5. 問題解決通過對一個局點的排查分析，找到問題根源并解決。其余局點的問題也進行同樣的處理。至此，該煙草公司視頻會議系統(tǒng)正常運行，圖像凍結(jié)、馬賽克現(xiàn)象全部消失，會議效果得到了大幅度提升。
　　總結(jié)
　　據(jù)統(tǒng)計，視訊會議系統(tǒng)出現(xiàn)的問題或者故障，60%是由網(wǎng)絡/防火墻造成。只要理清思路，從系統(tǒng)配置開始，再逐步排查局域網(wǎng)、廣域網(wǎng)，最終一定能夠準確得定位問題并找到解決問題的辦法。