作為一個開放系統的控制中心，軟交換設備有兩個基本的需求：一是要提供一個最基本的核心以滿足軟交換呼叫控制的需求；二是要向軟交換系統外圍的其他實體提供通用的接口，包括面向業務控制的接口以及使用標準的協議與其他網絡通信。因此，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)則是面向小型應用環境的集中控制模式，因此，呼叫關系模型的設計通常需要適應其所支持的外部業務開發模式的要求。根據與業務交互方式以及交互信息的不同要求，呼叫關系模型的建模側重點就會有所不同，最后導出的呼叫關系模型也會有所不同，但必須滿足其面向的外部業務開發模式的具體需求。