利用基于原語(yǔ)的H.323協(xié)議棧開(kāi)發(fā)VoIP系統
Brian Krejcarek Jonathan Shaw 2008/04/07
開(kāi)發(fā)H.323協(xié)議棧是通信設計過(guò)程中的一項極其艱巨的任務(wù)，難點(diǎn)主要在于：復雜的協(xié)議棧開(kāi)發(fā)需要投入數年的工程設計資源，而且掌握這些復雜的標準還需要一個(gè)知識的積累和學(xué)習過(guò)程，本文將探討開(kāi)發(fā)H.323協(xié)議棧和VoIP應用系統遇到的問(wèn)題、歧義、困難等。
利用基于原語(yǔ)(primitive)的H.323協(xié)議棧開(kāi)發(fā)IP承載話(huà)音(VoIP)應用系統不是一項小任務(wù)，因為創(chuàng )建一個(gè)魯棒的應用系統，需要花很多時(shí)間去研究含糊的標準和復雜的狀態(tài)機。
本文用例子說(shuō)明流程的實(shí)現以及原語(yǔ)(primitive)的定義，用以說(shuō)明如何構建一個(gè)基于原語(yǔ)接口的應用系統和一個(gè)基于簡(jiǎn)單接口的替代方案。在開(kāi)發(fā)協(xié)議棧之前，建議瀏覽一下H.323的基本標準。H.323是國際電信聯(lián)盟(ITU)頒布的標準，由一系列特定協(xié)議組成，包括Q.931、H.225、H.245和ASN.1。為了提供呼叫信令功能，H.323部分融合了H.225和Q.931標準。H.245定義了多個(gè)流程，以便于進(jìn)行能力信息互換(exchange
capability)、主從判斷(master-slave determination)和信道(channel)信令。最后，ASN.1規定了數據格式，使兼容H.323的端點(diǎn)能夠互通。
基本概念
使用H.323時(shí)，正確理解原語(yǔ)和流程這兩個(gè)術(shù)語(yǔ)很關(guān)鍵。原語(yǔ)用來(lái)描述應用層和H.323協(xié)議棧下層之間傳遞的結構或消息。H.323定義了多個(gè)原語(yǔ)，有四種類(lèi)型：請求、指示、響應和確認。每個(gè)原語(yǔ)的參數的數量是可變的，這由相關(guān)流程決定。這些參數表示應用層和協(xié)議棧下層的通信信息。
在H.323協(xié)議族中的每個(gè)協(xié)議定義了一組流程。每個(gè)流程代表一個(gè)狀態(tài)機，在大多數情況下，該狀態(tài)機用原語(yǔ)的形式規定一組消息，這些消息以特定的順序發(fā)送和接收。這些原語(yǔ)便于應用層和下層的通信。
流程提供具體的功能，可以異步啟動(dòng)或終止，或啟動(dòng)后在整個(gè)對話(huà)過(guò)程中保持激活狀態(tài)。例如，H.245流程包括主從判斷、能力信息互換、單向和雙向信道信令。其中，只有信令信道在實(shí)際的對話(huà)過(guò)程中保持激活。其它只是激活后發(fā)送和接收數據，然后就終止了。
Q.931/H.225流程包括呼叫建立和拆除。圖1表示一個(gè)完整的H.323協(xié)議棧的實(shí)現。值得指出的是，該實(shí)現依賴(lài)于網(wǎng)絡(luò )協(xié)議棧和實(shí)時(shí)操作系統(RTOS)。多數應用系統需要RTOS以便同時(shí)處理多個(gè)流程和/或呼叫。
呼叫信令
如上所述，H.323融合了Q.391和H.225協(xié)議，可提供呼叫信令功能。實(shí)際上，Q.931是ISDN相關(guān)的協(xié)議，用于建立和拆除呼叫。盡管從來(lái)沒(méi)有打算應用于VoIP應用系統，但是通過(guò)在該協(xié)議上增加信息，可以為H.323提供比較類(lèi)似的相關(guān)功能。
Q.931分組(packet)包含多個(gè)稱(chēng)為信息單元(information element)的參數。例如，Q.931分組可以包含一個(gè)用戶(hù)信息單元。H.323規定用戶(hù)信息單元必須包含一條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ù)包括主從判斷、能力信息互換、信道信令。當Q.931建立起呼叫，這些流程啟動(dòng)。此時(shí)，兩個(gè)終端已經(jīng)同意互連，但是還沒(méi)有收發(fā)多媒體數據。
主從判斷流程協(xié)商決定哪個(gè)終端是主，哪個(gè)是從。該流程可應用于：將一次協(xié)商中相同類(lèi)型的媒體數據流聯(lián)系起來(lái)；避免和解決由于編解碼器間的依賴(lài)關(guān)系造成的沖突。
能力(capability)信息互換流程告知遠程終端的音頻、視頻或數據能力。這可以避免能力猜測過(guò)程(即建立一個(gè)信道并發(fā)送遠程終端可能無(wú)法識別的數據)。
邏輯信道信令過(guò)程協(xié)商建立實(shí)時(shí)協(xié)議/實(shí)時(shí)控制協(xié)議(RTP/RTCP)信道，用于收發(fā)多媒體數據。
定義數據
抽象語(yǔ)法表示法(ASN.1)標準詳盡說(shuō)明了怎樣表示語(yǔ)法或結構化數據分組，它用于在本地和遠程端點(diǎn)間發(fā)送H.225和H.245消息。X.691規定了在A(yíng)SN.1語(yǔ)法結構和網(wǎng)絡(luò )接收的原始數據之間的編碼和解碼方法。H.225和H.245等ITU標準都為所有的協(xié)議消息規定了ASN.1語(yǔ)法結構。
RTP和RTCP也包括在H.323之中。RTP定義了一個(gè)消息頭，附加到多媒體數據分組的前端，并通過(guò)用戶(hù)數據報協(xié)議(UDP)發(fā)送。消息頭包含了有關(guān)多媒體數據的信息，包括順序號和時(shí)間戳。RTCP用這些數據來(lái)收集網(wǎng)絡(luò )性能統計信息，例如分組間的抖動(dòng)(測量分組到達時(shí)間的不規則性)和分組片段的丟失。
協(xié)議棧開(kāi)發(fā)
開(kāi)發(fā)H.323協(xié)議棧是一項艱巨的任務(wù)。困難產(chǎn)生于標準定義不詳盡而且不一致。標準的模糊導致互操作問(wèn)題，且所實(shí)現的協(xié)議棧移植性差。
Q.931和H.225定義了呼叫信令流程，但是定義不夠充分。與H.245相比，Q.931和H.225定義的原語(yǔ)缺乏充分的文字說(shuō)明。另外，產(chǎn)生混亂的原因是不完整的ASN.1標準，因而開(kāi)發(fā)人員需要將X.691編碼格式數據反向轉換。RTP/RTCP、H.245和應用層間的關(guān)系也存在問(wèn)題。
在H.323中，Q.931和H.225協(xié)議進(jìn)行了融合，但是融合不夠好。尤其是Q.931規范包含一些描述很充分的流程圖，這些流程圖顯示相關(guān)消息、原語(yǔ)和超時(shí)之間的關(guān)系。而H.225將Q.931中的多個(gè)消息標記成“禁用”，但卻沒(méi)有規定反映這些變化的新流程。這樣，H.225缺乏足夠的信息，因此，開(kāi)發(fā)者得到的文檔不完善。
與此相反，H.245是一個(gè)定義清晰的協(xié)議，具有大量的流程圖。與Q.931和H.225不同，它規定了每個(gè)原語(yǔ)的參數。這是極其有用的，而且這表明了Q.931和H.225的缺陷。盡管Q.931是基于原語(yǔ)的，但是沒(méi)有規定原語(yǔ)的字段。整個(gè)H.225標準只有一次提到原語(yǔ)而且沒(méi)有提供包含參數的信息。為每個(gè)原語(yǔ)選擇字段的工作留給了開(kāi)發(fā)者，因此，Q.931的接口變成專(zhuān)有的和不可移植的接口。
影響H.323協(xié)議棧開(kāi)發(fā)學(xué)習曲線(xiàn)的主要方面是ASN.1。盡管ASN.1詳細說(shuō)明了怎樣描述語(yǔ)法，但是，將語(yǔ)法結構編碼成字節流的方法有多個(gè)。X.691規定了打包編碼原則(PER)，是H.225和H.245使用的編碼規則集。不幸的是，X.691的不足削弱了ASN.1的優(yōu)點(diǎn)。ASN.1具有擴展給定語(yǔ)法的能力，而且能夠以完全后向兼容的方式編碼。但是，X.691只粗略地解釋了怎樣進(jìn)行編碼擴展。為了彌補X.691標準的不足，需要做大量的反向工程工作。通過(guò)購買(mǎi)現成的協(xié)議棧產(chǎn)品可以避免該任務(wù)。
RTP/RTCP和其它H.323相關(guān)協(xié)議的結合引入了更多難于捉摸的標準問(wèn)題。為了設計一個(gè)模塊化的H.323協(xié)議棧，需要在標準規定的范圍內仔細定義各協(xié)議間通信的信息結構。H.323標準不能清晰地描述各協(xié)議的互通性。RTP/RTCP就是這種缺陷的一個(gè)范例。
實(shí)時(shí)協(xié)議問(wèn)題
RTP/RTCP是設計者的大難題，因為很難從標準中推斷出它與其它協(xié)議的關(guān)系。可能有兩種選擇：在應用層進(jìn)行RTP/RTCP處理或者在下層協(xié)議中處理。
如果在應用層處理RTP/RTCP，應用程序必須知道RTP信道使用的端口號。因為使用原語(yǔ)進(jìn)行協(xié)議棧通信，H.245原語(yǔ)必須能夠將所有需要的端口信息傳送給應用層。但是，這些原語(yǔ)沒(méi)有描述遠程主機端口號的參數。因此，需要以非標準方式修改這些原語(yǔ)，增補缺少的信息。
如果在下層處理RTP/RTCP，協(xié)議棧需要有關(guān)編解碼器的信息以便調用合適的設備驅動(dòng)程序。然而，該解決方案也不夠合理，因為協(xié)議棧必須知道特定的設備信息，而這是不可移植的。
創(chuàng )建VoIP應用系統
為了更好地理解如何利用H.323協(xié)議棧實(shí)現VoIP應用系統，讓我們看幾個(gè)例子，它們展示了下層協(xié)議和應用層之間的交互關(guān)系。
要利用基于原語(yǔ)的H.323協(xié)議棧實(shí)現的基本的VoIP應用系統，必須實(shí)現一組由H.323標準定義的流程。這些流程由可重入狀態(tài)機組成，基于輸入或輸出原語(yǔ)的消息由狀態(tài)機執行。另一個(gè)替代方案是面向任務(wù)的，為每一個(gè)流程啟動(dòng)一個(gè)新線(xiàn)程。無(wú)論哪種方案，用原語(yǔ)表示的輸入或輸出消息都是異步發(fā)生的。應用系統程序必須把狀態(tài)值保持在這些流程中，而且某些流程可能會(huì )有多個(gè)運行實(shí)例。
每個(gè)原語(yǔ)包括多個(gè)參數，這些參數必須在應用層定義。在Q.931中，參數相當簡(jiǎn)單且易于理解。然而，當學(xué)習H.245協(xié)議時(shí)，閱讀復雜的ASN.1表結構是很困難的。有關(guān)能力集(capability
set)流程的原語(yǔ)尤其復雜，ASN.1結構可能嵌套5到6層深。對于不熟悉ASN.1的人來(lái)說(shuō)，這可不是簡(jiǎn)單工作。
本地流程時(shí)序
另一個(gè)核心開(kāi)發(fā)問(wèn)題是時(shí)序，即為了建立或拆除對遠程主機的呼叫，本地流程所執行的時(shí)序。當考慮其它H.323實(shí)現或應用的互操作性時(shí)，研究時(shí)序問(wèn)題尤其必要，這類(lèi)系統的實(shí)例有Microsoft的NetMeeting和NetSpeak的WebPhone。盡管H.323規范揭示了流程之間的依賴(lài)關(guān)系，必須通過(guò)實(shí)驗測試和反向工程來(lái)揭示發(fā)起呼叫并建立通信需要的時(shí)序。
圖2展示了與遠程終端建立通信關(guān)系時(shí)H.323協(xié)議棧必須執行的流程。注意，同一水平線(xiàn)上的流程可能同時(shí)運行，但是他們都完成后該時(shí)序才能繼續下去。
Q.931呼叫建立流程啟動(dòng)呼叫建立過(guò)程并且通知遠程終端有一個(gè)呼入。當呼叫建立起來(lái)后，某個(gè)終端可能啟動(dòng)H.245規定的主從判斷流程或能力信息互換流程。每個(gè)終端都需要執行能力信息互換流程，但是只要一個(gè)終端執行主從判斷流程就可以了。主從判斷和能力信息互換完成后，邏輯信道打通了。最后，該對話(huà)通過(guò)另一個(gè)Q.931流程關(guān)閉。
盡管該時(shí)序看起來(lái)直接明了，而且一些依賴(lài)關(guān)系在標準中定義的比較松散，因而很難實(shí)現該時(shí)序。因為僅依賴(lài)關(guān)系就占了H.245規范的257頁(yè)還多，實(shí)現時(shí)很容易疏忽。
另一個(gè)導致混亂的問(wèn)題起因于異步執行的流程。例如，主從判斷流程可以在能力信息互換流程之前或之后執行，而且可能同時(shí)或者相互覆蓋執行。更有甚著(zhù)，能力信息互換流程可能在一個(gè)閃斷信道(on
the fly once channel)上執行。這樣可以在對話(huà)期間動(dòng)態(tài)改變編解碼器，然而給協(xié)議棧開(kāi)發(fā)增加了工作負擔。
實(shí)現流程
H.323定義Q.931為呼叫信令協(xié)議，在此，將描述怎樣實(shí)現實(shí)際的流程。基于原語(yǔ)的H.323協(xié)議棧要求應用程序開(kāi)發(fā)者定義原語(yǔ)并用其與下層通信。為了方便描述呼叫建立流程，我們從Q.931規范的25頁(yè)文檔中歸納出一個(gè)流程圖(如圖3)。
當實(shí)現呼叫建立流程時(shí),首先發(fā)送建立請求消息，然后該流程等待一條告警指示消息。當該指示消息接收到后，該流程再次等待一條確認消息。如果這條確認消息也接收到了，該流程終止，應用程序可以開(kāi)始處理H.245流程。
為了開(kāi)發(fā)基于原語(yǔ)的H.323協(xié)議棧流程的狀態(tài)機，開(kāi)發(fā)者需要精通H.323協(xié)議，例如上述Q.931呼叫建立協(xié)議。注意，H.245流程比Q.931更具有面向狀態(tài)的特點(diǎn)。每個(gè)H.245流程必須按照標準規定的時(shí)序處理接收到的指示消息并發(fā)送請求消息。每個(gè)狀態(tài)機的具體實(shí)現將需要數月時(shí)間。
如果采用替代方案，H.323協(xié)議棧不使用原語(yǔ)，協(xié)議棧需要包括一個(gè)已經(jīng)實(shí)現了上述流程和狀態(tài)機的中間層，并提供一個(gè)簡(jiǎn)化的應用編程接口(API)。對于前面的例子，協(xié)議棧要發(fā)一個(gè)呼出，只需要調用下面這一個(gè)函數即可：
在使用API實(shí)現的系統中，makeCall()函數接受遠程端點(diǎn)的主機名字(hostname)和IP地址，并執行所有呼叫遠程終端的步驟。該方案需要一個(gè)流程構造前述的原語(yǔ)，實(shí)現處理所有輸入輸出原語(yǔ)的狀態(tài)機。使用基于A(yíng)PI的協(xié)議棧不需要理解原語(yǔ)接口，可以節省數月的開(kāi)發(fā)時(shí)間。
給原語(yǔ)參數賦值
前文的例子描述了流程的實(shí)現。下面的例子展示怎樣給原語(yǔ)賦值，以能力信息互換流程的“TRANSFER.request”原語(yǔ)為例。
“TRANSFER.request”原語(yǔ)有四個(gè)字段，用ASN.1格式填充。這四個(gè)字段是PROTOID、MUXCAP、CAPTABLE
和 CAPDESCRIPTORS。在此，我們集中討論CAPTABLE參數，它是特定終端支持的所有編解碼器的列表。在此例中，填充的CAPTABLE參數表示以下終端能力：?jiǎn)我籊.711
A律64k編解碼器，能夠接收的分組長(cháng)達180ms音頻數據。下面的偽碼是初始化一個(gè)ASN.1結構元素的基本步驟。
CAPTABLE參數實(shí)際上是CapabilityTableEntry的數組。填充該參數的第一步是為該數組分配內存空間。每個(gè)被支持的編解碼器都需要一個(gè)CapabilityTableEntry。在本例中，數組只有一個(gè)元素，因為只支持G.711編解碼器。每個(gè)CapabilityTableEntry有兩個(gè)元素：TableEntryNumber字段和可選的能力信息結構。
CAPTABLE[0].Capability.TableEntryNumber = 1 (1)
在行1的語(yǔ)句中，CapabilityTableEntryNumber任意設置，但是在同一消息中取值要不同。該參數由CAPDESCRIPTORS參數使用，以描述編解碼器之間的依賴(lài)關(guān)系。CAPDESCRIPTORS結構要復雜得多，不在本文討論范圍內。
能力信息結構描述了至少12種基本能力/業(yè)務(wù)中的一種。該結構是可選的，但是不選用的情況不多。在特定的應用方式下，ReceiveAudioCapability被選用。像ReceiveAudioCapability的AudioCapability結構包含14多種不同的編解碼器中的一種。用戶(hù)必須選用其中一種編解碼器。一旦選用了某特定的編解碼器，相關(guān)字段必須定義。在g711Alaw64k情況下，只需要一個(gè)字段。第二行語(yǔ)句表示編解碼器驅動(dòng)器能夠處理的分組大小至多180ms。
CAPTABLE[0].capability.receiveAudioCapability.g711Alaw64k
= 180 (2)
值得注意的是，這個(gè)簡(jiǎn)單例子在一個(gè)參數中只定義了一個(gè)編解碼器。其它原語(yǔ)和參數如CAPDESCRIPTORS要復雜得多。處理這種原語(yǔ)的過(guò)程枯燥、耗時(shí)且會(huì )給項目造成不必要的困難。
如果采用替代方案，開(kāi)發(fā)者使用簡(jiǎn)單的API協(xié)議棧，則不需要關(guān)心這些細節。只要給出用ASN.1正確描述的編解碼器驅動(dòng)器，一個(gè)在用戶(hù)層的簡(jiǎn)單的函數調用就能處理所有這些細節：
獨立進(jìn)行簡(jiǎn)單API協(xié)議棧研究和開(kāi)發(fā)，只需投入數百個(gè)工時(shí)去解決有關(guān)ASN.1的問(wèn)題就可以了。在應用層，僅僅RegisterCodec()函數就可以為開(kāi)發(fā)者節省相當多的時(shí)間。當成本和上市時(shí)間最重要時(shí)，該協(xié)議棧的簡(jiǎn)單性具有不可估量的價(jià)值。
作者簡(jiǎn)介：
Brian Krejcarek是US Software公司開(kāi)發(fā)嵌入式H.323協(xié)議棧的主要開(kāi)發(fā)人員。他擁有Illinois大學(xué)BSEE學(xué)位，可以通過(guò)briank@ussw.com與他聯(lián)系。
Jonathan Shaw也是US Software公司開(kāi)發(fā)H.323協(xié)議棧的主要開(kāi)發(fā)人員，他擁有George Fox大學(xué)應用科學(xué)學(xué)士學(xué)位以及Seattle
Pacific大學(xué)BSEE學(xué)位，可以通過(guò)jonathan@ussw.com與他聯(lián)系。
電子專(zhuān)輯
相關(guān)鏈接:
亚洲精品网站在线观看不卡无广告,国产a不卡片精品免费观看,欧美亚洲一区二区三区在线,国产一区二区三区日韩
霍州市|
五大连池市|
类乌齐县|
德惠市|
肥乡县|
山阳县|
合川市|
阜新市|
凌海市|
宜兰县|
临江市|
民乐县|
嘉禾县|
延寿县|
勐海县|
青河县|
贵阳市|
牙克石市|
宁陵县|
聂拉木县|
天全县|
石泉县|
巫溪县|
云梦县|
临高县|
南部县|
沂源县|
平南县|
石棉县|
石城县|
达州市|
云霄县|
清水河县|
满城县|
常德市|
瓦房店市|
沙雅县|
洪湖市|
平顺县|
应城市|
托里县|
http://444
http://444
http://444
http://444
http://444
http://444