《IP網絡多媒體通信技術及應用》課件第9章

第9章視頻會議多點通信控制技術

9.1多點視頻會議系統(tǒng)通信方式9.2

MCU的工作原理及通信流程9.3

MCU級聯(lián)控制及通信流程9.4

MCU的功能及實現(xiàn)9.5視頻IP組播技術9.6視頻會議中多畫面合成技術9.1多點視頻會議系統(tǒng)通信方式

1.集中型多點會議

在該類會議中,所有參會終端(包括網關)和MCU中的MC建立H.245控制信道的點到點聯(lián)系,該MC執(zhí)行對整個會議的集中控制。各終端的音頻、視頻和數(shù)據信道與MCU中的MP相連。該MP對各終端送來的信號進行音頻混合、視頻交換或混合及T.120數(shù)據分配,然后將處理所得的音頻、視頻和數(shù)據流再送回各終端。MP可以選擇轉送哪一個終端或哪幾個終端的信號,也可以對不同的音頻、視頻和數(shù)據格式和比特率進行轉換,使得各個參加會議的終端可以使用不同的通信模式。視頻信號還可以采用多播方式分發(fā)至各終端。

圖9－1所示為集中型多點會議結構示意圖。其中虛線表示控制信道,傳送H.245控制消息;實線表示邏輯信道,傳送媒體信息。

2.分散型多點會議

該類會議的終端仍然以點到點的方式和MC建立H.245通信信道連接,MC可位于MCU、網關、網守和某個終端中。各終端的數(shù)據信號一般仍通過MP集中分發(fā),但音頻和視頻信號則直接發(fā)送至其他終端,其發(fā)送方法有兩種:多播方式和多重單播方式。所謂多重單播,指的是每兩個終端之間都建有單播信道。這種管理方式沒有集中控制和集中管理的設備,MCU的功能以MC和MP功能模塊形式分別存在于系統(tǒng)的其他設備(如終端、網關和網守)中。MC仍然具有對會議的控制功能。圖9－2所示為分散型多點會議結構示意圖。圖9－1集中型多點會議圖9－2分散型多點會議

3.集中音頻混合型多點會議

該類會議的終端和MC之間仍然是點到點的H.245控制連接。音頻和數(shù)據信道連接至MP,由MP進行音頻混合,并能為每個終端發(fā)送不同的音頻組合信號。視頻信號則經由多播或多重單播方式在終端之間直接傳送。終端的媒體分配能力設定為集中式控制、集中型音頻、分散型視頻、集中型數(shù)據。

4.集中視頻混合型多點會議

該類會議和集中音頻混合型多點會議類似,只是音頻信號采用直接傳送方式,視頻信號經由MP集中分發(fā),可以根據需要為每個終端發(fā)送不同的視頻流,也可以按多播方式統(tǒng)一發(fā)送,以降低網絡帶寬消耗。終端的媒體分配能力設定為集中式控制、分散型音頻、集中型視頻、集中型數(shù)據。

5.特殊型多點會議

這類會議開始時是一個點到點會議,以后在呼叫過程中通過邀請他人或他人主動加入的方式擴展成為多點會議。它要求在初始的點到點呼叫中必須有一個MC。其可能的情況包括:其中一個終端含有或兩個終端都含有MC;呼叫控制通過網守轉接,該網守具有MC功能;雖然只是兩方呼叫,但也是通過MCU作為多點呼叫來處理的。

H.323標準規(guī)定,H.323終端和MCU必須支持集中型多點會議,而對分散型和混合型多點會議的支持是可選的。表9－1給出了常用的四種多點會議系統(tǒng)的特征。表9－1四種多點會議的特征9.2

MCU的工作原理及通信流程

9.2.1多點控制器

多點控制器是視頻會議系統(tǒng)中具有多點會議控制功能的H.323實體。MC完成對整個會議的集中控制。MC的控制功能通過H.245協(xié)議完成,因此參會各端點首先要建立至MC的H.245控制信道。

1.多點會議通信控制原理

1)呼叫建立

每一端點應與MC完成呼叫建立,建立至MC的H.245控制信道。由于MC本身并無獨立的地址,無法作為呼叫方,因此一般MC是位于MCU中的,但也可能位于網守或終端中。與MC建立H.245控制連接后,利用主從確定過程確定主MC,即經由MC位置指示消息通告主MC的地址(主MC所在端點IP地址),然后利用能力交換過程選定會議形式(集中型或分散型),會議形式的選擇受限于端點和MC的能力。對于每個新加入的端點,MC用“終端號分配”消息賦予終端號,用“終端加入會議”消息通知其他端點新成員的加入,新端點也可用“終端清單請求”消息請求其他端點的名單。

2)通信模式的確定

該過程確定各個邏輯信道的媒體類型、編碼方式、媒體信道和媒體信道傳輸層地址等參數(shù)。

在單播情況下,端點通過“打開邏輯信道”和“打開邏輯信道證實”消息建立至MCU或另一端點的邏輯信道。在多重單播情況下,端點必須逐一打開至所有其他端點的邏輯信道。由于端點只與MC建有H.245控制信道,因此“打開邏輯信道”消息必須送往MC,消息中帶有邏輯信道對端的終端號,然后由MC轉送給對端。端點收到回送的“打開邏輯信道證實”消息,可根據消息中的“前向邏輯信道號”和原請求消息匹配。

多播情況下,則由MC分配多播地址并決定通信模式,經由“通信模式信令”消息告知每個端點。然后,由各端點向MC發(fā)送“打開邏輯信道”消息,消息中帶有該多播地址;MC根據多播地址將此消息轉發(fā)給每個接收端點。

3)邏輯信道和RTP流的關聯(lián)

多播情況下,接收端點會從同一端口收到來自不同源的RTP流,在處理時需要加以識別。為此,H.245規(guī)定端點在發(fā)送“打開邏輯信道”消息時,應將MC分配給它的終端標記置入邏輯信道參數(shù)的源字段;目的地字段空缺,表示該信道的媒體流是多播流。同時,約定源端點發(fā)送的RTP流的源標記SSRC的最低字節(jié)取為該端點終端標記的最低字節(jié)。這樣,目的端點收到RTP流后,通過比較SSRC和邏輯信道參數(shù)源字段的最低比特就可判定該媒體流所屬的邏輯信道。

4)速率匹配

在多點會議中,各終端可能會以不同比特率發(fā)送信號。為了使發(fā)送能力和接收能力匹配,并使各個終端地位平等,MC可以通過發(fā)送“流量控制命令”消息來限定各終端的發(fā)送比特率。如有新的終端加入會議,MC將向其發(fā)送“多點會議”指示消息,要求它遵從比特率均等的安排。

5)加密

在集中型多點會議中,MP被認為是可信任實體。它可以將來自各端點的信息流解密,進行必要的處理,然后將處理后的復合信息重新加密后送往各端點。

6)會議控制

H.245專門定義了一組會議請求及響應消息和一組會議命令消息,供MC在通信過程中對會議進行控制。例如,在會議中,終端可以請求參會終端清單、充當主席、退出會議等,MC可以要求終端輸入口令、終端標識、命令結束會議等。

7)同步

在集中式或混合式多點會議中,為了保證音頻和視頻的同步,提供音頻混合的MP應該修改音頻流和視頻流的時間戳,實現(xiàn)多點會議中的多點音頻同步。當MP對進入MP的音頻流和/或視頻流進行處理產生新的媒體流時,它還應該在產生的音頻或視頻流包上打上自己的序列號。

2.多點會議控制方式

在多點視頻會議中,與會者既能看到其他會場的與會者,同時又能聽到他們的講話,但這個過程可能并不是同時發(fā)生的。那么,在某一時刻到底能看到誰呢?這是由多點視頻會議的控制模式來決定的。

目前廣泛應用在各類視頻會議系統(tǒng)中的控制模式主要有:聲控模式、發(fā)言人控制模式、主席控制模式、廣播/自動掃描模式以及多分屏模式。

(1)聲控模式。聲控模式又稱語音激勵模式,是一種自動工作模式,按照“誰發(fā)言,顯示誰”的原則,由當前發(fā)言者的聲音信號控制圖像的自動切換。在會場數(shù)目較多的情況下,聲控模式對MCU的語音選擇處理器要求過高。

(2)發(fā)言人控制模式。發(fā)言人控制模式也是一種自動工作模式,欲發(fā)言的人通過會議管理界面或遙控器向MCU發(fā)出發(fā)言請求,若MCU認可則將它的圖像、語音信號播放到所有與MCU相連的會議終端,發(fā)言者發(fā)言完畢,MCU自動切換到聲控模式。

(3)主席控制模式。該控制模式下,將所有會場分成主會場和分會場兩類,由主會場組織者(或稱主席)行使會議的控制權,根據會議進行情況和各個分會場的發(fā)言情況,決定在某個時刻人們可以看到哪個會場,而不考慮此刻是誰在發(fā)言。這種方式具有很大的主動性,控制較好,避免了聲控模式頻繁切換圖像造成會議“混亂無序”的現(xiàn)象。

(4)廣播/自動掃描模式。該控制模式實質是主席控制模式的一個變體。這種模式可以將畫面設置為某個會場,而這個會場中的與會者則可以定時輪流看到其他各個分會場。這種模式按照事先設定好的掃描間隔自動切換廣播畫面,而不論此刻誰在發(fā)言。

(5)多分屏模式。這是一種新的控制模式,這種模式通過將屏幕分割成為若干個窗口,而使與會者可以同時看到多個分會場的情況,當然這樣對于整個系統(tǒng)的軟硬件要求也較高。

H.323視頻會議系統(tǒng)只是邏輯意義上的網狀網結構,MCU與MCU、終端與MCU之間不是靜態(tài)固定連接的,會議組織流程較復雜,存在終端和MCU之間相互選擇的問題。在召開一個會議時,終端首先被接入所連接的本域MCU,其他域終端可加入到此MCU上參加會議。在選擇路由上,若參會終端比較分散,則可選擇任意一個參會終端所在地的MCU作為召集方,其他終端匯接到此MCU上。對于會議中邀請和加入其他終端的情況,若會議使用中的MCU端口數(shù)已滿,則終端會被指向與鄰近的MCU建立連接。9.2.2多點處理器

多點處理器(Multipointprocessor,MP)是視頻會議系統(tǒng)中接收并處理音視頻流的H.323實體。集中型會議各終端的音頻、視頻和數(shù)據信道與MCU中的MP相連。MP對各終端送來的信號進行音頻混合、視頻交換或合成以及T.120數(shù)據分配,然后將處理后的音視頻流和數(shù)據流再回送各終端。因此,MP必須能執(zhí)行各種媒體信息的編解碼。MP應具備在不同的音頻、視頻和數(shù)據格式以及比特率之間轉換的能力,使得與會終端能使用不同的通信模式加入同一會議。如果終端之間的SCM不同,MP則要進行通信模式的轉換以保證各終端之間的正常通信。對于視頻信號,MP必須能進行視頻交換或視頻合成。視頻交換就是選定某一源信號發(fā)往各終端,源選擇可通過發(fā)言者變換(檢測話音信號電平確定)實現(xiàn)或由H.245控制實現(xiàn)。視頻合成是指將多個視頻源信號組合成一個視頻信號后再傳送給各終端,其典型應用是將4幅源圖像組合成一個2×2的多畫面圖像,又稱為四分屏圖像。選擇哪些源和多少源圖像進行合成則由MC決定。對于音頻信號,MP能夠通過交換、混合或二者的組合將M個音頻輸入經處理后生成N個輸出。需要注意的是,音頻混合需要將每個輸入音頻首先解碼為線性PCM信號或模擬信號,然后將各路信號合成,最后再將合成后的信號重新編碼成相應格式。混合時,MP可以去除或衰減某些輸入信號,以降低噪聲和其他不需要的信號。終端應保證自己的話音信號不在自己的終端輸出。

1.音頻信號的處理

多點控制單元對語音信號可分為兩種情況:如只有一個會場發(fā)言,多點控制單元將它的音頻信號切換到其他不發(fā)言的會場;若同時有幾個會場發(fā)言,多點控制單元挑出電平最高的音頻信號切換到其他不發(fā)言的會場,或將它們的音頻信號進行混合處理,然后切換到除該會場以外的其他所有會場。在一個會議組中,為便于進行語音混合,一般為每個與MP建立連接的終端均設計了M個音頻緩沖區(qū),其中,M＝(與MCU建立呼叫連接的總終端數(shù)-1),即假設一個會議組中有N個終端與MP建立了連接,則MP為每一個終端均準備了M=(N-1)個緩沖區(qū),這(N-1)個緩沖區(qū)分別用來存放從除本終端外其他終端接收到的音頻數(shù)據,MP對它們進行音頻混合后再回送給這一個對應的終端。據此推斷,MP中共計有音頻緩沖區(qū)N×(N-1)個。每增加一個建立連接的新終端,都要新開辟多個緩沖區(qū),首先要為其他終端都開辟一個緩沖區(qū)用于存放從這個新終端接收到的音頻數(shù)據,然后還要為這個新增終端開辟多個緩沖區(qū)用于存放從其他終端接收到的音頻數(shù)據。圖9－3給出了僅有三個終端與MP建立連接時緩沖區(qū)的分配情況。圖9－3

MP中音頻緩沖區(qū)的分配MP的音頻處理方式采用了事件驅動的多線程機制。對于終端與MCU建立的每個呼叫連接,都對應有兩個線程:接收線程負責將從網絡上接收到的音頻數(shù)據送去解碼器進行解碼,并將得到的解碼流存放在用于存放這個終端的音頻信號的緩沖區(qū);而發(fā)送線程負責將已混合的音頻數(shù)據送去給編碼器進行編碼,并將得到的編碼流發(fā)送出去。MP對多個音頻緩沖區(qū)中的數(shù)據進行音頻混合的過程并不在這兩個線程當中。由于兩個線程之間存在有共享資源,為避免由于資源共享而引起的競爭、死鎖等錯誤,MCU軟件采用了事件和互斥方法來達到線程之間的同步。事件1是指由接收線程將解碼流送入對應緩沖區(qū),緩沖區(qū)被更新;事件2是指讀取緩沖區(qū)中的數(shù)據并對其進行語音混合。事件與線程之間的關系如下:接收線程掛起直到事件2發(fā)生才繼續(xù)執(zhí)行,發(fā)送線程被掛起直到事件1發(fā)生才繼續(xù)執(zhí)行,這樣,就可以保證線程間的同步了。

2.視頻信號的處理

對于視頻來說,要為每個與MP建立連接的終端準備一個緩沖區(qū),它既是接收緩沖區(qū)也是發(fā)送緩沖區(qū)。在主席模式下,對接收到的視頻數(shù)據,MP需先判斷是否是來自主席或選定聽眾的。若是來自主席的,則將它們分別存入與其他所有終端相對應的緩沖區(qū)中；若是來自選定聽眾的,則將其存入為主席準備的緩沖區(qū)中；若是來自其他終端的,則MP不予理會。發(fā)送時,只需將本緩沖區(qū)中的數(shù)據發(fā)往與本緩沖區(qū)對應的呼叫連接即可。在非主席模式下,MCU在接收到來自各終端音頻數(shù)據時就要進行判斷,選其音頻最高的作為當前發(fā)言者。對于視頻來說,MCU需將當前發(fā)言者的視頻數(shù)據存入與其他所有終端相對應的緩沖區(qū)中,而與當前發(fā)言者相對應的緩沖區(qū)中則存放從上一個發(fā)言者接收到視頻數(shù)據。圖9－4給出了主席模式下緩沖區(qū)的分配情況,而非主席模式下的情形類似。圖9－4主席模式下MP視頻緩沖區(qū)的分配若MP要進行四畫面合成,則情形又要稍復雜一些。首先通過MCU的操作界面選定參與畫面合成的四個源終端,MP將為這四個源終端另外創(chuàng)建四個緩沖區(qū),分別用來存放這四個源終端的視頻數(shù)據,MP將這四路視頻數(shù)據合成后再送到與各終端相對應的緩沖區(qū)中,其后的發(fā)送情況和單畫面時相同。9.2.3

MCU通信流程

1.注冊流程

MCU注冊流程如圖9－5所示。

(1)MCU啟動,向網守發(fā)“請求接入認證”(RRQ)消息。

(2)網守回送RCF消息。如果注冊消息被拒絕,則回送RRJ消息,MCU需重新注冊。

2.注銷流程

MCU注銷流程如圖9－6所示。

(1)MCU向網守發(fā)“請求用戶退出”(URQ)消息。

(2)網守收到URQ消息后,向MCU發(fā)送UCF消息。如果注銷消息被拒絕,則回送URJ消息,需重新進行注銷;如果MCU已關機,則網守應強制注銷。圖9－5

MCU注冊流程圖9－6

MCU注銷流程(1)MCU向網守發(fā)起注冊請求ARQ。

(2)網守回送ACF。

(3)向終端1發(fā)起Setup請求建立連接。

(4)終端1向MCU發(fā)送CallProceding消息。

(5)終端1向網守發(fā)送ARQ接入請求。

(6)網守向終端1回送ACF響應。

(7)終端1向MCU回送Alerting消息。

(8)終端1向MCU發(fā)送Connect消息,建立與MCU之間的媒體通道。圖9－7MCU發(fā)起會議流程

(9)終端1和MCU之間發(fā)送TerminalCapabilitySet交換能力。

(10)MCU發(fā)送MasterSlaverDetermination進行主從判決,確定MCU為主,終端為從。

(11)MCU發(fā)送TerminalNumberAssign,為終端1分配終端號。

(12)MCU和終端1之間發(fā)送OpenLogicChannel打開邏輯信道,建立連接。

(13)MCU向終端2發(fā)起Setup請求建立連接。

(14)終端2向MCU發(fā)送CallProceding消息。

(15)終端2向網守發(fā)送ARQ接入請求。

(16)網守向終端2回送ACF響應。

(17)終端2向MCU回送Alerting消息。

(18)終端2向MCU發(fā)送Connect消息,建立與MCU之間的媒體通道。

(19)終端2向MCU發(fā)送TerminalCapabilitySet報告能力。

(20)MCU發(fā)送MasterSlaverDetermination進行主從判決,確定MCU為主,終端為從。

(21)MCU向終端1和終端2發(fā)送MultipointConference消息,通知其已經加入多點會議。

(22)MCU為終端2分配終端號。

(23)MCU和終端2打開邏輯信道,建立連接。

(24)MCU在會議進行中定期發(fā)送相應的資源報告到GK。

(25)GK向MCU回送相應的確認消息和指示。

4.召集人發(fā)起會議

預約會議時間到了以及即時召集的會議認證通過后,會議就可以召集了。召集者終端發(fā)出會議建立請求,網守告知MCU需要召集的會議信息,由MCU呼叫其他與會終端。

召集人發(fā)起會議流程如圖9－8所示。圖9－8召集人發(fā)起會議流程

(1)召集人終端(終端1)發(fā)起會議申請,向網守發(fā)送帶有預約會議號和密碼的ARQ消息。

(2)駐地網守收到ARQ消息認證通過后,向其后的AAA服務器發(fā)送AccessRequest消息,開始對會議進行計費。

(3)AAA服務器向網守回送AcceptResponse消息。

(4)網守向終端回送ACF消息。

(5)預約終端在通過認證后,向網守發(fā)送ARQ消息,消息中包含會議召集者標識、受邀請的會議成員的情況和標識等。

(6)駐地網守收到ARQ消息后,調度相應的資源供會議使用,并回送ACF消息。

(7)召集人終端向駐地網守發(fā)送Setup消息,建立與其他終端的連接。

(8)網守向MCU發(fā)邀請會議成員的Setup消息,請求MCU邀請其他與會終端。

(9)MCU向網守發(fā)送ARQ消息,請求會議認證。

(10)網守回送ACF確認。

(11)MCU確認收到消息后,向網守發(fā)送Alerting消息。

(12)駐地網守確認收到消息后,向召集人終端發(fā)送Alerting消息。

(13)MCU向駐地網守發(fā)送Connect消息。

(14)駐地網守確認收到消息后,向召集人終端發(fā)送Connect消息。

(15)終端1和MCU之間發(fā)送TerminalCapabilitySet交換能力。

(16)MCU發(fā)送MasterSlaverDetermination進行主從判決,確定MCU為主,終端為從。

(17)MCU發(fā)送TerminalNumberAssign,為終端1分配終端號。

(18)MCU和終端1之間發(fā)送OpenLogicChannel打開邏輯信道,建立連接。

(19)MCU向終端2發(fā)起Setup請求。

(20)終端2向網守發(fā)送ARQ消息,請求認證。

(21)網守回送ACF確認。

(22)終端2向MCU回送Alerting消息。

(23)終端2向MCU發(fā)送Connect消息。

(24)終端2向MCU發(fā)送TerminalCapabilitySet報告能力。

(25)MCU發(fā)送MasterSlaverDetermination進行主從判決,確定MCU為主,終端為從。

(26)MCU向終端2發(fā)送MultipointConference消息,通知其已經加入多點會議。

(27)MCU向終端1發(fā)送MultipointConference消息,通知其已經加入多點會議。

(28)MCU為終端2分配終端號。

(29)MCU和終端2打開邏輯信道，建立連接。

(30)MCU在會議進行中定期發(fā)送相應的資源報告到網守。

(31)網守向MCU回送相應的確認消息和指示。

(16)所有終端退出會議后,MCU向GK發(fā)送DRQ消息拆除鏈接。

(17)網守回送DCF消息。

(18)網守向AAA遞送計費信息。

(19)AAA回送響應。

6.主席控制

主席控制流程包括申請主席、釋放主席、請求發(fā)言、廣播會場、視頻選看、強制非主席終端退出等。

1)申請主席

申請主席流程如圖9－10所示。

(1)終端使用ConferenceRequest(MakeMeChair)向MCU申請主席。

(2)如果當前沒有其他主席或該終端本身就是主席,MCU同意請求,回送ConferenceResponse;如果當前有其他主席,則拒絕該申請ConferenceResponse。一旦會議中某個終端申請主席成功,該會議中其他終端不能再申請主席。

2)釋放主席

釋放主席流程如圖9－11所示。

(1)終端使用ConferenceRequest向MCU申請釋放主席。

(2)MCU同意請求,回送ConferenceResponse。會議中其他終端可以再申請主席。圖9－10申請主席流程圖9－11釋放主席流程

3)終端請求發(fā)言

終端請求發(fā)言流程如圖9－12所示。

(1)終端向MCU請求發(fā)言。

(2)MCU向主席終端發(fā)送終端的發(fā)言請求。

(3)MCU如果同意發(fā)言,則回送廣播終端的命令。圖9－12終端請求發(fā)言流程

4)廣播會場

廣播會場流程如圖9－13所示。圖9－13選擇一視頻進行廣播5)視頻選看

圖9－14視頻選看流程

6)強制非主席終端退出

強制非主席終端退出流程如圖9－15所示。圖9－15強制非主席終端退出流程

(1)主席終端向MCU發(fā)送請求,強制一個終端的退出。

(2)MCU與退出終端間關閉邏輯通道。

(3)MCU與退出終端間關閉H.245會話。

(4)MCU向該終端發(fā)送ReleaseComplete消息。

(5)終端返回ReleaseComplete消息。

(6)MCU向主席終端返回TerminalLeftConference消息。

7)聲音控制

(1)每個會場均能同時聽到其他各會場的聲音。

(2)MCU自動根據與會者發(fā)言音量大小,將圖像切換到發(fā)言聲音最大的會場并廣播出去。

7.呼叫擴展流程

1)會議延時

會議延時流程如圖9－16所示:

(1)會議進行中,預約的時間就要到達,而會議并未結束,會議召集終端向網守發(fā)送ARQ請求,在ARQ請求中為同一個會議申請新的會議時間,會議標識與原預約會議標識相同,開始時間為原預約會議的結束時間,并且在ARQ消息中預約一個新的時長。

(2)網守檢查用戶是否有資源沖突,并向AAA服務器請求驗證用戶是否有權進行會議的延長或用戶賬上是否有足夠的余額。

(3)如果各種條件滿足,AAA返回確認信息。

(4)網守給終端返回一個ACF消息接受用戶新的預約。

注:如果是允許持卡用戶申請會議的延時,網守在開始會議預約時,應從AAA服務器得到用戶賬戶上剩余的金額。圖9－16會議延時流程圖9－17終端申請加入

2)成員加入

終端申請加入流程如圖9－17所示。

(1)申請加入一個已經召開的會議的終端,在取得會議號和密碼后發(fā)起會議申請,向網守發(fā)送帶有會議號和密碼的ARQ消息。

(2)網守收到ARQ消息后,向其后臺的AAA服務器發(fā)送AccessRequest消息,對終端的申請進行認證。

(3)AAA服務器查找其數(shù)據庫中關于會議的信息,確認該用戶有權加入會議后,AAA服務器向網守回送AcceptResponse消息。

(4)收到AccessResponse消息,網守向終端回送ACF消息。

(5)新加入終端在通過認證后,向網守發(fā)送ARQ消息,消息中包含新加入會議成員的情況和標識等。

(6)駐地網守收到ARQ消息后,向新加入終端回送ACF消息,其中包含駐地網守的信息;否則發(fā)送ARJ消息。

(7)新加入終端向駐地網守發(fā)送Setup消息,建立與其他終端的連接。

(8)駐地網守向MCU發(fā)會議成員申請加入的Setup消息,請求MCU連接新加入終端。

(9)MCU確認收到消息后,向網守送Alerting消息。

(10)駐地網守確認收到消息后,向召集人終端送Alerting消息。

(11)MCU向駐地網守送Connect消息。

(12)駐地網守確認收到消息后,向召集人終端送Connect消息。3)邀請新成員圖9－18邀請新成員流程

(1)會議在進行中,召集人邀請新成員加入,召集人在其終端填寫所邀新成員的終端標識號,向網守發(fā)送邀請消息Setup。

(2)邀請終端向網守發(fā)送ARQ,帶有預約會議號和密碼以及邀請新成員的信息。

(3)駐地網守收到ARQ消息后,向其后臺的AAA服務器發(fā)送AccessRequest消息,對終端申請進行認證。

(4)AAA服務器查找其數(shù)據庫中關于該終端的信息,確認該用戶有權邀請新成員,AAA服務器向網守回送AccessResponse消息。

(5)收到AccessResponse消息,網守向終端回送ACF消息。

(6)網守將被邀請終端標識用Setup消息送給MCU。

(7)MCU向受邀請終端發(fā)送Setup呼叫建立請求。

(8)受邀終端向網守發(fā)送ARQ消息,請求認證。

(9)網守回送ACF確認。

(10)被邀請終端回送Alerting。

(11)MCU向網守回送Alerting。

(12)被邀請終端參加會議,向MCU送Connect消息。

(13)MCU向網守發(fā)送邀請已完成的確認Connect消息。

(14)網守向召集人終端發(fā)送邀請成功應答消息。

9.3

MCU級聯(lián)控制及通信流程

9.3.1

MCU級聯(lián)的原理

在計算機硬件有限的處理能力下,要擴大會議規(guī)模,就必須對會議核心設備MCU的網絡結構進行合理的設計,基本原理是把各個處在不同地域的MCU通過管理軟件連接在一起,組成一個更大容量的會議系統(tǒng)。分布式MCU構建的方法主要是把MCU設備通過邏輯級聯(lián)的方式連接起來,把多個MCU設備連接成一個大型MCU,實現(xiàn)大容量的會議系統(tǒng)。在分布式級聯(lián)方案中,將主持方的MCU設置成主MCU,其余各個地域中不同的分MCU設置成從MCU,整個會議系統(tǒng)采用“一主多從”的形式,本質上是把主MCU中的會議參數(shù)傳遞給參加級聯(lián)的從MCU,即把主MCU中參加級聯(lián)的會議的音頻、視頻和會議模式等參數(shù)傳遞給所有從MCU中參加級聯(lián)的會議,把從MCU以用戶的身份加入到主MCU的參加級聯(lián)的會議中,把主MCU以用戶的身份加入到各個從MCU的參加級聯(lián)的會議中。用戶終端會議功能是通過參加級聯(lián)的各個級聯(lián)會議實現(xiàn)的,級聯(lián)會議的會議功能再通過MCU完成數(shù)據交互。按照每組會議總是把主席或者發(fā)言聽眾的數(shù)據轉發(fā)給其他用戶的原則,要把從MCU中用戶的數(shù)據傳遞給上層主MCU或者其他從MCU中的用戶,首先要把該用戶設置成主席,把該從MCU在主MCU中的身份設置成主席,把主MCU在其他從MCU中的身份設置成主席,再把主MCU在該從MCU中的身份設置成普通聽眾或者發(fā)言聽眾。要把主MCU中的用戶數(shù)據傳遞給下層從MCU的用戶,首先把該用戶設置為主席,再把主MCU在從MCU中的身份設置為主席就可以了。9.3.2

MCU級聯(lián)的流程

圖9－19

MCU級聯(lián)流程

(1)MCU1向網守1發(fā)起接入請求ARQ。

(2)網守1回送ACF。

(3)MCU1向MCU2發(fā)起Setup請求建立連接。

(4)MCU2向MCU1發(fā)送CallProcessing消息。

(5)MCU2向網守2發(fā)送ARQ接入請求。

(6)網守向MCU2回送ACF響應。

(7)MCU2向MCU1回送Alerting消息。

(8)MCU2向MCU1發(fā)送Connect消息,建立MCU之間的媒體通道。

(9)MCU2向MCU1發(fā)送TerminalCapabilitySet報告能力。

(10)MCU2發(fā)送MasterSlaverDetermination進行主從判決,確定MCU1為主MCU2為從。

(11)MCU1為MCU2分配終端號。

(12)MCU1發(fā)送RemoteMCRequest,激活MCU2。

(13)MCU2發(fā)送RemoteMCResponse,確認或拒絕激活。

(14)MCU1為MCU2上的終端分配號碼。

(15)邏輯信道打開,連接建立,會議正常進行。

(16)會議結束時,MCU1發(fā)送關閉邏輯信道請求。

(17)MCU1發(fā)送結束會話請求,MCU2回送結束會話請求。

(18)MCU1拆除連接。

(19)MCU1向網守1發(fā)送DRQ,報告會議結束并退出,MCU2向網守2發(fā)送DRQ,報告會議結束并退出。

(20)網守1回送DCF給MCU1,網守2回送DCF給MCU2。

9.4

MCU的功能及實現(xiàn)

9.4.1

MCU的功能要求

1.多點控制功能

MCU提供了在三個或更多個終端間召開多點會議的控制功能。

在多點會議中,MCU接受網守控制,召集、結束會議,呼叫參會終端,對一組或多組會議進行管理,處理會議中的呼叫服務,并向網守報告會議狀態(tài)。

MCU負責與每個端點的能力交換。在呼叫時,MCU發(fā)送能力集給會議中的端點,指示它們可用的傳輸模式。MCU可以因終端加入/離開會議或是其他原因而修改它發(fā)送到終端的能力集。

2.多點處理功能

在一個集中或混合的多點會議中,MCU接收來自終端的音頻、視頻和/或數(shù)據流。MCU處理這些媒體流并把它們送回到端點。

MCU應該具備視頻處理功能,提供視頻切換及視頻合成控制。

MCU必須具備音頻處理功能,通過混合或組合操作從多路音頻輸入中得到一路或多路音頻輸出。

MCU必須采取一定的措施以保持音頻和視頻的同步。

3.多點適應能力

MCU應該支持多點控制、級聯(lián)等功能,可選支持多點速率匹配、多通信模式匹配等功能。

(1)多點控制。MCU應該支持會議中的控制。會議中的控制包括設備控制和會議控制。設備控制的內容有攝像機遠程控制、麥克風遠程控制、圖像播放遠程控制、幻燈片播放遠程控制等;會議控制應該支持主席控制、可選操作員(導演)控制和語音控制等。

(2)級聯(lián)能力。多點控制功能可以在多個MCU之間分配。

(3)多點速率匹配。MCU可以支持終端以不同的比特率工作。

(4)多通信模式匹配。MCU應該具備音頻和/或視頻格式轉換的能力,不同端點可以采用不同的通信模式。

4.網管功能

多點控制單元應該支持本地和遠程的配置管理、故障管理、版本管理、用戶管理、日志管理等網管功能。9.4.2

MCU功能的實現(xiàn)

1.會議管理

單臺MCU的最大容量一般為16個用戶或更高,在其最大容量范圍內應能同時處理多組會議,每組會議之間互不干擾,獨立控制。各組支持的終端數(shù)之和不能超過MCU允許的最大容量。

會議管理功能支持多組會議控制(包括創(chuàng)建新的會議組和取消原有的會議組),對每組會議的成員信息可在會議進行中進行管理,方便新的與會者加入,自動處理某一與會者的退出等。為完成此項功能,首先要在程序內部維護一個會議成員信息類、一個會議成員列表類和一個組列表類。會議成員信息類用于存放會議組中成員的一些相關信息,如此成員的用戶名、別名、IP地址、所在會議組的組名和ID號、狀態(tài)(是否在線)以及其身份(主席、選定聽眾或一般用戶)等;會議成員列表類則相當于一個用戶鏈表,它存放了參加會議的所有用戶的信息,并且包含了完成添加、刪除、插入及查找某一用戶等與鏈表操作相當?shù)囊恍┗静僮鞯某蓡T函數(shù);而組列表類則相當于一個組鏈表,用于存放每個組,它也同樣具有完成添加、刪除、查找等功能的成員函數(shù)。另外,還可以添加一些友好界面,將這些操作顯示在界面上,加強人機交互的實用性。

MCU一般為嵌入式設備,其管理和控制是由專門的軟件通過與MCU互聯(lián)的遠端計算機來完成的。用戶可以通過B/S,即Web方式或C/S方式進行遠端訪問和控制。當然也可安裝專門的會議管理軟件,對MCU進行管理。

2.與參會終端建立一點到多點的通信

對于MCU設備來說,最重要的是能夠兼容各廠商符合H.323標準的設備,如終端、網關、網守等,并提供良好的互操作能力。對不同廠商的H.323設備要能夠做到互聯(lián)、互通和互控。對于符合H.320標準的終端,可通過網關接入,實現(xiàn)H.320和H.323會議終端的互通。與參會終端建立點到點通信是指MCU可以作為主叫方呼叫參會終端,也可以作為被叫方接受參會終端的呼叫,并與之建立呼叫連接。實現(xiàn)時,首先添加一個發(fā)起呼叫的功能塊和一個接受呼叫的功能塊,其次再完成其他工作,如完成RAS協(xié)議、Q.931協(xié)議和H.245協(xié)議等。為實現(xiàn)呼叫連接,必須為每個呼叫都創(chuàng)建一個呼叫線程,使得MCU與每個會議成員之間的呼叫互不影響。對于單個呼叫來說,必然要創(chuàng)建一個守聽線程來在特定的端口上偵聽來自遠端的呼叫。當有呼叫進來時,判斷呼叫方是否是本MCU成員列表里的一個成員。若是,則接受呼叫,并將此成員的狀態(tài)改為在線；若不是,則自動拒絕此呼叫。如果MCU作為主叫方呼叫了某一會議成員,首先就要生成一個新的傳輸層類,用于以后媒體信號的傳輸;接著構造一個新的H.323連接對象,用于管理它們之間的呼叫連接;最后還要生成一個呼叫守護線程,用于管理雙方的H.225/Q.931信令在TCP信道上的信令交換,而這些信令的發(fā)送與處理都是由呼叫連接類來完成。呼叫連接的建立標志著一個呼叫的成功。

MCU支持群呼和群掛斷功能,它可以呼叫一組終端,或者掛斷一組終端,甚至可以呼叫或掛斷所有終端。MCU可設置與會者列表,通過MCU或IVR的群呼功能,實現(xiàn)自動召集會議功能,無需各分會場主動呼入。對于IVR控制方式,可以使用任何一臺與會議系統(tǒng)互聯(lián)的IP電話、普通電話或移動電話召集和組織會議。

3.MCU工作方式的確定

MCU的工作方式主要分為主席模式和非主席模式兩種。在會議的進行過程中,可以動態(tài)地指定會議模式為主席模式或者非主席模式。在主席模式下,終端有三種可能的身份:主席、選定聽眾以及一般聽眾。除主席外,所有終端接收的視頻源均為主席的,即它們收看主席的圖像,而主席則收看選定聽眾的圖像。MCU具有語音選擇控制和操作員手工控制兩種控制方式,會議進行中可以在兩種控制方式之間切換。在手工操作方式下,發(fā)言者或主席是可以根據需要動態(tài)指定的。在語音選擇方式下,MCU自動將當前發(fā)言者的音視頻數(shù)據發(fā)送給其他與會者。在非主席模式下,采用語音激勵方式進行數(shù)據的轉發(fā),這時,所有會議成員(除發(fā)言者外)均接收發(fā)言者的信號源,而發(fā)言者則接收上一發(fā)言者的信號源。

MCU能自動檢測到每組會議中發(fā)言音頻強度最高的會場,并立即將該會場的音視頻流傳給該組其他所有會場。其語音激勵靈敏度可以根據會場具體情況進行動態(tài)手工調節(jié),以避免某些會場的噪音干擾。這樣MCU在無人操作的情況下,通過語音就能對會議進行控制,完成視頻畫面的切換。

在主席模式下,最重要的是在用戶類的數(shù)據成員“身份”上做好用戶的身份標志。而在非主席模式下,對每一組會議來說都需要維護一個發(fā)言者列表,以數(shù)組的形式存放,用于列出所有曾經是發(fā)言者的成員,而最新檢測到的發(fā)言者總是列在列表的最末位,即為數(shù)組的最后一個元素。

4.多路音視頻處理

可以實時將多路語音進行合成,使每個與會者能同時聽到多個與會者的聲音。為了避免自激、回音等現(xiàn)象的出現(xiàn),每個與會者將不能聽見自己的聲音。在會議進行的過程中可以動態(tài)選擇是否選中語音合成,不進行語音合成則可以通過選定主席或者選定組播方式完成數(shù)據交換和會議功能。多畫面合成又稱為多分屏或動態(tài)分屏,有多種實現(xiàn)方法,例如壓縮域合成方法和非壓縮域合成方法。在H.261視頻格式下,可以進行四畫面合成,將四路QCIF格式的視頻圖像合成為一路CIF格式的視頻圖像。MCU同時接收四路會場的視頻數(shù)據,不進行解碼處理,在壓縮域內合成,形成一條視頻流,再將合成后的視頻流發(fā)送給所有與會者,使每個與會者能同時看到四個會場的圖像。這種方法稱為壓縮域合成方法,該方法僅適用于H.261格式的視頻圖像,不適用于H.263或H.264等其他格式的視頻圖像。

MCU支持多畫面顯示功能,完成該功能的設備稱為多點顯示單元(MDU),又稱為多畫面電視墻。在不影響現(xiàn)有系統(tǒng)的情況下,MDU采用獨立的網絡接口,對多個會場的視頻數(shù)據進行解碼,這樣在中心會場就可選擇同時收看多路會場的圖像。

5.其他功能

MCU支持遠端攝像機控制(FarEndCamraControl,FECC)。在主席模式下,主席和選定聽眾之間可以實現(xiàn)遠端攝像機的互控。在語音激勵模式下,可實現(xiàn)當前發(fā)言人和前一發(fā)言人之間的遠端攝像機互控。在視頻會議中,遠端攝像機控制應遵循H.281協(xié)議。

MCU具有組播功能,可選擇組播多路視頻數(shù)據(最多四路),終端通過組播接收軟件動態(tài)選擇接收其中的任意一路組播視頻數(shù)據并進行顯示。

MCU應支持網絡遠程軟件升級。用戶可利用專門的軟件通過網絡對MCU軟件進行快速升級更新。

MCU應支持級聯(lián)控制,以便擴充MCU的容量。利用級聯(lián)方式,使用有限的帶寬將位于不同地域的多組用戶連接起來,有效節(jié)省長途傳輸帶寬。9.4.3

MCU的控制平臺CMS

MCU是多點會議的核心設備,承擔著幾乎所有的會議控制功能。同時,MCU作為一個系統(tǒng)設備,通常安裝在視頻會議網絡中的主要節(jié)點處,如網絡中心機房。而會議的控制通常由會議成員來進行,即對MCU的操作一般通過遠程控制平臺實現(xiàn)。

CMS(ContentManagementSystem)可作為MCU的管理中心,對MCU設備進行全面的功能設置和會議調度。CMS工具可安裝在Windows系統(tǒng)中。運行CMS管理程序,將自動搜索網上正在運行的MCU設備,選擇連接其中的一個,即可對其進行控制。這些控制通常包括設備管理、會議管理、會議設置、會議控制和MCU系統(tǒng)信息等。

(1)設備管理包括基本設置、時間同步、網守管理、網絡接口管理、用戶管理、終端列表、組播地址管理。

(2)會議管理包括會議添加和會議刪除。

(3)會議設置包括基本設置、會議成員、會議格式、字幕疊加、實況組播、會議預約、雙流顯示、攝像機遠程控制、允許自動發(fā)言、發(fā)言聽眾模式、允許終端發(fā)起會議、會議成員默認混音、會議成員默認閉音、斷線重連、帶寬優(yōu)化。

(4)會議控制包括呼叫連接、呼叫掛斷、多分屏切換、會議成員信息統(tǒng)計。

(5)MCU系統(tǒng)信息包括軟件版本、CPU資源利用率、軟件下載更新。 9.5視頻IP組播技術

9.5.1

IP組播的基本概念

我們知道,在多點視頻會議系統(tǒng)中,用戶數(shù)過多會造成基于IP網絡系統(tǒng)的服務質量的嚴重下降;若要保證服務質量,則又嚴重制約了用戶數(shù)的增加。針對這一矛盾,可以考慮使用IP組播技術。

1.視頻IP組播的概念

IPV4支持單播(Unicast)、廣播(Brocdcast)、組播(Multicast)三種數(shù)據傳送方式。組播是相對于單播和廣播而言的一種面向“組”發(fā)送數(shù)據的形式。廣播是指將信息從一個發(fā)送端傳送到整個子網中所有終端,而組播將信息從一個發(fā)送端傳送到多個接收端。

IP組播將IP數(shù)據包“盡最大努力”傳輸?shù)揭粋€構成組播群組的主機集合,群組的各個成員可以分布于各個獨立的物理網絡上。IP組播群組中成員的關系是動態(tài)的,主機可以隨時加入和退出群組。群組的成員關系決定了主機是否接收送給該群組的組播數(shù)據包,不是該群組的成員主機也能向該群組發(fā)送組播數(shù)據包。

IP組播是單播傳輸很好的改進,同單播相比效率非常高,不論網絡中有多少個接收端,發(fā)送端只需發(fā)送一個媒體流,因此可以顯著節(jié)省網絡帶寬和資源。如果有一個視頻服務器與遠端網絡通信,網絡中有n個用戶,對于一個活動全屏圖像,一個視頻信息流需占用1.5Mb/s的帶寬。在單播環(huán)境中,視頻服務器依次送出n個信息流,由網絡中的用戶接收,共需要n×1.5Mb/s的帶寬;如果服務器處于10Mb/s以太網內,6～7個信息流就占滿了帶寬;既便在高速以太網中,最多也只能容納250～300個1.5Mb/s的視頻流。在組播環(huán)境中,不論網絡中的用戶數(shù)目有多少,服務器發(fā)出一個視頻流,由網絡中的路由器或交換器同時復制出n個視頻流,廣播到每個用戶,僅需1.5Mb/s的帶寬。由此可見,IP組播能夠有效地節(jié)省網絡帶寬和資源,管理網絡的增容和控制開銷,大大減輕發(fā)送服務器的負荷,從而高性能地發(fā)送信息。組播傳送的信息能同時到達用戶端,時延小,且網絡中的服務器不需要知道每個客戶機的地址,所有的接收者使用一個網絡組播地址,可實現(xiàn)匿名服務,并且IP組播具有可升級性,與新的IP業(yè)務兼容。

在多點視頻會議系統(tǒng)中,我們讓大部分會議終端只有參加會議的權力,而不給它們提供發(fā)言權,利用組播技術把音視頻數(shù)據發(fā)送給它們,只讓少數(shù)重要的會議終端具有發(fā)言權。這樣做的目的是既節(jié)約了網絡帶寬,又增加了用戶數(shù),同時還保證了視頻會議系統(tǒng)的服務質量。在MCU中,音視頻媒體流組播一般是作為一種可選附加模塊進行添加的,其機制和視頻終端的機制很相似。只要在MCU的主席控制端中打開媒體流組播的功能,在控制中心即可將任意會場的視頻圖像通過媒體流組播發(fā)送出去。例如在召開四點視頻會議的同時,控制中心主席端可以打開流廣播的功能,將任意會場(主會場或分會場)的音、視頻廣播到其他未參加雙向會議的會場。

2.視頻IP組播實現(xiàn)機制

IP組播利用組播協(xié)議將IP數(shù)據包從一個源傳送到多個目的地,將信息的拷貝發(fā)送到一組地址,到達所有想要接收它的接收者處。

組播發(fā)送數(shù)據時,接收端通過IP網D類地址判斷自己是否是本組成員,若是則接收組播數(shù)據流。D類地址是一個格式為224.0.0.0～239.255.255.255的IP地址,其中較低位置的256個地址被保留給管理和系統(tǒng)級的路由選擇使用,中間范圍被組、內部網和Internet中的組播端用戶應用系統(tǒng)使用,較高位置的D類地址238.255.255.255～239.255.255.255被保留用于特定的多路廣播應用系統(tǒng)。在組播通信模型中,需要兩種新型地址:一個IP組播地址和一個Ethernet組播地址。IP組播地址表示一組接收者,它們要接收發(fā)給整個組的數(shù)據。由于IP包封裝在Ethernet幀內,所以還需要一個Ethernet組播地址。為使組播正常工作,主機應能同時接收單播和組播數(shù)據,主機需要多個IP地址和Ethernet地址,其中單播IP和Ethernet地址用于單播通信,而Ethernet組播地址用于組播通信。如果主機不準備接收組播,組播地址就設置為零組播地址。因此,單播和組播地址之間的主要差異在于每個主機都有一個惟一的單播地址,組播地址則不然。將D類IP地址映射為EthernetMAC地址是由數(shù)據鏈路層完成的。在映射過程中,組播IP地址中共有9位不參與替換,包括高位字節(jié)8位以及緊接在該字節(jié)后面的一個標志位,其中最開始的4位1110表示屬于D類IP地址,剩下的5位實際不參與映射,無論這些位的值是什么,組播Ethernet地址都是相同的。由于5個位共可以有32種不同的組合,所以映射并不具有惟一性。

3.組播路由協(xié)議

在一個組播路由器建立路由,傳送其組播群組成員關系信息之前,它必須確定在本地網絡上是否有一個或多個主機加入了某個組播群組。為此,組播路由器和實現(xiàn)組播的主機必須使用互聯(lián)網組管理協(xié)議(InternetGroupManagementProtocol,IGMP)來進行群組成員關系信息的通信。利用IGMP,組播路由器可判斷在與自己連接的任何一個網絡上是否存在組播組的一些成員,如存在組成員,組播路由器便可加入一個特定的組播組,并將組播數(shù)據轉發(fā)給加入該組的主機。因此,IGMP被主機用來通知直連的路由器,令其加入一個組播組,使組播網具有動態(tài)性和靈活性。

IP網絡的二層組播相關協(xié)議包括IGMPSnooping和CGMP。IGMPSnooping通過交換機去偵聽主機發(fā)向路由器的IGMP成員報告消息,形成組成員和交換機接口的對應關系,放在組播CAM表項中。交換機根據該對應關系將收到組播數(shù)據包只轉給有組成員的接口。

CGMP(CiscoGroupManagementProtocol)是Cisco基于客戶機/服務器模型開發(fā)的私有協(xié)議,它運行在路由器和交換機上,允許成員關系信息從路由器到交換機進行通信。在CGMP的支持下,組播路由器能夠根據接收到的IGMP數(shù)據包通知交換機哪些主機何時加入和脫離組播組,交換機利用由這些信息所構建的轉發(fā)表來確定將組播數(shù)據包向哪些接口轉發(fā)。組播注冊協(xié)議(GMRP)是主機到以太網交換機的標準協(xié)議,它使組播用戶可以在第二層交換機上對組播成員進行注冊。在基于路由器的網絡中,對于傳遞組播信息流,一個至關重要的問題是IP組播路由協(xié)議。它克服了利用單播通信模型傳遞組播信息帶來的帶寬瓶頸,減少了發(fā)送相同數(shù)據信息到多個接收者的通信費用,這也是IP組播應用得到發(fā)展的主要原因。組播網內數(shù)據的流動必須根據組播路由協(xié)議建立生成樹,使發(fā)送源和組播組成員之間形成一條單獨的轉發(fā)路徑,確保每個數(shù)據包都能轉發(fā)到目的地。

IP組播路由協(xié)議分為域內協(xié)議和域間協(xié)議。域內協(xié)議包括PIM－SM、PIM－DM、DVMRP、CBT等;域間協(xié)議包括MBGP、MSDP、BGMP等。根據網絡中主機的分布,上述IP組播域內路由協(xié)議一般可以分為兩類。第一類稱為密集型模式,這種模式指組播成員在網絡中密集分布,有足夠的帶寬,所以密集協(xié)議通過擴散技術傳播信息至整個網絡,包括DVMRP、MOSPF和PIM－DM,這類協(xié)議屬于數(shù)據驅動型的。第二類稱為松散型模式,這種模式指組播成員在網絡中分散分布,沒有足夠的帶寬,例如廣域網或用戶使用ISDN線上網,但松散型模式并不意味群組有很少的成員,只不過它們是分散分布的,它包括CBT和PIM－SM。擴散技術將浪費帶寬,它通過發(fā)出加入請求申請,在含有集中點或核心點的空生成樹上添加樹枝形成組播生成樹,這類協(xié)議屬于接收者驅動型。使用DVMRP、MOSPF組播路由協(xié)議時,單播路由協(xié)議相應地必須使用RIP、OSPF,這就造成了一定的局限性。DVMRP使用距離向量路由協(xié)議建立生成樹,MOSPF使用鏈路狀態(tài)數(shù)據庫建立生成樹。PIM和CBT獨立于單播路由協(xié)議,但依賴于單播路由表,其中PIM－SM和CBT有一個集中點或核心,連接源和接收者之間的各個路由器而形成路由。針對域間組播路由有兩類解決方案:短期方案和長期方案。短期方案包括三個協(xié)議:MBGP、MSDP和PIM－SM。MBGP(組播邊緣網關協(xié)議)用于在自治域間交換組播路由信息;MSDP(組播信源發(fā)現(xiàn)協(xié)議)用于在ISP之間交換組播信源信息;PIM－SM(協(xié)議無關組播－稀疏模式)用于域內組播路由管理。長期方案目前討論最多的是MASC、MBGP和BGMP,它們建立在現(xiàn)有的組播業(yè)務模型上。其中,MASC實現(xiàn)域間組播地址的分配;MBGP在域間傳遞組播路由信息;BGMP完成域間路由樹的構造。此外還有一些組播路由策略,如PIM－SSM(特定信源協(xié)議無關組播)等,建立在其他組播業(yè)務模型上。目前只有短期方案MBGP、MSDP和PIM－SM是成熟的,并被許多運營商所使用,其他方案的標準還在研究中。9.5.2

IP組播技術的特點

IP組播技術具有以下特點:

(1)群地址。在組播網中,每個組播群組擁有惟一的組播地址(D類地址),一部分IP組播地址是由Internet管理機構分配的,其他的組播地址作為暫時地址被用戶使用。組播數(shù)據包可以送到標識目的主機的組地址,發(fā)送者不必知道有哪些組成員,它自己不必是組成員,對組成員中主機的數(shù)目和位置也沒有限制。主機不需要和組成員以及發(fā)送者商量,可以任意加入和離開組播組。使用組地址,不必知道主機指定的位置,可以找到具有此組播地址的任何資源和服務器,在動態(tài)變化的信息提供者中搜尋到需要的信息,或者發(fā)布信息到任意大小的可選用戶群。

(2)規(guī)?？蓴U展性。如果網絡速率提高,則廣域組播網絡的容量需要擴大。組播路由算法和協(xié)議如PIM－DM、PIM－SM、CBT等都支持網絡規(guī)模的擴展,而群地址和動態(tài)性也是適應規(guī)?？蓴U展性的另一方面。

(3)健壯性。IP組播網絡使用的路由協(xié)議和算法能適應網絡路由動態(tài)變化,它采用軟件狀態(tài)刷新機制、制作路由備份等方法,來維護群組成員之間的連接,加強網絡的健壯性。

(4)路由算法的獨立性。組播路由算法和協(xié)議獨立于單播路由使用的協(xié)議,但又依靠現(xiàn)存的單播路由表,在域內適應網絡拓撲的變化,動態(tài)生成組播樹。

(5)組播生成樹的靈活性。組播生成樹的形成與發(fā)送者和接收者的分布、網絡的流量狀況以及組成員的動態(tài)性有關,且組播生成樹也反映了不同的組播路由算法和組播應用。靈活的組播生成樹有利于數(shù)據包的傳送,不容易造成網絡的擁塞。9.5.3

IP組播在視頻中的應用

如果要將組播通信應用在視頻網絡中,網絡里的會議終端、網關、MCU(發(fā)送和接收主機)、網絡路由器以及它們之間的網絡結構必須支持組播,防火墻應設置成允許組播通過。

每個會議端點要能支持組播,網絡接口卡能有效濾出由網絡層IP組播地址被映射成的數(shù)據鏈路層地址;要有加入組播組請求的IGMP的軟件和路由器通信并加入組播群;要有支持IP組播傳送和接收的TCP/IP協(xié)議棧。在視頻網絡中IP組播通信的過程如下:

(1)端點送出一條IGMP加入消息到相鄰路由器,端點的MAC地址映射為將要加入的D類組地址,并包含在IGMP數(shù)據報中,路由器知道端點想加入組播組。

(2)相鄰路由器接收加入消息后,動態(tài)跟蹤這些組播組,使用組播路由協(xié)議,在源端和接收端各個路由器之間建立組播生成樹,從每個發(fā)送者伸展到所有接收者。

(3)在源端和接收端建立組播路由后,源端就開始沿著組播路由發(fā)送數(shù)據給各個接收者。

9.6視頻會議中多畫面合成技術

9.6.1壓縮域合成

1.壓縮域合成算法原理

H.261標準分為CIF和QCIF兩種格式,其中一幀CIF格式圖像的大小為352×288像素,一幀QCIF格式圖像的大小為176×144像素,如表9－2所示。一幀H.261CIF圖像由12個塊組(GroupOfBlocks,GOB)組成,一幀H.261QCIF由3個塊組(GOB)組成。兩種格式的塊組空間排列方式如圖9－20所示,其數(shù)字為塊組號。表9－2

H.261CIF和QCIF像素大小比較圖9－20

H.261幀內塊組空間的結構

H.261視頻數(shù)據的編碼過程如下:首先通過離散余弦變換(DCT)壓縮圖像數(shù)據,再經過變長編碼進一步壓縮;然后對視頻數(shù)據進行四層復用數(shù)據結構封裝,由上到下依次是:圖像層、塊組層、宏塊層和像塊層,該封裝用來對視頻數(shù)據進行重組。H.261解碼過程是上述過程的逆過程。此處的壓縮域四畫面合成算法就是在圖像層進行解碼和編碼處理的一種合成算法。為了說明算法實現(xiàn)原理,假設MCU設備同時與4個終端連接,并分別從終端接收H.261QCIF視頻數(shù)據,MCU對4路數(shù)據進行壓縮域合成處理,合并成1路H.261CIF格式視頻數(shù)據,并將合并后的視頻數(shù)據分別發(fā)送給4個終端,每個終端都只接收并解碼1路H.261CIF格式的視頻數(shù)據流,但能同時顯示4個終端的畫面。其合成系統(tǒng)結構圖如圖9－21所示。圖9－21壓縮域內4畫面合成系統(tǒng)的結構

4畫面合成需要完成三個方面的操作:

(1)處理圖像幀頭的時域參考量TR。由以上對H.261數(shù)據結構的介紹可知,TR為5bit,可取32個值,其取值公式為

TR=(Ns+Nd+1)mod32

式中:Ns為已經發(fā)送的圖像數(shù);Nd為從上次發(fā)送的圖像之后所丟掉的圖像數(shù)。時域參考量用來平滑視頻的播放,讓人的視覺流暢,是保證視頻質量的重要方法。在合成圖像中,時域參考量TR可以按照下列方法取值:

(2)處理圖像層中幀頭的各個字段值。圖像合成之后只有一個圖像層幀頭,因此需要對4組源圖像層幀頭進行處理。當?shù)玫?路4層圖像復用數(shù)據結構之后,只保留第1路的圖像層幀頭,丟掉其他3路的圖像層幀頭。其中時域參考量TR按上述方法填充;類型信息域PTYPE的第4位由原來的“0”改為“1”,亦即由QCIF圖像標識修改為CIF圖像標識。

(3)處理塊組層塊組頭。合成過程需要把4組3個QCIF塊組合并成一組12個CIF塊組。MCU接收到4路H.261QCIF數(shù)據后,對4路視頻數(shù)據均進行找?guī)^和找塊組頭操作,分別得到4路數(shù)據的幀頭和3個塊組數(shù)據。讀取幀頭信息的PTYPE字段,要保證視頻數(shù)據信源格式為QCIF,并且其塊組號分別是1、3、5。進行合并時,第1路QCIF數(shù)據的塊組號保持不變;將第2路QCIF數(shù)據的塊組號分別由1、3、5修改成2、4、6;將第3路QCIF數(shù)據的塊組號分別由1、3、5修改成7、9、11;將第4路QCIF數(shù)據的塊組號分別由1、3、5修改成8、10、12。合并后形成1路視頻數(shù)據,要按照修改后的塊組號進行順序存儲。4路H.261QCIF的視頻數(shù)據在對塊組號修改和塊組排序后,形成了1路H.261CIF視頻數(shù)據。

2.具體的合成算法

算法設計中幾個關鍵問題在于:如何匹配幀頭(PSC)和塊組頭(GSC);如何組合各路數(shù)據;如何協(xié)調各路視頻之間的同步。

首先要尋找?guī)^和塊組頭,其過程需要對位進行操作。由H.261數(shù)據結構的知識可知,PSC(幀起始碼)為00000000000000010000,而GSC(塊組起始碼)為0000000000000001,則PSC的前16位和GSC均為0000000000000001。在找?guī)^和塊組頭的過程中,首先對幀頭和塊組頭不區(qū)分對待,按位進行操作,若出現(xiàn)連續(xù)15個或15個以上連0,并隨后出現(xiàn)1時,則認為是找到了幀頭或塊組頭。緊接其后的4位若為0000,則為PSC,找到幀頭;若其值介于0001(1)和1100(12)之間,則是GSC,找到塊組頭;若為其他值,則出錯。通過對接收到的H.261視頻流進行循環(huán)查找,可得到各路視頻的每一個塊組數(shù)據。找到4路H.261QCIF的各個塊組后,則需要對4路數(shù)據的塊組進行排列組合,數(shù)據組合的方式在上面已經做了較為詳細的介紹。在具體組合的實現(xiàn)過程中,利用一個類CMergeH.261來完成合并,該類的主要成員變量和成員函數(shù)及其描述如表9－3所示。表9－3類CMergeH261的主要成員變量和成員函數(shù)圖9－22壓縮域4畫面合成算法的流程由于4路視頻來自不同的視頻源,因而會出現(xiàn)視頻速率和幀速率不匹配的情況,即出現(xiàn)有的視頻幀速率快,而有的幀速率慢的情況。為了保證4路數(shù)據之間的同步,需要采用一些有效的手段和方法。首先,在進行H.323呼叫協(xié)商的時候,保證4個終端發(fā)送的視頻數(shù)據帶寬和幀速率與標稱值相同。然后,在MCU端利用RTP包包頭信息分別計算出4路數(shù)據的實際幀速率,其計算方法如下:根據RTP包頭信息的M標志位判斷RTP包是否是一幀結束,若是,則記錄下該RTP包到達的時間,即該幀到達的時間。每接收到25幀時,比較前后時間差,可實時計算出25幀所需要的實際時間T,將25除以T,則得到當前的實際幀速率。一般來講,實際幀速率和其標稱值會有一定的誤差,此時需要根據標稱值對實際幀速率進行調整。對照標稱值,使幀速率快的視頻數(shù)據接收線程進行等待,直到與標稱值相同;對幀速率慢的視頻數(shù)據進行空數(shù)據填充,使達到與標稱值相同。采用上述方式,基本可以保證各路視頻數(shù)據之間的同步。

壓縮域合成算法在實際項目應用中,效果較為理想。相對于傳統(tǒng)的模擬多畫面合成技術來說,它無需對視頻數(shù)據進行編解碼,因此時延小,硬件成本低。在合并的過程僅僅對數(shù)據進行重新組合,不存在數(shù)據丟失現(xiàn)象,保真率達到100%。9.6.2像素域合成

以上討論的壓縮域合成算法,執(zhí)行效率高,實際效果理想。但是,它僅僅適用于4路H.261QCIF到1路H.261CIF的4畫面合成,因此,它的適用范圍窄。針對這種情況,本節(jié)討論像素域合成的多畫面合成方法,理論上它適用于任何視頻格式數(shù)據的多畫面合成。因為只要能夠將視頻編碼數(shù)據解碼成YUV或者RGB這樣像素點數(shù)據,即可利用此像素域合成算法。本節(jié)對算法的討論,主要是針對YUV數(shù)據進行操作的,但同樣適用于對RGB數(shù)據的處理。但一般都會采用對YUV數(shù)據進行操作,因為這樣避免了從YUV數(shù)據到RGB數(shù)據的矩陣轉換,有效地節(jié)省了系統(tǒng)資源和運行時間。像素域合成方法可分為兩大類:無損