【正文】 資源浪費比較大第二、將MCU區(qū)分為MC+MP模式和MP only模式MCU主要由MC和MP模塊構(gòu)成（MP為音視頻處理模塊，MC為多媒體控制模塊），當(dāng)單個MCU可滿足需求時，我們配置MCU為MC+MP模式；當(dāng)單個MCU滿足不了用戶需求時，我們需要多個MCU，并且配置一個MC和多個MP的級聯(lián)會議，通過多個MP來解決單個MCU音視頻數(shù)據(jù)處理不過來的瓶頸，： MCU按MP only模式實現(xiàn)互控級聯(lián)總體組網(wǎng)圖該方法的優(yōu)點：功能上：功能的拓展了MCU的會議容量，功能上容易實現(xiàn)可用/易用性：沒有很大的修改用戶原先的使用環(huán)境，讓用戶感覺還是在單臺MCU上進行會議，操作方便該方法的缺點：功能上：實現(xiàn)復(fù)雜，需要修改MCU的配置，并使其注冊到上級MCU上，設(shè)備的可維護性較差；用戶在開完互控級聯(lián)之后想單臺使用時，需要自己手工配置回單臺模式；在多臺MCU處于不同網(wǎng)絡(luò)或網(wǎng)絡(luò)延遲比較高的時候，而MC和MP之間的通信比較頻繁，這種方法帶來的弊端是頻繁的會控會控操作會使圖像反應(yīng)很慢，帶來更高的延遲。因此，MCU需要高效靈活地平臺進行統(tǒng)一管理和調(diào)度，當(dāng)單個MCU不能滿足的要求的時候，我們需要調(diào)度多個MCU進行級聯(lián)，以實現(xiàn)會議的擴容。第2章：介紹在研究本課題前需要具備的專業(yè)知識。第6章：對此次開發(fā)過程中優(yōu)點和缺點的分析，并展望后續(xù)開發(fā)的需求。主要包含：TCP協(xié)議（Transmission Control Protocol傳輸控制協(xié)議）和UDP協(xié)議（User Datagram Protocol用戶數(shù)據(jù)報協(xié)議）。它僅僅把數(shù)據(jù)包分組傳輸過去，不保證數(shù)據(jù)一定能傳輸?shù)竭_，當(dāng)使用該協(xié)議進行傳輸時，任何保證數(shù)據(jù)輸出完整性的驗證只能在應(yīng)用層進行[1]。當(dāng)出現(xiàn)路徑不可用時，ICMP可以正常的中斷TCP連接[5]。： RTP報文各字段含義 [4]其具體含義如下：1）時間戳(Timestamp)：長度為32字節(jié)。當(dāng)發(fā)送一個RTP數(shù)據(jù)包序列號就加1，這樣接收端用它來檢驗數(shù)據(jù)包是否有丟包，但是RTP協(xié)議本身不負(fù)責(zé)丟包數(shù)據(jù)重傳，需要應(yīng)用層軟件來做相關(guān)處理。4）同步源標(biāo)識符（Synchronization Source Identifier）：長度為32位，用來標(biāo)識RTP碼流數(shù)據(jù)包的第一個包，在RTP會話中的每一個數(shù)據(jù)包都有一個同步源標(biāo)識符。 ：多點控制單元（MCU）、終端（MG）、網(wǎng)關(guān)（GateWay）、網(wǎng)守（GK）。 MCU的方式工作，但音頻處理器并不是必需的。，也是提供實時以及雙向通信的設(shè)備，提供對用戶音視頻信號的輸入采集、壓縮和解壓縮輸出處理，模擬會議參與者的行為，終端所在地即為用戶實際所在地。也就是說如果視頻會議系統(tǒng)的所有終端都在同一個IP網(wǎng)絡(luò)內(nèi)，那么網(wǎng)關(guān)則是一個可選設(shè)備。3）通信協(xié)議和通信規(guī)程()之間的互譯，以實現(xiàn)應(yīng)用層的通信。如果該會議系統(tǒng)中存在網(wǎng)守，那么整個“域”中的設(shè)備則都要接收網(wǎng)守的管理。終端在發(fā)起呼叫時必須經(jīng)過網(wǎng)守的允許，呼叫所使用的帶寬最終也是由網(wǎng)守來決定。短期內(nèi)，支持監(jiān)控、視訊、媒體發(fā)布業(yè)務(wù)，節(jié)約公司開發(fā)和維護成本。.SOA的開放框架，實現(xiàn)平臺所有功能全方位的開放，實現(xiàn)“開發(fā)即開放”，良好的適應(yīng)性和互通性，通過對多媒體應(yīng)用建模來實現(xiàn)，將體現(xiàn)更好的分層結(jié)構(gòu)和更合理的功能劃分，各個組件間功能耦合度低，可獨立的實現(xiàn)向前演進?！按罘e木”的開發(fā)方式，節(jié)省大量的重復(fù)開發(fā)成本，開發(fā)和穩(wěn)定周期更短。數(shù)據(jù)的存在形式不受位置（本地/遠程）、形式（數(shù)據(jù)庫/文件/原始磁盤塊）、格式（結(jié)構(gòu)化/非結(jié)構(gòu)化）的限制，同時支持對數(shù)據(jù)的擴展和替換。14浙江大學(xué)碩士學(xué)位論文 第3章總體設(shè)計第3章 總體設(shè)計 iMSC整體結(jié)構(gòu)互控級聯(lián)特性是在iMSC已有功能的基礎(chǔ)上，開發(fā)支持會議級聯(lián)的功能；需求來源于單個MCU的容量已經(jīng)不能滿足視訊會議市場的迅速發(fā)展，必須通過新的技術(shù)來解決，此時就引入了MCU的級聯(lián)技術(shù)即：各個廠商均支持在一個會議中，使用多個MCU的級聯(lián)關(guān)系，來增加會議容量，滿足客戶需求。在設(shè)備管理方面，通過SNMP協(xié)議負(fù)責(zé)設(shè)備注冊及狀態(tài)維護。這樣，呼叫層面，監(jiān)控－視訊實現(xiàn)標(biāo)準(zhǔn)化意義上的互通。4）SDK模塊：，用于接收WEB SERVER的函數(shù)調(diào)用。9）MM：負(fù)責(zé)IMOS管理模型的構(gòu)建和接口提供，包括系統(tǒng)管理、權(quán)限管理、設(shè)備管理、事件管理、任務(wù)管理、升級管理等功能。它是一種標(biāo)準(zhǔn)的、與具體的網(wǎng)絡(luò)環(huán)境無關(guān)的語法格式[1]。運行和調(diào)試接口：提供對運行日志信息的輸出、級別控制功能，同時提供對系統(tǒng)內(nèi)部信息的在線調(diào)試功能。 為了實現(xiàn)上述iMSC的功能，需要再原MCU和MG系統(tǒng)上配合修改，增加“iMSC平臺管理模塊”，由該模塊負(fù)責(zé)MCU和MG側(cè)消息的接收和下發(fā)，但這個不是本文研究的重點。比如iMSC上的時間為2011年3月15日10點整，且創(chuàng)建一個時間為1小時的會議，其中級聯(lián)MCUA和MCUB，而此時在MCUA的時間為2011年3月15日9點整，MCUB的時間為2011年3月15日11點整，則在創(chuàng)建會議前，獲取MCUA的時間與MCUB的時間后，在MCUA上創(chuàng)建一個從2011年3月15日9點開始持續(xù)1h的會議；同樣根據(jù)時間差在MCUB上創(chuàng)建一個2011年3月15日11點開始持續(xù)1h的會議。3) 設(shè)置一個NTP服務(wù)器，在使用iMSC時先用與NTP上的時間同步，在MCU注冊到iMSC上時進行一次時間同步，之后每個10分鐘再進行一次時間同步。 廣播和觀看下級會場策略廣播和觀看夏季會場策略對iMSC互控級聯(lián)會議影響最大，由于MCU上MP及硬件的限制，國內(nèi)視頻會議系統(tǒng)MCU和MG之間的通信都只有8路，具體為音頻通道、視頻通道、輔流通道、數(shù)據(jù)能力通道各占兩路，其中數(shù)據(jù)能力指傳輸攝像機控制等信息的通道，每條通道分為上行和下行通道。無法將下級會場的碼流直接發(fā)送到頂級MCU。會議開始與會議結(jié)束觸發(fā)的具體流程， 級聯(lián)會議生命周期在這里讓會議開始定時器和會議結(jié)束定時器規(guī)定比正常的時間延后10秒， 以便給MCU上報狀態(tài)留有時間余量，這里使用定時器為了防止當(dāng)MCU離線或異常時，iMSC上的會議信息顯示正常，即能正常的召開與結(jié)束。如果預(yù)約會議是立即會議，則會議狀態(tài)為召開中，直接進入F3流程。會議狀態(tài)為已召開，則把會議基本信息表中會議狀態(tài)變更為未召開，重新進F2流程；會場狀態(tài)為未召開，忽略該事件。方法1：會議預(yù)約信息表里的重復(fù)次數(shù)與周期會議截止時間為二選一：即通過重復(fù)次數(shù)控制周期會議結(jié)束或者通過截止時間控制會議結(jié)束。注：期會議不可能大于24小時，周期會議不可能肯是永久會議。結(jié)合當(dāng)天日期即可計算出下次會議的開始日期。“會議基本信息表”結(jié)束時間與開始時間 代表每次實際開會時間，會議預(yù)約信息表的開始時間與截止時間為周期會議的生命周期。上級MCU作為主MCU，下級MCU作為從MCU，召開級聯(lián)會議時，實際上通過iMSC在各級聯(lián)的MCU上召開會議再借助平臺來實現(xiàn)整個會議的互控級聯(lián)，會議參數(shù)的下發(fā)策略如下。具體原因在上面已經(jīng)說過，此處不再重復(fù)說明。 創(chuàng)建會議會議調(diào)度本方案中MCU之間的級聯(lián)關(guān)系的建立，通過創(chuàng)建會議時所選擇的入會會場所在域的MCU來自動調(diào)度。如果按行政區(qū)來劃分組織，且行政組織規(guī)模較小，沒有單獨的MCU，與其它行政區(qū)公用一個MCU，則可將這幾個公用一個MCU的行政區(qū)劃分在一個組織下，便于調(diào)度。 控制會議在視頻會議的會議控制過程中，主要包含以下操作：全部開/關(guān)麥克風(fēng)、全部停/發(fā)視頻、全部開/關(guān)揚聲器、發(fā)言申請、發(fā)送輔流、FECC控制、群邀上線、全部離線、廣播會場、會場選擇觀看、主場輪巡、廣播輪巡、結(jié)束會議等。 發(fā)言申請發(fā)言申請由終端發(fā)起，即在會控過程中，會議終端通過自己的界面發(fā)起申請發(fā)言的操作，該操作由用戶選擇是否同意發(fā)言申請，一般設(shè)置發(fā)言者后，需要廣播該發(fā)言者的會場，更符合用戶的習(xí)慣。 由iMSC的SS模塊查詢出會議所在的MCU， 然后構(gòu)建消息，發(fā)送給MCU。由終端發(fā)起的發(fā)言申請，SS模塊對輔流發(fā)送和發(fā)言申請的處理流程相似，不同的是MCU側(cè)對輔流發(fā)送需要特殊處理，處理流程與廣播圖像相似，具體在廣播圖像中說明。廣播圖像 ： 廣播圖像流程圖廣播某終端。 終端A掛在MCUA下面。， 廣播來自終端A的媒體流。在廣播終端的時候，需要判斷當(dāng)時否是廣播輪詢啟動中，如果是，則需要先停止廣播輪詢，還需要考慮路徑?jīng)_突的問題，如和主場觀看或者主場輪詢的沖突。： FECC控制流程圖 FECC受控流程圖設(shè)置/取消設(shè)置會場為FECC控制者。設(shè)置FECC控制者、受控制， 需要在指定好FECC一對控制者、受控者之后， 向控制者、受控者路徑上的MCU下發(fā)FECC指令。取消FECC控制，向控制者、受控者路徑上的MCU下發(fā)取消FECC指令，只要取消一個就向控制者和受控者路徑上的MCU下發(fā)取消FECC控制者和FECC受控者的消息，并清除內(nèi)存和數(shù)據(jù)庫中對應(yīng)的字段，沒有被取消的就仍然在內(nèi)存和數(shù)據(jù)庫中保存。 結(jié)束會議結(jié)束會議就是根據(jù)用戶的意愿，解散所有在開會的終端和MCU，并釋放資源，： 結(jié)束會議流程圖AS（SS）查詢出會議所在的MCU，如果會議是主控級聯(lián)會議， 則需要將消息發(fā)給主用MCU。 會議記錄的更新策略， 參考視訊MCU的處理。 結(jié)束會議時iMSC還是通過MCU的上報消息來統(tǒng)一處理，收到主MCU結(jié)束成功的上報后處理數(shù)據(jù)庫，同時并發(fā)給從MCU發(fā)結(jié)束會議的請求，但不關(guān)系結(jié)果的成功還是失敗，iMSC上認(rèn)為會議結(jié)束。即iMSC服務(wù)器在檢測到TCP連接中斷后，起一個定時器，15秒之后，判斷這個設(shè)備是否已經(jīng)在線，如果還離線，則啟動備份流程。： 會議備份流程圖： 查找備份MCU流程圖查找可用于備份MCU時，遵循的原則：第一、在設(shè)備管理界面，添加多點控制單元（MCU）時，有提供下面三個選項：專用的備份MCU 、可用于備份的MCU 和不能用于備份的MCU第二、那么在創(chuàng)建會議過程中時，如果會議級聯(lián)結(jié)構(gòu)樹為自動調(diào)度生成，則不選擇專用于備份的MCU，如果用戶手動調(diào)整該級聯(lián)結(jié)構(gòu)樹，則可使用任何MCU，不考慮MCU自身設(shè)置；第三、啟動會議備份時，從故障MCU所在的域逐級向上查找備份MCU，在一個域中，如果存在多個可用的MCU，則優(yōu)先選擇專用的備份MCU，其后選擇可用于備份的MCU，不選擇不能用于備份的MCU。 本章小結(jié)本章是本文的重點，主要介紹了iMSC級聯(lián)會議上5個比較重要的策略，重點介紹了創(chuàng)建會議、會議控制及會議備份的實現(xiàn)流程及具體算法。對于原有特性沒有變化的點不單獨設(shè)計測試用例，對新增和改變的地方進行重點測試。第四、壓力測試：在滿足性能要求的情況下的穩(wěn)定性測試；例如：進行長時間召開級聯(lián)會議，并進行各種會控操作的情況；在會議中反復(fù)執(zhí)行群邀上線、全部離線操作；反復(fù)召開/結(jié)束會議；批量增加會場等操作；會議備份壓力測試關(guān)注多次進行會議備份的情況（例如：從MCU出現(xiàn)故障后，備份該會議到其它MCU，當(dāng)其它MCU同樣出現(xiàn)故障時，可再次成功備份，可考慮MCU迭代出現(xiàn)故障的情況），同時關(guān)注各種壓力測試下的內(nèi)存是否泄漏和CPU的占有率；第五、異常測試：考慮通過歷史會議、預(yù)約會議創(chuàng)建過程中和會議召開過程中，設(shè)備異常情況（斷電、取消注冊、重啟等）、網(wǎng)絡(luò)異常（網(wǎng)絡(luò)設(shè)備斷電、網(wǎng)口翻轉(zhuǎn)、網(wǎng)絡(luò)丟包/延遲等）等情況下的業(yè)務(wù)是否可正常處理、設(shè)備是否穩(wěn)定；對于異常信令包、異常RTP報文的處理的測試；會議備份需要考慮找不到可用于備份MCU的情況及iMSC側(cè)與設(shè)備側(cè)TCP連接斷開后的保護處理；第六、組合測試：關(guān)注會議創(chuàng)建過程中和會議召開過程中，設(shè)備側(cè)取消iMSC注冊的情況；同時必須注意通過iMSC召開級聯(lián)會議后，各個MCU上會議管理的狀態(tài)是否顯示正確；關(guān)注會議管理和設(shè)備管理之間相互制約關(guān)系。難點主要在級聯(lián)特性和會議備份在功能方面的關(guān)聯(lián)性、約束性較多，需全面考慮；級聯(lián)特性因為級聯(lián)樹為自動生成，所以在創(chuàng)建一個會議時，需要關(guān)注生成的級聯(lián)關(guān)系是否正確，當(dāng)會議創(chuàng)建成功后、會議為預(yù)約狀態(tài)、通過歷史會議模版創(chuàng)建會議時，當(dāng)級聯(lián)樹中MCU狀態(tài)發(fā)生變化（掉線、重啟、取消注冊、注冊到其它服務(wù)器等）時異常點的考慮；針對會議備份，本身就是對會議召開過程中，所使用的設(shè)備出現(xiàn)故障時的一種異常處理，故測試過程中，這兩部分特性對異常點的構(gòu)造較多，需要重點測試。通過會議模版創(chuàng)建會議時：1) 模板中不設(shè)置主場和輔流源；2) 模板中設(shè)置主場和輔流源；3) 模板中設(shè)置主場和輔流源，但在創(chuàng)建會議時，從已選會場中刪除主場或輔流源；4) 模板中設(shè)置主場和輔流源，但在創(chuàng)建會議時，刪除全部已選會場，開啟匿名會場；5) 模板中設(shè)置主場和輔流源，但在創(chuàng)建會議時，再新增一些會場；6) 修改會議模版中參數(shù)，重新設(shè)置主場和輔流源后，再創(chuàng)建會議時，對應(yīng)修改均已生效。創(chuàng)建預(yù)約會議：1) 根據(jù)“開始時間（設(shè)置該時間晚于當(dāng)前系統(tǒng)時間）”，創(chuàng)建級聯(lián)/非級聯(lián)預(yù)約會議；2) 根據(jù)“會議周期”（分周期類型:按天/周/月、僅一次）來創(chuàng)建級聯(lián)/非級聯(lián)預(yù)約會議；3) 根據(jù)“會議周期”中“重復(fù)次數(shù)”來控制和創(chuàng)建級聯(lián)/非級聯(lián)預(yù)約會議；4) 根據(jù)“會議周期”中“結(jié)束日期”來控制和創(chuàng)建級聯(lián)/非級聯(lián)預(yù)約會議；5) 通過預(yù)約會議創(chuàng)建立即會議，永久會議。 刪除預(yù)約會議1) 主從MCU的Web上MCU管理信息的MCU級聯(lián)關(guān)系刪除；2) 主從MCU的Web上活動會議列表刪除該會議信息，歷史會議中存在該結(jié)束會議；3) 會場與MCU之間的關(guān)系刪除，其它會議可繼續(xù)使用。10) 會場樹顯示用戶在基本設(shè)置頁選擇的全部會場；11) 可以拖動會場至中間的會議結(jié)構(gòu)樹；12) 級聯(lián)樹上的會場可以拖動至右側(cè)會場樹；13) 級聯(lián)樹上的MCU設(shè)備可以拖動至左側(cè)可選多點控制單元樹；14) 頂級MCU設(shè)備下面的會場可以拖動至?xí)h主場(席)設(shè)置框；15) 頂級MCU設(shè)備下面的會場可以拖動至輔流發(fā)送會場設(shè)置框（支持輔流的情況下）；16) 選擇樹上的任一節(jié)點拖動至“回收站”按鈕后，所選節(jié)點上的MCU和會場會自動還原至相應(yīng)的位置；17) 級聯(lián)樹上可以沒有會場，但是必須要有MCU設(shè)備。廣播會場：1) 分別廣播主