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

一．呼叫控制模型

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

　　1. IN呼叫模型

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

　　BCSM用呼叫点（PIC）和触发点（DP）定义呼叫进程，PIC由进入事件、离开事件、PIC内执行的动作和PIC结束后可用的信息定义，DP点设置在PIC之间，并与特定PIC关联，检测基本呼叫过程的指定事件。而触发点设置在DP点内，假如DP点检测到满足触发点的触发条件时，就执行相应的业务逻辑，否则呼叫过程继续进行。

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

　　2. JTAPI呼叫模型

　　JTAPI由JavaSoft发布，它为基于Java的计算机电话应用提供面向对象的接口。这里的呼叫指双方或多方间的通信会话，各方都是参加呼叫的一个Leg（或者连接），它定义的呼叫模型支持基本的呼叫建立和许多扩展，主要是建立呼叫中心、多方会议呼叫、呼叫路由等模型。核心模型由一些电话类及其相互关系组成，如图3所示。每个对象对应呼叫中的一个逻辑或物理实体。提供者是电话业务提供者的抽象，提供者类负责治理代表呼叫过程各个阶段的呼叫对象，维护它域内的终端和地址对象的静态集合。终端对象代表呼叫的物理端点，而连接对象代表呼叫的逻辑端点，每个地址可以与多个终端相关，反之亦然。这集中反映了呼叫中心的标准配置。每个呼叫的呼叫对象、连接对象、终端对象都是动态生成，呼叫对象代表整个呼叫的状态和操作模型。呼叫的每个Leg由连接对象代表，连接对象代表呼叫和指定地址间的逻辑状态和操作模型。最后，终端连接代表连接和一个终端间的逻辑状态和操作模型。电话呼叫的状态由与呼叫相关的有限状态机维护，有限状态机的完整定义在JTAPI规范中说明。

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

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

　　所以，JTA非凡适合于面向PBX或呼叫中心的呼叫处理和应用，它在很大程度上是集中处理和控制。但提出了面向对象的呼叫控制，方便了面向对象应用的开发。
综上所述，开放电信网络的API，应借鉴IN和JTAPI的呼叫模型，取其优点，避其缺点。

二．呼叫控制API

　　当前，Parlay和JAIN组织都定义了呼叫控制API。值得注重的是JAIN定义的呼叫控制及调度和事务(JCC/JCAT)API是专为电信运营商域内的应用提供的统一的呼叫控制能力，隐藏了底层不同网络的呼叫控制信令协议。为了给第三方业务运营商提供安全、标准的API，JAIN组织和Parlay组织合作，定义了服务提供接入（SPA）API，该API完全采用了Parlay定义的API，使与JAIN兼容的实体可以访问Parlay框架，接入框架支持的业务。所以，从开放网络的角度来看，Parlay提供了核心的呼叫控制API。

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

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

　　Parlay定义了网络侧和客户应用侧的面性对象的接口，客户应用侧接口主要用于回调，时客户能与服务进行交互。Parlay定义了如下四种不同类型的呼叫控制服务：

　　1． 一般呼叫控制服务

　　一般呼叫控制服务是整个呼叫模型的子集。呼叫仅限于双方呼叫，且应用不可控制呼叫Leg。由于一般呼叫控制服务不能处理多媒体连接，所以不可能控制媒体信道。

　　一般呼叫控制由网络侧的两个接口（IpCallControlManager和IpCall）和企业侧的两个接口（lpAppCallControlManager和IpAppCall）构成。

　　IpCallControlManager提供治理呼叫的方法。该接口的CreateCall方法可建立新的呼叫对象（即实现IpCall接口的对象）。它也向客户应用提供请求通知呼叫事件的方法。例如，客户应用能够调用IpCallControlManager接口的方法，请求将到指定电话号码或一定范围电话号码的呼叫事件通知给客户应用，假如由于某种错误呼叫通知不可进行，则不答应客户应用请求呼叫通知。一旦调用了呼叫通知请求，可以通过接口更改或删除。接口也提供在一系列在呼叫上实施的负载控制方法和取消先前设置的负载限制的方法。

　　IpCall接口提供将呼叫路由到目的方和监视呼叫状态的方法。例如，客户应用能调用该接口的方法，请求当呼叫结束时，设置与呼叫相关的信息（例如计费）。使用IpCall接口，客户应用也能请求监视呼叫，即经过指定时长后，将呼叫的状态报告送到客户应用且将呼叫的控制权交给应用。这在预付费应用中很有用，以防止当预付费账户为零时，呼叫仍然继续。另外，IpCall接口也提供设置呼叫计费的操作，lpCall提供的另两个方法是请求用户提供更多的DTMF输入和计费建议操作，它通知用户有关呼叫计费的信息（即消息被发送到它的终端，假如终端有能力显示这一信息）。

　　企业侧的IpAppCallControlManager与IpCallControlManager接口相对应。该接口提供当呼叫事件（通过IpCallControlManager接口请求）到达时被调用的方法。也提供用以接收底层网络有关呼叫通知状态的信息（能够或不能）和当网络碰到呼叫过载时供Parlay网关发送通知信息的方法。接口也提供用以指示网络中呼叫终止的方法，当网络检测到应用感爱好的呼叫终止后，由Parlay网关调用该方法。

　　企业侧的IpAppCall与IpCall接口相对应。该接口提供用以处理呼叫请求的响应和状态报告的方法。例如，IpAppCall接口被通知有关路由请求的状态：路由成功和被叫应答，或被叫忙等。IpAppCall接口接收所有通过IpCall设置的请求的状态报告。

　　2． 多方呼叫控制服务

　　在多方呼叫控制服务中，有六个重要的接口：
　　IpMultiPartyCallControlManager
　　IpAppMultiPartyCallCaontrolManager
　　IpMultiPartyCall
　　lpAppMultiPartyCall
　　IpCallLeg
　　lpAppCallLeg。
　　其中IpMultiPartyCallControlManager接口，lpAppMultiPartyCallControlManager接口和IpAppMultiPartyCall接口从一般呼叫控制接口中继续了所有方法，并没有引入新的方法。

　　IpMultiPartyCall接口是IpCall的扩展，它包含显式接入呼叫Leg的操作，注重在多方呼叫中，一个呼叫能包含两个以上个呼叫Leg。接口也提供一个建立实现IpCallLeg接口对象的方法。

　　IpCallLeg接口提供将呼叫Leg路由到指定目的方并合并或分离与入呼/去呼叫相联系的媒体信道的方法，也提供当呼叫Leg终止时将Leg指定的请求信息发送到应用的方法。虽然能请求具体的Leg事件报告，但不提供连续监视Leg的方法。注重一个呼叫可以有多个Leg，但一个Leg同时仅能属于一个呼叫。

　　企业侧的IpA