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

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

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

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

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

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

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

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

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

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

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

    實時協(xié)議問題

    RTP/RTCP是設計者的大難題，因為很難從標準中推斷出它與其它協(xié)議的關系�？赡苡袃煞N選擇：在應用層進行RTP/RTCP處理或者在下層協(xié)議中處理。

    如果在應用層處理RTP/RTCP，應用程序必須知道RTP信道使用的端口號。因為使用原語進行協(xié)議棧通信，H.245原語必須能夠將所有需要的端口信息傳送給應用層。但是，這些原語沒有描述遠程主機端口號的參數(shù)。因此，需要以非標準方式修改這些原語，增補缺少的信息。

    如果在下層處理RTP/RTCP，協(xié)議棧需要有關編解碼器的信息以便調用合適的設備驅動程序。然而，該解決方案也不夠合理，因為協(xié)議棧必須知道特定的設備信息，而這是不可移植的。

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

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

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

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

    本地流程時序

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