圖2展示了與遠程終端建立通信關系時H.323協(xié)議棧必須執(zhí)行的流程。注意，同一水平線上的流程可能同時運行，但是他們都完成后該時序才能繼續(xù)下去。
Q.931呼叫建立流程啟動呼叫建立過程并且通知遠程終端有一個呼入。當呼叫建立起來后，某個終端可能啟動H.245規(guī)定的主從判斷流程或能力信息互換流程。每個終端都需要執(zhí)行能力信息互換流程，但是只要一個終端執(zhí)行主從判斷流程就可以了。主從判斷和能力信息互換完成后，邏輯信道打通了。最后，該對話通過另一個Q.931流程關閉。
盡管該時序看起來直接明了，而且一些依賴關系在標準中定義的比較松散，因而很難實現(xiàn)該時序。因為僅依賴關系就占了H.245規(guī)范的257頁還多，實現(xiàn)時很容易疏忽。
另一個導致混亂的問題起因于異步執(zhí)行的流程。例如，主從判斷流程可以在能力信息互換流程之前或之后執(zhí)行，而且可能同時或者相互覆蓋執(zhí)行。更有甚著，能力信息互換流程可能在一個閃斷信道(on the fly once channel)上執(zhí)行。這樣可以在對話期間動態(tài)改變編解碼器，然而給協(xié)議棧開發(fā)增加了工作負擔。
實現(xiàn)流程
H.323定義Q.931為呼叫信令協(xié)議，在此，將描述怎樣實現(xiàn)實際的流程。基于原語的H.323協(xié)議棧要求應用程序開發(fā)者定義原語并用其與下層通信。為了方便描述呼叫建立流程，我們從Q.931規(guī)范的25頁文檔中歸納出一個流程圖(如圖3)。
當實現(xiàn)呼叫建立流程時,首先發(fā)送建立請求消息，然后該流程等待一條告警指示消息。當該指示消息接收到后，該流程再次等待一條確認消息。如果這條確認消息也接收到了，該流程終止，應用程序可以開始處理H.245流程。
為了開發(fā)基于原語的H.323協(xié)議棧流程的狀態(tài)機，開發(fā)者需要精通H.323協(xié)議，例如上述Q.931呼叫建立協(xié)議。注意，H.245流程比Q.931更具有面向狀態(tài)的特點。每個H.245流程必須按照標準規(guī)定的時序處理接收到的指示消息并發(fā)送請求消息。每個狀態(tài)機的具體實現(xiàn)將需要數(shù)月時間。
如果采用替代方案，H.323協(xié)議棧不使用原語，協(xié)議棧需要包括一個已經(jīng)實現(xiàn)了上述流程和狀態(tài)機的中間層，并提供一個簡化的應用編程接口(API)。對于前面的例子，協(xié)議棧要發(fā)一個呼出，只需要調(diào)用下面這一個函數(shù)即可：
在使用API實現(xiàn)的系統(tǒng)中，makeCall()函數(shù)接受遠程端點的主機名字(hostname)和IP地址，并執(zhí)行所有呼叫遠程終端的步驟。該方案需要一個流程構造前述的原語，實現(xiàn)處理所有輸入輸出原語的狀態(tài)機。使用基于API的協(xié)議棧不需要理解原語接口，可以節(jié)省數(shù)月的開發(fā)時間。
給原語參數(shù)賦值
前文的例子描述了流程的實現(xiàn)。下面的例子展示怎樣給原語賦值，以能力信息互換流程的“TRANSFER.request”原語為例。
