“TRANSFER.request”原語有四個字段，用ASN.1格式填充。這四個字段是PROTOID、MUXCAP、CAPTABLE 和 CAPDESCRIPTORS。在此，我們集中討論CAPTABLE參數，它是特定終端支持的所有編解碼器的列表。在此例中，填充的CAPTABLE參數表示以下終端能力：單一G.711 A律64k編解碼器，能夠接收的分組長達180ms音頻數據。下面的偽碼是初始化一個ASN.1結構元素的基本步驟。

    CAPTABLE參數實際上是CapabilityTableEntry的數組。填充該參數的第一步是為該數組分配內存空間。每個被支持的編解碼器都需要一個CapabilityTableEntry。在本例中，數組只有一個元素，因為只支持G.711編解碼器。每個CapabilityTableEntry有兩個元素：TableEntryNumber字段和可選的能力信息結構。

    CAPTABLE[0].Capability.TableEntryNumber = 1 (1)

    在行1的語句中，CapabilityTableEntryNumber任意設置，但是在同一消息中取值要不同。該參數由CAPDESCRIPTORS參數使用，以描述編解碼器之間的依賴關系。CAPDESCRIPTORS結構要復雜得多，不在本文討論范圍內。

    能力信息結構描述了至少12種基本能力/業(yè)務中的一種。該結構是可選的，但是不選用的情況不多。在特定的應用方式下，ReceiveAudioCapability被選用。像ReceiveAudioCapability的AudioCapability結構包含14多種不同的編解碼器中的一種。用戶必須選用其中一種編解碼器。一旦選用了某特定的編解碼器，相關字段必須定義。在g711Alaw64k情況下，只需要一個字段。第二行語句表示編解碼器驅動器能夠處理的分組大小至多180ms。

    CAPTABLE[0].capability.receiveAudioCapability.g711Alaw64k = 180 (2)

    值得注意的是，這個簡單例子在一個參數中只定義了一個編解碼器。其它原語和參數如CAPDESCRIPTORS要復雜得多。處理這種原語的過程枯燥、耗時且會給項目造成不必要的困難。

    如果采用替代方案，開發(fā)者使用簡單的API協(xié)議棧，則不需要關心這些細節(jié)。只要給出用ASN.1正確描述的編解碼器驅動器，一個在用戶層的簡單的函數調用就能處理所有這些細節(jié)：

    獨立進行簡單API協(xié)議棧研究和開發(fā)，只需投入數百個工時去解決有關ASN.1的問題就可以了。在應用層，僅僅RegisterCodec()函數就可以為開發(fā)者節(jié)省相當多的時間。當成本和上市時間最重要時，該協(xié)議棧的簡單性具有不可估量的價值。

    作者簡介：

    Brian Krejcarek是US Software公司開發(fā)嵌入式H.323協(xié)議棧的主要開發(fā)人員。他擁有Illinois大學BSEE學位，可以通過briank@ussw.com與他聯(lián)系。

    Jonathan Shaw也是US Software公司開發(fā)H.323協(xié)議棧的主要開發(fā)人員，他擁有George Fox大學應用科學學士學位以及Seattle Pacific大學BSEE學位，可以通過jonathan@ussw.com與他聯(lián)系。