【導讀】市場也在不斷的發(fā)展壯大。因此，MCU需要高效靈活的平臺進行統(tǒng)一管理和調(diào)度，基于此，本文主要結(jié)合某公司開發(fā)的iMOS(IPMultimediaOpen. 本文從會議創(chuàng)建、會議控制和會議備份分析其流程實現(xiàn)，還考慮從原。MCU穩(wěn)定性出發(fā)，分析比較重要的幾個策略。根據(jù)級聯(lián)會議的特性，分析測試。的測試策略及測試方案，以保障產(chǎn)品在開發(fā)完成時的質(zhì)量。

　　

【正文】 當然，可能還會遇到下面這種情況：在會議召開過程中， MCU 異常離線，又上線再次注冊到 iMSC 上，而在 MCU 離線過程中，用戶在 iMSC 的界面上結(jié)束了該會議，這樣導致 iMSC 上會議已經(jīng)結(jié)束，而 MCU 側(cè)會議仍在繼續(xù)，帶來會議失控。為了避免出現(xiàn)此類情況，本文做如下處理：在 MCU 再次注冊到 iMSC 上時，刪除其上面的所有會議（包括活動會議和預約會議）。 iMSC 會議參數(shù)下發(fā)策略 iMSC 上的級聯(lián)會議，是通過 MCU 之間簡單級聯(lián)來實現(xiàn)，但通過 iMSC 平臺浙江大學碩士學位論文 第 4 章 詳細設計 24 的全局管理，可以達到常規(guī)視訊 網(wǎng)絡中的互控級聯(lián)的效果。 上級 MCU 作為主MCU，下級 MCU 作為從 MCU，召開級聯(lián)會議時，實際上通過 iMSC 在各級聯(lián)的 MCU 上召開會議再借助平臺來實現(xiàn)整個會議的互控級聯(lián)，會議參數(shù)的下發(fā)策略如下。 基本會議參數(shù)下發(fā)到主、從 MCU 上，下發(fā)的參數(shù)主要有：會議名稱、會議別名、會議創(chuàng)建者、會議創(chuàng)建時間、是否為立即會議、是為永久會議、會議召開時間、會議結(jié)束時間、會議描述、是否有會議備份、是否級聯(lián)、是否有預約會議信息、會議入會權(quán)限信息（是否密碼會議、入會密碼、最大會場數(shù)、會議鎖定）、會議速率、離線重邀方式、是否支持自動降速 、會議主場信息、音頻協(xié)議適配、音頻標準列表、主流協(xié)議適配、主流格式適配、主流設置、主流速率幀率適配、會議類型（純音頻會議、音視頻會議、雙流視頻會議）、是否輔流適配、輔流格式適配、輔流設置、輔流類型、輔流速率幀率適配、媒體加密算法、信令加密信息、 NAA 設置、 I 幀發(fā)送條件、是否要發(fā)組播（是否自動發(fā)送組播、組播應指定哪個 MCU 發(fā)送）、預設主席或主場、預設廣播會場、指定輔流會場等。再根據(jù)自動或手動調(diào)度的會場下發(fā)到各 MCU 中。 根據(jù)上面廣播和觀看下級會場的策略，下級的碼流是先發(fā)到主 MCU 下進行處理，故對于圖像參數(shù)的下 發(fā)有如下策略：對于圖像配置中的字幕、橫幅、會場名、多畫面信息等參數(shù)，只下發(fā)到主 MCU，從 MCU 采用默認值。具體原因在上面已經(jīng)說過，此處不再重復說明。此處還應注意，可以通過 iMSC 側(cè)實現(xiàn)會場輪巡，即在 iMSC 側(cè)啟用定時器，當輪巡到某一會場時，直接下發(fā)參數(shù)到 MCU，使其觀看該會場，而不是在 MCU 上輪巡，這樣可以簡化實現(xiàn)方式，故輪巡方式不下發(fā)給 MCU。 當會議中 MCU 異常后會議角色處理 一般情況下，視訊會議系統(tǒng)應用的網(wǎng)絡環(huán)境應該比較穩(wěn)定和暢通，但是萬一由于某種特殊原因產(chǎn)生網(wǎng)絡異常時，例如：通過 iMSC 召開的級聯(lián)會 議會議過程中，當 MCU 重啟，或者 MCU 與 iMSC 斷開連接后又重新注冊成功，這時會議的活動信息必然發(fā)生一些變化，（比如 FECC 控制者 /受控者、會議主場、廣播會場等會議信息）本節(jié)就是討論發(fā)生這種異常時 iMSC 的處理策略。 當發(fā)生上述情況時， iMSC 采用如下處理策略： 由于在互控級聯(lián)會議時，當 MCU 連接斷開后，如果自動恢復 MCU 上的活動會議信息到 iMSC 上 ，由于在 MCU 離線期間 iMSC 上用戶可能重新要對配置浙江大學碩士學位論文 第 4 章 詳細設計 25 進行設置，如發(fā)言者、廣播會場、主場、 FECC 控制 /受控者，此時當 MCU 再次上線時，再次將 MCU 上這些信息同步 到 iMSC，可能產(chǎn)生會議角色混亂的后果，而且需要記錄斷線 MCU 中的各個角色的信息，實現(xiàn)上復雜度也大大提高，故此處采用當 MCU 發(fā)生上述異常時，在數(shù)據(jù)庫中清空活動會議信息中的各種角色設置，但不下發(fā)到 MCU 中， MCU 上線后按 MCU 側(cè)的處理方式處理，但是此種情況可能產(chǎn)生的后果是： iMSC 界面上的活動會議信息，比如會議中發(fā)言人、主席、廣播者可能和實際 MCU 中的不一致，不過這些可由用戶重新設置來恢復，而且在 iMSC 的界面上僅僅表現(xiàn)出 MCU 異?；蛑貑⒑螅灰匦略O置會議角色便可恢復。 創(chuàng)建會議 會議調(diào)度 本方案中 MCU之間的級聯(lián)關系的建立，通過創(chuàng)建會議時所選擇的入會會場所在域的 MCU來自動調(diào)度。主要過程為：進入 iMSC的客戶端界面，用戶先劃分不同的域，然后在不同的域下添加對應的設備（視訊終端、多點控制單元），添加完成后，用戶創(chuàng)建會議，選擇要加入會議的會場到已選會場列表中，配置會議參數(shù)后，此時級聯(lián)調(diào)度算法先將會場進行域劃分，然后在各自的域下尋找可用的MCU，并嘗試創(chuàng)建會議（此時需要根據(jù)會議參數(shù)、入會會場數(shù)等信息，計算 MCU的資源，如果可用，則嘗試創(chuàng)建成功，否則失?。绻谧约旱挠蛳挛凑业娇捎玫?MCU，此時則會繼續(xù)向父域 查找，如找到則將該會場掛到父域所在的 MCU下，未找到則繼續(xù)向父域的父域查找，依次向上，一直找到可用的 MCU為止，如一直未找到，則確認此次級聯(lián)調(diào)度失??；如果在查找過程中，自己所在域或父域下同時提供多臺可用 MCU，則優(yōu)先使用設備編碼排序靠前的 MCU開會。 會議調(diào)度算法流程圖如 圖 ： 浙江大學碩士學位論文 第 4 章 詳細設計 26 根 據(jù) 終 端 列 表 得 到所 有 終 端 所 在 域 的信 息所 在 終 端 在 同一 個 域 下根 據(jù) 域 編 碼 查 詢 用戶 有 權(quán) 限 的 M C U 列表Y查 詢 數(shù) 據(jù) 庫 中 M C U終 端 列 表 ， 得 到 需要 增 加 終 端 列 表向 M C U 下 發(fā) 批 量 增加 終 端 的 需 求Y還 有 M C U 需 要 下發(fā) ？逐 個 向 M C U 發(fā) 送 嘗試 創(chuàng) 建 會 議 需 求沒 有 找 到 嘗 試成 功 的 M C U得 到 上 級 域 編 碼（ 編 碼 域 = = R o o t 域 ） | | （ 高 于 用戶 所 在 域 級 別 ）N存 在 （ 域 編 碼 = = R o o t域 ） | | 高 于 用 戶 所 在 域級 別 的 終 端按 照 所 屬 域 編 碼 分 組 未加 入 會 議 的 終 端獲 取 所 屬 于 級 別 最 低 的 終端 組 （ 一 個 或 多 個 組 ）對 每 組 終 端 在 域 內(nèi)查 找 符 合 條 件 的M C U ， 嘗 試 創(chuàng) 建 會議YNN所 有 終 端 都 找 到 適 合 的 M C U ，成 功 創(chuàng) 建 會 議 ？只 有 一 個 M C U未 找 到 適 合 M C U 的終 端 所 在 域 設 置 為當 前 域 的 父 域M C U l e v e l 不 同設 備 編 碼靠 前 的 為主 M C UYNNL e v e l 小 （ 級別 高 ） 作 為主 M C UYYNYYNN 圖 會議調(diào)度算法流程圖 注：在級聯(lián)調(diào)度時，由于實際組網(wǎng)每一個組織的 MCU對該組織的會場來說都是資源夠用的，調(diào)度 算法可以進行簡化，找一層即可，不需要往上找。 級聯(lián)關系樹的創(chuàng)建，遵循如下基本原則： 第一、 會場選擇 MCU時，根據(jù)調(diào)度算法將提供出所有可用的 MCU，然后根據(jù) Level值（每個組織域都有自己的 level）選擇小的進行選擇；在同一 level中如果浙江大學碩士學位論文 第 4 章 詳細設計 27 包含多個 MCU時，優(yōu)先使用設備編碼排序靠前的 MCU開會； 第二 、 將全網(wǎng)劃分為多個組織域，可按地域或行政區(qū)域劃分，每個組織下有一臺 MCU（如果有備用 MCU，則加上備用 MCU），若干終端。如果按行政區(qū)來劃分組織，且行政組織規(guī)模較小，沒有單獨的 MCU，與其它行政區(qū)公用一個 MCU，則可將這幾個公用一個 MCU的行政區(qū)劃分在一個組織下，便于調(diào)度。例如，某集團在新疆、西藏、內(nèi)蒙青海的分公司公用一個 MCU，則可將這些區(qū)域下的終端（會場）、 MCU劃分在一個組織――西北片區(qū)下。 第三 、自動調(diào)度時，下級會場只能在自己所在域或上級域中找可用 MCU，不能在下級或平級之間查找，如一直未找到，則調(diào)度失??；所有已選會場必選全部掛接到會議組織結(jié)構(gòu)樹上，否則認為自動調(diào)度失敗，可選擇手工調(diào)整，即 當自動調(diào)度完成后，不管是成功與否，用戶還可以手動調(diào)整級聯(lián)關系樹。 第四 、級聯(lián)只支持 2級級聯(lián)（不包含會場是 2級，包含會場 則為 3級）； 第五 、只有主 MCU調(diào)度成功了，該會議才確認為成功召開，否則調(diào)度失敗； 第六 、有對應組織權(quán)限時，則自動調(diào)度時，不能使用該組織下的 MCU或會場；一個級聯(lián)會議中，最多支持掛接 1024個會場， 16臺 MCU（一臺 主 MCU、 15臺從MCU），一臺 MCU下最多可掛接 256個會場。 控制會議 在視頻會議的會議控制過程中，主要包含以下操作：全部開 /關麥克風、全部停 /發(fā)視頻、全部開 /關揚聲器、發(fā)言申請、發(fā)送輔流、 FECC 控制、群邀上線、全部離線、廣播會場、會場選擇觀看、主場輪巡、廣播輪巡、結(jié)束會議等。根據(jù)觸發(fā)方 式和處理的不同，我們將上面會控操作分為下面三種： （ 1） 由終端發(fā)起的會議控制操作，如：發(fā)送輔流、申請發(fā)言；（ 2）由 iMSC 界面觸發(fā)，消息發(fā)送到主從 MCU 的會控操作，如：全部開 /關麥克風、全部停 /發(fā)視頻、全部開 /關揚聲器、群邀上線、全部離線、結(jié)束會議。（ 3）由 iMSC 界面觸發(fā)，消息只發(fā)送到主MCU 的會控操作，如廣播會場、 FECC 控制、會場選擇觀看、單個呼叫會場、單個掛斷會場。本文主要介紹這三種功能類型的實現(xiàn)方式，其他功能如鎖定會議、延長會議時長只做簡單介紹，針對上面三種類型，根據(jù)三類消息在會控操作中重要性我們重 點介紹：發(fā)言申請、廣播圖像、 FECC 控制、結(jié)束會議，剩下的會控操作只做簡單介紹。 浙江大學碩士學位論文 第 4 章 詳細設計 28 發(fā)言申請 發(fā)言申請由終端發(fā)起，即在會控過程中，會議終端通過自己的界面發(fā)起申請發(fā)言的操作，該操作由用戶選擇是否同意發(fā)言申請，一般設置發(fā)言者后，需要廣播該發(fā)言者的會場，更符合用戶的習慣。 對于 iMSC 上的互控級聯(lián)會議，在主 MCU 下的終端，其處理方式與非互控級聯(lián)會議相似，對于非主 MCU 下的會場，需要獲取消息下發(fā)的路徑，發(fā)送主 MCU后由主 MCU 下發(fā)到終端。對于主席和導演模式的會議，在主席存在的時候要將消息轉(zhuǎn)發(fā)給終端，沒有主席時處理方 式與導演模式相似。 具體步驟如圖 ： 浙江大學碩士學位論文 第 4 章 詳細設計 29 U I C L I B S S M C U M G發(fā) 言 申 請… …申 請 發(fā) 言判 斷 會 議 模 式* *發(fā) 送 給 主 席 終 端主 席 會 場 存 在主 席 會 場 不 存 在通 知 C L I B轉(zhuǎn) 化 為 A S N . 1 消 息發(fā) 送 發(fā) 言 列 表 到 U I用 戶 選 擇同 意 / 拒 絕 發(fā) 言轉(zhuǎn) 化 消 息 類 型同 意 / 拒 絕 發(fā) 言判 斷 是 否 級 聯(lián)按 原 流 程 處 理非 互 控 級 聯(lián) 會 議* *互 控 級 聯(lián) 會 議獲 取 路 徑 向 主 下 發(fā) 參 數(shù)下 發(fā) 參 數(shù) 到 主 M C U根 據(jù) 路 徑 發(fā) 下 到 各 個 終 端 圖 級聯(lián)會議發(fā)言申請流程圖 同意一個終端的發(fā)言申請。 由 iMSC 的 SS 模塊查詢出會議所在的 MCU， 然后構(gòu)建消息，發(fā)送給 MCU。如果會議是主控級聯(lián)會議，則需要將消息發(fā)給主用MCU。如果會議是簡單級聯(lián)會議，則需找到該終端所在 MCU， 然后將消息發(fā)給該 MCU，同時給會議的其他會議發(fā)送拒絕發(fā)言申請的消息。如果單畫面或者是多畫面設置中有畫面查看發(fā)言人，則需要在主 MCU 上設置畫面的布局，指定發(fā)言人位置的圖像為發(fā)言人所在分支的二級 MCU，同時設置從發(fā)言人到 主 MCU 之間的 MCU，將發(fā)言人的媒體流單播給上級 MCU 或者主 MCU。 浙江大學碩士學位論文 第 4 章 詳細設計 30 由終端發(fā)起的發(fā)言申請， SS 模塊對輔流發(fā)送和發(fā)言申請的處理流程相似，不同的是 MCU 側(cè)對輔流發(fā)送需要特殊處理，處理流程與廣播圖像相似，具體在廣播圖像中說明。 廣播圖像 廣播圖像是指在會議過程中，各個會場（除了用戶已經(jīng)選擇觀看其他會場）所看到的視頻畫面。廣播圖像分為廣播多畫面和廣播單畫面，當廣播多畫面而多畫面只有一個會場且會場占據(jù)整個畫面時，就是單畫面圖像。從實現(xiàn)上講，廣播多畫面要比廣播單畫面要復雜的多。廣播圖像 流程圖如圖 ： 浙江大學碩士學位論文 第 4 章 詳細設計 31 U I C L I B S S M C U M G判 斷 廣 播 單 還 是 多 畫 面* *廣 播 單 畫 面廣 播 與 主 看 一 致切 換 廣 播 多 畫 面檢 測 路 徑 是 否 沖 突廣 播 會 場轉(zhuǎn) 化 消 息 類 型廣 播 會 場 消 息判 斷 是 否 級 聯(lián)按 原 流 程 處 理非 互 控 級 聯(lián) 會 議* *互 控 級 聯(lián) 會 議判 斷 廣 播 會 場 與 主 場 是 否 一 致下 發(fā) 參 數(shù) 到 主 M C U廣 播 主 看 畫 面廣 播 與 主 看 不 一 致* *廣 播 多 畫 面* *不 沖 突路 徑 沖 突廣 播 失 敗界 面 提 示 用 戶 圖 廣播圖像流程圖 廣播某終端。 SS 查詢出會議所