作为一个开放系统的控制中心，软交换设备有两个基本的需求：一是要提供一个最基本的核心以满足软交换呼叫控制的需求；二是要向软交换系统外围的其他实体提供通用的接口，包括面向业务控制的接口以及使用标准的协议与其他网络通信。因此，UniNet软交换设备设计思想中有一个基本方面就是：通过一个标准模式，实现隐藏核心呼叫／会话处理和控制细节的要求，以达到抽象信令协议、封装实现过程的目的。这意味着，需要设计一个通用化的多方呼叫／会话模型，以适应未来那些新出现的协议及调整后的改进协议，或那些由不同厂商开发的协议实现形式。后面介绍支持语音业务的UniNet软交换设备核心呼叫控制功能的设计方式。

一、 呼叫控制功能的需求分析

NGN网络是一个业务驱动的网络，从业务提供的角度来说，软交换设备不仅要能够控制种类繁多、接口各异的网元设备（如IAD、IP终端以及接入网关、中继网关、信令网关等），实现基本的语音呼叫接续功能，还要能够在外部业务逻辑的控制下，完成对呼叫接续过程的更复杂的控制功能。

综合起来，支持语音业务的软交换设备需要实现的呼叫控制功能必须满足以下要求：

• 为语音呼叫的建立、维持和释放等过程提供通用的基本控制功能，这就要求软交换设备能够以统一的标准方式来处理各种信令协议；

• 能够接收来自上层业务的监视请求，支持业务触发事件检测，能够接收来自业务的呼叫控制相关指示，并对其中与呼叫相关的事件进行处理；

• 能够接入NGN中的各种信令协议，完成不同协议之间的互联互通，包括ISUP协议、H.323协议、SIP协议、Megaco/H.248协议等，并能够支持跨越多种协议终端的语音业务。

由此可见，为了支持语音业务，软交换设备的呼叫控制功能必须满足标准化的呼叫接续处理、多种信令的融合接人以及良好的业务支持能力这3点需求。通常，可以采用模型化的方法对上述功能的实现方式进行抽象描述，这就是呼叫模型。

二、呼叫模型的基本概念

在呼叫控制设备中（如电路交换机、呼叫服务器等），通常将实现呼叫控制的过程模型称为呼叫模型。呼叫模型的概念其实由来已久，它是对网络呼叫控制能力的一种抽象，最初是针对传统PSTN中的交换机提出的，其初始目的仅仅是为了规范化交换机的呼叫处理过程。而后，随着呼叫控制实体以及相关通信网络的不断变化，对呼叫模型的功能需求也随之发展，远远超越了最初的范畴。现在的呼叫模型不仅要满足基本呼叫处理过程的需求，还要满足非嵌入式（分布式）业务提供要求的更复杂的控制功能。

在传统通信网中，已存在若干种呼叫模型，包括智能网基本呼叫状态模型(IN-CS-1/CS-2BCSM)、JTAPI(Java电话APD模型和TAPIC电话APD模刮等。尽管它们的目标通常是相似的：用于发起、控制和操纵呼叫以及方便在呼叫之前、之中和之后执行业务交互功能，但是在建模方式上以及所能实现的能力上它们存在着很大的差别，这与它们所面向的不同网络结构或应用模式是相关的。

在软交换设备的设计中，网络应用的环境以及面向的业务开发需求与传统电信网有诸多不同之处。我们认为，其呼叫处理过程应通过提取不同电信网络中呼叫处理模式的通用特征，建立规范的呼叫处理方式，并尽量屏蔽不同网络处理模式的差异性，使软交换设备的核心控制功能具有良好的稳定性和适应性。因此，在实现软交换设备的呼叫控制功能时，建立一个恰当的呼叫模型具有非常重要的地位。

三、呼叫模型的结构及描述方式

呼叫模型在软交换设备的设计中居于核心地位，其功能的强弱决定了软交换设备的呼叫控制能力以及业务提供能力。整体上，呼叫模型是对软交换设备核心控制能力的抽象，它可以提供基本呼叫控制和连接控制能力以建立用户的通信链路，并把通信链路连接起来；同时，它还要能够检测出触发外部业务的基本呼叫和连接控制事件，并支持在呼叫处理过程中与外部业务的交互功能。

因此，对于软交换设备的呼叫建模，需要从基本呼叫处理以及复杂业务控制两方面的需求人手，描述两个层次的信息：Q)对于呼叫拓扑结构的描述；＠对于呼叫处理过程的描述。实际上，这两个层次反映了对呼叫建模采用的两个基本视点：全局视点和过程视点。从这两个不同的视点出发对软交换网络的呼叫进行建模，将能够全面描述一个呼叫的整体视图，如图7.I所示，其中： • 呼叫全局视点，即从整个呼叫的角度，描述呼叫中有哪些呼叫方、各个呼叫方之间的关联关系以及在呼叫处理过程中这些关系的变化情况。可以把从这个视点出发抽象的模型称为＂呼叫关系模型”，一般来说，它描述的是呼叫关系的拓扑结构，侧重于对一个呼叫所涉及到的所有通信支路（也就是到每一个端用户的通信连接）以及它们之间的关联关系的抽象描述。

• 呼叫过程视点，即从某个呼叫方的角度，描述为了建立和维护与该呼叫方有关的通信链路所要经历的呼叫处理过程，并标识出基本呼叫处理过程的各个逻辑阶段和主要操作。同样，可以把从这个视点出发抽象的模型称为＂呼叫状态模型“，一般来说，它侧重于对呼叫中所涉及到的某个通信支路的建立、维持、拆除等完整处理过程中各个阶段状态的抽象描述。

呼叫模型的基本结构

上述两个视点侧重点不同，采用的建模方式也不太一样。通常情况下，可以采用面向对象(00,0bjectOriented)的方法描述呼叫关系模型，以抽象呼叫的全局拓扑结构；而采用有限状态机(FSM,FiniteStateMachine)的形式描述呼叫状态模型，以追踪呼叫处理的逻辑过程。所谓有限状态机模型是一个系统的操作模型，它包含了该系统可能出现的一组规定状态以及从某一状态到另一状态可能存在的一组转移。抽象一个系统的有限状态机模型首先要表征该系统的所有状态。在任意给定时刻，该系统所允许执行的操作和动作是直接与该时刻所处状态相关的，从规定状态输入或者输出到另一个规定状态也是与该状态所允许的转移有关的。而“面向对象”的方法是把系统抽象为一组对象（一个或多个），这些对象能反映该系统感兴趣的特征，每个对象都用一组特征（称为属性）以及操作这些对象的动作（称为功能）来描述，因此“对象”是一个模型化和自治的实体。这些实体可以很自然地组合和重复使用，给出标志该系统的一组对象就可以描述系统的组成和它的操作点。采用上述的建模方式，就会得到两种不同的模型：呼叫关系模型和呼叫状态模型。从本质上说，呼叫关系模型是对呼叫包含的处理资源的一种抽象表示，其重点在于呼叫“关系”的描述，这里的“关系”是指呼叫各方的连接关系（或者信息传递关系）和控制关系；而呼叫状态模型则是对呼叫处理”过程”的描述。呼叫状态模型通常以单个呼叫方为描述对象，而呼叫关系模型则是对呼叫整体的描述。因此，由呼叫关系模型和呼叫状态模型组合而成的呼叫模型既反映了连接信息（如支路和连接点相互间的关系），也反映了呼叫处理信息（如事件和基本呼叫相关信息）。

四、 呼叫模型的运作机制

基于全局视点和过程视点建立的双层呼叫模型结构，从逻辑关系上看，可以认为关系模型在上，状态模型在下，两者互相配合，共同完成对呼叫的控制功能。底层的呼叫状态模型只需要处理基本呼叫行为，而由更高层次的呼叫关系模型维护多个呼叫方的连接视图，并管理与外部业务逻辑的交互。这种双层结构的呼叫模型设计方式同时兼顾了呼叫处理的高效性和灵活性需求，并较好地解决了业务交换与呼叫控制的分工问题。呼叫关系模型和呼叫状态模型的配合关系如图7.2(a)和(b)所示。从基本呼叫处理的角度，对于大多数只涉及两个呼叫方的点到点基本语音呼叫，网络拓扑关系非常简单（点到点呼叫的网络拓扑只有一种形式），通过由两个有限状态机（分别代表主叫和被叫）

呼叫关系模型和呼叫状态模型的配合关系

组成的呼叫状态模型，其呼叫关联关系就已经可以隐含地表示出来，因此可以直接通过呼叫状态模型进行控制，以提高处理效率。当需要提供多方呼叫的控制能力时，则由高层呼叫关系模型介入，协调和管理多个基本呼叫状态模型之间的交互关系，而基本呼叫状态模型完全不需感知多方通话的存在，也不用为实现多方通话做任何特殊的改动。因此这种分层呼叫模型结构有着很好的扩展性，可以满足复杂呼叫控制的要求。

从业务提供的角度，呼叫模型还需要管理与外部业务之间的交互方式，这里的交互包括两方面的含义：一方面，呼叫模型需要提供业务触发检测机制，检测呼叫／连接事件，通过交互向外部业务报告关于呼叫／连接状态变化以及特定事件的信息；另一方面，业务通过交互可识别这些信息，控制呼叫模型（如改变呼叫方连接的拓扑关系，触发呼叫支路的状态迁移），从而达到干预呼叫流程、实现业务控制的目的。其基本原理如图所示。

呼叫模型与业务交互关系

从上图中可以看到，呼叫关系模型在与业务交互过程中承担了重要作用。针对业务提供的需要，呼叫关系模型的基本功能如下：对上接收业务逻辑的控制操作或请求，并将其翻译成内部指令，与呼叫状态模型交互，从而改变呼叫处理过程；对下则接收呼叫状态模型报告的事件和状态信息，进一步地过滤和加工之后，按照业务逻辑的要求上报相应的呼叫信息，这些信息包括呼叫当前状态、呼叫状态的改变、与呼叫有关的网络事件和错误的报告（例如忙、已连接、阻塞等）。简单地说，呼叫关系模型通过其抽象的呼叫拓扑视图，管理和实现软交换设备呼叫控制功能与外部业务控制功能的交互过程，为外部业务逻辑提供了一个观察和影响内部呼叫及连接处理过程的有限窗口。

正因为具有与业务交互信息的功能，所以呼叫关系模型也可以称为业务交换模型(SSM,ServiceSwitchModel)。需要注意的是，从业务提供的角度，呼叫关系模型反映的是对网络中一个物理呼叫的高层应用观点。由于不同的业务开发模式关注的重点不同，需要的呼叫控制功能集也不同，如智能网业务开发模式是一种单端单控制的模式，而电话应用编程接口和Java电话应用编程接口(TAPI和JTAPI)则是面向小型应用环境的集中控制模式，因此，呼叫关系模型的设计通常需要适应其所支持的外部业务开发模式的要求。根据与业务交互方式以及交互信息的不同要求，呼叫关系模型的建模侧重点就会有所不同，最后导出的呼叫关系模型也会有所不同，但必须满足其面向的外部业务开发模式的具体需求。