前面我們分析了一些協(xié)議，以及協(xié)議棧的內(nèi)容。相信大家也都了解了H.323協(xié)議的內(nèi)容了。那么這里我我們就針對這個協(xié)議棧開發(fā)內(nèi)容進(jìn)行一下講解。開發(fā)H.323協(xié)議棧是通信設(shè)計(jì)過程中的一項(xiàng)極其艱巨的任務(wù)，難點(diǎn)主要在于：復(fù)雜的協(xié)議棧開發(fā)需要投入數(shù)年的工程設(shè)計(jì)資源，而且掌握這些復(fù)雜的標(biāo)準(zhǔn)還需要一個知識的積累和學(xué)習(xí)過程，本文將探討開發(fā)H.323協(xié)議棧和VoIP應(yīng)用系統(tǒng)遇到的問題、歧義、困難等。

利用基于原語(primitive)的H.323協(xié)議棧開發(fā)IP承載話音(VoIP)應(yīng)用系統(tǒng)不是一項(xiàng)小任務(wù)，因?yàn)閯?chuàng)建一個魯棒的應(yīng)用系統(tǒng)，需要花很多時間去研究含糊的標(biāo)準(zhǔn)和復(fù)雜的狀態(tài)機(jī)。

本文用例子說明流程的實(shí)現(xiàn)以及原語(primitive)的定義，用以說明如何構(gòu)建一個基于原語接口的應(yīng)用系統(tǒng)和一個基于簡單接口的替代方案。在開發(fā)協(xié)議棧之前，建議瀏覽一下H.323的基本標(biāo)準(zhǔn)。H.323是國際電信聯(lián)盟(ITU)頒布的標(biāo)準(zhǔn)，由一系列特定協(xié)議組成，包括Q.931、H.225、H.245和ASN.1。為了提供呼叫信令功能，H.323部分融合了H.225和Q.931標(biāo)準(zhǔn)。H.245定義了多個流程，以便于進(jìn)行能力信息互換(exchange capability)、主從判斷(master-slave determination)和信道(channel)信令。最后，ASN.1規(guī)定了數(shù)據(jù)格式，使兼容H.323的端點(diǎn)能夠互通。

基本概念

使用H.323時，正確理解原語和流程這兩個術(shù)語很關(guān)鍵。原語用來描述應(yīng)用層和H.323協(xié)議棧下層之間傳遞的結(jié)構(gòu)或消息。H.323定義了多個原語，有四種類型：請求、指示、響應(yīng)和確認(rèn)。每個原語的參數(shù)的數(shù)量是可變的，這由相關(guān)流程決定。這些參數(shù)表示應(yīng)用層和協(xié)議棧下層的通信信息。

在H.323協(xié)議族中的每個協(xié)議定義了一組流程。每個流程代表一個狀態(tài)機(jī)，在大多數(shù)情況下，該狀態(tài)機(jī)用原語的形式規(guī)定一組消息，這些消息以特定的順序發(fā)送和接收。這些原語便于應(yīng)用層和下層的通信。

流程提供具體的功能，可以異步啟動或終止，或啟動后在整個對話過程中保持激活狀態(tài)。例如，H.245流程包括主從判斷、能力信息互換、單向和雙向信道信令。其中，只有信令信道在實(shí)際的對話過程中保持激活。其它只是激活后發(fā)送和接收數(shù)據(jù)，然后就終止了。Q.931/H.225流程包括呼叫建立和拆除。圖1表示一個完整的H.323協(xié)議棧開發(fā)的實(shí)現(xiàn)。值得指出的是，該實(shí)現(xiàn)依賴于網(wǎng)絡(luò)協(xié)議棧和實(shí)時操作系統(tǒng)(RTOS)。多數(shù)應(yīng)用系統(tǒng)需要RTOS以便同時處理多個流程和/或呼叫。

#p#

呼叫信令

如上所述，H.323融合了Q.391和H.225協(xié)議，可提供呼叫信令功能。實(shí)際上，Q.931是ISDN相關(guān)的協(xié)議，用于建立和拆除呼叫。盡管從來沒有打算應(yīng)用于VoIP應(yīng)用系統(tǒng)，但是通過在該協(xié)議上增加信息，可以為H.323提供比較類似的相關(guān)功能。

Q.931分組(packet)包含多個稱為信息單元(information element)的參數(shù)。例如，Q.931分組可以包含一個用戶信息單元。H.323規(guī)定用戶信息單元必須包含一條H.225消息。H.323的附加信息存于此。有關(guān)網(wǎng)關(guān)、網(wǎng)守(gatekeeper)和協(xié)商的大部分信息由H.225承載。

Q.931和H.225定義呼叫信令，而H.245定義許多呼叫業(yè)務(wù)。最常用的業(yè)務(wù)包括主從判斷、能力信息互換、信道信令。當(dāng)Q.931建立起呼叫，這些流程啟動。此時，兩個終端已經(jīng)同意互連，但是還沒有收發(fā)多媒體數(shù)據(jù)。

主從判斷流程協(xié)商決定哪個終端是主，哪個是從。該流程可應(yīng)用于：將一次協(xié)商中相同類型的媒體數(shù)據(jù)流聯(lián)系起來；避免和解決由于編解碼器間的依賴關(guān)系造成的沖突。

能力(capability)信息互換流程告知遠(yuǎn)程終端的音頻、視頻或數(shù)據(jù)能力。這可以避免能力猜測過程(即建立一個信道并發(fā)送遠(yuǎn)程終端可能無法識別的數(shù)據(jù))。

邏輯信道信令過程協(xié)商建立實(shí)時協(xié)議/實(shí)時控制協(xié)議(RTP/RTCP)信道，用于收發(fā)多媒體數(shù)據(jù)。

定義數(shù)據(jù)

抽象語法表示法(ASN.1)標(biāo)準(zhǔn)詳盡說明了怎樣表示語法或結(jié)構(gòu)化數(shù)據(jù)分組，它用于在本地和遠(yuǎn)程端點(diǎn)間發(fā)送H.225和H.245消息。X.691規(guī)定了在ASN.1語法結(jié)構(gòu)和網(wǎng)絡(luò)接收的原始數(shù)據(jù)之間的編碼和解碼方法。H.225和H.245等ITU標(biāo)準(zhǔn)都為所有的協(xié)議消息規(guī)定了ASN.1語法結(jié)構(gòu)。

RTP和RTCP也包括在H.323之中。RTP定義了一個消息頭，附加到多媒體數(shù)據(jù)分組的前端，并通過用戶數(shù)據(jù)報(bào)協(xié)議(UDP)發(fā)送。消息頭包含了有關(guān)多媒體數(shù)據(jù)的信息，包括順序號和時間戳。RTCP用這些數(shù)據(jù)來收集網(wǎng)絡(luò)性能統(tǒng)計(jì)信息，例如分組間的抖動(測量分組到達(dá)時間的不規(guī)則性)和分組片段的丟失。

協(xié)議棧開發(fā)

開發(fā)H.323協(xié)議棧是一項(xiàng)艱巨的任務(wù)。困難產(chǎn)生于標(biāo)準(zhǔn)定義不詳盡而且不一致。標(biāo)準(zhǔn)的模糊導(dǎo)致互操作問題，且所實(shí)現(xiàn)的協(xié)議棧移植性差。

Q.931和H.225定義了呼叫信令流程，但是定義不夠充分。與H.245相比，Q.931和H.225定義的原語缺乏充分的文字說明。另外，產(chǎn)生混亂的原因是不完整的ASN.1標(biāo)準(zhǔn)，因而開發(fā)人員需要將X.691編碼格式數(shù)據(jù)反向轉(zhuǎn)換。RTP/RTCP、H.245和應(yīng)用層間的關(guān)系也存在問題。

在H.323中，Q.931和H.225協(xié)議進(jìn)行了融合，但是融合不夠好。尤其是Q.931規(guī)范包含一些描述很充分的流程圖，這些流程圖顯示相關(guān)消息、原語和超時之間的關(guān)系。而H.225將Q.931中的多個消息標(biāo)記成“禁用”，但卻沒有規(guī)定反映這些變化的新流程。這樣，H.225缺乏足夠的信息，因此，開發(fā)者得到的文檔不完善。

與此相反，H.245是一個定義清晰的協(xié)議，具有大量的流程圖。與Q.931和H.225不同，它規(guī)定了每個原語的參數(shù)。這是極其有用的，而且這表明了Q.931和H.225的缺陷。盡管Q.931是基于原語的，但是沒有規(guī)定原語的字段。整個H.225標(biāo)準(zhǔn)只有一次提到原語而且沒有提供包含參數(shù)的信息。為每個原語選擇字段的工作留給了開發(fā)者，因此，Q.931的接口變成專有的和不可移植的接口。

影響H.323協(xié)議棧開發(fā)學(xué)習(xí)曲線的主要方面是ASN.1。盡管ASN.1詳細(xì)說明了怎樣描述語法，但是，將語法結(jié)構(gòu)編碼成字節(jié)流的方法有多個。X.691規(guī)定了打包編碼原則(PER)，是H.225和H.245使用的編碼規(guī)則集。不幸的是，X.691的不足削弱了ASN.1的優(yōu)點(diǎn)。ASN.1具有擴(kuò)展給定語法的能力，而且能夠以完全后向兼容的方式編碼。但是，X.691只粗略地解釋了怎樣進(jìn)行編碼擴(kuò)展。為了彌補(bǔ)X.691標(biāo)準(zhǔn)的不足，需要做大量的反向工程工作。通過購買現(xiàn)成的協(xié)議棧開發(fā)產(chǎn)品可以避免該任務(wù)。

RTP/RTCP和其它H.323相關(guān)協(xié)議的結(jié)合引入了更多難于捉摸的標(biāo)準(zhǔn)問題。為了設(shè)計(jì)一個模塊化的H.323協(xié)議棧，需要在標(biāo)準(zhǔn)規(guī)定的范圍內(nèi)仔細(xì)定義各協(xié)議間通信的信息結(jié)構(gòu)。H.323標(biāo)準(zhǔn)不能清晰地描述各協(xié)議的互通性。RTP/RTCP就是這種缺陷的一個范例。#p#

實(shí)時協(xié)議問題

RTP/RTCP是設(shè)計(jì)者的大難題，因?yàn)楹茈y從標(biāo)準(zhǔn)中推斷出它與其它協(xié)議的關(guān)系?？赡苡袃煞N選擇：在應(yīng)用層進(jìn)行RTP/RTCP處理或者在下層協(xié)議中處理。

如果在應(yīng)用層處理RTP/RTCP，應(yīng)用程序必須知道RTP信道使用的端口號。因?yàn)槭褂迷Z進(jìn)行協(xié)議棧通信，H.245原語必須能夠?qū)⑺行枰亩丝谛畔魉徒o應(yīng)用層。但是，這些原語沒有描述遠(yuǎn)程主機(jī)端口號的參數(shù)。因此，需要以非標(biāo)準(zhǔn)方式修改這些原語，增補(bǔ)缺少的信息。

如果在下層處理RTP/RTCP，協(xié)議棧開發(fā)需要有關(guān)編解碼器的信息以便調(diào)用合適的設(shè)備驅(qū)動程序。然而，該解決方案也不夠合理，因?yàn)閰f(xié)議棧必須知道特定的設(shè)備信息，而這是不可移植的。

創(chuàng)建VoIP應(yīng)用系統(tǒng)

為了更好地理解如何利用H.323協(xié)議棧實(shí)現(xiàn)VoIP應(yīng)用系統(tǒng)，讓我們看幾個例子，它們展示了下層協(xié)議和應(yīng)用層之間的交互關(guān)系。

要利用基于原語的H.323協(xié)議棧實(shí)現(xiàn)的基本的VoIP應(yīng)用系統(tǒng)，必須實(shí)現(xiàn)一組由H.323標(biāo)準(zhǔn)定義的流程。這些流程由可重入狀態(tài)機(jī)組成，基于輸入或輸出原語的消息由狀態(tài)機(jī)執(zhí)行。另一個替代方案是面向任務(wù)的，為每一個流程啟動一個新線程。無論哪種方案，用原語表示的輸入或輸出消息都是異步發(fā)生的。應(yīng)用系統(tǒng)程序必須把狀態(tài)值保持在這些流程中，而且某些流程可能會有多個運(yùn)行實(shí)例。

每個原語包括多個參數(shù)，這些參數(shù)必須在應(yīng)用層定義。在Q.931中，參數(shù)相當(dāng)簡單且易于理解。然而，當(dāng)學(xué)習(xí)H.245協(xié)議時，閱讀復(fù)雜的ASN.1表結(jié)構(gòu)是很困難的。有關(guān)能力集(capability set)流程的原語尤其復(fù)雜，ASN.1結(jié)構(gòu)可能嵌套5到6層深。對于不熟悉ASN.1的人來說，這可不是簡單工作。

本地流程時序

另一個核心開發(fā)問題是時序，即為了建立或拆除對遠(yuǎn)程主機(jī)的呼叫，本地流程所執(zhí)行的時序。當(dāng)考慮其它H.323實(shí)現(xiàn)或應(yīng)用的互操作性時，研究時序問題尤其必要，這類系統(tǒng)的實(shí)例有Microsoft的NetMeeting和NetSpeak的WebPhone。盡管H.323規(guī)范揭示了流程之間的依賴關(guān)系，必須通過實(shí)驗(yàn)測試和反向工程來揭示發(fā)起呼叫并建立通信需要的時序。

#p#

圖2展示了與遠(yuǎn)程終端建立通信關(guān)系時H.323協(xié)議棧必須執(zhí)行的流程。注意，同一水平線上的流程可能同時運(yùn)行，但是他們都完成后該時序才能繼續(xù)下去。

Q.931呼叫建立流程啟動呼叫建立過程并且通知遠(yuǎn)程終端有一個呼入。當(dāng)呼叫建立起來后，某個終端可能啟動H.245規(guī)定的主從判斷流程或能力信息互換流程。每個終端都需要執(zhí)行能力信息互換流程，但是只要一個終端執(zhí)行主從判斷流程就可以了。主從判斷和能力信息互換完成后，邏輯信道打通了。最后，該對話通過另一個Q.931流程關(guān)閉。

盡管該時序看起來直接明了，而且一些依賴關(guān)系在標(biāo)準(zhǔn)中定義的比較松散，因而很難實(shí)現(xiàn)該時序。因?yàn)閮H依賴關(guān)系就占了H.245規(guī)范的257頁還多，實(shí)現(xiàn)時很容易疏忽。

另一個導(dǎo)致混亂的問題起因于異步執(zhí)行的流程。例如，主從判斷流程可以在能力信息互換流程之前或之后執(zhí)行，而且可能同時或者相互覆蓋執(zhí)行。更有甚著，能力信息互換流程可能在一個閃斷信道(on the fly once channel)上執(zhí)行。這樣可以在對話期間動態(tài)改變編解碼器，然而給協(xié)議棧開發(fā)增加了工作負(fù)擔(dān)。

實(shí)現(xiàn)流程

H.323定義Q.931為呼叫信令協(xié)議，在此，將描述怎樣實(shí)現(xiàn)實(shí)際的流程?；谠Z的H.323協(xié)議棧開發(fā)要求應(yīng)用程序開發(fā)者定義原語并用其與下層通信。為了方便描述呼叫建立流程，我們從Q.931規(guī)范的25頁文檔中歸納出一個流程圖(如圖3)。

當(dāng)實(shí)現(xiàn)呼叫建立流程時,首先發(fā)送建立請求消息，然后該流程等待一條告警指示消息。當(dāng)該指示消息接收到后，該流程再次等待一條確認(rèn)消息。如果這條確認(rèn)消息也接收到了，該流程終止，應(yīng)用程序可以開始處理H.245流程。

為了開發(fā)基于原語的H.323協(xié)議棧流程的狀態(tài)機(jī)，開發(fā)者需要精通H.323協(xié)議，例如上述Q.931呼叫建立協(xié)議。注意，H.245流程比Q.931更具有面向狀態(tài)的特點(diǎn)。每個H.245流程必須按照標(biāo)準(zhǔn)規(guī)定的時序處理接收到的指示消息并發(fā)送請求消息。每個狀態(tài)機(jī)的具體實(shí)現(xiàn)將需要數(shù)月時間。

如果采用替代方案，H.323協(xié)議棧開發(fā)不使用原語，協(xié)議棧需要包括一個已經(jīng)實(shí)現(xiàn)了上述流程和狀態(tài)機(jī)的中間層，并提供一個簡化的應(yīng)用編程接口(API)。對于前面的例子，協(xié)議棧要發(fā)一個呼出，只需要調(diào)用下面這一個函數(shù)即可：

在使用API實(shí)現(xiàn)的系統(tǒng)中，makeCall()函數(shù)接受遠(yuǎn)程端點(diǎn)的主機(jī)名字(hostname)和IP地址，并執(zhí)行所有呼叫遠(yuǎn)程終端的步驟。該方案需要一個流程構(gòu)造前述的原語，實(shí)現(xiàn)處理所有輸入輸出原語的狀態(tài)機(jī)。使用基于API的協(xié)議棧不需要理解原語接口，可以節(jié)省數(shù)月的開發(fā)時間。

給原語參數(shù)賦值

前文的例子描述了流程的實(shí)現(xiàn)。下面的例子展示怎樣給原語賦值，以能力信息互換流程的“TRANSFER.request”原語為例。

“TRANSFER.request”原語有四個字段，用ASN.1格式填充。這四個字段是PROTOID、MUXCAP、CAPTABLE 和 CAPDESCRIPTORS。在此，我們集中討論CAPTABLE參數(shù)，它是特定終端支持的所有編解碼器的列表。在此例中，填充的CAPTABLE參數(shù)表示以下終端能力：單一G.711 A律64k編解碼器，能夠接收的分組長達(dá)180ms音頻數(shù)據(jù)。下面的偽碼是初始化一個ASN.1結(jié)構(gòu)元素的基本步驟。

CAPTABLE參數(shù)實(shí)際上是CapabilityTableEntry的數(shù)組。填充該參數(shù)的第一步是為該數(shù)組分配內(nèi)存空間。每個被支持的編解碼器都需要一個CapabilityTableEntry。在本例中，數(shù)組只有一個元素，因?yàn)橹恢С諫.711編解碼器。每個CapabilityTableEntry有兩個元素：TableEntryNumber字段和可選的能力信息結(jié)構(gòu)。

CAPTABLE[0].Capability.TableEntryNumber = 1 (1)

在行1的語句中，CapabilityTableEntryNumber任意設(shè)置，但是在同一消息中取值要不同。該參數(shù)由CAPDESCRIPTORS參數(shù)使用，以描述編解碼器之間的依賴關(guān)系。CAPDESCRIPTORS結(jié)構(gòu)要復(fù)雜得多，不在本文討論范圍內(nèi)。

能力信息結(jié)構(gòu)描述了至少12種基本能力/業(yè)務(wù)中的一種。該結(jié)構(gòu)是可選的，但是不選用的情況不多。在特定的應(yīng)用方式下，ReceiveAudioCapability被選用。像ReceiveAudioCapability的AudioCapability結(jié)構(gòu)包含14多種不同的編解碼器中的一種。用戶必須選用其中一種編解碼器。一旦選用了某特定的編解碼器，相關(guān)字段必須定義。在g711Alaw64k情況下，只需要一個字段。第二行語句表示編解碼器驅(qū)動器能夠處理的分組大小至多180ms。

CAPTABLE[0].capability.receiveAudioCapability.g711Alaw64k = 180 (2)

值得注意的是，這個簡單例子在一個參數(shù)中只定義了一個編解碼器。其它原語和參數(shù)如CAPDESCRIPTORS要復(fù)雜得多。處理這種原語的過程枯燥、耗時且會給項(xiàng)目造成不必要的困難。

如果采用替代方案，開發(fā)者使用簡單的API協(xié)議棧，則不需要關(guān)心這些細(xì)節(jié)。只要給出用ASN.1正確描述的編解碼器驅(qū)動器，一個在用戶層的簡單的函數(shù)調(diào)用就能處理所有這些細(xì)節(jié)：

獨(dú)立進(jìn)行簡單API協(xié)議棧研究和開發(fā)，只需投入數(shù)百個工時去解決有關(guān)ASN.1的問題就可以了。在應(yīng)用層，僅僅RegisterCodec()函數(shù)就可以為開發(fā)者節(jié)省相當(dāng)多的時間。當(dāng)成本和上市時間最重要時，該協(xié)議棧開發(fā)的簡單性具有不可估量的價(jià)值。