【正文】 CU不能把作為會場的MCU給掛斷，MCU需要特殊處理。注：保存會議狀態(tài)到DB。 更新數(shù)據(jù)庫：修改會議時間和會議狀態(tài)，更新會議會場統(tǒng)計報等數(shù)據(jù)庫操作依靠上報消息，其他從MCU結束消息在主MCU的上報消息中下發(fā)處理。首先，我們如何判斷MCU已經出現(xiàn)異常？iMSC服務器檢測到MCU?；钍?，即15秒之后（3次?；钍?，每次5秒），啟動備份流程（具體流程會在下面敘述）。其次，在會議備份時，需要區(qū)分級聯(lián)和非級聯(lián)會議，如果為非級聯(lián)會議，則只要查找到可用于備份的MCU，并嘗試創(chuàng)建會議，如果可創(chuàng)建成功，則在備份MCU上批量添加終端，創(chuàng)建會議；如果為級聯(lián)會議，因為級聯(lián)會議中存在主從關系，因此會議中，只要有MCU出現(xiàn)故障，則在進行會議備份時，找到可用于備份的MCU后，必須將對應的主從MCU的會場列表都添加到備份MCU上，然后創(chuàng)建會議；，則認為該會場已存在，則仍使用備份MCU上的會場信息進行顯示。在使用iMSC的會議備份功能時，由于MCU的價格昂貴，而且MCU本身已經比較穩(wěn)定，所以實際使用時除非本次會議意義比較大，在平常的開會時可以不需要設置備份。測試設計仍使用等價類劃分、邊界值和錯誤推測法，測試仍通過配置測試、功能測試、性能測試、壓力測試、異常測試和組合測試來進行。考慮最大會場數(shù)、最大MCU數(shù)、iMSC服務器上并發(fā)級聯(lián)會議、每臺MCU并發(fā)級聯(lián)會議等情況。會議備份主要驗證當會議中的MCU出現(xiàn)故障時，按照系統(tǒng)實現(xiàn)算法是否可找到可用于備份的MCU，并成功召開會議；會議召開成功后，當備份的MCU出現(xiàn)問題時，會議是否仍可繼續(xù)召開；如果會議中的MCU設備，自己取消注冊iMSC服務器或注冊到其它iMSC服務器時，會議備份將不被啟用；當出現(xiàn)故障的MCU上存在多個會議時，將備份到不同MCU時，會議仍可正常召開；同時也需要考慮，當MCU出現(xiàn)故障時，找不到可用于備份的MCU時的異常情況處理；如果會議為預約會議，MCU出現(xiàn)故障時，會議備份的情況。 功能測試 創(chuàng)建會議新建會議時：1) 存在級聯(lián)，將從MCU下的所有會場掛接到主MCU下；2) 存在級聯(lián)，將主MCU下的所有會場掛接到從MCU下；3) 存在級聯(lián)，主MCU下掛接多個從MCU（1～15個MCU的情況）；4) 存在級聯(lián)，主MCU和從MCU下無會場存在，僅包含MCU（匿名會議的情況）；5) 存在級聯(lián)，主MCU和從MCU下掛接會場（0～1024個會場的情況）；6) 在同樣的級聯(lián)MCU上創(chuàng)建多個級聯(lián)會議；7) 。創(chuàng)建匿名會議：1) 在密碼會議召開過程中，匿名會場呼入時，密碼位空，可不輸入，自動加入會議，若設置密碼必須輸入，若輸入密碼錯誤，則拒絕該會場入會，輸入密碼錯誤超過3次，則直接拒絕，不再顯示密碼輸入框；2) 級聯(lián)會議中，；3) 匿名會場呼入會議后，活動會議中正確顯示該條匿名會場信息，且查看該匿名會場的“會場信息”顯示正確；4) 掛斷匿名會場后，活動會議列表中不顯示該匿名會場；5) 當會議結束后，在“歷史會議”的會場列表中不顯示該匿名會場；6) 創(chuàng)建新會議時，匿名會場開啟的同時，如果“已選會場”列表為空，則自動調度失敗；如果使用歷史會議創(chuàng)建，則可調度成功；7) 匿名會議已經開啟，掛斷一個在線會場，然后讓該會場以匿名的方式呼入其它MCU，此時刪除原定的MCU下該終端，在已呼入的MCU上增加該終端為正式終端。5) 預約會議中，主MCU狀態(tài)發(fā)生變化（網(wǎng)絡、設備側取消注冊等）；6) 預約會議中，從MCU狀態(tài)發(fā)生變化（網(wǎng)絡、設備側取消注冊等）；7) 預約會議中，已選會場狀態(tài)發(fā)生變化（網(wǎng)絡、設備側取消注冊等）。8) MCU樹是一顆組織樹，每個組織節(jié)點下面僅顯示用戶有權限使用的在線MCU；9) 可以拖動樹上的MCU設備至中間的級聯(lián)樹。主場觀看：1) 分別主場觀看主、從MCU下的會場，會議信息主場觀看、圖像主場觀看顯示相應的會場；2) 依次對主、從MCU的會場進行主場觀看操作，會議信息主場觀看、圖像主場觀看顯示相應的會場；3) 依次對從、主MCU的會場進行主場觀看操作，會議信息主場觀看、圖像主場觀看顯示相應的會場；4) 會議信息中的主場觀看與實際圖像主場觀看的會場一致；5) 如果在創(chuàng)建會議的時候，配置了主場觀看不受廣播影響，且主場和廣播觀看不同的畫面（如：一個單畫面一個多畫面），那么主場觀看畫面不會隨著廣播切換；6) 主場觀看之后，畫面模式設置中對應的畫面會切換成單分屏，自動填充；7) 主場觀看之后，如果當前有主場輪詢，會被停止；8) 如果主場觀看會場和當前廣播的會場在同一個二級子MCU下，會提示沖突。 會議控制延長會議：1) 會議信息以及會議參數(shù)中的會議時長信息與實際一致；2) iMSC上的活動會議列表中的剩余時長被延長；3) 主、從MCU上的會議列表中剩余時長被延長，并且兩則的時間與iMSC一致； 4) 級聯(lián)會議，主MCU離線，會控延長會議無效彈出錯誤提示；5) 級聯(lián)會議，從MCU離線，會控延長會議，延長時間主MCU與iMSC上顯示的時長一致，但從MCU上的會議時長未被延長；從MCU重新上線，進行同步后，查看該活動會議時長保持與主MCU和iMSC一致，但從MCU上分會議開始時間是重新上線的時間。 會議調度方式1) 修改預約會議開會時間，為當前iMSC服務器時間；2) 修改預約會議為“立即會議”；3) 選擇該預約會議，然后點擊“立即召開”按鈕；4) 創(chuàng)建預約會議，讓主MCU離線，等自動召開后再讓主MCU上線；5) 創(chuàng)建預約會議，讓從MCU離線，等自動召開后再讓從MCU上線；6) 召開立即會議，會議可成功召開。 查看會議1) 查看預約會議：預約會議各項參數(shù)同創(chuàng)建會議時一致2) 查看歷史會議：歷史會議中各項參數(shù)均顯示正常關注；a、如為匿名會議、在會議中刪除的會場不在歷史會議中顯示；b、如在會議中掛斷一會場，后該會場又通過匿名的方式加入到其它MCU下，此時查看歷史會議中級聯(lián)樹的顯示是否正確；c、如通過該歷史會議創(chuàng)建新會議時，召開會議各項參數(shù)與之前召開的歷史會議一致。通過歷史會議創(chuàng)建會議時：1) 創(chuàng)建會議前，在設備管理中，刪除歷史會議中的主MCU；2) 創(chuàng)建會議前，在設備管理中，刪除歷史會議中的從MCU；3) 創(chuàng)建會議前，在設備管理中，使部分MCU離線（網(wǎng)絡、設備側取消注冊等）；4) 創(chuàng)建會議前，在設備管理中，刪除歷史會議中主MCU下面的部分/全部會場；5) 創(chuàng)建會議前，在設備管理中，刪除歷史會議中從MCU下面的部分/全部會場；6) 創(chuàng)建會議前，在設備管理中，刪除歷史會議中指定的主場或輔流源會場；7) 創(chuàng)建會議前, 在設備管理中，修改會場設置、MCU設置；8) 創(chuàng)建會議前，在iMSC上修改終端名或者MCU名。同時iMSC本身就是對設備的統(tǒng)一網(wǎng)管，故在進行性能、壓力、并發(fā)測試時，對iMSC客戶端的PC機要求、交換機/路由器性能都有一定要求，需要重點考慮測試環(huán)境能滿足我們的測試需求，同時也要關注當測試環(huán)境不能達到要求時，一些異常情況的考慮；因為當前視訊終端設備有限，故必須借助自動化工具和腳本來模擬我們的實際終端，與我們的服務器進行配合測試，系統(tǒng)長時間穩(wěn)定性測試也是必須關注的重點，故在會議召開中必須借助腳本來進行系統(tǒng)長時間穩(wěn)定性測試，該測試中包括會議的創(chuàng)建、修改、會控操作、會場操作等；同時對注冊?；睢⒍M制消息轉發(fā)、數(shù)據(jù)同步等流程進行測試時，需借助相應抓包工具（ethereal）和調試信息進行觀察，以確保各個消息的正確性、合理性，當遺漏了某些消息報文時，有相應的異常處理。 測試策略測試需求主要是功能上滿足使用多臺MCU的級聯(lián)關系來增大會議的容量，讓更多的會場可以加入到一個會議中來；會議備份功能則使得正在召開的會議，不會因為MCU設備出現(xiàn)異常而被終止，可通過iMSC系統(tǒng)進行處理，使得會議繼續(xù)正常召開。第一、配置測試：對設備配置參數(shù)，會議配置參數(shù)和會控配置參數(shù)的合法性測試不關注（屬原有內容），對級聯(lián)特性中有改動或限制的地方必須關注；級聯(lián)會議必須注冊GK，；級聯(lián)會議不支持多分屏、主席模式、多畫面自動切換，且主場/主席會場、雙流發(fā)送源只能選擇主MCU下的會場。38浙江大學碩士學位論文 第5章測試驗證第5章 測試驗證本方案描述iMSC互控級聯(lián)和會議備份的測試內容和測試方法，從測試人員的角度出發(fā)，從整體上關注整個iMSC功能的實現(xiàn)和穩(wěn)定，針對此次合入的功能與原先iMSC功能的區(qū)別，主要包含在如下三方面：創(chuàng)建會議：用戶創(chuàng)建會議時，必須手動選擇一臺MCU才可開會；該特性的合入將改變此種操作，完全由系統(tǒng)自行選擇可用的MCU來開會，用戶無需手動選擇；會議控制；會議創(chuàng)建成功后，在進行會控操作時，通過界面出發(fā)后，SS模塊查詢出該會議所在的MCU，然后構建對應的消息給MCU來進行處理；對于互控級聯(lián)特性，由于涉及到多臺MCU之間的信息交互，如果仍選用之前的處理機制，進行會控操作，由于各個MCU無法獲取到其它MCU下的會場狀態(tài)，故進行操作時，無法進行統(tǒng)一處理，導致會場狀態(tài)不正確。第四、備份MCU的查找，只能在故障MCU所在域和上級域（MCU所在域的父域、父域的父域等）中進行，不能在平級域和下級域中查找；第五、如果搜索到的備份MCU已經在該級聯(lián)會議中（級聯(lián)會議中主或從MCU出現(xiàn)故障的情況），則該MCU不能作為備份MCU使用。對于MCU側主動發(fā)起的離線，比如，注冊到其他vmserver；升級時，MCU側會向iMSC服務器發(fā)送注銷消息，此時不會啟動備份流程。 會議備份故障恢復在視頻會議系統(tǒng)中，如果是單個終端突然壞了或者網(wǎng)絡異常了，影響的僅僅是單個會場不能參加會議；如果是MCU突然壞了或網(wǎng)絡異常了，那對整個會議影響是致命的。 大體的策略如下：在歷史表中新建一條記錄A， 拷貝該會議信息到記錄A中。如果會議是簡單級聯(lián)會議，則需要給主MCU下發(fā)結束會議消息。如果取消的時候只有一個了，那么只清除數(shù)據(jù)庫和內存的信息，然后返回成功。當設置只有一個的時候，只在數(shù)據(jù)庫和內存中記錄，直接返回成功。SS查詢出會議所在的MCU， 然后構建消息，發(fā)送給MCU。支持廣播視頻，不支持廣播音頻。 MCU X為主MCU。SS查詢出會議所在的MCU， 然后構建廣播某終端的消息， 發(fā)送給MCU。 廣播圖像廣播圖像是指在會議過程中，各個會場（除了用戶已經選擇觀看其他會場）所看到的視頻畫面。如果會議是主控級聯(lián)會議，則需要將消息發(fā)給主用MCU。對于iMSC上的互控級聯(lián)會議，在主MCU下的終端，其處理方式與非互控級聯(lián)會議相似，對于非主MCU下的會場，需要獲取消息下發(fā)的路徑，發(fā)送主MCU后由主MCU下發(fā)到終端。根據(jù)觸發(fā)方式和處理的不同，我們將上面會控操作分為下面三種：（1）由終端發(fā)起的會議控制操作，如：發(fā)送輔流、申請發(fā)言；（2）由iMSC界面觸發(fā)，消息發(fā)送到主從MCU的會控操作，如：全部開/關麥克風、全部停/發(fā)視頻、全部開/關揚聲器、群邀上線、全部離線、結束會議。例如，某集團在新疆、西藏、內蒙青海的分公司公用一個MCU，則可將這些區(qū)域下的終端（會場）、MCU劃分在一個組織――西北片區(qū)下。主要過程為：進入iMSC的客戶端界面，用戶先劃分不同的域，然后在不同的域下添加對應的設備（視訊終端、多點控制單元），添加完成后，用戶創(chuàng)建會議，選擇要加入會議的會場到已選會場列表中，配置會議參數(shù)后，此時級聯(lián)調度算法先將會場進行域劃分，然后在各自的域下尋找可用的MCU，并嘗試創(chuàng)建會議（此時需要根據(jù)會議參數(shù)、入會會場數(shù)等信息，計算MCU的資源，如果可用，則嘗試創(chuàng)建成功，否則失?。?，如果在自己的域下未找到可用的MCU，此時則會繼續(xù)向父域查找，如找到則將該會場掛到父域所在的MCU下，未找到則繼續(xù)向父域的父域查找，依次向上，一直找到可用的MCU為止，如一直未找到，則確認此次級聯(lián)調度失??；如果在查找過程中，自己所在域或父域下同時提供多臺可用MCU，則優(yōu)先使用設備編碼排序靠前的MCU開會。此處還應注意，可以通過iMSC側實現(xiàn)會場輪巡，即在iMSC側啟用定時器，當輪巡到某一會場時，直接下發(fā)參數(shù)到MCU，使其觀看該會場，而不是在MCU上輪巡，這樣可以簡化實現(xiàn)方式，故輪巡方式不下發(fā)給MCU?；緯h參數(shù)下發(fā)到主、從MCU上，下發(fā)的參數(shù)主要有：會議名稱、會議別名、會議創(chuàng)建者、會議創(chuàng)建時間、是否為立即會議、是為永久會議、會議召開時間、會議結束時間、會議描述、是否有會議備份、是否級聯(lián)、是否有預約會議信息、會議入會權限信息（是否密碼會議、入會密碼、最大會場數(shù)、會議鎖定）、會議速率、離線重邀方式、是否支持自動降速、會議主場信息、音頻協(xié)議適配、音頻標準列表、主流協(xié)議適配、主流格式適配、主流設置、主流速率幀率適配、會議類型（純音頻會議、音視頻會議、雙流視頻會議）、是否輔流適配、輔流格式適配、輔流設置、輔流類型、輔流速率幀率適配、媒體加密算法、信令加密信息、NAA設置、I幀發(fā)送條件、是否要發(fā)組播（是否自動發(fā)送組播、組播應指定哪個MCU發(fā)送）、預設主席或主場、預設廣播會場、指定輔流會場等。當然，可能還會遇到下面這種情況：在會議召開過程中，MCU異常離線，又上線再次注冊到iMSC上，而在MCU離線過程中，用戶在iMSC的界面上結束了該會議，這樣導致iMSC上會議已經結束，而MCU側會議仍在繼續(xù)，帶來會議失控。開會當天的具體開始時間，取預約會議表開始時間的時分部分。方法2：根據(jù)周期表計算下次開會時間。通過重復次數(shù)控制時，每開一次會，重復次數(shù)減一，此時截止時間為空。第二、非周期會議或者周期會議結束將會議數(shù)據(jù)搬移到歷史會議信息表中，刪除會議數(shù)據(jù)。F2：會議開始定時器超時或SS收到MCU上報會議狀態(tài)變更消息；則將會議基本信息表中會議狀態(tài)變更為已召開； F3：SS收到MCU會議狀態(tài)變更“召開中”與“在解散中”，只更新數(shù)據(jù)庫會議基本信息表中會議狀態(tài)，不做其他處理。各MCU上的時間和iMSC上的時間應該保持一致（在上面策略中已經說明）， 這樣可以防止會議狀態(tài)混亂。為了解決該問題，考慮通過當某個下級MCU有兩路或兩路以上碼流需要上傳時，可以通過先在該MCU上進行圖像的編解碼處理，這樣可以實際上傳一路碼流，而其中包含多路碼流的信息。iMSC是基于原