【正文】 如果在有效期內(nèi)還沒(méi)有收到響應(yīng)，則端點(diǎn)就會(huì)再發(fā)出一個(gè)“終端能力設(shè)置釋放”消息，這是一種指示消息，不用給以響應(yīng)。這個(gè)消息中僅含有與最初收到消息中的序號(hào)相匹配的序號(hào)。這個(gè)消息帶有一個(gè)序號(hào)和該端點(diǎn)能夠發(fā)送和接收的音頻、視頻格式類型，對(duì)發(fā)送和接收格式的指示是分開(kāi)進(jìn)行的。由于一個(gè)端點(diǎn)只能處理某一種特定格式的媒體，所以在呼叫前必須知道每個(gè)端點(diǎn)能支持什么類型。① 能力交換過(guò)程在端點(diǎn)之間建立會(huì)話以前，首先要進(jìn)行能力交換。在本系統(tǒng)中，當(dāng)Answer按鈕按下，先使用Find Connection with Lock( )找出連接，然后調(diào)用Answer Call允許接通呼叫，最后用H323 Connection::unLock( )釋放連接。如果調(diào)用Answer Call Denied，呼叫被切斷，連接中斷。當(dāng)監(jiān)聽(tīng)到呼叫請(qǐng)求后，系統(tǒng)自動(dòng)回調(diào)Answer Call Response On Answer Call( )函數(shù)進(jìn)行握手協(xié)商。Token代表了返回連接的索引號(hào)。remoteParty，pstringamp。以便輸出到網(wǎng)絡(luò)接口，同時(shí)從網(wǎng)絡(luò)接口輸入報(bào)文中檢索出接收到控制流。p Monikeramp。pDevEnum)；//創(chuàng)建視頻采集設(shè)備的枚舉器I Enum Moniker*p Class Enum=NULL；PDevEnum→CreateClassEnumerator(CLSID_VideoInputDevieeCategory，amp。pGraph)；//創(chuàng)建采集圖構(gòu)造器CoCreatelnstance(CLSID_CaptureGraphBuilder2，NULL，CLSCTXINPROC，IID_ICaptureGraphBuilder2，(void**)amp。代碼的主要過(guò)程如下：//創(chuàng)建最基本的組件IGraphBuilder*PGraph。④ 通過(guò)調(diào)用Setup window函數(shù)設(shè)定圖像播放的窗口大小和位置。此功能通過(guò)編寫(xiě)一個(gè)Find Devices (IBaseFilter**pF)函數(shù)實(shí)現(xiàn)，該函數(shù)返回一個(gè)IBascFilter指針類指針。在句柄函數(shù)中調(diào)用IMediaEvent::GetEvent方法用以響應(yīng)隊(duì)列中的事件。InCaptureGraphBuilder2接口的作用是在將 Capture Filter加入 Filter Graph之后，連接剩下的Filter。獲得IGraphBuilder接口指針，并把它存儲(chǔ)到pGraph中。和系統(tǒng)設(shè)備沒(méi)關(guān)系的過(guò)濾器(視音頻混合過(guò)濾器、視音頻抓包過(guò)濾器)直接用函數(shù)COCreatelnstance創(chuàng)建。接下來(lái)的任務(wù)是創(chuàng)建上面過(guò)濾器圖表中的過(guò)濾器，并通過(guò)函數(shù)Add Filter把過(guò)濾器加入到過(guò)濾器圖表中。視頻窗口接口的任務(wù)是設(shè)置視頻預(yù)覽窗口的參數(shù)，如窗口的位置、大小等等；在將g_pGraph和g_pCapture。初始化COM庫(kù)是進(jìn)行DirectShow編程所必需的。在視音頻抓包過(guò)濾器后接了一個(gè)渲染過(guò)濾器，這是一個(gè)完整的過(guò)濾器圖表所必需的，雖然它不對(duì)視頻音頻做任何處理。視頻音頻混合過(guò)濾器的任務(wù)是把視頻和音頻組合成一條視音頻交錯(cuò)排放的數(shù)據(jù)流。壓縮的編碼器可以是系統(tǒng)中的設(shè)備也可以是自己實(shí)現(xiàn)的編碼器。視音頻回放過(guò)濾器的任務(wù)是實(shí)時(shí)顯示畫(huà)面和播放聲音。發(fā)送端過(guò)濾器圖表的主要任務(wù)是視音頻的采集并將視音頻數(shù)據(jù)寫(xiě)入U(xiǎn)DP發(fā)送端的緩沖區(qū)，以及本地的視音頻預(yù)覽和回放。許多 DirectShow API都創(chuàng)建為COM對(duì)象的實(shí)例，應(yīng)用程序正是通過(guò)訪問(wèn)這些COM對(duì)象的接口來(lái)實(shí)現(xiàn)用戶所需的各種操作。COM是微軟提出的組件技術(shù)標(biāo)準(zhǔn)，它按照組件化程序設(shè)計(jì)的思想，把復(fù)雜的應(yīng)用程序設(shè)計(jì)成一些小的、功能單一的組件模塊，各組件可用統(tǒng)一的方式進(jìn)行交互。為執(zhí)行特定的任務(wù)，需要把不同的過(guò)濾器通過(guò)輸入針和輸出針連接起來(lái)，這樣，就構(gòu)成了一個(gè)完整的過(guò)濾器圖。一個(gè)過(guò)濾器往下傳遞媒體數(shù)據(jù)到下一個(gè)過(guò)濾器。這里說(shuō)的外部設(shè)備包括文件系統(tǒng)、顯示卡、聲卡、網(wǎng)卡等。把多個(gè)數(shù)據(jù)流組合成一個(gè)數(shù)據(jù)流等。壓縮編碼或解碼。② 變換過(guò)濾器(Transform Filter)變換過(guò)濾器是整個(gè)過(guò)濾器圖(Filter Graph)的核心，負(fù)責(zé)數(shù)據(jù)格式的轉(zhuǎn)換。它從外部設(shè)備獲取原始數(shù)據(jù)并作簡(jiǎn)單處理，再將數(shù)據(jù)往下一級(jí)過(guò)濾器送。事實(shí)上用戶的一個(gè)應(yīng)用程序就是幾個(gè)不同功能的過(guò)濾器合在一起的過(guò)濾器圖(Filter Graph)。過(guò)濾器是DirectShow的最基本的組成元件，由過(guò)濾器圖管理器進(jìn)行管理。應(yīng)用程序通過(guò)過(guò)濾器圖表管理器所提供一組組件對(duì)象模型 (COM)接口來(lái)訪問(wèn)過(guò)濾器圖表。作為高效的多媒體開(kāi)發(fā)系統(tǒng)，DirectShow兼?zhèn)渑c底層的硬件設(shè)備和高層的應(yīng)用程序打交道的能力。因此，DirectShow可以充分發(fā)揮媒體的性能提高運(yùn)行速度，可以簡(jiǎn)化媒體播放、媒體間的格式轉(zhuǎn)換和媒體捕獲等工作。支持多種媒體格式，包括ASF(Advanced System Format)，MPEG(Motion Picture Experts Group)，AVI(AudioVideo Interleaved)，Mp3(MPEG Audio Layer3)和WAV聲音文件；可以從硬件上捕獲媒體數(shù)據(jù)流。DirectShow技術(shù)是建立在DirectDraw和DirectSound組件基礎(chǔ)之上，它通過(guò)DirectDraw對(duì)顯卡進(jìn)行控制以顯示視頻，通過(guò)DirectSound對(duì)聲卡進(jìn)行控制以播放聲音。DirectX是Microsoft公司為游戲和其他高性能多媒體應(yīng)用所提供的一套底層應(yīng)用程序編程接口。在本系統(tǒng)的實(shí)現(xiàn)中，音頻、視頻的采集和傳輸模塊以及控制和通信模塊的實(shí)現(xiàn)是視頻會(huì)議系統(tǒng)最關(guān)鍵的部分，本章對(duì)這幾個(gè)問(wèn)題作詳細(xì)的闡述。 本章小結(jié)本章介紹了一種局域網(wǎng)內(nèi)點(diǎn)對(duì)點(diǎn)的視頻會(huì)議軟件的總體設(shè)計(jì)，實(shí)現(xiàn)了兩個(gè)終端之間的音頻視頻傳輸。如果對(duì)方不愿意接收，則它會(huì)返回一個(gè)“打開(kāi)邏輯信道拒絕”消息，并帶有拒絕原因。發(fā)送一個(gè)“打開(kāi)邏輯信道”請(qǐng)求消息后就可以打開(kāi)一條邏輯信道。由于每個(gè)終端只能處理一定格式的媒體，所以，要通過(guò)能力交換，首先告訴對(duì)方自己初始化發(fā)送呼叫請(qǐng)求能力交換請(qǐng)求主從確定請(qǐng)求打開(kāi)邏輯信道請(qǐng)求初始化接收呼叫請(qǐng)求發(fā)送會(huì)話請(qǐng)求能力交換回應(yīng)主從確定回應(yīng)打開(kāi)邏輯信道回應(yīng)同意會(huì)話客戶端服務(wù)器端類型音頻錄制信令或數(shù)據(jù)據(jù)視頻錄制編碼壓縮壓縮編碼RTP打包創(chuàng)建RTP套接字創(chuàng)建RTP套接字音頻音頻解碼音頻錄制音頻解碼音頻錄制stopstop關(guān)閉邏輯信道結(jié)束編碼壓縮接收接收接收打開(kāi)信令回應(yīng)操作發(fā)送YNNNYYYN發(fā)送其他音頻視頻其他 終端軟件開(kāi)發(fā)流程圖所能處理的媒體類型。兩終端呼叫建立起來(lái)之后。多媒體通信與控制模塊：這個(gè)模塊的主要工作是完成視音頻通信，包括協(xié)調(diào)多媒體信息流的同步工作，保障多媒體信息流的實(shí)時(shí)傳輸。一部分是發(fā)送端視音頻的采集和壓縮；另一部分是接收端視音頻的解壓縮和回放。會(huì)議控制與管理模塊：會(huì)議控制和管理用于建立和控制視頻會(huì)議，包括會(huì)議建立、控制會(huì)議進(jìn)程，并對(duì)系統(tǒng)各項(xiàng)性能參數(shù)進(jìn)行設(shè)置和調(diào)整，提供方便易用的人機(jī)接口。這時(shí)，服務(wù)程序被“驚醒”并且為客戶提供服務(wù)，對(duì)客戶的請(qǐng)求作適當(dāng)?shù)姆从场o(wú)論具體的協(xié)議是對(duì)稱的還是非對(duì)稱的，當(dāng)服務(wù)被提供時(shí)必然存在客戶進(jìn)程和服務(wù)進(jìn)程。在對(duì)稱的協(xié)議中，每一方都有可能扮演主從角色?？蛻魴C(jī)/服務(wù)器模型工作時(shí)要求有一套為客戶機(jī)和服務(wù)器所共識(shí)的管理來(lái)保證服務(wù)所能夠被提供，這一套慣例包含了一套協(xié)議，它必須在通信的兩頭都被實(shí)現(xiàn)。“客戶/服務(wù)器”模式將應(yīng)用系統(tǒng)整體分為兩個(gè)邏輯上分離的部分，一個(gè)“客戶”和“服務(wù)器”，每一部分充當(dāng)不同的角色，完成不同的功能。 視頻會(huì)議系統(tǒng)軟件結(jié)構(gòu)打包麥克風(fēng)攝像頭IP網(wǎng)絡(luò)用戶界面解包同步聽(tīng)筒 視頻回放用戶界面信令，控制消息回復(fù) 系統(tǒng)軟件終端框圖 軟件體系結(jié)構(gòu)設(shè)計(jì)軟件體系結(jié)構(gòu)是軟件在設(shè)計(jì)構(gòu)成上的基本、可供設(shè)計(jì)選擇的形態(tài)和總體結(jié)構(gòu)，定義了軟件的局部和總體計(jì)算部件的構(gòu)成，以及這些部件之間的相互作用關(guān)系。其中計(jì)算機(jī)對(duì)輸入的不同類型的數(shù)據(jù)進(jìn)行不同的處理，如果是音視頻數(shù)據(jù)，采用無(wú)連接的UDP協(xié)議進(jìn)行傳輸；如果是信令和數(shù)據(jù)則采用面向連接的TCP協(xié)議進(jìn)行傳輸，然后經(jīng)網(wǎng)絡(luò)傳輸?shù)接脩鬊。同時(shí)，介紹了視頻會(huì)議系統(tǒng)中的流媒體傳輸，音/視頻編解碼，NAT穿越等關(guān)鍵技術(shù)。 本章小結(jié) 這一章闡述了基于IP網(wǎng)絡(luò)的視頻會(huì)議系統(tǒng)所采用的關(guān)鍵技術(shù)。由于代理處于局域網(wǎng)內(nèi)部，為了使服務(wù)器能穿透NAT將信令轉(zhuǎn)發(fā)到代理，需要在NAT設(shè)備中配置一條靜態(tài)的NAT路由。代理同時(shí)具有注冊(cè)服務(wù)功能和代理功能。隧道透明穿越技術(shù)方案：隧道透明穿越的方案是在要進(jìn)行多媒體業(yè)務(wù)的局域網(wǎng)內(nèi)放置一個(gè)代理，經(jīng)過(guò)NAT設(shè)備與公網(wǎng)上的服務(wù)器建立連接。其優(yōu)點(diǎn)是可以穿越對(duì)稱NAT及可以分配端口號(hào)連續(xù)的RTP/RTCP地址對(duì)。Mid更多的是一種穿越的技術(shù)，而不是一個(gè)完整的方案，但是可以和很多方案一起配合使用[21]。中間箱通方案：此協(xié)議是由IETF的Mid小組提出的幫助復(fù)雜應(yīng)用（如SIP）穿越Middle box（如防火墻/NAT）的一種手段。并為分配給呼叫雙方的地址和端口進(jìn)行綁定，這樣，呼叫雙方的RTP連接地址都是RTP Proxy，由RTP Proxy經(jīng)過(guò)中轉(zhuǎn)，發(fā)至真正的目的地。 NAT穿越的主要技術(shù)為了解決NAT穿越問(wèn)題，當(dāng)前的主要技術(shù)有：應(yīng)用層網(wǎng)關(guān)（ALG, Application Level Gateways）方案，中間箱通信（MIDCOM, Middle Box Communication）方案，SIP代理（SIP Proxy）方案，中繼穿越NATTURN, Traversal Using Relay NAT）方案等。但是并非所有網(wǎng)絡(luò)應(yīng)用程序都使用能與NAT協(xié)同工作的協(xié)議，“NAT穿越”對(duì)于解決由NAT引起的連接問(wèn)題是一種較為全面的解決方案。 NAT穿越技術(shù) NAT技術(shù)與NAT穿越NAT技術(shù)，即在一個(gè)網(wǎng)絡(luò)內(nèi)部的節(jié)點(diǎn)要與外部Internet網(wǎng)絡(luò)進(jìn)行通訊時(shí)，網(wǎng)絡(luò)中的IP包從源地址在到達(dá)目的地址的過(guò)程中，NAT就修改該IP包的源、目的地址（IP）和源、目的端口（Port），通過(guò)這個(gè)修改將其內(nèi)部自定義的IP地址轉(zhuǎn)換為合法的公用IP地址并作好所有的轉(zhuǎn)換記錄；反之，NAT也會(huì)進(jìn)行反向的修改，通過(guò)這兩種可逆操作可實(shí)現(xiàn)內(nèi)部網(wǎng)和外部Internet網(wǎng)的通訊[17]。每個(gè)RTCP包都和RTP數(shù)據(jù)包類似，都以一個(gè)固定的頭部開(kāi)始，后面跟著一個(gè)隨包的類型的不同而不同的結(jié)構(gòu)化元素。參與會(huì)話的每個(gè)成員周期性地發(fā)送RTCP包，各站點(diǎn)可據(jù)此估計(jì)或計(jì)算出參與會(huì)話的人數(shù)，及時(shí)調(diào)節(jié)實(shí)時(shí)控制的信息量，使得控制信息量和媒體業(yè)務(wù)量達(dá)到平衡。RTP數(shù)據(jù)包只能通過(guò)隨機(jī)產(chǎn)生的32bits的標(biāo)志符來(lái)標(biāo)志源，而RTCP的SEDS數(shù)據(jù)包為每一個(gè)對(duì)話成員提供了全局惟一的標(biāo)志符信息，如Email等，可以滿足復(fù)雜應(yīng)用的需要。RTCP的SR包中含有實(shí)際時(shí)間和相應(yīng)的RTP時(shí)間戳，可用于不同媒體間的同步。會(huì)話成員向所有參與會(huì)話活動(dòng)的音頻、視頻源發(fā)送RR包，包中含有所接收的最高包序列號(hào)，丟失的包數(shù)，包間隔抖動(dòng)測(cè)量值以及計(jì)算源端和目的端之間RTT(Round Trip Time,來(lái)回時(shí)間)所需的時(shí)間戳。RTCP可以實(shí)現(xiàn)以下的控制功能[15][16]：QOS監(jiān)控和擁塞控制。RTCP可以為傳送的RTP數(shù)據(jù)的QOS提供反饋，這樣通信中的第三方在收到反饋包時(shí)可以判斷網(wǎng)絡(luò)的狀況。RTP本身并不提供資源預(yù)留，也不保證實(shí)施服務(wù)的QOS（QualityofService），而是依賴于下層服務(wù)來(lái)實(shí)現(xiàn)，如RSVP（Resource Reservation Protocol）[14]。這些服務(wù)包括負(fù)載類型識(shí)別，序列編號(hào)，時(shí)間戳及傳輸監(jiān)控[13]。實(shí)現(xiàn)流式傳輸通常采用實(shí)時(shí)傳輸控制協(xié)議（RTCP）和實(shí)時(shí)傳輸協(xié)議（RTP）。流式傳輸不僅是啟動(dòng)延時(shí)成十倍、百倍地縮短，而且不需要太大的緩存容量。流式傳輸時(shí)，聲音、影像或動(dòng)畫(huà)等時(shí)基（基于時(shí)間連續(xù)的）媒體由音視頻服務(wù)器向用戶計(jì)算機(jī)連續(xù)、實(shí)時(shí)傳送，用戶不必等到整個(gè)文件全部下載完畢，而只需經(jīng)過(guò)幾秒或十?dāng)?shù)秒的啟動(dòng)延時(shí)緩存即可進(jìn)行觀看。流媒體(Steaming Media)是一種新興的網(wǎng)絡(luò)傳輸技術(shù)，在互聯(lián)網(wǎng)上實(shí)時(shí)順序地傳輸和播放枷音頻等多媒體內(nèi)容的連續(xù)時(shí)基數(shù)據(jù)流，流媒體技術(shù)包括流媒體數(shù)據(jù)采集，枷音頻編解碼，存儲(chǔ)，傳輸，播放等領(lǐng)域。所謂流媒體技術(shù)（或稱流式媒體技術(shù)）就是把連續(xù)的影像和聲音信息經(jīng)過(guò)壓縮處理后存放到視頻傳送服務(wù)器上，由視頻傳送服務(wù)器把節(jié)目傳送到網(wǎng)絡(luò)，用戶在客戶端通過(guò)播放器可實(shí)時(shí)觀看節(jié)目。數(shù)字簽名的發(fā)送者發(fā)送的報(bào)文簽名，接收者不能偽造發(fā)送者的報(bào)簽名，接收者不能對(duì)發(fā)送者的報(bào)文進(jìn)行部分篡改，網(wǎng)絡(luò)中的某一用戶不能冒充另一用戶作為發(fā)送者或接收者?；驹硎窃诎l(fā)送端對(duì)要發(fā)送的數(shù)據(jù)加擾，同時(shí)在授權(quán)的接收端(擁有相應(yīng)的解密密鑰)對(duì)接收的數(shù)據(jù)解擾。目前，用于視頻會(huì)議系統(tǒng)的信息安全技術(shù)主要有兩大類:第一類是加解擾技術(shù):該類技術(shù)目的是防止信息被非法盜用，可以用于視音頻數(shù)據(jù)的加密。視頻會(huì)議系統(tǒng)是一個(gè)開(kāi)放的系統(tǒng)，基本上沒(méi)有考慮安全性的問(wèn)題。在視頻會(huì)議中，可以采用RSVP協(xié)議來(lái)確保網(wǎng)絡(luò)中能預(yù)留一定的帶寬。信宿樹(shù)以接收端為根結(jié)點(diǎn)，以發(fā)送端為葉結(jié)點(diǎn)，發(fā)送端與接收端之間的通道作為樹(shù)的分支。RSVP可以滿足大型點(diǎn)到多點(diǎn)通信群的資源預(yù)訂需求。另外，RSVP是一個(gè)面向客戶端協(xié)議，由接收端負(fù)責(zé)資源預(yù)訂，可以滿足點(diǎn)到多點(diǎn)群通信中客戶端異構(gòu)的需求，每個(gè)客戶端可以預(yù)訂不同數(shù)量的資源，接收不同的數(shù)據(jù)流。RSVP建立在IP協(xié)議之上，可以利用IP數(shù)據(jù)報(bào)傳輸RSVP消息。從我們要實(shí)現(xiàn)的視頻會(huì)議系統(tǒng)所使用的網(wǎng)絡(luò)環(huán)境來(lái)說(shuō)，它是一個(gè)服務(wù)質(zhì)量不能保證的通信網(wǎng)，而會(huì)議系統(tǒng)存在實(shí)時(shí)