專利名稱：用于通話控制和媒體控制的統(tǒng)一框架和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及遠(yuǎn)程通信和網(wǎng)絡(luò)計(jì)算機(jī)電話系統(tǒng)，包括互聯(lián)網(wǎng)和公共交換電話系統(tǒng)，并且更具體地涉及ー種用于實(shí)現(xiàn)供通話控制和媒體控制使用的統(tǒng)ー框架的系統(tǒng)和方法。
背景技術(shù)：
世界范圍內(nèi)已經(jīng)發(fā)展出兩種主要的遠(yuǎn)程通信網(wǎng)絡(luò)。第一種是形式為公共交換電話系統(tǒng)(PSTN)的電話系統(tǒng)網(wǎng)絡(luò)。該網(wǎng)絡(luò)最初被設(shè)計(jì)用于傳送語(yǔ)音通信，不過隨后也適用于傳輸數(shù)據(jù)。第二種是形式為互聯(lián)網(wǎng)的計(jì)算機(jī)系統(tǒng)網(wǎng)絡(luò)?；ヂ?lián)網(wǎng)不但被設(shè)計(jì)用于傳送數(shù)據(jù)，而且正越來越多地被用于傳輸語(yǔ)音和多媒體信息。計(jì)算機(jī)實(shí)現(xiàn)的電話應(yīng)用已經(jīng)被集成到這兩種遠(yuǎn)程通信網(wǎng)絡(luò)中以提供更好的通信服務(wù)。例如在PSTN上，計(jì)算機(jī)電話集成已經(jīng)為POTS (普通老式電話服務(wù))提供了更多的功能和控制。在互聯(lián)網(wǎng)上，計(jì)算機(jī)自身就是用于語(yǔ)音通信的終端設(shè)備并且還用作供終端設(shè)備的主機(jī)使用的智能路由器和控制器。互聯(lián)網(wǎng)是根據(jù)TCP/IP (傳輸控制協(xié)議/互聯(lián)網(wǎng)協(xié)議)套件通信的IP網(wǎng)絡(luò)全球通信網(wǎng)。具體地，語(yǔ)音和其他多媒體信息根據(jù)VoIP (互聯(lián)網(wǎng)語(yǔ)音傳輸)協(xié)議在互聯(lián)網(wǎng)上傳輸。PSTN和IP網(wǎng)絡(luò)的集成通過利用IP網(wǎng)絡(luò)固有的路由靈活性和計(jì)算可達(dá)性而允許在自動(dòng)化語(yǔ)音應(yīng)用方面有更多便利。美國(guó)專利US6922411中介紹了ー種用于簡(jiǎn)單配置電話應(yīng)用的示例性平臺(tái)，通過引用將其全部公開內(nèi)容并入本文。實(shí)際上，網(wǎng)絡(luò)電話系統(tǒng)允許用戶配置與指定電話號(hào)碼相關(guān)聯(lián)的互聯(lián)網(wǎng)計(jì)算機(jī)電話應(yīng)用。電話應(yīng)用很容易由用戶在XML(擴(kuò)展標(biāo)記語(yǔ)言)中用預(yù)定義的電話XML標(biāo)簽(例如VoiceXML)創(chuàng)建并且易于在網(wǎng)站上配置。電話XML標(biāo)簽包括用于通話控制和媒體控制的內(nèi)容。用于這些指定電話號(hào)碼中任何一個(gè)的通話都可以源于任何ー種網(wǎng)絡(luò)電話系統(tǒng)例如PSTN(公共交換電話系統(tǒng))、無線網(wǎng)絡(luò)或互聯(lián)網(wǎng)。通話由互聯(lián)網(wǎng)上安裝的應(yīng)用網(wǎng)關(guān)中心(AGC)接收。類似于網(wǎng)絡(luò)瀏覽器，AGC提供設(shè)備以用于從其網(wǎng)站中檢索相關(guān)的XML應(yīng)用并相應(yīng)地處理通話。這種類型的電話平臺(tái)允許在互聯(lián)網(wǎng)上構(gòu)建和配置非常強(qiáng)大而又簡(jiǎn)單的電話應(yīng)用。以下是在這種平臺(tái)上配置的電話應(yīng)用的ー些示例?！案?發(fā)現(xiàn)(Follow me, find me)”應(yīng)用相繼呼叫由用戶指明的一系列電話號(hào)碼，直到其中ー個(gè)號(hào)碼應(yīng)答井隨后連接該通話為止。否則，它就做一些別的事例如收取信息或發(fā)送電子郵件或者向呼叫中心發(fā)送呼叫等。在另ー個(gè)示例中，電話調(diào)查應(yīng)用查詢待調(diào)查人口的電話號(hào)碼數(shù)據(jù)庫(kù)。然后僅受所支持的并行對(duì)話最大數(shù)量限制地并行呼叫多個(gè)號(hào)碼，然后響應(yīng)于被呼叫方的應(yīng)答播放一系列交互式語(yǔ)音提示/信息并在數(shù)據(jù)庫(kù)中記錄結(jié)果等。在另ー個(gè)示例中，幫助臺(tái)(Help Desk)應(yīng)用響應(yīng)于被呼叫方的應(yīng)答播放一系列交互式語(yǔ)音提示/信息并且可以將連接與在線客服通話作為ー種選擇等。在又ー個(gè)不例中，股市或銀行交易應(yīng)用響應(yīng)于被呼叫方的應(yīng)答播放一系列交互式語(yǔ)音提示/信息并且利用后端數(shù)據(jù)庫(kù)或網(wǎng)絡(luò)應(yīng)用來進(jìn)行合適的交易等。后面的示例通常稱為自助式應(yīng)用。在語(yǔ)音領(lǐng)域，自助式應(yīng)用被稱為IVR。IVR涉及交互式語(yǔ)音應(yīng)答并且是一種與電話呼叫方自動(dòng)交互的技術(shù)。企業(yè)正越來越多地轉(zhuǎn)至IVR以降低常規(guī)的銷售、服務(wù)、催收催繳、查詢和支持其公司往來呼叫的成本。IVR解決方案使用戶能夠從任意的電話中通過音頻信道將語(yǔ)音用作媒體內(nèi)容或其他形式的輸入以檢索包括銀行結(jié)存、航班時(shí)刻表、產(chǎn)品細(xì)節(jié)、訂單狀態(tài)、電影上映時(shí)間與更多內(nèi)容的信息。另外，IVR解決方案正越來越多地用于設(shè)置呼出電話以輸送或收集關(guān)于預(yù)約、過期賬單以及其他時(shí)間關(guān)鍵性事件和活動(dòng)的信息。

圖1示意性地示出了通信應(yīng)用環(huán)境。通信應(yīng)用環(huán)境10包括與應(yīng)用平臺(tái)100內(nèi)的通信應(yīng)用服務(wù)器200交互的一個(gè)或多個(gè)客戶端。應(yīng)用平臺(tái)100主持由以面向?qū)ο筌浖帉懙膽?yīng)用腳本210指明的應(yīng)用。通信應(yīng)用服務(wù)器200包括用于解讀并執(zhí)行應(yīng)用腳本210的瀏覽器220。應(yīng)用腳本的執(zhí)行調(diào)用應(yīng)用服務(wù)器200內(nèi)的一個(gè)或多個(gè)服務(wù)器端組件。在客戶端和通信服務(wù)器中，這些組件310提供的服務(wù)用于通話控制、與ー個(gè)或多個(gè)媒體服務(wù)器230之間的媒體控制還有與后端系統(tǒng)240例如數(shù)據(jù)庫(kù)以及業(yè)務(wù)邏輯和遺留系統(tǒng)例如CRM(客戶關(guān)系管理)和ERP (企業(yè)資源管理)的交互。該平臺(tái)的ー個(gè)示例是主持一種在多信道環(huán)境中用語(yǔ)音、文本信息和其他客戶端交互的IVR應(yīng)用。通信應(yīng)用平臺(tái)在任意數(shù)量的客戶端20，22，30之間提供了第三方通話控制。應(yīng)用腳本210定義了通信應(yīng)用300并且指導(dǎo)如何處理通話。例如，當(dāng)用戶通過語(yǔ)音客戶端例如電話聽筒20或VoIP電話22向IVR發(fā)起呼叫時(shí)，檢索與呼叫號(hào)碼相關(guān)聯(lián)的語(yǔ)音應(yīng)用腳本210。瀏覽器220執(zhí)行或提供檢索到的語(yǔ)音應(yīng)用腳本以允許用戶與語(yǔ)音應(yīng)用300交互。終端和第三方通話控制器之間的多媒體信息通信通常都需要通話控制和媒體控制。圖2A至圖2C示出了多個(gè)客戶端例如VoIP電話22或終端與通信應(yīng)用服務(wù)器200中的各種通話場(chǎng)景。圖2A示出了 VoIP電話形式的客戶端呼叫通信應(yīng)用服務(wù)器。例如，通信應(yīng)用服務(wù)器200主持IVR并且VoIP電話22呼叫IVR。呼叫信號(hào)和媒體內(nèi)容在VoIP電話22和應(yīng)用服務(wù)器200之間交換。圖2B示出了第一 VoIP電話呼叫第二 VoIP電話。作為第三方通話控制器,應(yīng)用服務(wù)器200控制第一和第二電話之間的通話。在第一電話22-1和應(yīng)用服務(wù)器200之間建立起ー個(gè)通話連接。在第二電話22-2和應(yīng)用服務(wù)器200之間建立起另ー個(gè)通話連接。兩個(gè)電話隨后連接在應(yīng)用服務(wù)器上以允許第一電話與第二電話通話。在此場(chǎng)景中，媒體內(nèi)容可以用兩種模式中的一種進(jìn)行處理。在橋接模式下，兩部電話之間交換的媒體內(nèi)容通過應(yīng)用服務(wù)器路由。在直連模式下，媒體內(nèi)容在兩部電話之間直接交換。圖2C示出了處于會(huì)議中的三部電話。在此場(chǎng)景中，每一部電話都建立起接至應(yīng)用服務(wù)器的通話。三路通話隨后在應(yīng)用服務(wù)器連接或混合以提供會(huì)議功能。對(duì)于通話控制，已經(jīng)提出了用于互通性的多種協(xié)議標(biāo)準(zhǔn)。例如，H.323標(biāo)準(zhǔn)是ー種由ITU (國(guó)際電信聯(lián)盟)推薦的用于IP技術(shù)的信號(hào)傳輸和通話控制的協(xié)議標(biāo)準(zhǔn)。一種越來越普及的替代H.323用于通話控制的標(biāo)準(zhǔn)是SIP( “會(huì)話發(fā)起協(xié)議”)。SIP是ー種IETF(互聯(lián)網(wǎng)工程任務(wù)組)協(xié)議，用于IP電話的信號(hào)傳輸和通話控制以及兩臺(tái)或多臺(tái)終端之間的多媒體通信。這種協(xié)議基于文本并且更加以網(wǎng)絡(luò)為中心，因此是ー種相對(duì)簡(jiǎn)單和更加輕量級(jí)的替代札323的協(xié)議。在傳統(tǒng)的網(wǎng)絡(luò)范例中，形式為運(yùn)行網(wǎng)絡(luò)瀏覽器的客戶機(jī)的用戶主體向網(wǎng)絡(luò)服務(wù)器發(fā)出請(qǐng)求。網(wǎng)絡(luò)服務(wù)器返回對(duì)請(qǐng)求的響應(yīng)。通信根據(jù)HTTP (超文本傳輸協(xié)議)進(jìn)行。具體地，網(wǎng)絡(luò)瀏覽器請(qǐng)求網(wǎng)絡(luò)資源例如由來自網(wǎng)絡(luò)服務(wù)器的網(wǎng)址明確的網(wǎng)頁(yè)。通常網(wǎng)絡(luò)服務(wù)器通過返回請(qǐng)求的網(wǎng)頁(yè)做出響應(yīng)。網(wǎng)頁(yè)可以包含文本內(nèi)容以及用于瀏覽器以在網(wǎng)頁(yè)中顯示出文本的嵌入指令。在更為復(fù)雜的應(yīng)用中，網(wǎng)頁(yè)經(jīng)常通過使用服務(wù)器端程序動(dòng)態(tài)生成并且可以加入例如來自后端數(shù)據(jù)庫(kù)的查詢結(jié)果等內(nèi)容。因此，部分內(nèi)容并非硬編碼在網(wǎng)頁(yè)上而是由網(wǎng)絡(luò)服務(wù)器動(dòng)態(tài)地生成和顯示。服務(wù)器端程序也可以用于將數(shù)據(jù)從客戶端發(fā)送至后端數(shù)據(jù)庫(kù)。通常，這些服務(wù)器端程序被實(shí)現(xiàn)為符合CGI (通用網(wǎng)關(guān)接ロ )協(xié)議的腳本。CGI是在網(wǎng)絡(luò)服務(wù)器上執(zhí)行任務(wù)以生成并顯示動(dòng)態(tài)內(nèi)容或者執(zhí)行其他后端功能的代碼模塊。但是，CGI具有若干缺點(diǎn)。首先，CGI的移植性不太好，原因在于不同的網(wǎng)絡(luò)服務(wù)機(jī)器具有不同的處理器和操作系統(tǒng)，可能需要它們自用版本的腳本。其次，CGI不能有效地利用服務(wù)器的資源。不同的CGI在與起動(dòng)它們的服務(wù)器不同的進(jìn)程關(guān)聯(lián)中運(yùn)行。對(duì)于每ー個(gè)請(qǐng)求都有創(chuàng)建ー個(gè)新進(jìn)程的開銷，并且不同的進(jìn)程無法訪問服務(wù)器資源中的公共集。JAVA 服務(wù)器端應(yīng)用程序(servlet)模型解決了 CGI的這些缺點(diǎn)。Servlet是用高度可移植性的JAVA 編程語(yǔ)言編寫的模塊，由于它們是在相同的JAVA虛擬機(jī)中運(yùn)行，因此獨(dú)立于處理器的硬件或者操作系統(tǒng)。在面向?qū)ο蟮腏ava編程語(yǔ)言中，分析HTTP請(qǐng)求并使之與軟件對(duì)象交互，軟件對(duì)象根據(jù)由應(yīng)用操作的實(shí)際對(duì)象建摸。類似地，生成符合HTTP協(xié)議的響應(yīng)并隨后發(fā)往請(qǐng)求者。Servlet運(yùn)行在Java服務(wù)器的多線程環(huán)境中并且允許通過單獨(dú)的tread類來處理每ー個(gè)請(qǐng)求。與并發(fā)請(qǐng)求需要載入多份CGI腳本副本的CGI相比，還有ー種Java腳本的范例則需要載入到處理器內(nèi)存中。原始Servlet符合HTTP協(xié)議并且可以被視為“HTTP servlet”。Servlet模型提供了通過在應(yīng)用服務(wù)器內(nèi)載入對(duì)應(yīng)的servlet容器而實(shí)現(xiàn)的ー組API (應(yīng)用程序設(shè)計(jì)接ロ)。Servlet模型使開發(fā)人員能夠快速開發(fā)應(yīng)用并且將其移植到不同的服務(wù)器并能夠高效運(yùn)行。Servlet模型在網(wǎng)絡(luò)應(yīng)用中廣泛使用并且以開放性的標(biāo)準(zhǔn)為基礎(chǔ)。API是描述一種用于與組件所用函數(shù)組交互的接ロ的抽象。它是ー種包含庫(kù)內(nèi)所包括函數(shù)組的描述并且解決特定問題的列表。在當(dāng)前Java面向?qū)ο笳Z(yǔ)言的語(yǔ)境中，API包括ー組Java類定義以及擴(kuò)展類定義的描述，擴(kuò)展類定義具有與類相關(guān)聯(lián)的ー組行為。API可以被認(rèn)為是通過類(類接ロ)公開的所有方法的全集。這就意味著API規(guī)定了用于處理由類定義得出的對(duì)象的方法。對(duì)于通話控制，SIP servlet已經(jīng)被開發(fā)并確立為用于根據(jù)SIP協(xié)議處理請(qǐng)求的標(biāo)準(zhǔn)，正如HTTP servlet根據(jù)HTTP協(xié)議處理請(qǐng)求一祥。圖3A示出了圖1所示通信應(yīng)用中服務(wù)器端組件的通話控制對(duì)象實(shí)現(xiàn)為SIPservlet的現(xiàn)有實(shí)施方式。通話控制對(duì)象的形式為SIP servlet 320。這一點(diǎn)通過實(shí)現(xiàn)SIPservlet容器340和SIP servlet通話控制API 350而可行。SIP Servlet Specification(JSR 289)是ー種基于容器的方法(根據(jù) HTTPservlet范例建模)以利用會(huì)話發(fā)起協(xié)議(SIP)開發(fā)通信應(yīng)用。SIPservlet是ー種執(zhí)行SIP信號(hào)傳輸?shù)腏ava編程語(yǔ)言的服務(wù)器端組件。SIPservlet由SIP servlet容器管理,其通常是實(shí)現(xiàn)SIP的應(yīng)用服務(wù)器的一部分。SIP servlet通過響應(yīng)輸入的SIP請(qǐng)求并返回對(duì)應(yīng)的SIP響應(yīng)而與客戶端交互。SIP servlet由Java Servlet Specification提供的通用servlet API 構(gòu)建，Java Servlet Specification 是一種由 Java Community Process (SM)程序通過Java Specification Request (JSR)過程建立的開放性標(biāo)準(zhǔn)。將SIP servlet (JSR 289)用于通話控制以發(fā)揮servlet模型的優(yōu)勢(shì)。還提供了獨(dú)立于底層媒體服務(wù)器控制協(xié)議的Java API。美國(guó)專利US7865607B2公開了ー種用于富媒體應(yīng)用的servlet模型。用于通話控制的SIP servlet通過媒體控制API擴(kuò)充。但是,媒體控制API是定制的，而且并不符合servlet 模型。對(duì)于媒體控制，媒體控制對(duì)象如圖3A所示由基于標(biāo)準(zhǔn)的媒體控制API，JSR 309支持。因此，媒體服務(wù)器的細(xì)節(jié)由JSR 309驅(qū)動(dòng)器處理，允許應(yīng)用開發(fā)人員獨(dú)立于媒體服務(wù)器的供應(yīng)商利用JSR 390的API編程。用這種方式，應(yīng)用程序就能夠與由不同操作人員和服務(wù)供應(yīng)商配置的不同媒體服務(wù)器一起工作。因此，應(yīng)用開發(fā)人員就能根據(jù)開放性標(biāo)準(zhǔn)JSR 289在底層通話控制對(duì)象和API方面開發(fā)出形式為SIP Servlet的通信應(yīng)用組件，并且在底層媒體控制對(duì)象和API方面開發(fā)出形式為開放性標(biāo)準(zhǔn)JSR 309的通信應(yīng)用組件。利用底層和通用對(duì)象及其API工作的一種缺點(diǎn)是開發(fā)人員必須重復(fù)性地處理底層的細(xì)節(jié)，即使是這些細(xì)節(jié)在建模對(duì)象處于某些狀態(tài)時(shí)無關(guān)緊要也仍然如此。圖3B示出了現(xiàn)有的應(yīng)用實(shí)施方式為何必須根據(jù)圖3A中所示的標(biāo)準(zhǔn)通話控制和媒體控制API處理每ー個(gè)事件。例如，SIP servlet接收到再見(BYE)請(qǐng)求以結(jié)束通話。它檢查現(xiàn)在所處的狀態(tài)以相應(yīng)地采取動(dòng)作。在仍處于“連通(CONNECTED)”狀態(tài)時(shí)，調(diào)用doBYE方法以終止連接并執(zhí)行相關(guān)的通話切斷和清理任務(wù)。但是，用戶即使在通話連接建立之前也可能會(huì)決定終止呼叫。在此情況下甚至并未處于“CONNECTED”狀態(tài)，并且因此根據(jù)狀態(tài)無需servlet接收BYE請(qǐng)求并執(zhí)行任何通話切斷任務(wù)。盡管如此，在當(dāng)前的實(shí)施方式中，每一次接收到BYE請(qǐng)求，servlet仍然必須對(duì)其狀態(tài)進(jìn)行檢查并相應(yīng)地采取動(dòng)作。因此而增加的檢查和處理無關(guān)請(qǐng)求的負(fù)擔(dān)就變成了應(yīng)用代碼的一部分。這一點(diǎn)對(duì)于媒體事件同樣成立，并且應(yīng)用程序必須提供邏輯和附加代碼來處理可能無法應(yīng)用于當(dāng)前狀態(tài)的事件。希望研發(fā)出ー種應(yīng)用程序不必處理與當(dāng)前處理的對(duì)象模型無關(guān)的細(xì)節(jié)。而且，希望獲得ー種系統(tǒng)和一致的處理通話控制和媒體控制事件的方法，不必處理它們?cè)趹?yīng)用中的底層細(xì)節(jié)從而獲得簡(jiǎn)潔和高效的代碼。

發(fā)明內(nèi)容
根據(jù)本發(fā)明的ー種主要應(yīng)用，一種通信系統(tǒng)包括在Java虛擬機(jī)中主持通信應(yīng)用的服務(wù)器。通信應(yīng)用采用統(tǒng)ー的通信API編程。統(tǒng)ー的通信API是ー種在基于標(biāo)準(zhǔn)的通話控制API和基于標(biāo)準(zhǔn)的媒體控制API上層的統(tǒng)一通信框架層。統(tǒng)ー的通信API提供對(duì)用于應(yīng)用對(duì)象模型的統(tǒng)ー類對(duì)象的訪問。統(tǒng)ー的類對(duì)象由獨(dú)立的通話控制API和媒體控制API中的基元類對(duì)象構(gòu)成。根據(jù)本發(fā)明的ー種應(yīng)用，統(tǒng)ー的類對(duì)象包括事件源對(duì)象，它以統(tǒng)一的方式處理通話控制API和媒體控制API中通常獨(dú)立的事件。具體地，事件源對(duì)象僅根據(jù)事件類型和應(yīng)用狀態(tài)向應(yīng)用分配與應(yīng)用的對(duì)象模型相符的事件。用這種方式，應(yīng)用可以通過將Java類對(duì)象加工為應(yīng)用的對(duì)象模型而方便地構(gòu)建，其中類對(duì)象以基于標(biāo)準(zhǔn)的API中的基元Java類對(duì)象為基礎(chǔ)。與此同時(shí)，由于能夠集中在業(yè)務(wù)邏輯上而不必處理基元類對(duì)象中的底層細(xì)節(jié)，因此應(yīng)用編程得以簡(jiǎn)化。本發(fā)明的更多目標(biāo)、特征和優(yōu)點(diǎn)將根據(jù)以下對(duì)其優(yōu)選實(shí)施例的說明而得到理解，這些說明內(nèi)容應(yīng)該與附圖相結(jié)合。附圖簡(jiǎn)要說明圖1示意性地示出了通信應(yīng)用環(huán)境。圖2A示出了呼叫通信應(yīng)用服務(wù)器的VoIP電話形式的客戶端。圖2B示出了呼叫第二 VoIP電話的第一 VoIP電話。圖2C示出了處于會(huì)議中的三部電話。圖3A示出了圖1所示通信應(yīng)用中實(shí)現(xiàn)為SIP servlet的服務(wù)器端組件的通話控制對(duì)象。圖3B示出了應(yīng)用為何必須根據(jù)圖3A中所示的標(biāo)準(zhǔn)通話控制和媒體控制API處理
每ー個(gè)事件。圖4示意性地示出了統(tǒng)一通信框架的常用實(shí)施方式。圖5示出了用于編程通信應(yīng)用的統(tǒng)一通信框架的實(shí)施方式，其中通信服務(wù)器類似于圖1和圖2A-2C中所示用作第三方的通話控制和媒體控制。圖6示出了通過統(tǒng)一通信框架中的應(yīng)用有效處理事件的示例。圖7以UML (統(tǒng)ー建模語(yǔ)言)示意圖示出了應(yīng)用對(duì)象。圖8以UML示意圖示出了通話對(duì)象。圖9以UML示意圖示出了會(huì)議對(duì)象。圖10以UML示意圖示出了媒體服務(wù)對(duì)象。 圖11以UML示意圖示出了事件源對(duì)象。圖12示出了統(tǒng)一通信框架的優(yōu)選實(shí)施方式中的各種類。用于通話控制和媒體控制的統(tǒng)ー框架根據(jù)本發(fā)明的ー種主要應(yīng)用，ー種通信系統(tǒng)包括主持通信應(yīng)用的服務(wù)器。通信應(yīng)用采用統(tǒng)一的通信API編程。統(tǒng)ー的通信API是ー種在基于標(biāo)準(zhǔn)的通話控制API和基于標(biāo)準(zhǔn)的媒體控制API上層的統(tǒng)一通信框架層。統(tǒng)ー的通信API提供對(duì)由獨(dú)立的通話控制API和媒體控制API中的基元對(duì)象構(gòu)成的統(tǒng)ー對(duì)象的訪問。軟件框架在計(jì)算機(jī)編程中是ー種抽象，其中提供一般性功能的通用代碼可以由提供專用功能的用戶代碼選擇性地專用?？蚣苁擒浖?kù)的ー種特殊情形，原因在于它們是包裝在精確定義的API中的可重復(fù)使用的抽象代碼，然而它們包含一些使其不同于普通庫(kù)的關(guān)鍵區(qū)別特征。在此情況下，統(tǒng)ー的通信API表示從基元通話控制和媒體控制API得出的進(jìn)ー步抽象，其更加接近地建模由應(yīng)用解決的實(shí)際情況。更高層對(duì)象模型的抽象通過允許設(shè)計(jì)和編程人員將他們的時(shí)間投入到滿足軟件要求而不是處理更多的提供工作系統(tǒng)的標(biāo)準(zhǔn)底層細(xì)節(jié)而有助于軟件開發(fā)，由此縮短總體的開發(fā)時(shí)間。圖4示意性地示出了統(tǒng)ー通信框架的常用實(shí)施方式。統(tǒng)ー的調(diào)用控制和媒體控制API 420在統(tǒng)ー的通信框架400中提供。統(tǒng)ー的API 420定義了一組類對(duì)象422 (統(tǒng)ー的通信對(duì)象)，這是對(duì)象模型更高層次的抽象。統(tǒng)ー的通信對(duì)象422是由底層通話控制API 350和媒體控制API 360定義的基元對(duì)象的更高層結(jié)構(gòu)。因此，應(yīng)用組件不再是通過操作基元對(duì)象構(gòu)建，而是通過統(tǒng)一通信對(duì)象中的內(nèi)容來構(gòu)建。圖5示出了用于編程通信應(yīng)用的統(tǒng)一通信框架的實(shí)施方式，其中通信服務(wù)器類似于圖1和圖2A-2C中所示用作第三方的通話控制和媒體控制。它通過提供用于通話和媒體控制的統(tǒng)ー模型同時(shí)仍然給出對(duì)底層JSR 289/309API的直接訪問而在SIP ServletQSR289) API 350和Java媒體控制(JSR309)API 360的基礎(chǔ)上構(gòu)建。但是，對(duì)象模型足夠通用以允許在其他協(xié)議例如Jingle和其他類型的通信例如即時(shí)通信的頂層實(shí)現(xiàn)。統(tǒng)ー的通信框架提供了統(tǒng)ー的框架API 420，其中包括一組統(tǒng)ー的通信對(duì)象類。通信應(yīng)用可以在處理這些統(tǒng)一通信對(duì)象類以及JSR 289和JSR 309的API中的基元對(duì)象類方面進(jìn)行編碼。這些統(tǒng)一通信對(duì)象的示例有通話(Call)440、混合器(Mixer)442、媒體服務(wù)(MediaService)446、事件源(EventSource) 430、SIP Servlet 320、媒體事件監(jiān)聽器(MediaEventListener) 332、觀測(cè)器(observer)450 等。用統(tǒng)一通信框架建立應(yīng)用的優(yōu)點(diǎn)在于應(yīng)用是由更加專用于所述應(yīng)用的高層對(duì)象構(gòu)建。通話控制和媒體控制事件被關(guān)聯(lián)至這些高層對(duì)象的具體行為，結(jié)果就是以更加系統(tǒng)和一致的方式處理這些事件而不必讓應(yīng)用去處理底層的細(xì)節(jié)。用這種方式就對(duì)應(yīng)用開發(fā)人員屏蔽了與對(duì)象模型無關(guān)的底層細(xì)節(jié)，并且應(yīng)用的代碼更加簡(jiǎn)潔和高效。圖6示出了通過統(tǒng)一通信框架中的應(yīng)用有效處理事件的示例。統(tǒng)ー的事件處理由統(tǒng)ー事件源對(duì)象430和觀測(cè)器對(duì)象450實(shí)現(xiàn)。統(tǒng)ー事件源對(duì)象EventSource 430將所有的通話控制事件和媒體控制事件串行化以使監(jiān)聽事件源的應(yīng)用組件毎次只需處理ー個(gè)事件。應(yīng)用300加入觀測(cè)器對(duì)象450以監(jiān)聽來自統(tǒng)一事件源對(duì)象430的事件。觀測(cè)器對(duì)象450定義的事件處理方法只有單個(gè)單數(shù)并且其類型是由統(tǒng)一事件源對(duì)象430產(chǎn)生的事件類型。事件處理方法確定由統(tǒng)ー應(yīng)用框架定義的QState (狀態(tài))注釋。統(tǒng)ー事件源對(duì)象430在事件類型匹配事件處理方法中定義的單個(gè)單數(shù)類型或者是單個(gè)參數(shù)類型的父類型時(shí)向事件處理方法分配事件。如果SlState注釋的值不為空，那么統(tǒng)一事件源對(duì)象僅在SlState注釋的值匹配統(tǒng)一事件源對(duì)象的狀態(tài)性質(zhì)時(shí)才向事件處理方法分配事件。 由此觀測(cè)器對(duì)象450只有在事件源430適當(dāng)?shù)靥幱谀承?yīng)用狀態(tài)時(shí)才接收來自于事件源430的事件。例如，應(yīng)用只有在已被初始化之后(也就是處于“初始化”狀態(tài)時(shí))才能開始考慮成為通話一方的邀請(qǐng)。在接收到該事件時(shí)，應(yīng)用隨后應(yīng)調(diào)用MyInviteHandler(我的邀請(qǐng)?zhí)幚砥?來處理邀請(qǐng)。類似地，終止通話的事件(也就是BYE)及其相關(guān)切斷和清理操作只有在通話已經(jīng)實(shí)際建立之后(也就是處于“Connected”狀態(tài)時(shí))才是合適的。在接收到該事件吋，應(yīng)用隨后應(yīng)調(diào)用MyByeHandler (我的再見處理器)來處理BYE。類似地，播放媒體的OutputCompleteEvent (輸出完成事件)在應(yīng)用處于“Connected”狀態(tài)時(shí)的環(huán)境中才是合適的。在接收到該事件吋，應(yīng)用隨后應(yīng)調(diào)用MyPlayerHandler (我的播放器處理器)來處理媒體。與圖3B中示出的應(yīng)用必須監(jiān)聽并處理由JSR 289 API和JSR 309 API生成的每ー個(gè)事件的現(xiàn)有示例不同，這些事件首先由統(tǒng)一通信框架中的事件源對(duì)象430進(jìn)行處理。事件源將僅向應(yīng)用發(fā)送選擇性的設(shè)定事件。例如，如果事件是BYE并且狀態(tài)是“Connected”，那么可以向應(yīng)用發(fā)送事件。另ー方面，如果狀態(tài)是“not connected”(未連通)，那么就不向應(yīng)用發(fā)送事件。通過處理從JSR 289和JSR 309的底層對(duì)象中抽象出的高層對(duì)象，在應(yīng)用層級(jí)的編程就會(huì)更加高效并且與手頭的問題更加相關(guān)。統(tǒng)ー通信框架中的通話控制模型被設(shè)計(jì)用于由第三方服務(wù)器應(yīng)用例如PBX、IVR,會(huì)議和呼叫中心應(yīng)用控制的通話和媒體。假設(shè)所有通話都至少使其信號(hào)由通信應(yīng)用控制。在大多數(shù)情況下，媒體也應(yīng)該優(yōu)選地由通信應(yīng)用控制。表I列出了優(yōu)選實(shí)施例中統(tǒng)一通信框架的調(diào)用控制所涉及的示例性類/對(duì)象。
權(quán)利要求
1.一種用于構(gòu)建在服務(wù)器的Java虛擬機(jī)上執(zhí)行的應(yīng)用組件所用的通話控制和媒體控制的統(tǒng)ー應(yīng)用框架，包括: 通話控制API，用于提供通話控制所用的標(biāo)準(zhǔn)Java接ロ，所述通話控制API定義了ー組用于通話控制的類對(duì)象基元； 媒體控制API，用于提供媒體服務(wù)器控制所用的標(biāo)準(zhǔn)Java接ロ，所述媒體控制API定義了一組用于媒體控制的類對(duì)象基元； 統(tǒng)ー的通話控制和媒體控制API，定義了 ー組由通話控制API和媒體控制API的類對(duì)象基元構(gòu)成的統(tǒng)ー類對(duì)象；并且 其中所述應(yīng)用組件由所述的統(tǒng)ー類對(duì)象構(gòu)建。
2.按權(quán)利要求1所述的統(tǒng)一應(yīng)用框架，其中所述應(yīng)用組件由統(tǒng)ー類對(duì)象以及通話控制API的類對(duì)象基元構(gòu)建。
3.按權(quán)利要求1所述的統(tǒng)一應(yīng)用框架，其中所述應(yīng)用組件由統(tǒng)ー類對(duì)象以及媒體控制API的類對(duì)象基元構(gòu)建。
4.按權(quán)利要求1所述的統(tǒng)一應(yīng)用框架，其中所述統(tǒng)ー類對(duì)象以規(guī)定通話控制API和媒體控制API的類對(duì)象基元中某些預(yù)定結(jié)構(gòu)的特定對(duì)象模型為基礎(chǔ)。
5.按權(quán)利要求1所述的統(tǒng)一應(yīng)用框架，其中所述統(tǒng)ー類對(duì)象包括在符合特定對(duì)象模型的預(yù)定應(yīng)用狀態(tài)下響應(yīng)的統(tǒng)一事件處理器。
6.按權(quán)利要求1所述的統(tǒng)一應(yīng)用框架，其中所述統(tǒng)ー類對(duì)象包括將不適合于特定對(duì)象模型中場(chǎng)景的事件忽略的統(tǒng)ー事件處理器。
7.按權(quán)利要求1所述的統(tǒng)一應(yīng) 用框架，其中所述統(tǒng)ー類對(duì)象包括: 統(tǒng)ー事件源對(duì)象，用于根據(jù)通話控制事件和媒體控制事件生成統(tǒng)ー事件； 明確事件類型和應(yīng)用狀態(tài)的觀測(cè)器對(duì)象；并且 所述統(tǒng)一事件源在事件類型和應(yīng)用狀態(tài)與所述觀測(cè)器對(duì)象明確的內(nèi)容相匹配時(shí)才向所述觀測(cè)器對(duì)象分配具有所述事件類型的統(tǒng)一事件。
8.按權(quán)利要求7所述的統(tǒng)一應(yīng)用框架，其中所述統(tǒng)一事件源將通話控制事件和媒體控制事件串行化以使監(jiān)聽所述事件源的應(yīng)用組件每次只需處理ー個(gè)事件。
9.按權(quán)利要求1所述的統(tǒng)一應(yīng)用框架，其中所述應(yīng)用組件是交互式語(yǔ)音應(yīng)答應(yīng)用的一部分。
10.按權(quán)利要求1所述的統(tǒng)一應(yīng)用框架，其中所述應(yīng)用組件是自助式應(yīng)用的一部分。
11.一種操作服務(wù)器的方法，包括: 提供通話控制API，用于根據(jù)SIP提供通話控制所用的標(biāo)準(zhǔn)Java接ロ并且定義了ー組用于通話控制的類對(duì)象基元； 提供媒體控制API，媒體控制API提供用于媒體服務(wù)器控制的標(biāo)準(zhǔn)Java接ロ并且定義了一組用于媒體控制的類對(duì)象基元； 構(gòu)造統(tǒng)一的通話控制和媒體控制API，定義ー組由通話控制API和媒體控制API的類對(duì)象基元構(gòu)成的統(tǒng)ー類對(duì)象； 配置應(yīng)用，具有根據(jù)統(tǒng)一類對(duì)象的組構(gòu)建的組件；并且 在所述服務(wù)器的Java虛擬機(jī)上執(zhí)行應(yīng)用。
12.按權(quán)利要求11所述的方法，其中所述應(yīng)用組件由所述的統(tǒng)一類對(duì)象以及通話控制API的類對(duì)象基元構(gòu)建。
13.按權(quán)利要求11所述的方法，其中所述應(yīng)用組件由所述的統(tǒng)ー類對(duì)象以及媒體控制API的類對(duì)象基元構(gòu)建。
14.按權(quán)利要求11所述的方法，其中所述統(tǒng)ー類對(duì)象以規(guī)定通話控制API和媒體控制API的類對(duì)象基元中某些預(yù)定結(jié)構(gòu)的特定對(duì)象模型為基礎(chǔ)。
15.按權(quán)利要求11所述的方法，其中所述統(tǒng)ー類對(duì)象包括在符合特定對(duì)象模型的預(yù)定應(yīng)用狀態(tài)下響應(yīng)的統(tǒng)一事件處理器。
16.按權(quán)利要求11所述的方法，其中所述統(tǒng)ー類對(duì)象包括將不適合于特定對(duì)象模型中場(chǎng)景的事件忽略的統(tǒng)一事件處理器。
17.按權(quán)利要求11所述的方法，其中所述統(tǒng)ー類對(duì)象包括: 統(tǒng)ー事件源對(duì)象模型，用于生成通話控制事件和媒體控制事件； 明確事件類型和應(yīng)用狀態(tài)的觀測(cè)器對(duì)象；并且 所述統(tǒng)一事件源在事件類型和應(yīng)用狀態(tài)與所述觀測(cè)器對(duì)象明確的內(nèi)容相匹配時(shí)才向所述觀測(cè)器對(duì)象分配具有所述事件類型的統(tǒng)一事件。
18.按權(quán)利要求17所 述的方法，其中所述統(tǒng)一事件源將通話控制事件和媒體控制事件串行化以使監(jiān)聽所述事件源的應(yīng)用組件毎次只需處理ー個(gè)事件。
19.按權(quán)利要求11所述的方法，其中所述應(yīng)用組件是交互式語(yǔ)音應(yīng)答應(yīng)用的一部分。
20.按權(quán)利要求11所述的方法，其中所述應(yīng)用組件是自助式應(yīng)用的一部分。
全文摘要
一種通信系統(tǒng)和方法，包括在Java虛擬機(jī)內(nèi)主持交互式語(yǔ)音應(yīng)答或自助式應(yīng)用的服務(wù)器。通信應(yīng)用采用由統(tǒng)一應(yīng)用框架提供的統(tǒng)一通信API編程。API提供一組統(tǒng)一的類對(duì)象用于通話控制和媒體控制。統(tǒng)一的類對(duì)象由基于標(biāo)準(zhǔn)的獨(dú)立Java通話控制API和媒體控制API中的類對(duì)象基元構(gòu)成。結(jié)構(gòu)體是一種符合應(yīng)用及其狀態(tài)的對(duì)象模型的結(jié)構(gòu)化和限制性集合。API具有用于通話控制和媒體控制的統(tǒng)一事件處理器并且根據(jù)事件類型和對(duì)象模型的應(yīng)用狀態(tài)向應(yīng)用分配事件。
文檔編號(hào)G06F9/44GK103098023SQ201180029060
公開日2013年5月8日 申請(qǐng)日期2011年4月18日 優(yōu)先權(quán)日2010年4月18日
發(fā)明者陳為, 劉志雨, 祝效普, 何塞·瑪麗亞·小德卡斯特羅 申請(qǐng)人:Voxeo研究有限公司