??? 摘? 要: 在下一代網絡的背景下，介紹了下一代呼叫中心" title="呼叫中心">呼叫中心的概念、網絡結構和網元；以實現(xiàn)融合業(yè)務為目標，重點提出傳真、短信、Web這三種非語音類業(yè)務在下一代呼叫中心架構上的可行方案；同時，對該方案的優(yōu)點做了詳細分析。
??? 關鍵詞: 下一代呼叫中心? 融合業(yè)務? 非語音類業(yè)務

?

??? 隨著傳統(tǒng)的基于時分復用TDM（Time Division Multiplexing）的公共交換電話網PSTN（Public Switched Telephone Network）向下一代網絡NGN（Next Generation Network）演進的步伐日益推進，基于TDM的已有業(yè)務也必然經歷改變或改革以移植到目標網絡上。同時，NGN具有的開放且獨立的網絡分層結構更有利于布置新興的增值業(yè)務，這就促使網絡運營商" title="網絡運營商">網絡運營商和業(yè)務提供商協(xié)作開發(fā)用戶需求的非語音類業(yè)務（例如傳真、短信、Web等）。于是，如何將基于窄帶的語音業(yè)務" title="語音業(yè)務">語音業(yè)務與基于寬帶的非語音類業(yè)務進行統(tǒng)一控制以減少網絡成本是網絡運營商關注的焦點。
??? 呼叫中心是企業(yè)為客戶提供的服務之一，它包括咨詢、查詢和投訴等多種服務，目的是為企業(yè)和客戶之間提供及時交流的平臺。傳統(tǒng)的呼叫中心是基于TDM技術，它只提供了人工語音和交互式語音應答IVR（Interactive Voice Response）兩種方式，對于擁有大規(guī)?？蛻羧旱钠髽I(yè)來說只有增加座席才能達到業(yè)務質量指標。在此情況下，若呼叫中心增加傳真、短信和Web等業(yè)務不僅能夠豐富服務的提供方式以提升客戶體驗，而且能夠將一些不是很急迫的服務請求從實時的語音服務中分流出去，這樣可以降低平臺負荷以減少企業(yè)成本，同時又可提升一定的業(yè)務質量指標。
??? 基于下一代呼叫中心的網絡結構來實現(xiàn)上述非語音類業(yè)務是本文的研究重點。
1 下一代呼叫中心
??? 下一代呼叫中心是基于NGN實現(xiàn)的呼叫中心系統(tǒng)。它繼承了傳統(tǒng)的語音業(yè)務，又補充了諸如傳真等非語音類業(yè)務。在系統(tǒng)結構上，它遵循了NGN分層結構的思想，通過應用可編程接口API（Application Programming Interface）或公用對象請求代理程序體系結構CORBA（Common Object Request Broker Architecture）中間件進行層與層之間的通信，以真正實現(xiàn)業(yè)務與控制分離，控制與承載分離，承載與接入分離，這樣有利于迅速引入新的業(yè)務，也有利于網絡各層獨立進行升級，更有利于實現(xiàn)第三方開發(fā)。
??? 下一代呼叫中心的系統(tǒng)結構如圖1所示。虛線框所包含的是用于呼叫中心的網元設備。整個呼叫中心按職能可以分成四層，從下至上分別是業(yè)務接入層" title="接入層">接入層、業(yè)務支撐層、業(yè)務執(zhí)行層和業(yè)務提供層。
??????????????????????????

??? 業(yè)務接入層是向外部呼叫提供訪問呼叫中心的入口。位于該層的設備是軟自動呼叫分配Soft ACD（Soft Automatic Call Distributor），它是軟交換SS（Softswitch）設備的擴充，以完成呼叫鏈路" title="鏈路">鏈路的建立。它采用若干排隊策略（例如，根據用戶號碼、終端特性或者用戶要求來劃分）將不同的呼叫分配到不同的隊列，每個隊列對應一位座席或者一個虛擬座席（IVR資源號），以保證呼叫的有序進行。Soft ACD設備內部存有一些預置的語音媒體資源用于不同的場景下，例如，當呼叫接入時它可以給終端播放廣告，或者在用戶等待座席接聽時播放等待音，或者在無可用資源的情況下呼叫被置于等待隊列時播放音樂等。
??? 業(yè)務支撐層負責對呼叫路由的控制和資源分配的統(tǒng)一管理，其核心設備是計算機電話集成CTI（Computer Telephone Integration）。CTI接收來自Soft ACD的呼叫請求，接著根據請求查詢上層相應的資源（座席或IVR）并從所有可用資源中依據某個策略（例如資源使用情況）選擇一個資源，然后將該資源號返回給Soft ACD，由SoftACD建立外部呼叫和資源之間的鏈路。在無可用資源的情況下，CTI也會將該事件返回給Soft ACD，指示Soft ACD將外部呼叫置入等待隊列中，同時，CTI會對上層資源進行監(jiān)視，一旦發(fā)現(xiàn)資源可用就再將資源號發(fā)送給Soft ACD，由Soft ACD完成后續(xù)的工作。
??? 業(yè)務執(zhí)行層提供了業(yè)務執(zhí)行的環(huán)境，根據業(yè)務功能主要分成人工和自動兩個執(zhí)行環(huán)境。人工服務由Agent（代理）負責，Agent是座席的統(tǒng)稱，座席可以根據技能或等級分組，組長能夠對組員的狀態(tài)進行監(jiān)視和控制。一旦Soft ACD在CTI的控制下完成了外來呼叫與座席的連接，座席側就開始振鈴（之后的過程與普通電話呼叫過程相同）。座席在和來電者的通話中可以根據來電者的請求或問題訪問上層做相應操作，在操作進行中座席以播放音樂的形式將電話保持住，當操作完成后再用結束音樂回復用戶。自動服務則由IVR/MS（Media Server媒體服務器）來完成，服務流程依據CTI指定的語音擴展標記語言VXML（Voice Extensible Markup Language）腳本，腳本由上一層提供，IVR/MS在CTI指示下連接上層服務器以下載。另外，在CTI的控制和橋接下，Agent和IVR/MS之間可以傳送隨路數據以實現(xiàn)人工與自動之間的轉換。
??? 最上層的業(yè)務提供層是存儲業(yè)務數據和生成業(yè)務腳本的關鍵層，其中應用服務器負責管理所有用戶信息、生成IVR業(yè)務執(zhí)行腳本以及為Agent提供操作平臺。數據庫存儲用戶信息和業(yè)務數據，可以是本地的數據庫，也可以是遠端數據庫以實現(xiàn)數據共享。文件服務器一般是為本地Application服務的，用于存放業(yè)務腳本模板。
可見，下一代呼叫中心具有層次清晰，職能明確的特點，符合網絡發(fā)展的要求。
2 非語音類業(yè)務的實現(xiàn)方案
??? 在下一代呼叫中心系統(tǒng)中需要增加的非語音類業(yè)務主要是傳真、短信和Web，下面分別介紹它們的實現(xiàn)方案。
2.1傳真業(yè)務
??? 將傳真業(yè)務用于呼叫中心是為解決客戶需要查詢大量資料而過長地占用語音鏈路的問題，也給呼叫中心提供了一種能夠有效回復客戶所咨詢的問題的方式。
??? 根據一般傳真資料的流程——呼叫、連接、發(fā)送、結束，可以將傳真看成是語音呼叫的特例。也就是對Soft ACD來說，處理傳真與處理一般語音呼叫的請求是基本一樣的，惟一區(qū)別在于它們攜帶的呼叫標識不一樣，Soft ACD能夠根據標識將傳真和語音呼叫分配到不同的隊列中，而CTI則控制Soft ACD將IVR/MS和SS先建立語音鏈路，等IVR/MS從應用服務器取得傳真腳本后由IVR/MS依據腳本完成以后的操作來實現(xiàn)語音鏈路到傳真鏈路的切換。
??? 圖2和圖3分別是呼叫中心接收外來傳真和呼叫中心向外發(fā)送傳真的業(yè)務流程。與語音業(yè)務一樣，SS和Soft ACD之間以及Soft ACD和IVR/MS之間均是采用標準的SIP協(xié)議^[1]；Soft ACD和CTI之間一般采用CSTA協(xié)議[2]就可以完成一般語音業(yè)務和傳真業(yè)務的操作，也可以使用Parlay API來滿足多媒體需求；CTI和IVR/MS之間目前還沒有標準的協(xié)議，建議采用基于動態(tài)鏈接庫DLL（Dynamic Link Library）的API進行功能調用，這將是接下來的研究工作；應用服務器和IVR/MS之間是通過超文本傳輸協(xié)議HTTP來傳送VXML[3]腳本的，需要對VXML增加傳真標識等傳真屬性來支持傳真業(yè)務；File Servers也是通過HTTP來接收多媒體文件和發(fā)送多媒體文件的。

??????????????????

?????????????????? ?????????
??? 從圖2可知，接收傳真是由網絡中的SS發(fā)起的，當收到用戶終端發(fā)來的帶有傳真標識的呼叫后，SS首先將呼叫請求發(fā)送到呼叫中心的接入層，由Soft ACD排列此呼叫請求（步驟1）。假設此前傳真隊列中沒有滯留的請求，Soft ACD向CTI查詢IVR資源，若有空閑資源，CTI回復IVR資源號并通知IVR/MS（步驟2～4）；反之，CTI命令Soft ACD將此呼叫置于等待并播放等待音。根據獲得的資源號，SoftACD將外側的呼叫連接到相應的IVR鏈路（步驟5～11）。連接成功后，IVR/MS將結果回復給CTI并向上層獲取接收傳真的業(yè)務腳本（步驟12～14）。于是，按照VXML腳本中的指令順序，IVR/MS先去CTI獲取諸如傳真端口一類的數據，然后通知Soft ACD切換到傳真鏈路，獲得成功響應后即開始傳真（步驟15～19）。傳真接收完成后，IVR/MS會將傳真數據保存在文件服務器中，并將傳真結果告訴CTI，最后斷開傳真鏈路（步驟20～27）。
??? 呼叫中心接收到的傳真將由CTI指派給狀態(tài)為空閑的座席來處理，處理好的傳真仍然放在文件服務器中。為了不影響座席處理后續(xù)業(yè)務，發(fā)送傳真將由后臺來進行，因此引入了GW（Gateway網關）設備，其網絡位置如圖1， CTI和GW之間也建議通過API進行功能調用。座席需要向CTI預設發(fā)送傳真的時間，缺省為按隊列前后順序。CTI將傳真文件標識、發(fā)送時間和目標地址轉發(fā)給網關，由網關對所有待發(fā)傳真的任務進行管理并按時發(fā)起發(fā)送傳真的操作（如圖3）。
??? 從圖3可知，發(fā)送傳真的大部分信令流程和接收傳真的一樣，也是分成建立語音鏈路——切換為傳真鏈路——傳真結束三個階段。兩者的不同點主要在于：(1)在發(fā)送傳真的流程中，語音到傳真的鏈路切換不是由IVR/MS直接發(fā)起的，而是由IVR/MS通過已建的語音鏈路向SS發(fā)送隨路數據（如傳真端口和Ready就緒消息），使外部傳真設備產生傳真信號，再由接收人員按下“傳真”鍵發(fā)出鏈路切換指令，于是由SS通過Soft ACD向IVR/MS發(fā)送Re_Invite[1]消息以切換到傳真端口（步驟20～21），等SS收到來自IVR/MS的200確認消息后即開始傳真。(2)當呼叫中心向外發(fā)送傳真結束時，斷開鏈路不是由IVR/MS直接發(fā)起，而是在CTI接收到來自IVR/MS的傳真結束通知以后，由CTI指使Soft ACD依次斷開兩邊的鏈路（步驟27～30）。這種由CTI控制后續(xù)流程的方法可以簡化更加復雜的業(yè)務流程，比如傳真轉到人工服務的業(yè)務。其實現(xiàn)方法是當傳真發(fā)送結束（步驟24）后由CTI控制Soft ACD再切回語音鏈路并轉接到座席上。這樣就可以避免重復建立語音鏈路，從而縮短客戶的等待時間和提升客戶的業(yè)務體驗。
2.2 短信/Web業(yè)務
??? 由于目前短信和Web的客戶數量十分巨大且不斷上升，所以它們幾乎成為電信融合業(yè)務必備的子業(yè)務。另外，呼叫中心也可以利用短信和Web業(yè)務來分擔實時語音業(yè)務的負荷。
??? 現(xiàn)有的SMS（短信服務器）和Web服務器都已經相當成熟，因此考慮升級網絡已有設備來實現(xiàn)這兩個業(yè)務。下一代呼叫中心可以通過GW設備與底層網絡中的SMS或Web服務器進行互通。接收短信是由GW將來自SMS服務器的數據，包括短信URL（統(tǒng)一資源定位）和源地址等，轉發(fā)給CTI，再由CTI派發(fā)給座席來處理。處理短信是由指定座席在空閑時完成，座席仍將編輯后的回復短信存放在File Servers中并將相應的URL告訴CTI，再由CTI將短信標識、短信URL、發(fā)送時間等數據發(fā)送給GW。發(fā)送短信則是由GW按序或者座席指定的時間將短信URL和目標地址等數據發(fā)送給SMS服務器，于是就由底層網絡完成發(fā)送短信的操作。
??? Web業(yè)務主要包括Web聊天、瀏覽導航等，其實現(xiàn)方案和短信類似，是由GW代理呼叫中心與底層服務器進行通信，或者接受Web服務器發(fā)來的處理請求，或者調用Web服務器接口執(zhí)行答復客戶的操作。
??? 呼叫中心將逐步成為大型企業(yè)的品牌業(yè)務，優(yōu)化呼叫中心系統(tǒng)的網絡架構、加載多種增值業(yè)務是呼叫中心領域的兩大研究熱點。在層與層之間采用開放式接口和標準化協(xié)議進行通信是NGN的最終目標，因此它是呼叫中心進一步發(fā)展的方向，也是下一代呼叫中心的理想目標。當然，完善呼叫中心體系不能僅僅依靠網絡運營商的努力，而應該通過設備提供商、獨立軟件開發(fā)商和網絡運營商三方面協(xié)作來不斷地實踐和驗證。
參考文獻
[1] ROSENBERG J, SCHULZRINNE H, CAMARILLO G,et al.RFC 3261.SIP: Session Initiation Protocol[S]. USA. June
?2002.
[2] ?ECMA. Monica Broxner-TR-068.DOC-03.05.95 16,09,Scenarios for Computer Supported Telecommunications
?Applications (CSTA) Phase II[S]. http://www.ecma.ch,December 1994.
[3] ?MCGLASHAN S, BURNETT D C, CARTER J, et al.Voice Extensible Markup Language (VoiceXML) Version
?2.0[EB/OL]. http://www.w3.org/TR/2004/REC-voicexml20-20040316/, March 16, 2004