经典呼叫模型与应用编程接口

6．3．3　经典呼叫模型与应用编程接口

未来的通信网络将融合分组网（IP或ATM）、电路交换网（PSTN）和无线网络，不仅业务提供商需要提供综合这些网络的业务，更重要的是，为了快速有效地提供业务，需要开放、标准、安全的网络API，使第三方业务开发商和软件商进入电信业务市场。其中最主要的是呼叫控制API，它决定着电信网络的开放程度，以及从网络之外控制电信核心网络的能力，最终将影响着第三方业务提供商所开发业务的功能。

1．经典呼叫控制模型

已经开发了几个呼叫模型以及相关的API，包括智能网（IN）呼叫模型、Java电话API（JTAPI）模型、电话API（TAPI），虽然这些模型面向不同的结构和应用，具有很多不同点，但是它们的整体目标是相似的，都是为了发起呼叫、控制呼叫，方便开发在呼叫之前、呼叫之间、呼叫之后执行的应用。

1）IN呼叫模型

IN呼叫模型是专为PSTA应用开发的，所以假定了一个特殊的分布式结构，电话交换机执行基本的呼叫控制过程，在呼叫之前、呼叫之间的增值业务执行在业务逻辑执行环境中，如业务控制点（SCP）。IN呼叫模型基于基本呼叫状态模型（BCSM），该模型本质上由两个元素组成，第一个元素是一组有限状态机，代表分别在发起和终止交换机中的呼叫过程。第二个元素是触发的概念，触发点定义为发起和终止交换机中有限状态机的特定状态，当呼叫处理进入有限状态机定义并激活的触发点后，当前的处理过程悬挂起来，调用在远程网络元素（如SCP）中执行的业务逻辑程序，当业务逻辑执行完成后，恢复被悬挂的呼叫过程继续执行，直到完成整个呼叫。

IN呼叫模型是以交换为中心的，呼叫过程视为交换机的功能，而业务逻辑视为呼叫过程的补充。应用开发者必须理解发起和终止有限状态机的细节，才能与有限状态机中指定状态的呼叫处理过程进行交互。它没有清楚地抽象出能使程序员控制整个呼叫、呼叫中的分支和呼叫中的主要逻辑实体（如主叫和被叫的地址和电话号码）的概念，而且没有采用面向对象的方式，但IN的有限状态机确实捕捉到呼叫过程的主要状态，便于应用开发者介入呼叫过程。

2）JTAPI呼叫模型

JTAPI由Java Soft发布，为基于Java的电话应用提供面向对象的接口。这里的呼叫指双方或多方间的通信会话，各方都是参加呼叫的一个连接。JTAPI定义的呼叫模型支持基本的呼叫建立和许多扩展，主要是建立呼叫中心、多方会议呼叫、呼叫路由等模型。

JTAPI核心模型由一些电话类及其相互关系组成，如图6．6所示。每个对象对应呼叫中的一个逻辑或物理实体。

图6．6　JTAPI模型中的对象

提供者是电话业务提供者的抽象，提供者类负责管理代表呼叫过程各个阶段的呼叫对象，维护域内的终端和地址对象的静态集合。终端对象代表呼叫的物理端点，而连接对象代表呼叫的逻辑端点，每个地址可以与多个终端相关，反之亦然。这集中反映了呼叫中心的标准配置。每个呼叫的呼叫对象、连接对象、终端对象都是动态生成，呼叫对象代表整个呼叫的状态和操作模型。呼叫的每个分支由连接对象代表，连接对象代表呼叫和指定地址间的逻辑状态和操作模型。最后，终端连接代表连接和一个终端间的逻辑状态和操作模型。电话呼叫的状态由与呼叫相关的有限状态机维护，有限状态机的完整定义在JTAPI规范中说明。

JTAPI克服了IN的几个限制，给程序员提供了清晰的呼叫控制和逻辑实体模型，API是面向对象的，继承了Java的优点，具有很好的扩展性，并且封装了呼叫状态（主要由连接对象有限状态机维护），所有呼叫状态只能通过父类控制。JTAPI使用Java异常和Java事件报告呼叫状态的改变和应用感兴趣的事件。

然而，JTAPI也有缺点。首先，连接对象的有限状态机不如IN丰富和详细，即使增加了呼叫控制扩展包，也不能描述IN提供的所有呼叫状态。然后，JTAPI没有提供与IN触发点相似的方法，无法将呼叫过程悬挂在指定状态，调用应用程序后返回结果。最后，JTA－PI的提供者控制呼叫的所有分支，这样方便了集中呼叫中心的管理，但在融合的下一代网络中这种假设是不现实的。

所以，JTAPI特别适合于面向PBX或呼叫中心的呼叫处理和应用，它在很大程度上是集中处理和控制，但提出了面向对象的呼叫控制，方便了面向对象应用的开发。

2．呼叫控制API

用开放的API构建业务是实现开放式业务体系的关键技术，也是下一代网络区别于传统电信网的主要特点之一。基于API的业务提供技术延续了计算机领域传统的应用软件开发方式，符合计算机软件开发者的习惯。基于API的业务开发方式可以把广大的计算机软件开发商引入到电信业务开发的领域中，使得计算机软件领域已有的丰富的开发资源，包括大量专业的开发人员、丰富的开发经验和成熟的开发技术等，能够成为电信业务开发的推动力。因此，这种开放的第三方API被认为是NGN最具吸引力的能力，可以比较彻底地解决传统电信网络业务提供能力不足的顽疾。

目前，关于下一代网络的开放式业务API标准主要包括：由Parlay组织制定的Parlay API以及由SUA公司在Java平台上推出的JAINAPI。它们最初并不是由国际标准化组织制定的，但是正在获得越来越多的支持。尤其是Parlay API规范，目前已成为业界最具影响力的API规范，并得到大多数标准化研究机构和厂商的采用或认可，成为事实上的网络开放标准接口。

要真正实现业务层的融合，需要通过某种方式屏蔽不同的底层网络的技术细节，使上层的业务执行与具体网络无关，从而能够以一种统一的方式实现跨越多个异构网络的业务。Parlay API是实现这一目标的一种有效技术。

Parlay API由两大部分组成：服务（Service）接口和框架（Framework）接口，如图6．7所示。

服务接口为高层应用业务提供了访问网络资源和信息的能力。服务接口包括现有网络的多种基本功能，例如呼叫控制、消息控制、连接管理、用户交互管理和移动管理。服务接口也包括通用应用程序接口以方便网络应用的部署。业务供应商可以按照不同的业务逻辑调用它们以实现不同的业务。

图6．7　ParlayAPI体系结构

框架接口为服务接口提供必需的支撑能力以及对服务接口的安全管理。框架接口的存在是为了保证上层的应用业务以一种可扩展的和安全的方式使用Parlay服务接口。当前ParlayAPI规范的框架接口提供的功能包括：服务注册、订购和查找、认证和鉴权、完整性管理。Parlay网络业务运行在框架管理域内，并且只能通过框架接口来接入。

服务接口与框架接口的结合使传统网络能力在保证安全性前提下的开放成为可能，而应用则是使用这两种能力的客户端。

资源接口的作用是使Parlay API与具体的网络资源相分离，实现Parlay API的网络独立性，以便基于Parlay API的应用可以在广泛的网络环境中运行，并且避免重新开发已经存在的功能。现有的ISUP、INAP、CAP、H．323、SIP等协议都可充当这一接口的角色。但是资源接口的选择和定义不在Parlay规范的范围内。

Parlay采用的呼叫模型由呼叫对象、呼叫分支对象、媒体对象和地址对象组成。呼叫对象是指呼叫方间的关系，它是应用对网络中物理呼叫的抽象。呼叫分支对象是呼叫对象和地址对象间的逻辑关系，在常规的双方呼叫中，总是包含两个呼叫分支，一个代表主叫方，一个代表被叫方。Parlay一般呼叫控制服务向用户隐藏了呼叫分支，所以在常规的双方呼叫中，应用不能访问呼叫分支；而在多方呼叫中，应用可以也有必要访问呼叫分支。媒体对象代表呼叫中的媒体信道。地址对象逻辑上代表呼叫中的一方，通过电话号码或IP地址标识。一个呼叫分支可以与一个或多个媒体对象相关联，呼叫分支可以与呼叫对象连接和分离，相应地把相关呼叫分支的媒体信道进行连接和分离。

Parlay应用可以有两种方法控制呼叫，一种方法是应用先设置一定的标准（与IN的触发点相同），当产生满足该标准的事件后通知应用；另一种方法是应用通过构造一个新的呼叫对象发起呼叫。

Parlay定义了网络侧和客户应用侧的面性对象的接口，客户应用侧接口主要用于回调时客户能与服务进行交互。