利用基于原语的H.323协议栈开发VoIP系统

创建VoIP应用系统

为了更好地理解如何利用H.323协议栈实现VoIP应用系统，让我们看几个例子，它们展示了下层协议和应用层之间的交互关系。

要利用基于原语的H.323协议栈实现的基本的VoIP应用系统，必须实现一组由H.323标准定义的流程。这些流程由可重入状态机组成，基于输入或输出原语的消息由状态机执行。另一个替代方案是面向任务的，为每一个流程启动一个新线程。无论哪种方案，用原语表示的输入或输出消息都是异步发生的。应用系统程序必须把状态值保持在这些流程中，而且某些流程可能会有多个运行实例。

每个原语包括多个参数，这些参数必须在应用层定义。在Q.931中，参数相当简单且易于理解。然而，当学习H.245协议时，阅读复杂的ASN.1表结构是很困难的。有关能力集(capability set)流程的原语尤其复杂，ASN.1结构可能嵌套5到6层深。对于不熟悉ASN.1的人来说，这可不是简单工作。

本地流程时序

另一个核心开发问题是时序，即为了建立或拆除对远程主机的呼叫，本地流程所执行的时序。当考虑其它H.323实现或应用的互操作性时，研究时序问题尤其必要，这类系统的实例有Microsoft的NetMeeting和NetSpeak的WebPhone。尽管H.323规范揭示了流程之间的依赖关系，必须通过实验测试和反向工程来揭示发起呼叫并建立通信需要的时序。



图2展示了与远程终端建立通信关系时H.323协议栈必须执行的流程。注意，同一水平线上的流程可能同时运行，但是他们都完成后该时序才能继续下去。

Q.931呼叫建立流程启动呼叫建立过程并且通知远程终端有一个呼入。当呼叫建立起来后，某个终端可能启动H.245规定的主从判断流程或能力信息互换流程。每个终端都需要执行能力信息互换流程，但是只要一个终端执行主从判断流程就可以了。主从判断和能力信息互换完成后，逻辑信道打通了。最后，该对话通过另一个Q.931流程关闭。

尽管该时序看起来直接明了，而且一些依赖关系在标准中定义的比较松散，因而很难实现该时序。因为仅依赖关系就占了H.245规范的257页还多，实现时很容易疏忽。

另一个导致混乱的问题起因于异步执行的流程。例如，主从判断流程可以在能力信息互换流程之前或之后执行，而且可能同时或者相互覆盖执行。更有甚着，能力信息互换流程可能在一个闪断信道(on the fly once channel)上执行。这样可以在对话期间动态改变编解码器，然而给协议栈开发增加了工作负担。

实现流程

H.323定义Q.931为呼叫信令协议，在此，将描述怎样实现实际的流程。基于原语的H.323协议栈要求应用程序开发者定义原语并用其与下层通信。为了方便描述呼叫建立流程，我们从Q.931规范的25页文档中归纳出一个流程图(如图3)。

当实现呼叫建立流程时,首先发送建立请求消息，然后该流程等待一条告警指示消息。当该指示消息接收到后，该流程再次等待一条确认消息。如果这条确认消息也接收到了，该流程终止，应用程序可以开始处理H.245流程。

为了开发基于原语的H.323协议栈流程的状态机，开发者需要精通H.323协议，例如上述Q.931呼叫建立协议。注意，H.245流程比Q.931更具有面向状态的特点。每个H.245流程必须按照标准规定的时序处理接收到的指示消息并发送请求消息。每个状态机的具体实现将需要数月时间。



如果采用替代方案，H.323协议栈不使用原语，协议栈需要包括一个已经实现了上述流程和状态机的中间层，并提供一个简化的应用编程接口(API)。对于前面的例子，协议栈要发一个呼出，只需要调用下面这一个函数即可：

在使用API实现的系统中，makeCall()函数接受远程端点的主机名字(hostname)和IP地址，并执行所有呼叫远程终端的步骤。该方案需要一个流程构造前述的原语，实现处理所有输入输出原语的状态机。使用基于API的协议栈不需要理解原语接口，可以节省数月的开发时间。

给原语参数赋值

前文的例子描述了流程的实现。下面的例子展示怎样给原语赋值，以能力信息互换流程的“TRANSFER.request”原语为例。

“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()函数就可以为开发者节省相当多的时间。当成本和上市时间最重要时，该协议栈的简单性具有不可估量的价值。

上一页  [1] [2] [3]