邏輯信道信令過程協(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ù)報協(xié)議(UDP)發(fā)送。消息頭包含了有關(guān)多媒體數(shù)據(jù)的信息，包括順序號和時間戳。RTCP用這些數(shù)據(jù)來收集網(wǎng)絡(luò)性能統(tǒng)計信息，例如分組間的抖動(測量分組到達(dá)時間的不規(guī)則性)和分組片段的丟失。
協(xié)議棧開發(fā)
開發(fā)H.323協(xié)議棧是一項艱巨的任務(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é)議棧產(chǎn)品可以避免該任務(wù)。
RTP/RTCP和其它H.323相關(guān)協(xié)議的結(jié)合引入了更多難于捉摸的標(biāo)準(zhǔn)問題。為了設(shè)計一個模塊化的H.323協(xié)議棧，需要在標(biāo)準(zhǔn)規(guī)定的范圍內(nèi)仔細(xì)定義各協(xié)議間通信的信息結(jié)構(gòu)。H.323標(biāo)準(zhǔn)不能清晰地描述各協(xié)議的互通性。RTP/RTCP就是這種缺陷的一個范例。
實(shí)時協(xié)議問題
RTP/RTCP是設(shè)計者的大難題，因?yàn)楹茈y從標(biāo)準(zhǔn)中推斷出它與其它協(xié)議的關(guā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é)議棧需要有關(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ā)起呼叫并建立通信需要的時序。
