由于呼叫關系模型是與外部業務開發模式密切相關的，呼叫關系模型對外提供的業務接口應兼容多種業務接口規范。根據軟交換系統業務能力的要求，一般需要軟交換設備提供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)模型。
-
連接視圖的定義
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對象操作后的執行結果的方法。例如，如果業務邏輯申請，呼叫模型必須使用這個接口提供的方法，發送與呼叫相關的信息給客戶應用。
