|
|
|
| 分布式視頻會議系統 |
| 發布時間：2020-5-16 13:41:26 |
|
瀏覽次數：
次 |
|
|
| |
| |
分布式視頻會議系統
視頻會議系統是目前疫情時期企事業交流之中的一個重要組成部分。電路交換網絡中的視頻會議系統已有較成熟的模型，如ITU的H.320標準等，但分組交換網（包括Ethernet、Internet等）的使用正日益普及，新的解決方案必須著重考慮如何利用這種網絡來實現視訊系統。
本文提出的方案并不針對某種具體網絡，而是根據Internet上多點視頻會議系統的需要設計的。它充分利用了分組交換網多播功能和高帶寬特點，是基于RTP協議的分布式多點會議系統，端主機是支持IP多播的Solaris 2.x系統，具有以下特點：
每個節點的數據通過多播到達其他節點。
音頻和視頻的合成由端主機完成。
不使用參考時鐘實現發送/接收編解碼器的良好同步，對分組抖動和丟失有較好控制。
動態流控機制允許視頻壓縮器根據網絡狀態調整發送率。
采用一種適合IP網絡并能穿越防火墻的目錄服務體系。
分布式視頻會議系統的關鍵技術
會議系統的控制和數據傳送
這是集中式方案中MCU的主要功能，在分布式系統中，MCU的功能可由網絡和/或端節點來實現。在我們的方案中，數據傳送主要利用了分布式網絡的多播功能，不少控制功能都由端主機和網絡共同實現。
帶寬的有效使用和服務質量保證
分組交換網的復用機制可有效利用帶寬，但也可能導致報文抖動甚至丟失。Internet大部分還未實現服務質量（QoS）保證，傳統應用中通常由較高層TCP/IP協議來保證可靠傳輸。TCP用重傳機制實現可靠傳輸，其內部流控機制根據確認包動態調整發送率。對于實時會議，重傳導致的延遲是無法忍受的，因此傳輸層協議使用不具有可靠傳輸和內部流控制的UDP，而端到端同步和流控的任務則轉嫁到視頻會議系統上。
目錄服務功能
Internet不像電路交換網，它沒有統一的尋址機制，另外還存在防火墻和地址不公開的問題，因此目錄服務是分布式會議系統中要解決的重點問題。
分布式多點視頻會議系統的具體實現方案
整體結構
該系統的主要硬件如下：
音頻/視頻捕捉/回放卡。聲音、圖像和數據作為不同的流進行傳送，接收者可選擇從某個源只接收聲音，這對于沒有圖像處理功能的端節點特別有用，用靜默檢測避免不發言時發送音頻流。
Codec和DSP（數字信號處理器）卡。DSP根據端用戶的選擇合成視頻和音頻源，它還具有屏蔽時鐘不同步、聲音/圖像不同步和分組丟失等功能。卡上還有一個Ethernet網卡，會議系統可直接連到LAN上，無需CPU的參與。音頻/視頻捕捉/回放卡和Codec/DSP卡之間有直接接口，可繞過系統總線，節省CPU時間。
傳輸層協議的選擇
由于UDP不提供端到端可靠傳輸，出現了基于UDP、專為實時通信提供傳輸層服務的RTP協議。盡管RTP本身不實現服務質量保證，但它提供的多路復用、順序號、時標、監控及對IP多播的靈活接口對我們設計的多播、同步、會話數據加密、動態流控、目錄服務、安全穿越防火墻等方法非常重要。RTP是一個開放協議，為上層應用提供了充分的靈活性。但RTP的組成部分之一RTCP（實時傳輸控制協議）提供的松散管理和監控功能還不能滿足我們所需的控制和管理功能（如動態獲取和分發多播地址、分發會話密鑰等），所以我們采用H.323的集中管理模型。
網絡的多播
多播在現有網絡中實現的并不多，在這種情形下，我們認為實現多播的途徑可有以下幾中：
使用實現了DVMRP的交換式以太網Hub，通過Hub之間的Tunnel功能在Internet上構造多播網絡。
在Internet上以傳統方式進行分組的復制和轉發，端系統通過為每個目的節點復制和轉發分組的方式來模擬多播。
當數據從實現多播的局域網向未實現的局域網發送時，使用RTP的Translator模擬多播功能。我們使用的是第三種，為了實現更方便的地址分配和安全保密功能，還需具有動態、分布式和安全特性的目錄服務的配合。
壓縮數據流的合成
在分布式系統中，網絡的多播功能使每個端節點可同時接收多個源的圖像和聲音，而合成由端系統實現。為了降低開銷，我們的合成是對壓縮視頻流進行的。壓縮視頻流的合成算法也是當前的研究熱點，我們的算法利用了以下事實；幾乎所有的標準視頻壓縮數據都包含一系列獨立的由預定義分隔符分隔的編碼組，通過檢查分隔符可將壓縮數據流分成像素區域。將各段壓縮數據與像素區域對應起來后，就可根據用戶設置來重新組裝這些數據。
會話的保密
接收方發起的多播使得發送方無法控制接收數據的用戶，局域網的廣播性質使得局域網上任何主機都有可能監聽會話，因此有必要對會話數據加密。可以用會話初始協議分發會話密鑰，也可用RTP會話配置文件保存會話密鑰（這種方法安全性低）。為了防止已知明文攻擊，每個消息中應加入一次性且不可預測的信息。RTP報頭的時標字段為我們提供了這個機制，而加密RTCP報文之前應在要加密的報文前添加一個隨機數。
時鐘同步和聲音/視頻同步
點到點連接中接收方根據數據到達速率實現與服務方的同步。
分布式多點會議中有多個發送/接收對需同步，這種方案就不適合了。我們設計了一種簡單有效的方法解決時鐘不同步和同一源的聲音/圖像不同步問題。該方法使用了RTP提供的時標，可簡單概括為：靜音抑制音頻數據包的發送。聲音在接收端以接收方的音頻時鐘回放，音頻時鐘的不同步在靜默期間被抵消。音頻/視頻的同步是在每個音頻突發的開始時刻，通過丟棄一些延遲的視頻幀或者重用一些視頻幀實現的。此機制不需回放時鐘與捕捉時鐘的同步，它能達到預期性能是基于以下事實：
突發平均持續時間相對靜默持續時間較短；
捕捉端和回放端時鐘的不同步較小。這兩點使音頻/視頻的同步在較短的突發持續期間內不可能漂移很多。我們對不同源數據流之間的順序關系沒有采取任何控制。隨著RMP（可靠多點發送協議）等協議在群組通信中的使用，我們將對這種順序進行控制。
IP網目錄服務目錄服務在集中和分布式會議中都很重要。電路交換網中節點由固定號碼標識，分組交換網中節點由IP地址來標識。異質網絡中，ATM節點由E.164標識，POTS和ISDN節點由電話號碼標識，Internet節點由IP地址標識，如果目錄服務能將會議參加者的名字轉換成其物理地址，將帶來很大方便。在移動通信中，會議參加者可能從不同地方接入Internet，使用動態地址，目錄服務更顯得必要。如果防火墻內的用戶不想暴露自己的IP地址，目錄服務的功能將更復雜。
Internet域名服務系統（DNS）是一種分布式目錄服務解決方案，但普通的DNS系統不支持動態分配的IP地址。動態IP地址查詢方案要求有一個實時登記機制獲取用戶登錄時動態分配的IP地址。目前已有的實時登記協議有SDP、LDAP、安全動態更新的DNS等（分布式）。Internet數據庫提供商也為各種應用提供了專用實時登記協議（集中式）。集中式方案易實現，但擴展性差，且要求所會議成員向同一服務提供商登記也不大可能。分布方式基于有DNS系統，實踐證明它運行穩定、擴展性良好。安全動態更新的DNS就是一個理想選擇。
目前人們提出的目錄服務都未考慮穿越防火墻的問題。穿越防火墻最常用的方法是使用代理服務器。通用代理服務器也能進行IP地址轉換，且有一整套強大的安全功能，但它們的通用性也帶來了以下問題：
同時有許多應用使用可能造成延遲，無法保證實時性；
為黑客提供了可突破的漏洞；
無法提供不同子網間域名查詢服務；
在IP地址轉換級連的情況下會產生無法預料的情況。我們使用的專用代理能克服以上缺點，可在RTP的Mixer或Translator上實現 。
假設A和B分別位于兩個不同的防火墻之內，我們可在A和B所在子網的防火墻上各設一個代理PA和PB，在它們共同連接的Internet有一個公共目錄服務提供商。假設A是呼叫方，B是被呼叫方。下面是穿越防火墻通信的過程：
用戶A登錄到網上時向PA登記。PA為A建立一個內部記錄，登記A的IP地址和E-mail地址。然后，PA向外部目錄服務提供商登記A的用戶名（E-mail地址）和自己的IP地址。用戶B登錄時，B和PB進行同樣的操作。
當A要與B通信時，A向PA發一個呼叫請求，給出呼叫目標B的E-mail地址。
PA向外部目錄服務提供商發出解析名字B的請求。外部目錄服務將返回步驟1中為B登記的地址（即PB的IP）。根據B的域名或目錄服務提供的一些特殊信息，PA可以知道B處于某個防火墻內。
PA向PB發出一個連接請求，給出呼叫方和被呼方的名字A和B。這樣PA和PB就可為A和B建立一個虛連接，后面的通信可以通過A-PA-PB-B這條鏈路進行。
結束語
Internet 的發展促使了新的分布式多點視頻會議解決方案的出現，分布式解決方案與電路交換網絡中的集中式方案有很大區別。作為群組計算的一個重要應用，分布式多點視頻會議系統會得到新的群組通信技術的進一步支持，如：更理想的多播路由算法和協議；能適應復雜網絡環境的資源預留和信息過濾技術；可靠有序的通信保障；針對會議系統應用的支持。然而，如何最有效地使用這些支持來適應視頻會議中復雜、多樣的需求將繼續是我們的研究主題。
應用實例
中國移動貴州公司項目主要采用DANACOID的分布式系統，大樓包括3層一號視頻會議室、3層多功能廳、13層一號二號三號視頻會議室、經分會議室、視頻控制室、總控室和18層黨組會議室、19層大會議室等組成。
所有會議室中視頻信號的接入和輸出設備都是通過
多功能廳主顯示屏為P2.5,輔助顯示屏為P1.25；
接口機共計 200臺，雙服務器備份設計；
一臺27寸觸控一體機集中管理。
|
| |
|
|
|
|
|
