分布式視頻會議系統(tǒng)地關鍵技術及完成

    Internet不像電路交換網，它沒有統(tǒng)一的尋址機制，另外還存在

    防火墻和地址不公開的問題，因此目錄服務是分布式會議系統(tǒng)中要解決的重點問題。

    分布式多點視頻會議系統(tǒng)的具體實現方案

    整體結構

    該系統(tǒng)的主要硬件如下：①音頻/視頻捕捉/回放卡。聲音、圖像和數據作為不同的流進行傳送，接收者可選擇從某個源只接收聲音，這對于沒有圖像處理功能的端節(jié)點特別有用，用靜默檢測避免不發(fā)言時發(fā)送音頻流。②Codec和DSP（數字信號處理器）卡。DSP根據端用戶的選擇合成視頻和音頻源，它還具有屏蔽時鐘不同步、聲音/圖像不同步和分組丟失等功能。卡上還有一個Ethernet網卡，會議系統(tǒng)可直接連到LAN上，無需CPU的參與。音頻/視頻捕捉/回放卡和Codec/DSP卡之間有直接接口，可繞過系統(tǒng)總線，節(jié)省CPU時間。

    傳輸層協議的選擇

由于UDP不提供端到端可靠傳輸，出現了基于UDP、專為實時

    通信提供傳輸層服務的RTP協議。盡管RTP本身不實現服務質量保證，但它提供的多路復用、順序號、時標、監(jiān)控及對IP多播的靈活接口對我們設計的多播、同步、會話數據加密、動態(tài)流控、目錄服務、安全穿越防火墻等方法非常重要。RTP是一個開放協議，為上層應用提供了充分的靈活性。但RTP的組成部分之一RTCP（實時傳輸控制協議）提供的松散管理和監(jiān)控功能還不能滿足我們所需的控制和管理功能（如動態(tài)獲取和分發(fā)多播地址、分發(fā)會話密鑰等），所以我們采用H.323的集中管理模型。

    （3）網絡的多播

    多播在現有網絡中實現的并不多，在這種情形下，我們認為實

    現多播的途徑可有以下幾中：①使用實現了DVMRP的交換式以太網Hub，通過Hub之間的Tunnel功能在Internet上構造多播網絡。②在Internet上以傳統(tǒng)方式進行分組的復制和轉發(fā)，端系統(tǒng)通過為每個目的節(jié)點復制和轉發(fā)分組的方式來模擬多播。③當數據從實現多播的局域網向未實現的局域網發(fā)送時，使用RTP的Translator模擬多播功能。我們使用的是第三種，為了實現更方便的地址分配和安全保密功能，還需具有動態(tài)、分布式和安全特性的目錄服務的配合。

    壓縮數據流的合成

    在分布式系統(tǒng)中，網絡的多播功能使每個端節(jié)點可同時接收多個源的圖像和聲音，而合成由端系統(tǒng)實現。為了降低開銷，我們的合成是對壓縮視頻流進行的。壓縮視頻流的合成算法也是當前的研究熱點，我們的算法利用了以下事實；幾乎所有的標準視頻壓縮數據都包含一系列獨立的由預定義分隔符分隔的編碼組，通過檢查分隔符可將壓縮數據流分成像素區(qū)域。將各段壓縮數據與像素區(qū)域對應起來后，就可根據用戶設置來重新組裝這些數據。

    會話的保密

    接收方發(fā)起的多播使得發(fā)送方無法控制接收數據的用戶，局域網的廣播性質使得局域網上任何主機都有可能監(jiān)聽會話，因此有必要對會話數據加密�？梢杂脮�話初始協議分發(fā)會話密鑰，也可用RTP會話配置文件保存會話密鑰（這種方法安全性低）。為了防止已知明文攻擊，每個消息中應加入一次性且不可預測的信息。RTP報頭的時標字段為我們提供了這個機制，而加密RTCP報文之前應在要加密的報文前添加一個隨機數。

    時鐘同步和聲音/視頻同步

    點到點連接中接收方根據數據到達速率實現與服務方的同步。

    分布式多點會議中有多個發(fā)送/接收對需同步，這種方案就不適合了。我們設計了一種簡單有效的方法解決時鐘不同步和同一源的聲音/圖像不同步問題。該方法使用了RTP提供的時標，可簡單概括為：靜音抑制音頻數據包的發(fā)送。聲音在接收端以接收方的音頻時鐘回放，音頻時鐘的不同步在靜默期間被抵消。音頻/視頻的同步是在

    每個音頻突發(fā)的開始時刻，通過丟棄一些延遲的視頻幀或者重用一些視頻幀實現的。此機制不需回放時鐘與捕捉時鐘的同步，它能達到預期性能是基于以下事實：①突發(fā)平均持續(xù)時間相對靜默持續(xù)時間較短；②捕捉端和回放端時鐘的不同步較小。這兩點使音頻/視頻的同步在較短的突發(fā)持續(xù)期間內不可能漂移很多。我們對不同源數據流之間的順序關系沒有采取任何控制。隨著RMP（可靠多點發(fā)送協議）等協議在群組通信中的使用，我們將對這種順序進行控制。