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