第8章視頻會議通信控制技術

8.1會議終端通信協議及過程8.2視頻數據實時傳輸控制技術8.3網守控制的會議終端通信過程8.4網守的設計與實現 8.1會議終端通信協議及過程

8.1.1終端間通信原理

兩個H.323會議終端間一次完整的通信過程包括5個階段:呼叫建立過程、能力交換和主從確定過程、媒體信道建立過程、媒體流傳輸過程和呼叫中止過程。

呼叫建立過程可以不經過網守,直接在兩個終端間進行。在多點視頻會議中,由于會議終端數量較多且能力不同,因而會議終端管理及呼叫建立過程一般通過網守進行。呼叫建立過程使用H.225.0呼叫信令協議。能力交換和主從確定過程使用H.245協議。能力交換過程用來保證傳輸的媒體信號是能夠被接收端接收的。這要求每一個終端的接收和解碼能力必須被對方終端知道。終端不需具備所有的能力,對于不能處理的要求可以不予理睬。終端通過發送它的能力集合使對方知道自己的接收和解碼能力,接收方可以從中選擇某種方式。主從確定過程通過主從終端判斷來保證當一個呼叫中出現兩個終端同時初始化一個相同事件時不會產生沖突。終端的狀態一旦確定,在整個呼叫過程期間都不會改變。在能力交換過程完成后,主叫和被叫之間就可以根據對方的接收能力發起媒體信道建立過程,包括單向信道打開過程和雙向信道打開過程。媒體信道建立過程主要涉及RTP/RTCP協議。

媒體流傳輸過程主要是指在媒體信道上傳輸媒體信息流(包括音頻、視頻和數據流)。媒體流是直接在終端與終端之間或終端與MCU之間傳輸的,不涉及網守,但在H.323系統跨越代理通信時需要重定向媒體流。在通信過程中,網守可以利用IRQ消息查詢終端的狀態,也可以在RCF消息或ACF消息中要求終端定期發送IRR消息以便網守查詢終端狀態。在通信過程中還可以利用H.245控制消息實現改變信道結構、能力、接收模式等功能。例如,可以通過BRQ消息改變邏輯信道的帶寬。8.1.2

H.225.0呼叫信令協議及呼叫建立過程

1.H.225.0呼叫信令協議

H.225.0呼叫信令協議是以ISDN的Q.931/Q.932為基礎制訂的,其中尤以Q.931最為重要。Q.931是ISDN用戶-網絡接口(UNI)的第三層信令協議,用于基本呼叫控制。它和網絡-節點接口(NNI)的7號信令ISDN用戶部分(ISUP)配合,完成從主叫用戶到被叫用戶的端到端連接的建立、維護和釋放。對于補充業務,ISDNUNI制訂了通用功能協議Q.932,規定了各種補充業務的一般控制機制及相應的消息和信息單元。與之對應,H.323系統也采用同樣的體系來處理補充業務。呼叫信令由多個信令消息組成,而消息中又包含了多個不同的信息單元。H.225.0呼叫信令消息和信息單元取自于Q.931和Q.932消息和信息單元。H.225.0與它們的主要差別是H.225.0對各個消息中用戶－用戶信息單元的內容根據H.323系統作了新的增補定義,另外對某些信息單元的個別字段的編碼和含義作了一些擴充和界定。

由于H.323呼叫不承擔連接控制的任務,許多Q.931和Q.932中的消息在H.225.0中已經失去意義,因此H.225.0消息是對Q.931和Q.932消息的一種精簡。H.225.0呼叫信令消息如表8－1所示。表8－1

H.225.0呼叫信令消息

H.225.0消息可以分為四大類:呼叫建立消息、呼叫清除消息、其他消息和Q.932消息。其中前三大類消息繼承于Q.931消息。對于每個消息的含義和用途可參閱相關資料。H.225.0呼叫信令消息的一般結構如圖8－1所示。圖8－1

H.225.0呼叫信令消息的一般結構公共的消息頭部由三個部分組成:協議標志符、呼叫引用值(CallReferenceValue,CRV)和消息類型。其中協議標志符固定為80H,一個字節長度,表示是Q.931協議。CRV長度為2個字節,其值由主叫方產生并且保證惟一性,用于標識呼叫,僅在呼叫段上局部有效。例如,呼叫信令采用網守選路方式傳送,則主叫終端-網守和網守-被叫終端這兩個信令段的CRV值一般是不同的。若采用直接呼叫方式,則主叫終端和被叫終端的CRV值相同。為了予以區分，增設一個CRV標志位F，規定主叫側發出的信令消息恒置F=0，被叫側發出的信令消息恒置F=1。消息類型由Q.931統一編碼,在H.225.0中也規定了一些擴展值。除了上述固定的消息頭部外,每一個消息中包含了若干個信息單元(InformationElement,IE),其中某些是必備的,某些是任選的。H.225.0的信息單元共有16個,其中從Q.931繼承了14個,從Q.932繼承了2個。各信息單元名稱與相應的功能如表8－2所示。表8－2

H.225.0信息單元及其功能

2.呼叫建立過程

呼叫建立過程包括呼叫控制和連接控制兩部分。

(1)呼叫控制:執行呼叫信令協議(屬于H.225.0),控制信道為呼叫信令信道(可靠信道)。呼叫建立成功后,在終端之間建立起H.245控制信道。

(2)連接控制:執行H.245控制協議,控制信道為媒體控制信道,簡稱控制信道(可靠信道)。在終端之間建立起具有一定帶寬的一個或多個邏輯信道,如音頻邏輯信道、視頻邏輯信道。實時通信的邏輯信道均為不可靠信道,采用UDP連接。圖8－2直接傳遞信令消息的呼叫建立過程兩個會議終端直接傳遞信令消息的呼叫建立過程如圖8－2所示。

終端1(主叫終端)首先根據終端2的IP地址和呼叫信令信道公認的TCP端口(終端默認為1720)向終端2發起呼叫,建立其至終端2的TCP連接,即建立起可靠的呼叫信令信道。

終端1在此呼叫信令信道上發送Setup消息。

終端2回送CallProceeding消息,指示呼叫已經抵達,正在處理之中。

終端2向終端1回送Alerting消息,等待用戶應答。用戶應答后,終端2向終端1發送Connect消息,消息中帶有終端2的H.245控制信道TCP端口號。至此,呼叫建立完成。

之后,終端1會根據終端2發送的H.245控制信道TCP端口號,與終端2建立H.245通道。至此,呼叫信令信道建立完畢。8.1.3

H.245媒體控制協議及過程

1.H.245媒體控制協議

H.245是通用的多媒體通信控制協議,主要針對會議通信設計。H.323系統采用H.245協議作為媒體控制協議,用于控制通信信道的建立、維護和釋放。在H.245中定義了兩類信道:控制信道和通信信道。其中,控制信道也稱為H.245信道,位于H.323實體上的兩個H.245對等信令實體通過該信道傳送H.245消息,以控制媒體信道的建立和釋放。通信信道也稱為邏輯信道,在其上傳送用戶通信信息。一般來說,兩個實體間可有多條邏輯信道,可分別傳送音頻、視頻、數據。在呼叫建立過程中,被叫終端向主叫終端回送Connect消息,傳遞被叫終端H.245控制信道TCP端口號。主叫終端通過該端口與被叫終端建立H.245控制信道,每個呼叫有且只有一個H.245控制信道,它伴隨著呼叫信令信道的存在而存在,直到通信結束后才釋放。在控制信道中,終端通過互相發送消息進行能力協商(CapabilityExchange),確定雙方的接收能力和發送能力,即交換雙方所能支持的編解碼器類型信息,然后根據協商的結果,分別打開相應的邏輯信道,在邏輯信道上傳送相應的音視頻流。結束通信時,由發送方關閉邏輯信道,雙方關閉H.245控制信道和呼叫信令信道。

H.245消息可以分為4種類型:請求、響應、命令和指示。請求和響應消息由協議實體使用,構成協議過程。請求消息要求接收方執行所要求的動作,并立即返回響應。響應消息是對請求消息的回復,可以是證實、拒絕和返回請求的結果。命令消息也要求接收方執行指定的動作,但不要求其回送響應。指示消息通常是終端的狀態信息,它只傳送信息,不要求接收方執行動作,也不要求其回復響應。

H.245幾個主要協議過程中使用的H.245消息如表8－3所示。其中每個過程都有相應的請求消息。例如,能力集協商過程中,終端能力集請求消息,對應的有終端能力集證實(Acknowledge)和拒絕(Reject)兩種響應消息,而Release消息是發出請求后超時未收到任何響應時,請求方發出的撤除該請求的指示消息。打開邏輯信道確認消息用于雙向信道建立,因為這是一個三次握手過程。維護環路命令關閉消息是通知對方環路測試結束的命令消息。表8－3

H.245協議過程中所用的消息

H.245基本命令消息見表8－4。其中流量控制消息的功能是限制一個邏輯信道的比特率或者所有邏輯信道總的比特率。發送終端能力集命令的作用是在發生中斷或其他不確定問題的情況下,請求遠端終端發送能力集消息告知其發送和接收能力。加密命令用來交換加密能力,命令遠端在信道上發送初始矢量。結束會話命令表示結束,終止H.245消息傳輸,通常是呼叫控制過程中的最后一個消息。表8－4

H.245基本命令消息表8－5

H.245基本指示消息

2.H.245主要協議過程

H.245控制信道建立以后,需要進行能力協商以確定應該打開哪些類型的邏輯信道,根據情況的不同,需要采用不同的協議過程。以下主要介紹H.245的幾個最重要的協議過程:能力協商(交換)過程、主從確定過程和邏輯信道信令過程。

1)能力協商過程

能力協商過程是H.245控制信道建立后首先要執行的一個過程,它使通信雙方了解對方接收和發送信號的能力。接收能力限定了對端發送信號的模式,發送能力給定了對端請求信號希望模式的協商范圍。描述終端接收和發送能力的終端能力集消息不但給出終端可支持的各種媒體信號的操作模式,而且還給出了終端同時處理多種媒體信號的可能的組合操作模式。圖8－3給出了終端能力集消息的數據結構。其中,序號由證實消息返回,發送終端據此可以確定與該證實消息匹配的終端能力集消息。協議標識指明H.245版本號。復用能力主要指示該終端的多點通信能力,用于會議通信。能力表(CapabilityTable)列出了終端所允許的操作模式,如G.711音頻、G.722音頻、H.261CIF視頻等,每種模式對應能力表中的一個表項,賦予相應的序號,稱之為能力序號。圖8－3終端能力集消息的數據結構一個能力描述語集(CapabilityDescriptorSet)由若干個能力描述語(CapabilityDescriptor)組成,每個能力描述語由一個能力描述語序號(CapabilityDescriptorNumber)和一個同時能力(SimultaneousCapabilities)組成。同時能力由若干個可選能力集(AlternativeCapabilitySet)組成,可選能力集由若干個能力序號(CapabilityNumber)組成。對于可選能力集,終端可以按照其中的任何一種方式工作,如可選能力集{G.711,G.723,G.728}表示終端可以采用其中任何一種音頻編碼方式,但不同時使用多種工作模式。而對于同時能力,終端可以同時使用一組能力進行工作。例如,同時能力由可選能力集{H.261,H.263}和{G.711,G.723,G.728}組成,則表示終端可同時工作于一個視頻信道和一個音頻信道,視頻信道有H.261和H.263兩種可選模式,音頻信道有G.711、G.723和G.728三種可選操作模式。若干個同時能力構成了能力描述語集,使得終端可能選用多種組合方式工作。在不同的組合方式下,各個信道允許的操作模式可能不一樣,以滿足不同的需求。例如,終端的能力描述語集中,一個同時能力為上述的{{H.261,H.263},{G.711,G.723,G.728}},另一個同時能力為{{H.262},{G.711}},它表示該終端的視頻信道也可以采用H.262編解碼,但此時音頻只能采用G.711。

2)主從確定過程

主從確定過程確定哪個終端是主終端,哪個是從終端,避免信令過程中的沖突現象。其主要應用是會議通信中的MC仲裁。一個會議呼叫中只能有一個MC,如果兩個參會的H.323實體都含有MC,則必須通過一定的規則確定其中一個是主MC。該協議過程也適用于雙向信道建立時的主從終端確定。主從狀態確定后,在整個呼叫中將保持不變。

在執行主從確定過程時,每個終端需生成一個隨機數,稱為狀態確定號(StatusDeterminationNumber),其取值范圍為0～224－1。為了確定主從關系,任一終端可向對方發送一個主從確定消息,該消息中包含兩個參數:狀態確定號和終端類型。終端類型亦為一個整型數,其值按表8－6的規定確定。表8－6用于主從確定過程的H.323終端類型取值對方收到主從確定消息后,執行主從確定計算。確定主從終端的規則是:首先比較兩個終端的終端類型值,大者為主;如果終端類型值相同,再比較兩個終端的狀態確定號,大者為主;如果仍然相同,則判定為不可確定。一般主從終端是可以確定的,此時對方回送確定消息,告知判定結果;如果不可確定,則回送確定拒絕消息,告知理由為數字相同,此時,本地終端重新生成一個狀態確定號,再次啟動主從確定過程。

3)邏輯信道信令過程

能力協商完成后,終端就可根據對方的接收能力發起邏輯信道建立過程。以單向信道為例,其建立過程如圖8－4所示。圖8－4單向邏輯信道建立過程信道打開由發送方啟動,它向接收方發送打開邏輯信道消息,消息中包含前向邏輯信道號和信道參數。其中,信道號必須由發送方賦值,證實消息返回此值,以和請求消息匹配。信道參數包括數據類型、媒體信息是否需要確保傳送、是否執行靜音抑制、目的地終端標記等。

對方接收到打開邏輯信道消息并確認后,回送打開邏輯信道證實消息,消息中包含前向邏輯信道號和前向復用證實參數。至此,兩終端間建立起了前向邏輯信道,開始傳送信號。這里,“前向”指的是打開邏輯信道消息發送方至接收方的方向。雙向信道信令過程和單向信道基本相同,其主要差別在于消息中還包含反向信道參數。因此,一次消息交換同時建立兩個方向的信道。此外,請求方收到對端的證實消息后,還需回發一個確認消息,表示反向信道建立成功,可以開始傳送信號。

通信的雙方都可以發起呼叫釋放,但關閉邏輯信道只能由發送方完成。接收方如果遇到無法解碼等特殊情況,可以向發送方發送關閉邏輯信道請求。

8.2視頻數據實時傳輸控制技術

8.2.1

RTP/RTCP協議結構

兩個終端間呼叫信令信道建立之后,H.245控制信道建立起來,然后通過能力協商,打開相應的H.245邏輯信道,其中傳輸視頻數據的視頻信道就是一種H.245邏輯信道。在視頻會議系統中,如何提高音視頻數據傳輸的實時性和通信的QoS,這是一個技術重點也是一個難點。在H.323視頻會議系統中,采用了IETF提出的RTP(Real－timeTransportProtocol,實時傳輸協議)來保證QoS。

RTP為具有實時特性的音頻視頻通信提供了傳輸服務。它實際上包含兩個協議:RTP本身和RTCP。RTP用以傳送實時數據,提供凈荷類型指示、數據分組序號、數據發送時間戳和數據源標識等。RTCP用于傳送實時信號傳遞的質量參數,提供QoS監測機制,同時還可以傳送會議通信中的參會者信息,為會議通信提供控制機制。本節將分別介紹RTP、RTCP及其頭部結構。

1.RTP

RTP通常運行在UDP之上,二者共同完成傳輸層的功能。UDP提供復用及校驗和服務,也就是通過分配不同的端口來傳送多個RTP流。協議規定,RTP流應使用偶數(2n)端口號,相應的RTCP應使用相鄰的奇數(2n+1)端口號。

RTP分組頭部固定結構如圖8－5所示。其各個字段的含義簡單介紹如下,有關具體解釋和說明可參閱協議規范文獻。圖8－5

RTP分組頭部結構

V:版本號,2比特,用于標識RTP的版本號,其值一般為2。

P:填充指示位,1比特。如果P位置“1”,表示分組結尾含有1個或多個填充字節。兩種情況下需要填充,一種是某些加密算法要求數據塊大小固定;二是在一個低層協議數據包中載有多個RTP分組。

X:擴展指示位,1比特。如果X位置“1”,則固定頭部后還有一個擴展頭部。擴展頭部提供各種應用,傳送和凈荷格式無關的附加的公共信息,建議不要使用。

CC:CSRC計數,4比特,指示固定頭部后部的CSRC標識的個數。

M:標志位(Marker),1比特。標志位的含義一般由應用文檔解釋。例如,其在H.261視頻流的應用中,一般作為幀邊界標志。

PT:凈荷類型(PayloadType),7比特。該字段標識RTP的凈荷類型,值為0標識傳輸G.711u數據;值為8標識傳輸G.711A數據;值為4標識傳輸G.723數據;值為18標識傳輸G.729數據;值為31標識傳輸H.261數據。其值也可以由具體應用定義。一般在會話過程中,RTP源可以改變凈荷類型。序號(SequenceNumber):16比特。每發送一個RTP分組,序號加1。序號可供接收方檢測分組丟失和恢復分組順序。序號的初值應為隨機數,使得數據加密后不易受到攻擊。

時間戳(Timestamp):32比特。時間戳指示的是RTP數據分組第一個字節的取樣時刻。如同序號一樣,時間戳的初始值也是隨機數。如果幾個相鄰的RTP分組是同時產生的,則它們的時間戳值應相同,例如屬于同一幀的數據時間戳相同。

SSRC(SynchronousSource):同步源標識,32比特。SSRC用于標識信號的同步源,其值隨機產生,但要保證同一個RTP會話中任意兩個同步源的SSRC標識都不相同。

CSRC(ContributingSource):分信源標識,32比特。CSRC標識由混合器插入,其值就是組成復合信號的每個分信號的SSRC標識,用于標識各個組成分信號的信源。CSRC的個數由CC字段指定,最多包含15個。采用RTP協議傳送視頻時,用UDP分組傳送,每個數據包并不一定按照先后順序到達,甚至會出現數據包丟失的現象。此時,可以利用序號字段來判斷是否有數據丟失,如有丟失,則需要進行相應的處理。另外,利用序號字段也可以對數據包進行重新排序。根據M標志位字段,可以快速判斷視頻數據包是否到了幀的結尾。根據時間戳字段,可以統計出每幀數據采樣的時間差,從而計算出發送端視頻數據的采樣速率。因此,采用RTP協議能快速得到一些統計信息,以便接收端采取相應的措施,保證數據傳輸的實時性和正確性。

2.RTCP

RTCP的基本思想是采用和數據分組同樣的配送機制向RTP會話中的所有與會者周期性地傳送控制分組,從而提供數據傳送QoS的監測手段,并獲知與會者的身份信息。RTCP主要有4大功能:提供數據傳送質量的反饋信息,這是RTCP最主要和最基本的功能;傳送RTP源傳輸層永久標識,此標識稱為規范名(CanonicalName,CNAME),接收方可根據CNAME跟蹤每個與會者;確定RTCP分組發送速率,一方面保證能及時提供監測信息,另一方面使RTCP分組不會多到影響音視頻信號的傳送;傳送少量會話控制信息,如與會者標識等。

RTCP中定義了如下幾個分組類型:發送者報告(SenderReport,SR)、接收者報告(ReceiverReport,RR)、源描述項(SourceDescription,SDES)、BYE(退出會話)和APP(應用特定功能)。每個RTCP分組由固定頭部和若干個可變長度的數據單元組成。分組長度必定是32比特字的整數倍,且頭部有長度字段,因此多個RTCP分組可以組裝成一個復合RTCP分組,各分組間無需分界指示。

SR是由數據發送者發出的發送和接收統計數據,RR是由非數據發送者發出的接收統計數據。對于復合RTCP分組,第一個RTCP分組必須是SR或RR。即使尚未發送和接收任何數據,也必須發送一個空的RR。

(1)頭部:長度為8個字節。頭部包含以下字段:

·版本號V,2比特。這個字段標識RTP的版本號,其值一般為2。

·填充指示P,1比特,含義同RTP分組頭。

·接收報告計數RC,5比特,指示分組中包含的接收報告塊個數,可以為0。

·凈荷類型PT,8比特。SR的凈荷類型值為200,RR的凈荷類型值為201。

·長度,16比特,其值加1表示RTCP分組的長度。長度單位為32比特字,包括頭部和填充字節。

·發送方SSRC,32比特,為發送該SR分組站點的同步源標識。

(2)發送方信息:長度為20字節,是SR分組的必備部分。發送方信息包含以下字段:

·NTP(NetworkTimeProtocol)時間戳,64比特,指出該SR分組發出的絕對時間,它表示相對于1990.1.1零點的時間差值,單位為秒。前32比特高位字為整數部分,后32比特低位字為小數部分。根據此值和由其他接收端回送的NTP時間戳,就能測出至這些接收端的往返傳播時延。

·RTP時間戳,32比特,它所指示的時間與NTP時間戳指示的時間相同,但時間單位和初始值與數據分組中的RTP時間戳相同。此值可用于NTP同步的不同信源之間的同步。

·發送方RTP分組計數值,32比特。其值為發送者自開始發送以來直至本SR分組生成為止發送的RTP數據分組總數。

·發送方RTP字節計數值,32比特。其值為發送者自開始發送以來直至本SR分組生成時為止發送的RTP數據分組的凈荷字節數(不含頭部和填充字節),該值可用來估算平均凈荷數據速率。

(3)接收報告塊:每個報告塊提供來自指定同步源的接收數據的統計信息。接收報告塊包含以下字段:

·SSRC－n,32比特,本報告塊信息所屬信源的SSRC標識。

·丟失率,8比特,自上次SR發送以來,由SSRC－n發來的RTP數據分組的丟失比率。

·累計丟失分組數,24比特,指示從開始接收以來丟失的來自SSRC－n的RTP數據分組總數。

·擴展的已接收最高序號,32比特,該值減去收到的初始序號就是期望收到的分組數。

·到達時延抖動,32比特,是一對分組接收端接收間隔和發送端發送間隔之差值的平均偏差。

·最末SR時間戳,32比特,為最近收到的來自SSRC－n的SR分組中NTP時間戳的中間32比特。

·最末SR后的時延,32比特,為收到最近一個來自SSRC－n的SR分組至發送本接收報告塊的時延,單位為1/65535秒。

2)QoS性能監測

SR和RR中有許多有用的信息可供信號發送者、接收者和第三方監測QoS性能和診斷網絡問題,并及時調整發送模式。這些信息可分為三類:累計信息、即時信息和時間信息。通過計算兩個接收報告累計信息之差可以監測長期性能指標;由即時信息可以測量短期性能;時間信息可以用來計算比特率指標。例如,兩個接收報告的累計丟失分組數之差給出了在這段時間中的丟失分組數;擴展最高序號之差為這段時間內的期望接收分組數;二者之比為這段時間內的分組丟失率。丟失分組數除以兩個報告的NTP時間戳之差為每秒分組丟失率。期望接收分組數減去丟失分組數即為這段時間內收到的分組數。由期望接收分組數還可以判斷丟失統計指標的可信度。由于上述測量都是基于兩個接收報告之差的,因此即使曾發生報告丟失也不會影響測量結果。第三方即使沒有接收實際音視頻數據,通過收到的發送者信息也可計算出這段時間內的平均凈荷數據率和平均分組發送率,兩者之比即給出平均凈荷大小。假定分組丟失率和分組大小無關,則由某個接收站接收分組數乘以平均凈荷大小就得出該接收站的吞吐量。

H.323系統利用RTCP的SR和RR監測QoS。SR主要用于多RTP流,如音頻和視頻流的同步。與流同步的相關字段是RTP時間戳和NTP時間戳。RR用于監測QoS指標,包括長時間指標和短時間指標。如果分組丟失率高于設定值,就應降低媒體速率。如果接收報告間隔超過設定值,則根據RR分組中的丟失率判斷是否網絡擁塞。若是,應降低媒體速率或者進行其他相關的處理,如降低圖像幀速率、關閉不重要的媒體等。需要注意的是,RTP和RTCP為音頻、視頻等實時數據提供端到端的傳遞服務,可以向接收終端傳送實時信號必需的定時和順序信息,并向收發雙方和網絡運營者提供QoS監測手段。但是,RTP本身并不提供任何保證QoS的機制,要確保通信的實時性還需要IP網絡本身具有這方面的增強能力。8.2.2

H.261視頻數據的RTP封裝

1.RTP封裝原理

針對具體的音視頻標準的RTP封裝,IETF制訂了相應的凈荷格式規范。現以H.261視頻格式為例,分析如何對視頻進行RTP封裝。經過RTP封裝后的H.261數據分組是一個如圖8－7所示的三層結構。圖8－7

RTP數據分組圖8－8

H.261頭部結構

H.261頭部結構如圖8－8所示,長度為4個字節,32位。每個字段含義如下:

·SBIT(StartbitPosition,開始位位置),3比特,H.261數據中第一個字節需要被忽略的位數,從第一位開始計算。

·EBIT(EndbitPosition,結束位位置),3比特,H.261數據中最后一個字節需要被忽略的位數,從最后一位開始計算。

·I為幀內編碼標志,1比特。若數據流僅僅只有幀內編碼塊數據,則置“1”,否則置“0”。

·V為運動矢量標志,1比特。如果數據流使用了運動矢量,則置“1”,否則置“0”。

·GOBN為塊組號,4比特,分組中開始數據所在的塊組號。若分組以塊組頭開始,則置“0”。

·MBAP為宏塊地址預測,5比特。

·QUANT為量化因子,5比特。若分組數據以塊組頭開始,最后5個字段值均置0。

·HMVD為水平運動矢量,5比特。若分組數據以塊組頭開始,最后5個字段值均置0。

·VMVD為垂直運動矢量,5比特。若分組數據以塊組頭開始,最后5個字段值均置0。如果每幀H.261數據都可以封裝在一個RTP分組中進行傳輸,則RTP封裝問題將會很簡單,可以將一幀數據封裝在一個RTP分組中。然而,由于一個RTP分組最大為2048字節,而通常一幀數據甚至是一個塊組的數據都可能大到無法封裝在一個RTP分組中進行傳輸。因此,需要將一幀數據分割成多個較小的數據包,再封裝在RTP分組中進行傳輸。在國際標準中規定將宏塊作為RTP分組封裝不可分割的最小單位,多個宏塊可以封裝在同一個RTP分組中,并且只要分組大小允許,多個塊組甚至多個幀都可以封裝在一個RTP分組中。因為當數據量很小時,這樣做可以減少數據包發送的頻率。需要注意的是,不可將幀頭和該幀中第一個塊組分開封裝在不同的RTP分組中,也不可將塊組頭和該塊組中第一個宏塊分開封裝在不同的RTP分組中。另外,有時宏塊并不是以整字節開始和結束的,而RTP封裝是以宏塊為最小分割單位的,所以在每個分組的H.261頭中包含了兩個3比特的整數SBIT和EBIT,分別標識封裝后的H.261數據的第一個字節和最后一個字節中未被使用的比特位的個數。這些未被使用的位是用于補充成整字節的填充位。

2.RTP封裝具體實現算法

在一般的H.261視頻數據RTP封裝中,均以宏塊為最小分割單位。但是,在低帶寬情況下,可以以塊組為最小分割單位進行RTP分組,這種方法與以宏塊為最小分割單位的方法原理相同,但是執行效率較高。

對H.261數據流進行RTP封裝可以分為以下三步進行,其算法流程描述如圖8－9所示。圖8－9

H.261視頻數據RTP封裝的算法流程

(1)找幀頭和塊組頭,并進行分組。當編碼器產生H.261數據流后,將該數據流保存到源緩沖區m_srcBuffer中,并將連0計數器m_zeroCounter置0,目標緩沖區m_dstBuffer賦全0。根據H.261幀結構可知,幀起始碼為00000000000000010000,共20位,塊組起始碼和塊組號連接在一起為0000000000000001xxxx,也是20位(其中xxxx的值為塊組號,從1變化到12)。變量m_zeroCounter標識連0的個數,當出現14個以上連0(H.261編碼時保證了純數據不會出現14個以上連0)且最后出現1時,則認為是找到了幀頭或塊組頭,而1后面的4比特位(將其值保存到變量m_gobNum中)決定了是幀頭還是塊組頭。當m_gobNum等于0時,則為幀頭;若m_gobNum大于0且小于等于12時,則為塊組頭,且m_gobNum的值即為塊組號;若m_gobNum值大于12,則認為是出錯。在找幀頭和塊組頭的同時,編碼器不斷從m_srcBuffer中讀出下一比特位的值,賦給臨時變量m_tmpBitValue,經過判斷后將m_tmpBitValue寫入到m_dstBuffer(目標緩沖區)對應的字節中對應的比特位,以完成從源緩沖區到目標緩沖區的數據拷貝。最終,m_dstBuffer中保存的值就是進行找幀頭和塊組頭后的分組數據。

(2)分組后的H.261數據加入H.261頭。此時需要在m_dstBuffer的分組數據前加入4個字節的H.261頭,H.261頭各個字段值由具體的數據內容所決定。由于m_dstBuffer是從第0個字節的第0位開始拷貝的,所以將字段SBIT的值置為000;而字段EBIT的值則由m_dstBuffer的最后一個字節有幾個無效位(填充位)決定,其值在000～111之間變化。由于一般都采用幀內和幀間編碼相結合的方式,所以字段I的值置0;H.261編碼中一般采用運動檢測,字段M置1。采用塊組作為最小分割單位時,GOBN、MBAP、QUANT、HMVD、VMVD幾個字段均置全0。

(3)在加入H.261頭的基礎上加入RTP頭。H.261分組數據加上H.261頭后,需要再添加RTP頭。當找到幀頭時,可以認為是上一幀數據的結束,則將m_markFlag(幀結束標志)置為1(修改RTP頭的Mark標志位的值為1),再將加入H.261頭的m_dstBuffer加入相應的RTP頭。當找到塊組1時,由于不能將幀頭和塊組1分開,所以在此處不作處理,繼續找塊組2的起始碼。當找到塊組2到12時,將m_markFlag(幀結束標識)置為0(修改RTP頭的Mark標志位的值為0),再將加入H.261頭的m_dstBuffer加入相應的RTP頭。最后將加上H.261頭和RTP頭的H.261分組數據從視頻邏輯信道中發送出去,在接收端按照與上述相反的過程去掉RTP頭和H.261頭即可得到視頻數據。至此,完成視頻會議系統中視頻數據的實時傳輸。

在低帶寬情況下,以塊組為最小分割單位時能極大提高程序運行的效率;當帶寬較大時,需要以宏塊為最小分割單位,以此來保證傳輸的圖像質量。當將塊組作為最小分割單位時,若視頻編碼率小于384kb/s,則圖像較為理想,基本不出現馬賽克現象。當視頻編解碼速率大于768kb/s時,圖像會出現比較嚴重的馬賽克現象(因為處理時將大于2048字節的塊組丟棄)。當視頻編碼率速率較高時,每個塊組數據量很大,會超過2048字節,此時不能將一個塊組數據封裝在一個RTP包中,需要對塊組進行拆分,將其分成多個宏塊進行RTP封裝。

8.3網守控制的會議終端通信過程

由網守控制的H.323終端之間建立通信一般要經過以下三個控制過程。

(1)呼叫接納控制:執行RAS協議(屬于H.225.0),控制信道為RAS信道(不可靠信道)。網守同意接納后在終端和網守之間建立起呼叫信令信道,進入呼叫建立。

(2)呼叫控制:執行呼叫信令協議(屬于H.225.0),控制信道為呼叫信令信道(可靠信道)。呼叫建立成功后,在終端之間建立起H.245控制信道。

(3)連接控制:執行H.245控制協議,控制信道為媒體控制信道,簡稱控制信道(可靠信道)。在終端之間建立起具有一定帶寬的一個或多個邏輯信道,如音頻邏輯信道、視頻邏輯信道。實時通信的邏輯信道均為不可靠信道,采用UDP連接。8.3.1網守的功能

在H.323標準中,網守(GateKeeper,有時又稱網閘)提供對端點和呼叫的管理功能,它是一個任選部件,但是對于公用網上實際運行的視頻會議系統來說,網守是一個不可缺少的重要組件。在邏輯上,網守是一個獨立于端點的功能單元,然而在物理實現時,它可以裝備在終端、MCU或網關中。網守相當于H.323網絡中的虛擬交換中心,其功能是向H.323節點提供呼叫控制服務。當系統中存在網守時,它必須提供以下基本功能:

(1)地址翻譯。根據端點在網守注冊時建立的翻譯數據庫表,將被叫終端或網關的別名地址翻譯為傳輸層地址。網守運行期間,翻譯數據庫表不斷地根據注冊信息更新。別名可以是一些便于記憶的名字,比如昵稱或電子郵件地址等,但更常用的別名是E.164地址(電話號碼)。

(2)呼叫接入控制。當端點發起呼叫時,首先給網守發送接入請求消息(ARQ)。網守根據用戶的權限和此時的可用網絡帶寬等條件判定是否允許該次呼叫請求,相應地回送接入證實(ACF)或接入拒絕(ARJ)消息。

(3)帶寬管理。網守支持BRQ/BRJ/BCF消息,網守根據終端類型和網絡帶寬利用率對域中帶寬的使用情況進行控制,并且可以根據端點的請求情況和網絡實際運行情況動態地重新分配帶寬。

(4)區域管理。域中所有的設備都要在網守上注冊,網守提供對整個域(包括終端、網關、MCU、MC以及非H.323設備)的管理功能。

(5)呼叫控制。H.323協議規定終端至終端的呼叫信令有兩種傳送方式:一是經由網守轉接的網守轉發呼叫信令方式,雙方不知道對端的地址,有利于保護用戶的隱私權,網守介入呼叫信令過程;另一種是端到端的直接路由呼叫信令,網守只在初始的RAS過程中提供被叫的呼叫信令信道傳輸層地址,其后不再介入呼叫信令過程。

(6)呼叫管理。例如,網守可以保存一份正在進行的H.323呼叫清單,據此來判定被叫終端是否忙,并向帶寬管理模塊提供帶寬使用信息。

(7)網絡管理。網守可以向計費中心提供計費基礎數據,向管理中心提供話務統計基礎數據。

(8)其他功能,如終端帶寬預留、目錄服務、信息庫管理等。8.3.2網守的層次結構

公用視頻會議系統采用兩級體系結構,即頂級網守和一級網守。在業務量大的地區可根據需要增加二級網守,形成三級體系結構。公用視頻會議系統網守的體系結構如圖8－10所示。圖8－10公用視頻會議系統網守體系結構頂級網守云可以包含多個頂級網守,頂級網守之間的連接、一級網守與頂級網守之間的連接以及不同運營者之間的連接由各運營者根據各自的情況自行確定其方式。當運營者網絡規模不是很大時,頂級網守的功能可由其中一個一級網守完成。

(1)頂級網守。頂級網守負責管理屬于該運營者的一級網守,主要負責一級網守之間的地址解析、不同運營者視頻會議網之間的互通和地址交換;也負責國際業務的管理,即國際呼叫的建立和拆除。

(2)一級網守。一級網守主要負責該一級網守所管轄的全部二級網守以及IP電話終端代理間的地址解析工作。在兩級網的情況下,二級網守的功能全部歸入一級網守。

(3)二級網守。二級網守主要負責所屬區域內用戶的地址解析和認證,防止非法用戶的接入和非法網關的登記;負責向所屬網關提供路由信息,包括被叫網關的端口信息等。

(4)網守之間的互通。網守之間的通信完成不同區域之間的呼叫建立。頂級網守與一級網守之間,或一級網守與二級網守之間的互通采用RAS協議,主要傳送用戶地址解析信息。

(5)網守與網關之間的互通。網守與網關之間使用RAS協議進行通信,RAS信令采用H.225.0消息在網守與端點之間完成注冊、接入控制、帶寬轉換、狀態信息傳送和切斷等操作。RAS信令信道與呼叫信令信道和H.245呼叫控制信道無關。RAS信令信道為非可靠信道,使用UDP方式傳送信令。8.3.3網守的RAS協議及過程

1.RAS協議

RAS協議是H.225.0協議的一部分,故又稱H.225.0RAS協議。RAS協議為網守專用,故又稱網守RAS協議。

RAS協議用于端點和網守或網守與網守之間,主要實現呼叫的設備管理、地址解析、計費和認證信息的傳遞。具體的RAS消息如表8－7所示。表8－7

RAS消息表8－7

RAS消息

RAS協議的管理功能主要包括設備的管理、呼叫管理和資源管理三部分。

設備管理分為搜索、登錄和注銷三個流程。搜索有動態搜索和靜態配置兩種,靜態配置無需進行設備發現申請,直接通過設備間事先的手工配置進行。動態搜索則需要設備進行動態的發現流程,即請求上級設備提供可接入的設備的IP地址,同時交換雙方的安全信息,協商加密算法,協商共享密碼。呼叫管理包括接入控制序列、拆線序列和地址解析序列,主要用在網關和網守之間。接入控制序列由網守檢查網關接入呼叫的信息,分為帶卡流程和不帶卡流程兩種;拆線序列實現呼叫的釋放、計費信息的提取和保護;地址解析序列根據被叫信息解析被叫對端網關的地址。

資源管理包括帶寬管理、信息查詢、資源可用性匯報序列。

2.RAS協議過程

RAS信道是不可靠傳輸信道(在IP網絡上使用UDP),用于承載注冊、認證、狀態等RAS消息。RAS信道使用周知端口UDP1719。

1)網守查找

H.323提供一種自動查找網守的方法。終端廣播一條網守請求消息GRQ,接收到GRQ消息的網守向該終端發出網守確認消息GCF;當網守不希望終端向其注冊時就發出網守拒絕消息GRJ,如圖8－11所示。如果一個終端收到多個GCF消息,它可以選擇其中一個網守注冊。圖8－11網守查找

2)終端注冊

注冊是一個終端加入一個域并告知網守其傳輸層地址和別名地址的過程。終端發起呼叫之前必須先向網守注冊。終端向網守發送登記請求消息RRQ,網守返回注冊確認消息RCF或注冊拒絕消息RRJ,如圖8－12所示。圖8－12終端注冊終端可以向網守發送注銷注冊消息URQ以注銷其注冊。網守以注銷注冊確認消息UCF響應。當終端并未在該網守注冊時,網守返回注銷注冊拒絕消息URJ。注銷注冊使終端可以改變其別名地址和傳輸層地址的關聯。網守也可以通過發送URQ消息來注銷終端的注冊,這時終端必須返回UCF消息。此后終端應重新注冊。終端重新注冊時可以向另外一個網守注冊。注銷注冊過程如圖8－13所示。圖8－13注銷注冊過程

3)終端定位

當一個終端或網守知道另一個終端的別名地址并想取得它的聯系信息時,可以發出定位請求消息LRQ。LRQ消息可以發往指定網守的RAS信道,也可以向GRQ消息一樣廣播出去。另一個終端所注冊的網守應發送定位確認消息LCF,該LCF消息包含了該終端或該終端所屬的網守的聯系信息。聯系信息包括與該終端聯系的呼叫信令信道和RAS信道地址。

當網守在其RAS信道上收到LRQ消息,而目標終端未向其注冊時,網守應返回定位拒絕消息LRJ;當網守在其廣播地址上收到LRQ消息,而目標終端未向其注冊時,網守不必做出響應。

4)認證、帶寬改變和脫離

RAS信道也用于傳送認證、帶寬改變、狀態和脫離等消息。這些消息在終端和網守之間提供認證控制和帶寬管理的功能。

認證請求消息ARQ制訂了所需的呼叫帶寬,這是發送和接收的媒體信道除去RTP頭、RTP載荷、網絡載荷以及其他開銷的總的比特率上限。數據和控制信道不包括在此上限中。網守可以在認證確認消息ACF中降低呼叫帶寬。終端應確保其發送和接收的媒體流的總比特率不高于呼叫帶寬。終端或網守可以通過帶寬更改請求消息BRQ來修改呼叫帶寬。8.3.4網守轉發呼叫信令過程

在沒有網守的網絡中,呼叫信令消息在主叫和被叫終端之間直接傳送。主叫終端應知道被叫終端的呼叫信令信道傳輸層地址,以使它們能直接通信。呼叫信令信道可以使用周知端口TCP1720。

在包含網守的網絡中,初始的認證消息在主叫終端和網守之間通過網守的RAS信道交換,網守在ACF消息中指示主叫終端呼叫信令是直接發往被叫終端還是通過網守轉發。

1)呼叫信令信道路由

呼叫信令有兩種傳送方式:一種方式是網守轉發呼叫信令,呼叫信令消息通過網守在兩個終端之間轉發,如圖8－14所示;另一種方式是終端直連呼叫信令,呼叫信令消息在兩個終端之間直接傳送,如圖8－15所示。采用哪種方式由網守決定。圖8－14網守轉發呼叫信令圖8－15終端直連呼叫信令

2)H.245控制信道路由

當采用網守轉發呼叫信令方式時,有兩種方法轉發H.245控制信令:一種是在兩個終端之間直接建立H.245信道,如圖8－16所示;另一種方法是在終端和網守之間建立H.245信道,由網守轉發H.245控制消息,如圖8－17所示。采用哪種方式由網守來選擇。當采用終端直接呼叫信令方式時,H.245控制信道只能在終端之間直接建立。圖8－16終端直接建立H.245控制信道圖8－17網守轉發H.245控制信道8.3.5呼叫中止信令過程

通信的任何一方都可以發起呼叫終止過程,而且網守也可以終止一個呼叫。

1)終端中止呼叫

終端中止呼叫的步驟如下:

(1)關閉所有媒體信道。

(2)在H.245控制信道中發送結束會話消息(EndSessionCommand),通知遠端斷開媒體信道連接,然后停止H.245控制消息的傳輸。

(3)等待接收遠端的結束會話消息,然后關閉H.245控制信道。

(4)若呼叫信令信道是打開的,則發送ReleaseComplete消息并關閉此信道。

(5)如果終端已在網守注冊,則還要向網守發送H.225.0脫離請求消息DRQ,網守以脫離證實消息DCF響應。這是因為網守需要知道帶寬釋放的情況。DRQ/DCF消息在RAS信道上發送。

如果未發出結束會話消息的終端收到了結束會話消息,它將執行上述除第(3)步外的其他4步,無需等待遠端發送結束會話消息。

2)網守中止呼叫

網守可以向一個端點發送DRQ來中止呼叫。此終端應立即執行如下步驟:

(1)關閉所有媒體信道。

(2)在H.245控制信道中發送結束會話消息通知遠端斷開媒體信道連接,然后停止H.245控制消息的傳輸。

(3)等待接收遠端的結束會話消息,然后關閉H.245控制信道。

(4)如果呼叫信令信道是打開的,則發送ReleaseComplete消息并關閉此信道。

(5)網守發送DCF消息。8.3.6快速協議過程

為加快邏輯信道的建立速度和節省資源,在H.323v4版本之中定義了快速連接(FastStart)方式和隧道機制(Tunneling)。

1)快速連接

常規的H.323系統協議過程是首先利用H.225.0信令建立呼叫,然后進行能力交換,最后才打開傳輸媒體流的邏輯信道,其過程比較繁雜。快速連接的特點是將信道建立過程和呼叫建立過程融合在一起,且省略了能力交換過程,從而有效地縮短了連接建立時間。快速連接的過程如下：主叫在Setup消息中置入“快速啟動”(FastStart)數據單元,該單元由若干個“打開邏輯信道”(OLC)數據結構組成,每個OLC描述主叫提議的一個發送或接收媒體信道,包括立即打開此信道并在此信道上傳輸媒體信息所需的所有參數。如果被叫愿意執行快速連接過程,則可在主叫提議的OLC中選取它同意并能夠支持的一個信道構成返回快速啟動數據單元,置入后向消息(CallProceeding、Alerting或Connect等)之中返回給主叫,這樣,凡是選中的信道就認為已經被打開。被叫在給主叫返回了包含返回快速啟動數據單元的后向消息后,就立即可以開始在自己打開的反向信道上發送媒體信息,并準備好在它同意接受的前向信道上接收媒體信息。于此相應,主叫在發出Setup消息后必須準備在它提議的任一個反向信道上接收數據。如果被叫不能執行或者不愿執行快速啟動,則可以拒絕使用此過程。方法是不在Connect及其以前的后向消息中包含任何返回快速啟動數據單元。另外,如果主叫未在Setup消息中發送快速啟動數據單元,被叫也不能自己生成返回快速啟動數據單元。快速連接過程只能由主叫發起。

2)隧道機制

為了節省資源、融合呼叫信令和呼叫控制并縮短呼叫建立時間,H.323v4設計了在H.225.0呼叫信令信道上傳送H.245消息的隧道機制。

隧道機制在呼叫信令消息之中新增一個“H.245隧道”單元,將H.245消息作為字符串復制、封裝在該單元中。一個信令消息可以封裝多個H.245消息,接收方按順序逐個處理。如果在需要傳送H.245消息時沒有信令消息要發送,則用Facility消息封裝傳送。如果主叫要使用隧道機制,則應置Setup消息中的“H.245隧道”單元為真,其后所有信令消息中的該單元都須置真。如果被叫支持并愿意使用隧道機制,也要在響應Setup的所有后向消息中置“H.245隧道”單元為真。一旦某消息置此單元為假,則自此以后隧道機制失效。被叫可以用將此單元置假的方法來拒絕使用隧道機制。隧道機制不能和快速連接方式同時使用,因為隧道傳送的H.245消息可以強制覆蓋快速連接過程。

快速連接方式和隧道機制在H.323系統跨越代理通信的情形之中也要求能夠理解其連接建立過程,并能夠處理相應的消息。 8.4網守的設計與實現

8.4.1網守的系統設計

網守的結構如圖8－18所示。這是一種較為完整的結構,適合大規模系統應用。此處我們只討論能夠為所有連接到LAN上的H.323端點提供基本服務的網守的實現問題。

1)標準性要求

網守設計應符合ITU－T制訂的H.323協議和中國通信行業標準《IP電話網守設備技術要求》的要求,支持H.225.0、H.245、LAN通信協議(IEEE802.3或IEEE802.3u)、TCP/IP等;使用面向對象的編程技術,使系統具有清晰的邏輯層次結構,系統應具有較強的兼容性,易于維護和二次開發;能夠和符合H.323協議的各種設備(網守、終端、MCU、網關)相兼容,并且可以為它們提供相應的服務。

2)功能性要求

網守應實現H.323規定的基本功能和部分可選附加功能,實現相關的所有協議,應具有記錄網守運行日志的能力,能夠提供計費所使用的原始通信紀錄,實現計費功能,或提供運營商所需的計費接口。根據H.323協議中關于網守功能的規定,可將網守劃分為五個功能模塊:

·呼叫控制和管理(CallControlandManagement)

·地址翻譯(AddressTranslation)

·帶寬控制和管理(BandwidthControlandMangement)

·用戶認證、授權和計費(Authentication,Authorization&Account,AAA)

·計費信息的采集(CallDetailRecordConvergence,CDRConvergence)

3)運行環境要求

系統要最大限度地適用于多種平臺環境,兼容性要好,一般要求能夠在Windows9x、Windows2000、WindowsXP、WindowsCE、UNIX等平臺下運行。

4)使用維護要求

要求系統兼容性較強,結構簡單,維護方便,升級容易,功能較強,組網靈活,成本較低。圖8－18網守的結構8.4.2網守的實現方法

網守實現基于面向對象的編程方法,用VC++語言作為開發系統,采用Pwlib和OpenH323兩個SDK動態連接類庫。

軟件實現平臺采用Pwlib和OpenH323兩個動態連接類庫的原因在于:

(1)這兩個庫中封裝了大量的通信類庫以處理信令交互和報文收發,整個平臺的設計遵循開放性原則(MozillaPublicLicense),能夠很好地支持H.323協議。

(2)類庫Pwlib是一個適度大小的類庫,它的發展已有很長一段時間了,其最初的主要目的是形成一種同時可在MicrosoftWindows、UNIX、Linux等多種操作系統平臺上運行的具有通用性的類庫系統,然而它以后的發展卻遠遠超越了最初的目的。I/O的封裝類、多線程類、UNIX后臺郵件收發類、基于NT平臺的服務器類,幾乎所有的互聯網協議類均被逐漸地增加進來,同時遵循了開放性原則,因此Pwlib非常適合作為開發H.323系統的基礎類庫。

(3)類庫OpenH323基于類庫Pwlib之上,也是一種開放源代碼的、可供互操作的、具備完整特性的、適度大小的、面向整個H.323協議棧的基礎類庫,是由澳大利亞一家叫EquivalencePtyLtd的公司發展起來的。在遵循開放性原則的前提下,所有對其感興趣的團體、商業、個人均可免費使用該類庫。

(4)開發人員可以通過互聯網在開放性原則下共同使用這兩個類庫,相互交流,共同開發,共同提高,這使得我們可以最大限度地降低開發成本和減少開發周期,也使得網守與類庫可實現同時升級。

網守的開發系統采用VisualC++6.0,數據庫使用微軟的Access。對于一個電信級會議系統,由于用戶數很多,數據量很大,安全性要求很高,必須使用大型的數據庫來完成各種信息的存取,通常可使用SQLServer、Oracle、Sybase等。使用Microsoft的Access數據庫,主要基于以下考慮:

(1)微軟在Windows和VisualStudios系列中對Access數據庫的支持,讓我們可以方便地操作Access數據庫,并且它的效率也較高。

(2)面向小規模應用所設計的網守,數據量相對還不是很大,Access數據庫完全滿足應用要求。

(3)Access數據庫的整個數據存放在一個文件中,移動和拷貝比較方便。

(4)采用適當的封裝之后,在以后需要升級到大規模的應用數據庫時,可以方便地從訪問Access數據庫向訪問SQLServer或者Oracle數據庫過渡轉變。當然,如果使用ODBC數據庫引擎訪問數據庫,這種轉變將不再是問題。8.4.3網守的實現

1.模塊說明

根據以上對網守功能結構的分析,我們在實現時把網守分解為以下幾個主要的功能模塊:RAS協議過程實現模塊、呼叫信令路由模塊、端點注冊信息鏈表模塊、計費模塊、H.245協議處理模塊等,如圖8－19所示。圖8－19網守主要模塊的信息傳遞結構圖

RAS協議過程實現模塊用來處理RAS協議過程,它包括網守搜尋(采用多播機制完成)、端點登記、呼叫接納、呼叫退出、帶寬管理等過程,并且把相應的端點信息傳送到端點注冊信息鏈表模塊。

呼叫信令路由模塊用來與終端之間進行H.225.0呼叫信令過程,它包括呼叫建立、呼叫清除、Q.932消息處理等過程,并且支持呼叫轉移功能,既可以進行一般的連接過程,又支持快速連接過程。建立呼叫路由之前首先要從端點注冊信息鏈表模塊中取得端點信息,在合法的情況下再去建立呼叫路由,然后再把呼叫信息傳送到當前呼叫信息鏈表模塊中,直至呼叫清除時再次傳送信息給當前呼叫信息鏈表模塊和計費模塊去處理。端點注冊信息鏈表模塊用來儲存注冊終端的詳細信息,包括別名、呼叫信令傳輸層地址、RAS端口地址、終端ID、終端類型、制造廠商代碼等;還提供端點的插入、刪除、更新、查詢、類型判斷、超時處理等大量的用戶接口功能。

當前呼叫信息鏈表模塊用來儲存當前正在進行呼叫和通話的每一對呼叫的詳細信息,包括主叫和被叫ID、呼叫ID、呼叫引用值、分配帶寬、呼叫的發起時間等信息,同樣也包括呼叫的插入、刪除、更新、查詢等大量的用戶接口功能。計費模塊從呼叫信令路由模塊中取得呼叫信息,對每次的呼叫原始計費信息進行詳細記錄。這些信息至少包括呼叫起始時間、終止時間、主被叫E.164別名地址、主被叫IP地址、使用帶寬等信息。

2.網守主程序

一個處于運行狀態中的網守,其各個功能模塊的瞬時運行狀態都是隨機并發的,每個模塊內部又要同時處理若干個端點的請求或連接。因此網守最適合于使用多線程的編程方法來實現。網守在實現時,首先由主程序創建RAS處理線程、呼叫信令處理線程、多播接收處理線程這三個線程來啟動相應的功能處理模塊,然后在各線程內部當每接收一個請求或連接時,該模塊便向系統申請所需的資源,然后在其內部產生一個專門用來處理此次請求或連接的子線程,直至此次請求或連接結束時,該子線程將自動停止運行,釋放所占用的系統資源以備系統重新分配使用。網守的主程序完成的任務主要是生成網守的主控制臺界面窗口,實現網守運行前的初始化過程,搜集所需的各項環境參數,建立終端注冊表(EndpointTable)、當前呼叫信息表(CallDetailTable)等各功能塊運行所必需的信息鏈表,啟動網守各功能模塊的相應線程,以及隨時根據系統管理員發出的控制臺命令對網守當前工作狀態、運行日志進行查詢、關閉或結束網守等動作。圖8－20是網守的主控制臺界面。圖8－20網守的主控制臺界面網守的主控制臺界面主要包括四部分:菜單欄、圖形按鈕、網守所在主機IP地址顯示窗、網守工作信息顯示窗。菜單欄內包含很多命令，用于啟動或關閉網守,查看注冊終端表、當前呼叫信息表、工作日志等。圖形按鈕是最常用的菜單命令的快捷按鈕。網守所在主機IP地址顯示窗是網守啟動后顯示主機IP地址的窗口,該地址供各終端設置時查詢使用。網守工作信息顯示窗用于顯示網守的工作狀態以及各表項參數。

網守主程序的簡要工作流程如圖8－21所示。圖8－21網守主程序簡要工作流程下面是網守主程序中啟動各功能塊的關鍵語句以及簡要說明,它們完成了各數據鏈表的建立和各工作線程的啟動:

//建立注冊終端信息表

MyEnviron.EPTable=newEndpointTable(MyEnviron);

//建立當前呼叫信息表

MyEnviron.CTable=newCallTable(MyEnviron);

//建立RAS日志

MyEnviron.Log=newOpengateLog;

//創建呼叫信令處理線程

CallThread*CThread=newCallThread(MyEnviron);

MyEnviron.MyCallAddr=CThread－>GetMyCallSignallingAddr();

//創建RAS信令處理線程

RasThread*RThread=newRasThread(MyEnviron);

//創建Multicastreceiver線程

MulticastThread*MCThread=newMulticastThread(MyEnviron);

3.RAS消息處理線程

RAS消息處理線程(RasThread)完成的功能實際就是RAS協議過程,它包括網守搜尋、端點登記等過程。RAS協議是端點和網守之間執行的協議,基本上實現管理功能。

網守賦予了一個公認TSAP標識(對于IP網絡來說就是TCP/UDP端口號)作為RAS信道的TSAP標識,對于IP網絡來說就是端口1719。一般的端點在啟動時首先要向網守注冊登記,因此必須事先知道網守的RAS協議的傳輸層地址(網絡層地址+TSAP標識),也稱為RAS地址。圖8－22是RAS消息處理線程的簡要流程。圖8－22

RAS消息處理線程簡要流程流程圖中處理RAS消息是該線程的核心部分,完成了RAS協議的主要功能,包括端點登記、呼叫接納和退出帶寬管理等功能。

1)網守搜索

網守搜索有兩種方式:人工方式和自動方式。自動方式是通過搜尋多播地址發送GRQ消息來實現的。人工方式通過對端點的配置來完成,將其歸屬的網守傳輸層地址預置入端點的配置文件或初始化文件中。

自動方式允許端點和歸屬網守的關系可以隨時間而改變,當原有網守出故障時可以自動切換到替換網守上去,當所屬網守改變后無需在每個終端上修改其配置文件。在自動方式中,端點采用搜尋多播地址發送GRQ消息,詢問“誰是我的網守”。可以有一個或多個網守回送GCF消息,表示“我可以是你的網守”,并在消息中告知其RAS地址。不愿意該端點在其上登記的網守則返回GRJ消息。如果有多個網守回送GCF消息,端點可在其中任選一個作為其歸屬網守。如果超時仍未收到網守的響應,端點可重發GRQ消息,但兩次相鄰GRQ之間的時間間隔不能小于5秒。如果仍未收到響應,則改用人工搜尋。當然如果事先知道網守的IP地址,則可以直接使用人工搜尋。端點發送的GRQ消息包含端點類型、端點自身的RAS地址、希望在其上登記的網守標識等參數。若未含網守標識參數,就表示端點愿意在任何一個網守上登記。網守返回的GCF消息除了包含該網守標識和RAS地址外,還可包含“替換網守”序列參數并指定優先級順序。如果至該網守的請求未予響應或被拒絕