由于呼叫关系模型是与外部业务开发模式密切相关的，呼叫关系模型对外提供的业务接口应兼容多种业务接口规范。根据软交换系统业务能力的要求，一般需要软交换设备提供INAP接口或者Parlay接口，因此，在UniNet软交换设备设计中，根据对外提供的业务接口方式的不同，呼叫关系模型的设计也各不相同，主要有两种：智能网交换状态模型<IN-SSM)和Parlay呼叫控制模型。概括地说，当软交换设备对外提供智能网INAP接口时，呼叫关系模型的实现应遵照智能网SSF的定义方式，保持与SSF的一致性。当软交换设备对外提供Parlay接口时，呼叫关系模型的实现应遵照Parlay呼叫接口模型的定义方式。下面分别介绍这两种呼叫关系模型的实现。 IN-SSM的实现

在智能网中，呼叫关系视图是通过IN交换状态模型(IN-SSM)表述的。IN-SSM的功能主要是向SCF描述呼叫／连接的当前状态，可以使SCF了解SSF/CCF内部呼叫处理的状态和事件并且可以通过指令去影响SSF/CCF的呼叫处理。IN-SSM可以有多种类型。在智能网CS-1阶段，由于IN-CS-1业务主要是点到点的两方业务，因此IN-SSM的作用并不突出。在IN-CS-2中，为了支持呼叫方处理(CPH,CallPartyHandling)特性，相应地增强了IN-SSM的作用。

CPH是指在呼叫的任何状态（包括建立时期和稳定状态）对其中每个用户（一个或多个）连接的控制与管理。实现CPH的关键是提供一种方法，使SCF实时地了解当前的连接状况，并根据这一信息对呼叫方以及呼叫连接进行处理，如对呼叫方的增加、删除、保持、恢复等，从而提供各种灵活的多方呼叫业务。CPH能力的另一个重要方面是对各种可能的多方呼叫业务的处理。IN-CS-2中提出了实现CPH的方法，即连接视图状态(CVS,ConnectionViewState)方法。它的基础就是描述当前呼叫连接状况的连接视图(CV,ConnectionView)模型。

1. 连接视图的定义

   CS-2阶段的IN-SSM建立在连接视图模型的基础上。连接视图是智能网中的重要概念之一，它运用面向对象的方法，对SSF/CCF中的呼叫及连接处理资源进行抽象，通过定义对象和对象间的关系来描述当前呼叫处理与连接的状态。这些对象包括支路(Leg)、连接点(CP,ConnectionPoint)、呼叫段(CS,CallSegment)、呼叫段关联(CSA,CallSegmentAssociation)。

   Leg表示通向一个可寻址的网络实体的通信通路，根据状态的不同可以或不可以传送语音信息。Leg分为两种，ControllingLeg和PassiveLeg。其中ControllingLeg指呼叫中的控制方，对应的用户动作可以影响整个呼叫和连接的状态，而PassiveLeg指呼叫中的被动方，它（们）的连接状态将受到来自控制方的影响。

   CP则代表各个支路的相互连接点，并允许信息在Leg之间流动，同时还可以转发从一个Leg到另一个Leg的信令消息。连接点既可以代表两个Leg之间的连接功能，也可以代表3个或多个Leg之间的会议功能。CP用于唯一标识一个CS。CS对“半个呼叫＂的物理资源和处理进行抽象，它包括一个CP及所有与之相连的Leg。智能网把呼叫分为发端和收端两部分，与此对应，CV从功能上把呼叫分成两部分，

   对于分开后的每个部分称为“半个呼叫(HalfCall)"或“呼叫段(CallSegment)",如图7.7左侧所示。呼叫段的概念反映了智能网业务中非常重要的“单端业务特征”和“单点控制”的定义。所谓“单端”是指业务特性仅对呼叫中的一方产生作用，而与可能加入呼叫的其他用户无关。一个单端业务实例仅直接影响SSF/CCF中分割开的半个呼叫的处理（即单端业务逻辑实例的控制范围只限于分割的半个呼叫，也就是呼叫段），另外半个呼叫可以通过两个呼叫段之间的信息交互来影响，如图右侧所示。这种互不相关性使得同一呼叫中的另一方可以具有相同或不同的单端业务特性，这样多个单端业务逻辑实例（每半个呼叫一个）在一个呼叫中可以同时激活，每一个由“半个呼叫“间的相互通信来分割。而所谓＇单控制点”是指一次呼叫仅由智能网的一个业务控制点所控制。

   

智能网中半呼叫以及单端控制的概念

CSA指一对相关联的呼叫段，由SSF/CCF把它们结合在一起作为一对来操作（例如将它们组合成一个单一的呼叫段）。关联呼叫段仅限于两个呼叫段都是针对同一个端用户的情况，例如一个端用户已经在呼叫中，而他又发出一个新的呼叫，或者又有新的呼叫叫他，SSF/CCF就可以把这两个呼叫段结合起来，称之为呼叫段关联(CSA),如图7.8所示。从业务控制的角度，CSA对应于SCF与SSF间的一个对话，可包含一个或多个相关CS。

CSA概念示意图

在连接视图中，Leg、CP、CS以及CSA都是与连接相关的对象，反映一个CS或一组相关CS的状态，包括其中各个Leg以及Leg与CP的关系。在智能网中，通常用图形化的方法来描述CV中各对象及其相互关系，如图7.9所示。

连接视图状态中各对象及相互关系的描述

需要说明的是，在呼叫段中的Leg或者用实线或者用虚线来表达。实线代表连接(Joined),表示Leg已经连接到了CP,使用户可以和CS中的另外用户通信。虚线表示Leg的状态或者是“共享"(Shared,表示该Leg不在当前的CS,而是在一个相关的CS中，该状态仅对ControllingLeg而言）、悬置(Pending,表示该Leg正处于呼叫建立过程中），或“代理"(Surrogate,表示该Leg指向网络中的一个虚拟呼叫方，如网络本身、前转呼叫的呼叫方等，而不是指向外部的一个实际的端用户）。

虽然CV采用了面向对象的连接视图模型对呼叫／连接处理过程中涉及的各种资源进行了抽象。但是IN-SSM实际上是采用建立在连接视图模型基础上的连接视图状态(CVS)方法，来描述连接视图模型中规定的连接视图状态以及状态之间可允许的过渡，它可以使SCF了解SSF/CCF内部呼叫处理的状态和事件，并且可以通过指令去影响SSF/CCF的呼叫处理。

所谓连接视图状态，是对某个时刻CV的连接对象及其间连接关系的一种描述，或者说是对某个时刻CV的连接对象及其间连接关系的一张图形化的“快照“。尽管在理论上呼叫连接的状态可以为无穷多，但其中一些状态是不可能在实际呼叫中形成的，有些连接状态则十分危险，易产生网络问题，因此CS-2中只是定义了有限的14个CVS(如下图所示）。

对于CS-2所建议的业务及业务流程，这些CVS状态足以描述可能的所有呼叫及连接状态。此外，CS-2中还描述了一个（组）操作如何影响一个呼叫连接的状态，即定义CVS之前相互转移方式。

由上图可见，连接视图采用面向对象的有限状态自动机机制，从多个方面描述了不同阶段（包括呼叫建立及稳定态）呼叫方与连接以及呼叫过程的有关信息。根据这些信息，SCF可以在整个呼叫存在阶段指挥SSF执行相应的操作，从而控制呼叫连接的状态变化，表现在CVS上，就是各个状态间的转移。简而言之，通过CVS,业务逻辑可以在呼叫的任何状态（包括建立时期和稳定状态）对其中每个用户（一个或多个）连接进行控制与管理（如对呼叫方的增加、删除、保待、恢复等），从而提供各种灵活的业务。

2.CVS与BCSM的关系 CVS反映了呼叫连接方面的属性，主要用于管理多用户呼叫，它描述了CS的状态或一对关联的CS的状态，包括在CS中的一组Leg以及每一个Leg与连接点的关系。BC¬SM则反映了呼叫处理方面的属性，用于描述在一个CS中建立和维持Leg所要求的基本呼叫处理过程。因此，CVS中的每一个Leg都与一个O_BCSM实例或T_BCSM实例相关联。图7.11说明了连接处理对象和呼叫处理对象的关系，它也是UniNet软交换设备对外提供INAP业务接口时的完整呼叫模型的示意图，其中CV充当了UniNet呼叫模型中的呼叫关系模型。

连接视图状态和BCSM的关系

在Leg与BCSM的对应关系上，根据Leg的性质，这里可以有两种情况： (1)、当CS中存在一个或多个PassiveLeg时，每一个PassiveLeg都有BCSM与之直接关联，而ControllingLeg间接地与所有这些BCSM同时关联。因为如果BCSM与ControllingLeg而不是PassiveLeg关联，则在涉及3个或3个以上的呼叫方时，PassiveLeg的信令状态（主叫或被叫）将会产生二义性。

(2)、当CS中只有一个ControllingLeg且Leg的状态为Joined时，该ControllingLeg与一个BCSM相关联。一旦有PassiveLeg加入，则ControllingLeg不再与任何BCSM关联，即心中所述的情况。 因此，通过上述CVS和BCSM的组合，既反映了连接信息（如Leg和CP之间的关系），也反映了呼叫处理信息（如BCSM事件和基本呼叫相关信息），这些信息可以由业务逻辑使用并影响呼叫连接和呼叫处理。SCF可以调用SSF功能去操作这些对象（例如改变它们的属性和相互关系，因此也就改变了连接状态并支持基本呼叫处理）。

当一个业务逻辑实例被调用时，就会产生一个CV状态机实例。它或者是由于在BCSM中遇到了满足DP标准的TDP而产生的，或者是由SCF启动而与TDP无关。在与基本呼叫处理交互时，当CV接收到BCSM的报告或者SCF的指示，就会驱动CV从一个状态迁移到其他状态。这也隐含了Leg的状态迁移是受SCF指示或者基于BCSM的事件（或者说是呼叫控制信令事件）驱动的结果。因此，在定义每个CVS时，都是从3个方面入手：与BCSM的关系、入口事件（即导致建立该连接状态的一些事件）及出口事件（即导致从该状态转移到其他状态的一些事件）。

Parlay呼叫控制模型的实现

在Parlay接口规范中，呼叫控制功能可以提供从非常基本的两方呼叫控制直到多方、多媒体和会议呼叫控制的分层控制能力，因此需要根据软交换设备的应用范围选择使用合适的呼叫控制接口。

1.Parlay呼叫控制模型

ParlayAPI定义了一组呼叫控制接口，并采用面向对象的方法描述呼叫对象及其之间的关系。Parlay呼叫模型由一组对象组成，主要包括以下几类对象。

• Call对象：Call对象表示连接两个或多个呼叫方的逻辑实体，从应用来看，Call对象与整个呼叫视图相关，它为应用程序提供完整的呼叫视图。Call对象要维护与呼叫相关的全局信息，如呼叫上下文、呼叫方数据、计费信息等。

• Address对象：Address对象代表一个逻辑端点，如电话号码或IP地址。

• Leg对象：Leg对象代表在一个Call和一个Address之间的动态联系，这种联系主要是双方的信令关系。只有当Leg选路成功之后才建立Call与Address的联系。在此之前Leg对象处于空闲状态，表示Call还没有与Address关联起来。

由上述对象组成的呼叫模型可由下图来表示。

在Parlay呼叫模型中，对于呼叫参与方的数目没有固有的限制。如果要标识多方呼叫，只需简单增加与Call关联的Leg和Address即可。注意一个呼叫可以有多个Leg,但一个Leg同时仅能是一个呼叫的部分。Parlay呼叫控制接口分为多种类型，它们所能提供的控制能力各不相同，但属于一种逐步增强的继承关系，这种分级的呼叫控制接口对Parlay呼叫模型的具体实现方式也存在着影响。Parlay呼叫模型在常规的两方呼叫中，总是包含两个Leg:一个代表主叫，另一个代表被叫。但是Parlay一般呼叫控制接口对外部业务隐藏了Leg,在常规的双方呼叫中，业务只能接入Call对象，而不能接入Leg对象。而在多方呼叫中，这个接入是可能的甚至是必需的。

用传统电话术语来说，Parlay呼叫模型的特点在于：首先它是“对称的＂，因为一个呼叫的发起方和接收方在最高层没有根本的区别；其次它也是“完整的“，业务逻辑可以获得所有呼叫方的视图而不是只能简单得到呼叫发起方或终止方的视图。Parlay呼叫控制模型与智能网连接视图(CV)模型的最大差别在于，Parlay不存在“半呼叫＂的概念，因此通过Parlay呼叫控制模型可以简化对呼叫的控制操作，摆脱智能网连接视图模型中的复杂性。

相对于智能网的连接视图模型，Parlay的呼叫控制模型显得相对单薄一些。Parlay呼叫对象模型只对呼叫中的所有分支以及呼叫分支之间的信令控制关系进行抽象，但是不描述对象之间的连接关系，这需要由业务逻辑自己来维护。但是相对而言，Parlay的呼叫模型更简单和直观一些，更易于理解和实现。在UniNet软交换设备核心控制功能的实现中，当对外采用Parlay业务接口时，就需要采用Parlay的多方呼叫模型作为UniNet呼叫模型中的呼叫关系模型，此时的UniNet呼叫模型的整体结构如图所示

Parlay呼叫对象模型与BCSM的关系

在多方呼叫控制中，Call接口包含接入Leg的操作。注意在多方呼叫中，一个呼叫能包含多于两个的Leg。Leg接口可以提供将对应的呼叫方路由到指定目的地以及合并或分离与该Leg相连接的媒体流的方法，也提供当呼叫Leg终止时，将Leg指定的请求信息发送到应用的方法。虽然业务能请求详细的Leg事件报告（例如事件是被叫和拆链的应答），但是Parlay接口不提供连续监视Leg的操作。

2.基于ParlayAPI的业务交互模式

Parlay应用有两种方式控制呼叫。一是由软交换设备通知Parlay应用符合先前指定标准的呼叫事件产生，从而建立控制关系；二是Parlay应用主动建立新的呼叫从而控制呼叫。与智能网不同的是，ParlayAPI的信息流是通过对象之间的接口调用机制实现的。下图勾画出了ParlayAPI接口和应用逻辑的关系。Parlay接口基于分布式处理技术，并且可以基于通用对象请求代理体系结构(CORBA)、分布式构件对象模型(DCOM)以及Java远程方法调用(RMI)。

ParlayAPI接口和应用逻辑的关系

Parlay呼叫控制API的定义包含应用侧和服务器侧两部分。在这里，服务器侧实际就是指嵌入到UniNet呼叫模型中的Parlay接口对象，主要包括IpCallContro!Manager（该对象用于提供对所有呼叫接口的管理功能，如在一个新的呼叫请求到来时，创建一个呼叫对象实例）、IpCall和lpCallLeg3类，这3类对象为业务逻辑提供了控制呼叫以及请求通知呼叫事件的方法。应用侧接口则包含在应用业务逻辑中，为呼叫模型提供了向业务逻辑报告呼叫事件和信息的方法。Parlay服务器一侧的每一个接口对象在应用侧都有一个对应的接口对象。比如，服务器侧的IpCall接口对象在应用侧对应于lpAppCall接口对象，它提供了用于处理呼叫请求响应和状态报告的操作。例如，通过IpAppCall接口对象向应用逻辑通知有关路巾状态信息，如路由成功和被叫应答或被叫忙等。lpAppCall接口也为呼叫控制功能提供了向业务逻辑报告它调用lpCall对象操作后的执行结果的方法。例如，如果业务逻辑申请，呼叫模型必须使用这个接口提供的方法，发送与呼叫相关的信息给客户应用。