江湖龙虎斗
您現在的位置:中國智能建筑信息網>> 技術文章>>文章內容
分享到:    

H.323標準下會議系統關鍵技術分析

 

摘 要: IP視頻會議系統是近年飛速發展的一種通信技術,并且預示巨大的應用前景。本文深入地分析了會議系統的基本類型優缺點及基本結構。同時也研究了H.323標準下的會議系統的特點和關鍵技術。

關鍵詞: 會議系統 H.323 多點控制單元

  視頻會議系統是一種支持人們遠距離進行實時信息交流、開展協同工作的應用系統,不僅能實時傳輸視頻與音頻信息,使協作成員可以遠距離進行直觀、真實的視音頻交流,還可利用多媒體技術的支持,幫助使用者對工作中各種信息進行處理,如共享數據、共享應用。

會議系統有很多類型,雖然基于H.320技術體系下的IP可視電話在1992年就已經面世,但是,受網絡環境特別是帶寬影響,這些設備僅僅在商用市場上有了應用。近年來,互聯網的飛速發展,許多國外企業重新開始關注家用IP可視電話市場。本文以H.323標準下IP視頻會議為研究對象,重點分析組成會議系統的核心設備—多點控制單元(MCU,Multi-Control Unit)實現關鍵技術。

1 基本會議模型

  H.323建議根據媒體通信的組織方式,定義了四種會議模型:集中式會議模型;分布式會議模型;混合式會議模型,可看作集中式會議模型與分布式會議模型的某種形式的組合;Ad Hoc會議模型,特殊的多點會議,由點到點呼叫通過邀請他人或他人主動加入擴展而成。

這里所說的集中式會議模型和分布式會議模型都是針對單一媒體類型而言的。一個實際的H.323系統可能在音頻和數據媒體信息的處理上遵循集中式會議模型,而在視頻媒體信息的處理上遵循分布式會議模型,有些資料將這種情形也歸入到混合式會議模型一類。從會議控制方式上看,H.323建議定義的各種會議模型都屬于緊耦合式會議(集中控制型會議)。此類系統采用以MCU為中心的星型結構,一個會議只允許一個活動MC存在。以上四種會議模型中,集中式會議模型與分布式會議模型是最基本的,下面對這兩種會議模型進行討論。

1.1 集中式會議模型

在集中式會議中,所有與會終端采用點到點的方式與MCU通信,所有的音頻、視頻、數據和控制流都被送到MCU,MCU中的MC負責管理整個會議,MP負責處理送來的信息流并送回與會終端,典型處理方式包括音頻混合、視頻交換或混合和T.120數據分配。MP可以選擇轉送哪一個終端或那幾個終端的信息流,也可以對不同的音頻、視頻、數據格式和比特率進行轉換,使得各與會終端可以使用不同的通信模式。集中式會議模型具有以下優點:(1)充分保證了MCU對各個與會終端上媒體播放的控制。對于遠程教育的應用來說,這一點很重要。由于集中式會議在媒體通信上采用星形拓撲,各個與會終端分別與MCU建立媒體傳輸信道,因此,MCU可以很方便的控制各個與會終端接收與播放的媒體信息。必須指出的是,MCU控制權的增強是以降低各個與會終端的獨立性與靈活性為代價的。(2)占用的網絡帶寬資源小。由于采用了星形拓撲,集中式多點會議中的媒體信道數與終端數目成正比。隨著會議規模的擴大,會議占用的帶寬資源呈線性增長。對與會終端處理能力的要求低。當與會終端為獨立設備,例如以太網電話機或可視電話機時,降低對處理能力的要求意味著可以大大降低產品成本。(3)不需要組播支持。鑒于目前互聯網上設置為支持組播模式的路由器還不夠多,組播應用主要局限在局域網內,是否需要組播支持在當前的應用中仍然是十分重要的問題。

集中式會議模型的缺點是:MCU結構和功能復雜,開銷大;對媒體信息流的處理不夠靈活。受MCU的處理能力與網絡帶寬限制,難以針對各個與會終端的不同能力與不同需要進行個性化媒體信息流處理;會議質量不如分布式會議模型,主要體現為多媒體信息數據的延時和丟包率偏大。

1.2 分布式會議模型

在分布式會議中,與會終端通過組播方式或多重單播方式將音頻流和/或視頻流發送給其它與會終端,終端必須完成對接收到的音頻和視頻信號的混合和切換。MC通過與各終端之間的H.245控制信道對會議進行管理。在此類會議中,不需要處理音頻和視頻信號的MP,原來集中式會議中的MP功能分散到各終端完成。

分布式會議模型的優點是:(1)MCU結構和功能簡單,開銷小。由于不需要集成MP模塊,MCU的結構和功能都大大簡化了。在此情形下,可以考慮不設置MCU,而將MC內置于網關、網閘或某個與會終端中。對某些應用來說,這種設置是合意的。(2)對多媒體信息流的處理比較靈活,各個與會終端可根據自己的能力、對收到的多媒體信息流進行個性化處理。(3)會議質量優于集中式會議。

分布式會議模型的缺點是:削弱了MCU對各個與會終端上媒體播放的控制權;對與會終端的處理能力要求高。各個與會終端需自行對接收到的一路或多路音頻/視頻媒體信息流進行處理,這就要求與會終端具有相當程度的處理能力;要求網絡支持組播方式。如果不采用組播方式,以多重單播方式則會議占用的帶寬資源將隨會議規模的擴大成指數增長趨勢,大大加重網絡擁塞。

1.3 兩種會議模型的比較

從上面的分析可以看出,集中式會議模型與分布式會議模型各有利弊,集中式會議模型的服務質量不如分布式會議模型,也不夠靈活,但控制簡單,無需組播支持,一般比較適合于各種廣域網應用。分布式會議模型目前更適合于各種局域網應用,但隨著組播技術與音頻/視頻分層編碼技術的發展與推廣,分布式會議模型的優勢與潛力將進一步發揮出來。

1.4 兩種耦合方式的比較

根據會議的控制方式,將其大致劃分為兩大類型:緊耦合式與松耦合式。緊耦合式會議又稱集中控制型會議、正式會議,實施集中式會議控制策略,要求由中央權威對會議的成員資格、成員接納等進行控制,它的典型應用為商業會議;松耦合式會議又稱分布控制型會議、非正式會議,實施分布式會議控制策略,不對會議的成員資格、成員接納等進行中央控制,不要求設立會議主席,典型應用為研究小組的討論會。

H.323建議定義的各種會議模型都是緊耦合式的。緊耦合式會議模型要求MC掌握所有的會議成員,并要求實現關于會議建立、能力溝通、音頻/視頻/數據流的創建與控制、會議關閉的一整套復雜的信令流程。當會議規模增大時,MC的開銷呈非線性增長趨勢,這樣,緊耦合式會議模型的可擴展性就受到了很大限制。

與緊耦合式會議模型不同,松耦合式會議模型不要求實現嚴格的會議成員管理功能,不要求參數溝通過程,也不要求設置負責實施會議控制的中央節點,因而具有良好的可擴展性。IETF制定的RTP/RTCP協議提供了一些基本的會議控制功能,用以支持松耦合式會議模型。IETF規定RTCP的一個可選功能為傳遞最小集合的會話控制信息,例如成員身份標識,該標識可能用于顯示在用戶界面上。松耦合式會議系統也可以將RTCP作為到達所有與會終端的一個方便的信道。對于某個松耦合式會議系統而言,RTCP不能實現系統所需的全部支持,在此情形下可引入高層的會話控制協議。松耦合式會議模型的缺點在于會議控制過于簡單、松散,對于很多應用來說是不可接受的。而且,如果該會議通過RTCP來實現會議主席功能,則實時性不能得到保證。

緊耦合式會議模型與松耦合式會議模型相比,各有側重。一種自然的想法是構建混合控制型會議模型,綜合兩種會議模型的優點,取長補短。ITU1998年提出的H.332建議是一種混合控制型會議模型,下面對此建議進行介紹。

2 H.332標準下會議系統

為了解決H.323會議系統在可擴展性方面的新技術不足,ITU19989月提出了H.332建議,H.323緊耦合式會議系統擴展為H.332松耦合式會議系統(實質上是混合控制型會議系統)

 

1 H.332松耦合式會議系統的組織結構

  與H.323會議模型相比,H.332會議模型的最主要特點是將與會終端劃分為專門小組(panel)RTP接收終端兩個群體,并施以不同的控制策略。專門小組即相當于原來的H.323緊耦合式會議,其成員為功能完全的H.323終端,按照H.323建議定義的方式實現完全交互。RTP接收終端只是被動的以組播方式接收RTP/RTCP音頻/視頻媒體流,不發送媒體流,也不參加H.323信令流程,從而避免了增加系統MC的開銷。只要專門小組的規模保持恒定,RTP接收終端的數量增加時,系統MCU的開銷基本不變。基于這個原理,H.332松耦合式會議系統實現了良好的可擴展性,可以很方便的擴展到數千與會終端的規模。

H.332建議不允許RTP接收終端直接進行交互,但允許RTP接收終端依照某種流程加入(或被邀請加入)專門小組,從而獲得進行交互所需的權限。為此目的,H.332建議將專門小組進一步劃分為永久成員與臨時成員。永久成員在整個會議期間始終保持在專門小組內,例如遠程教室中的授課老師、遠程報告中的報告人等。臨時成員從需要獲得交互權限的RTP接收終端中選出,隨著各個RTP接收終端加入或退出專門小組,臨時成員在整個會議期間可以發生變動。通過這一機制,保持專門小組的規模恒定,系統MC的開銷在基本恒定的前提下,H.332會議系統向各個RTP接收終端提供了盡可能多的交互機會。

H.332建議還對原H.323建議中的能力溝通的機理進行了改進,以提高會議系統的可擴展性。H.332建議規定,在預先發布一個會議時,會議布告中應包含有關該會議的充分信息,使得會議布告的接收者能夠發現和參與會議,至于具體發布哪些信息則由布告發布者決定。會議布告采用IETF的會話描述協議(SDP)編碼,編碼信息可通過電子郵件、Web服務或其他任何機制發布。如果會議基于安全、注冊或收費等方面的考慮而對與會資格進行限制,則可同時發布私有布告與公共布告,其中私有布告應包含密鑰、加密算法等信息,而公共布告應包含如何登記和獲取私有布告的信息。

作為能力信息發布機制的補充,H.332建議允許引入某種形式的簡單的能力溝通流程,以適應不同用戶的網絡帶寬與端點資源(例如用戶主機的CPU處理能力、顯示器解析度等),該流程可以在會議開始之前進行。此外,H.332建議還允許采用視頻的分層組播技術,以適應不同用戶的網絡帶寬及對圖像質量的要求。

3 H.323使用MCU創建會議信令過程

當創建一個會議后,一般要求對其命名,例如[email protected] ms.com,參與者一開始就知道這是一個會議呼叫。創建會議最簡單的方法是呼叫一個MCU,發送一條Setup消息,其中將ConferenceGoal(會議目的)參數設置為“create(創建)”并給一個唯一的全局CID。消息中也可給出會議的別名。該過程與一個普通呼叫沒有兩樣。如果MCU決定接受這個呼叫,它將發送一條Connect應答。終端和MCU將交換它們的TerminalCa-pabilitySet。當主從過程開始后,MCU成為會議的活動MCMCU向主叫終端發送MCLocationlndi-cation表示它是會議的活動MC。它也可以通過TermtnaINumberAssign消息向終端分配一個8bit數字(終端必須將這個8bit數字拷貝到它所有RTP報文的SSRC域的低8bit),會議的創建過程如圖2所示。

 

2 創建一個會議的過程

 (1)邀請加入會議:一旦終端處在一個會議中,它可以通過向活動MC發送Setup消息來邀請其他人加入,Setup消息中應該包含一個新的呼叫參考值CRV和會議的CID;并將ConferenceGoal參數值設為“invite(邀請)”。Setup消息的目的地址和可選的目的呼叫信令地址必須是被邀請加入會議的終端地址,比如終端B。當MCU接收到這條消息,它會向終端B發送一條Setup消息(其中CID=N,而且ConferenceGoal=Invite)到邀請終端。隨后,活動的MC將利用Connect消息提供的傳輸地址與終端B建立一條H.245控制通道,然后交換它們的Ter-minaICapabilitySets。在主從過程中,活動MC可能會需要發送MCLocationIndication消息。當這一切結束后,MC會向邀請和被邀請終端各發送一條MultipointConference(多點會議)消息。如果在呼叫中還有其它終端,MCU將向它們發送Terminal-JoinedConference(終端加入會議)H.245消息使它們意識到新成員的存在。

  因為進入的終端性能可能會與會議現有的媒體通道存在不兼容,所以MCU必須向所有終端發送CommunicationModeCommand(通信模式命令)來指定每種流的新發送模式。所有不符合條件的媒體通道都必須關閉。這時,MC可以開始向終端發送OpenLogicaIChannel消息。已經接收到多點會議消息的終端應該在接收到通信模式命令消息之后才能打開邏輯通道。而且所有終端都必須向MC發送OpenLogicaIChannel消息。MCU也可以發出邀請,例如邀請不是發自一個H.323終端,而是發自MCUweb界面。

(2)主動加入的會議:終端也可以很容易地加入一個已經存在的會議,它只需要向MCU發送Setup消息,其中包含會議的CID,同時設置Conference-Goal=Huang。如果終端只知道會議的別名,那么它必須提供這個別名,同時將CID0

(3)瀏覽會議:MCU可以提供一個存在會議列表,它通過向終端發送ConferenceListChoice H.245消息來實現。例如當Setup消息中使用的別名實際上是會議組的名字時, [email protected]這個組名可能包括Q931supportH245support[email protected]

4 小結

  隨著H.323標準的推出,基于該標準在IP環境下的開發的會議系統產品非常之多,應用也特別普遍。本論文通過介紹會議系統的一些關鍵技術,為大家了解會議系統及視頻會議的推廣和普及起到拋磚引玉的作用。

參考文獻

1 TU-T,Call signalling protocols and media stream packetization forpacket-based multimedia communication systems, ITU-T Recom-mendation H.225.0,1998.2

2 ITU-T,Packet-Based Multimedia Communications Systems,ITU-TRecommendation H.323,1998.2

3 糜正琨.IP網絡電話技術.人民郵電出版社,2000.6

4 ITU-T,Control protocol for multimedia communication,ITU-T Rec-ommendation H.245,1998.9

作者:吳曉紅 黃永峰 來源:《數據通信》2004年第5期 點擊數: 發布時間:2014年02月09日
【字體: 收藏 打印文章
回到中國智能建筑信息網首頁