“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种基本能力/业务中的一种。该结构是可选的，但是不选用的情况不多。在特定的应用方式下，ReceiveAudioCapability被选用。像ReceiveAudioCapability的AudioCapability结构包含14多种不同的编解码器中的一种。用户必须选用其中一种编解码器。一旦选用了某特定的编解码器，相关字段必须定义。在g711Alaw64k情况下，只需要一个字段。第二行语句表示编解码器驱动器能够处理的分组大小至多180ms。
CAPTABLE[0].capability.receiveAudioCapability.g711Alaw64k = 180 (2)
值得注意的是，这个简单例子在一个参数中只定义了一个编解码器。其它原语和参数如CAPDESCRIPTORS要复杂得多。处理这种原语的过程枯燥、耗时且会给项目造成不必要的困难。
如果采用替代方案，开发者使用简单的API协议栈，则不需要关心这些细节。只要给出用ASN.1正确描述的编解码器驱动器，一个在用户层的简单的函数调用就能处理所有这些细节：
独立进行简单API协议栈研究和开发，只需投入数百个工时去解决有关ASN.1的问题就可以了。在应用层，仅仅RegisterCodec()函数就可以为开发者节省相当多的时间。当成本和上市时间最重要时，该协议栈的简单性具有不可估量的价值。
作者简介：
Brian Krejcarek是US Software公司开发嵌入式H.323协议栈的主要开发人员。他拥有Illinois大学BSEE学位，可以通过briank@ussw.com与他联系。
Jonathan Shaw也是US Software公司开发H.323协议栈的主要开发人员，他拥有George Fox大学应用科学学士学位以及Seattle Pacific大学BSEE学位，可以通过jonathan@ussw.com与他联系。
