未來的通信網絡將融合分組網（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