邏輯信道信令過(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í)序。
