【文章內(nèi)容簡介】 CU上線。 為了實現(xiàn)上述iMSC的功能，需要再原MCU和MG系統(tǒng)上配合修改，增加“iMSC平臺管理模塊”，由該模塊負責MCU和MG側(cè)消息的接收和下發(fā)，但這個不是本文研究的重點。：、MCU及iMSC總體模塊及關(guān)系 本章小結(jié)本章主要介紹iMSC各個模塊及其主要作用，通過對iMSC的了解，在整體模塊和流程上對級聯(lián)會議有個總體上的了解，為下步詳細設計打下了堅實的基礎(chǔ)。18浙江大學碩士學位論文 第4章 詳細設計第4章 詳細設計本章主要介紹iMSC互控級聯(lián)會議于實現(xiàn)上述功能幾個主要的策略及幾個主要功能的實現(xiàn)。 實現(xiàn)策略 MCU時間同步策略在互控級聯(lián)會議中，時間同步十分重要，由于各個MCU上的時間以及MCU與iMSC上的時間可能存在差異，所以需要對每臺MCU的時間進行同步，同步各個MCU的時間可以有以下3種方式：1) 在創(chuàng)建互控級聯(lián)會議時，獲取MCU與iMSC之間的時間差，根據(jù)用戶在iMSC上創(chuàng)建會議的時間，如果MCU的時間與iMSC上的時間不一致，在MCU上創(chuàng)建會議時推遲或提前召開該會議。比如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的會議。這種方式增加軟件代碼量，提高流程的復雜度，可能在軟件穩(wěn)定性上存在風險。2) 在創(chuàng)建級聯(lián)會議前，檢查各個MCU上的時間與iMSC上的時間是否相同，若不相同，則提示管理員去修改該MCU的上時間；如果時間不能被修改，比如正在召開會議等，則該MCU包括其下級MCU不能被級聯(lián)入會；如果MCU與iMSC上的時間一致，則可以正常召開該互控級聯(lián)會議。該方法可以減少軟件的代碼量，但是在實際使用過程中維護起來麻煩。3) 設置一個NTP服務器，在使用iMSC時先用與NTP上的時間同步，在MCU注冊到iMSC上時進行一次時間同步，之后每個10分鐘再進行一次時間同步。這種方法比較簡單，只需要在實施布置視頻會議網(wǎng)絡環(huán)境是布置一個NTP服務器就可以，降低了軟件實現(xiàn)的復雜度，也降低的維護成本，使管理時間同步變得的簡單。故在iMSC處理iMSC和MCU時間同步問題時采用該方法。解決了時間同步問題后，在后面召開會議和對會議進行控制都是在該前提下進行。 廣播和觀看下級會場策略廣播和觀看夏季會場策略對iMSC互控級聯(lián)會議影響最大，由于MCU上MP及硬件的限制，國內(nèi)視頻會議系統(tǒng)MCU和MG之間的通信都只有8路，具體為音頻通道、視頻通道、輔流通道、數(shù)據(jù)能力通道各占兩路，其中數(shù)據(jù)能力指傳輸攝像機控制等信息的通道，每條通道分為上行和下行通道。iMSC是基于原先穩(wěn)定的MCU和MG視訊產(chǎn)品的基礎(chǔ)上開發(fā)的，在互控級聯(lián)中，下級MCU以終端的方式被呼叫入會，這樣上級MCU與下級MCU之間的關(guān)系實際上為MCU與MG之間的能力關(guān)系，故在iMSC的互控級聯(lián)中也存在該限制。即當設計廣播或會場觀看的時候，如果所需要的通道被占用，就不能實現(xiàn)該功能，也就是當廣播下級會場而其他用戶再執(zhí)行選擇觀看該MCU下的其他會場，則此時不能正常觀看；當多畫面中有兩個子畫面同時為同一下級MCU的兩個會場時，也不能實現(xiàn)。下圖為MCU中MP模塊音視頻處理的模塊圖，在vpn處開啟通道，然后再pool池中緩存各個數(shù)據(jù)，再發(fā)到vpc對圖像進行整理，在mixer中將數(shù)據(jù)分發(fā)到各個通道中，： MP模塊音視頻處理流程圖看到上圖后，也許大家還有疑問是：為什么下級會場不直接發(fā)碼流給頂級MCU呢？原因很簡單，下級會場已經(jīng)在會議中，不能再次與頂級MCU建立連接。，無法將下級會場的碼流直接發(fā)送到頂級MCU。為了解決該問題，考慮通過當某個下級MCU有兩路或兩路以上碼流需要上傳時，可以通過先在該MCU上進行圖像的編解碼處理，這樣可以實際上傳一路碼流，而其中包含多路碼流的信息。不過這樣處理帶來的最大的影響就是在編解碼的時候增加了延時，實現(xiàn)復雜，對系統(tǒng)影響較大，且考慮一般用戶使用互控級聯(lián)時，均為某個組織或區(qū)域下的觀看特定的會場，一般觀看一個就已經(jīng)足夠，故在該項目第一期的時候暫不考慮。 會議生命周期策略這里主要描述： 會議狀態(tài)從未召開到活動會議，從活動會議到歷史會議；以及數(shù)據(jù)庫的會議數(shù)據(jù)的如何操作。會議開始與會議結(jié)束觸發(fā)的具體流程， 級聯(lián)會議生命周期在這里讓會議開始定時器和會議結(jié)束定時器規(guī)定比正常的時間延后10秒， 以便給MCU上報狀態(tài)留有時間余量，這里使用定時器為了防止當MCU離線或異常時，iMSC上的會議信息顯示正常，即能正常的召開與結(jié)束。各MCU上的時間和iMSC上的時間應該保持一致（在上面策略中已經(jīng)說明）， 這樣可以防止會議狀態(tài)混亂。當SS沒有收到MCU狀態(tài)上報，定時器觸發(fā)。會議的召開和結(jié)束分為下面4個步驟：F1：會議預約成功后在數(shù)據(jù)庫中記錄會議數(shù)據(jù)，會議基本信息表中會議狀態(tài)為未召開。如果預約會議是立即會議，則會議狀態(tài)為召開中，直接進入F3流程。F2：會議開始定時器超時或SS收到MCU上報會議狀態(tài)變更消息；則將會議基本信息表中會議狀態(tài)變更為已召開； F3：SS收到MCU會議狀態(tài)變更“召開中”與“在解散中”，只更新數(shù)據(jù)庫會議基本信息表中會議狀態(tài)，不做其他處理。F4：會議結(jié)束定時器超時或收到MCU上報會議狀態(tài)變更消息（指明會議結(jié)束）,刷新統(tǒng)計報表。 結(jié)束會議時處理分兩種情況：第一、周期會議未結(jié)束（經(jīng)計算，周期會議還有下一輪的會議）：如果周期會議未結(jié)束（判斷方法見下面方法1），先將會議數(shù)據(jù)搬移到歷史會議信息表中，會議預約信息表重復次數(shù)減一（如果是次數(shù)控制見方法1），重新計算下次開始與結(jié)束會議的時間，并保存到會議基本信息表中（計算方法見下面方法2），查詢會議狀態(tài)。會議狀態(tài)為已召開，則把會議基本信息表中會議狀態(tài)變更為未召開，重新進F2流程；會場狀態(tài)為未召開，忽略該事件。第二、非周期會議或者周期會議結(jié)束將會議數(shù)據(jù)搬移到歷史會議信息表中，刪除會議數(shù)據(jù)。在搬移過程，會議所有數(shù)據(jù)（包括會議ID）不變地搬移到歷史會議信息表。歷史會議規(guī)格為10萬條，根據(jù)歷史記錄管理方法（時間與條數(shù)）進行備份與清除。方法1：會議預約信息表里的重復次數(shù)與周期會議截止時間為二選一：即通過重復次數(shù)控制周期會議結(jié)束或者通過截止時間控制會議結(jié)束。通過重復次數(shù)控制時，每開一次會，重復次數(shù)減一，此時截止時間為空。使用截止時間來控制周期會議結(jié)束，重復次數(shù)為0。如果會議基本信息表中會議設定為永久會議，則會議基本信息表的結(jié)束時間為空，即會議不會結(jié)束，除非用戶主動撤銷該會議。注：期會議不可能大于24小時，周期會議不可能肯是永久會議。方法2：根據(jù)周期表計算下次開會時間。周期會議類型有月、周、天。對于月類型會議，重復日期為32位數(shù)據(jù)，每一位代表月的每一天（為1時要開會，為0時不開會）。結(jié)合當天日期即可計算出下次會議的開始日期。開會當天的具體開始時間，取預約會議表開始時間的時分部分。結(jié)束時間根據(jù)原會議基本信息表中會議時長（結(jié)束時間與開始時間的差值 ）加上新的會議開始時間。注：會議開始時間與結(jié)束時間可能跨天?！皶h基本信息表”結(jié)束時間與開始時間 代表每次實際開會時間，會議預約信息表的開始時間與截止時間為周期會議的生命周期。當然，可能還會遇到下面這種情況：在會議召開過程中，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平臺的全局管理，可以達到常規(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上用戶可能重新要對配置進行設置，如發(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異?；蛑貑⒑?，只要重新設置會議角色便可恢復。 創(chuàng)建會議會議調(diào)度本方案中MCU之間的級聯(lián)關(guā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)度算法流程圖注：在級聯(lián)調(diào)度時，由于實際組網(wǎng)每一個組織的MCU對該組織的會場來說都是資源夠用的，調(diào)度算法可以進行簡化，找一層即可，不需要往上找。級聯(lián)關(guān)系樹的創(chuàng)建，遵循如下基本原則：第一、會場選擇MCU時，根據(jù)調(diào)度算法將提供出所有可用的MCU，然后根據(jù)Level值（每個組織域都有自己的level）選擇小的進行選擇；在同一level中如果包含多個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)關(guā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個會場。 控制會議在視頻會議的會議控制過程中，主要包含以下操作：全部開/關(guān)麥克風、全部停/發(fā)視頻、全部開/關(guān)揚聲器、發(fā)言申請、發(fā)送輔流、FECC控制、群邀上線、全部離線、廣播會場、會場選擇觀看、主場輪巡、廣播輪巡、結(jié)束會議等。根據(jù)觸發(fā)方式和處理的不同，我們將上面會控操作分為下面三種：（1）由終端發(fā)起的會議控制操作，如：發(fā)送輔流、申請發(fā)言；（2）由iMSC界面觸發(fā)，消息發(fā)送到主從MCU的會控操作，如：