目 錄

系統(tǒng)拓撲結構圖

·PBX/ACD：實現(xiàn)電話呼入、呼出和話務管理等功能，提供自動排隊機系統(tǒng)，實現(xiàn)對來話的均衡分配

。。VoiceXML的模型如圖所示，一個文檔服務器比如說一個Web服務器，處理一個來自終端應用的請求，這一請求經(jīng)過了VoiceXML解釋程序和VoiceXML解釋程序環(huán)境處理。作為響應，服務器產(chǎn)生出VoiceXML文檔，在回復當中，要經(jīng)過VoiceXML解釋程序的處理。
　<?xml version="1.0"?>
　　這是一個簡單的VoiceXML文檔，執(zhí)行時輸出Hello World!的合成語音。可以看作一個包含會話的容器，所有的VoiceXML文檔都是由一系列會話構成的。一個VoiceXML文檔（或稱為請求的一組文檔）構成了一個對話式的有限狀態(tài)機。用戶總是處于某一對話狀態(tài)（或稱為會話）。每一個會話決定要轉(zhuǎn)移到的下一個會話。轉(zhuǎn)移由URIs指定，URIs定義下一個要使用的文檔和會話。當一個會話沒有指定后繼者或指明退出對話狀態(tài)時操作才會終止。

·VoiceXML語音瀏覽器（Voice Browser）

5.6 數(shù)據(jù)庫服務器

5.8 業(yè)務管理系統(tǒng)

　　呼叫中心系統(tǒng)同業(yè)務有關系的主要是IVR服務器和Agent人工座席兩部分，他們都是通過AppServer應用服務器同后臺業(yè)務系統(tǒng)進行互聯(lián)；IVR服務器和人工座席都是采用瀏覽器模式，他們的業(yè)務邏輯都是通過應用服務器上的Web服務器進行的，IVR的VoiceXML頁面和人工座席的HTML頁面都是通過AppServer上的Web服務器靜態(tài)或動態(tài)產(chǎn)生的，他們同AppServer的通信都是通過HTTP協(xié)議進行的。

　　當人工座席登陸后，XCCP Agent從系統(tǒng)數(shù)據(jù)庫加載業(yè)務菜單，每個業(yè)務菜單都對應一個URL，當話務員點擊業(yè)務菜單時，系統(tǒng)就訪問對應的URL，效果顯示在座席瀏覽器上；系統(tǒng)同時將呼叫信息或從其他座席和IVR得到的UUI信息傳送給相應的頁面，有頁面對這些信息自行處理；菜單和URL的對應關系由XCCP Management進行配置；如果業(yè)務系統(tǒng)本身就是瀏覽器模式的，這樣的結構可以將這些終端界面直接嵌入座席系統(tǒng)中，無需進行二次開發(fā)和進行接口定義。下面是配置界面：

6.3 IVR服務器

　　通過上圖可以看出，用戶根據(jù)自己的業(yè)務需求和流程書寫VoiceXML格式的文件，對于需要從數(shù)據(jù)庫和其他系統(tǒng)獲取的數(shù)據(jù)，可以使用Web Scripts(ASP,JSP等)語言訪問外部系統(tǒng)以獲取數(shù)據(jù)，把這些數(shù)據(jù)合并到VXML的模板中，形成完整的業(yè)務流程。IVR服務器負責解析和執(zhí)行這些自動語音頁面，完成相應的語音業(yè)務。

6.4 應用服務器接口

　　可以看出AppServer應用服務器是外部系統(tǒng)同XCCP呼叫中心系統(tǒng)接口的核心模塊，由于XCCP采用開放協(xié)議和標準，應用服務器實際就是一個Web服務器，因此同后臺業(yè)務系統(tǒng)接口技術不受XCCP系統(tǒng)的限制，只要Web服務器能支持通信技術在這里都全面支持，下面都分別進行舉例說明；如果有些通信技術在下面描述中沒有涉及到的，但是Web技術支持的，應用服務器都支持。

6.4.1 XML/WebService模式
　　后臺業(yè)務系統(tǒng)提供WebService接口，該接口基于HTTP協(xié)議，數(shù)據(jù)格式采用雙方共同定義的XML格式，后臺系統(tǒng)提供AppServer可以訪問的URL就可以了；環(huán)境成熟時，可以直接采用.Net的WebService方式，只是要遵守他們的調(diào)用格式就可以了。后臺可以用多種方式提供接口：ASP、JSP、PHP、CGI、JavaScript等等，Web服務器只要支持HTTP就可以了。
這是我們主要推薦的接口模式，主要優(yōu)點：開放的標準和協(xié)議，兼容性好，跨平臺；由于采用XML，數(shù)據(jù)格式定義靈活，擴展方便；成熟技術，系統(tǒng)穩(wěn)定；第三方技術支持多，開發(fā)簡單，開發(fā)速度快，可維護性好；系統(tǒng)性能好，安全性高。這是整個IT界一個技術發(fā)展方向。

6.4.2 COM/DCOM模式
　　該模式主要針對傳統(tǒng)的通信接口，傳統(tǒng)的通信手段有：
·Socket
·Windows DLL
·中間件Service／DLL，
　　這些技術都將在AppServer中被包裝成COM／DCOM／COM＋，應用服務器通過對這些COM的調(diào)用實現(xiàn)對后臺業(yè)務系統(tǒng)的訪問。因為很多用戶的環(huán)境已經(jīng)存在很多IT系統(tǒng)，對外的通信接口有很多種，這種模式比較好地能支持這些環(huán)境。例如：Socket通信就在很多系統(tǒng)中存在，而中間件模式在很多金融系統(tǒng)中存在，所以該接口模式能支持大多數(shù)已經(jīng)存在的系統(tǒng)。

6.4.3 DB/SQL模式
　　有些業(yè)務系統(tǒng)的數(shù)據(jù)庫可以公開給內(nèi)部網(wǎng)絡上其他IT系統(tǒng)直接訪問，在這種情況下，AppServer可以直接訪問這些數(shù)據(jù)庫。訪問的對象可以為兩種對象：表和存儲過程；通過對訪問用戶權限的設置，也可以增加系統(tǒng)的安全性，例如：限制AppServer不能直接訪問表，所有的訪問都是通過存儲過程控制的，這樣數(shù)據(jù)庫的安全性也很高。

6.4.4 文件模式
　　這是最原始、最簡單的方法，后臺業(yè)務數(shù)據(jù)庫同AppServer如果只有很少或很簡單信息交換，而且系統(tǒng)穩(wěn)定性要求不是特別高，在某種情況下文件交換的方式也是可以實行的，所有的信息存儲在文件中，通過目錄結構、文件命和文件內(nèi)容進行信息交換。

上海聲軟技術（Voicesoft）公司供稿 CTI論壇編輯