|
介紹
計算機電話(huà)系統
Dialogic® NetMerge™ CT應用開(kāi)發(fā)環(huán)境
應用環(huán)境語(yǔ)言（ADL）
應用開(kāi)發(fā)ActiveX對象（ADX）
新的方向
■ 介紹
本文可以幫助用戶(hù)了解Dialogic® NetMerge™ CT應用開(kāi)發(fā)環(huán)境（CT ADE）對于項目開(kāi)發(fā)的價(jià)值，可以為用戶(hù)提供以下有價(jià)值的幫助如果用戶(hù)：
- 通常是在C/C++中使用硬件API編寫(xiě)電話(huà)應用
- 使用過(guò)Dialogic早期產(chǎn)品：VOS和CallSuite
- 曾經(jīng)使用過(guò)其他應用開(kāi)發(fā)工具
- 剛剛開(kāi)始進(jìn)行電話(huà)應用開(kāi)發(fā)
■ 計算機電話(huà)應用
開(kāi)始之前，我們應該考慮一下，我們打算使用這種技術(shù)做什么，以何種方式應用這種技術(shù)。
我們的應用需要能夠：
- 檢測和應答到達的呼叫
- 進(jìn)行呼出呼叫并且檢測結果（忙，無(wú)應答，語(yǔ)音應答，機器應答等等）
- 與呼叫方交互（向呼叫方播放語(yǔ)音，來(lái)子呼叫者的信號音和語(yǔ)音）
- 與呼叫方交換數據（從數據庫中讀寫(xiě)數據）
- 控制呼叫（會(huì )議，拆線(xiàn)，轉接，保持，重試）
這些基本的操作應該能夠在下列環(huán)境中執行：
- 多種協(xié)議的網(wǎng)絡(luò )中（環(huán)路啟動(dòng)，T-1/E-1 CAS, ISDN, IP），網(wǎng)絡(luò )協(xié)議隨國家而改變
- 多種尺寸的設備中（一個(gè)機箱2個(gè)模擬端口，一個(gè)機箱500個(gè)端口，多個(gè)協(xié)作的機箱）
- 多種操作系統控制下（Windows, Linux, Unix）
- 與系統管理監控器和管理器相連接
最后，所有的這些任務(wù)都要和商業(yè)邏輯協(xié)調工作，輸入分析，控制操作，和輸出。
創(chuàng )建這種應用的可選項有：
- 軟件包－如果您的應用執行相當普通的操作，您會(huì )發(fā)現完軟件包可以按照您的意愿完成90％的操作，最后可以通過(guò)配置和定制滿(mǎn)足最后10％。語(yǔ)音郵件和交互式語(yǔ)音應答（IVR）系統是此類(lèi)一種普遍的應用。
- 結構－能夠為您的商業(yè)邏輯提供電話(huà)容器的解決方案較少，呼叫控制，呼叫監控，呼叫管理組件提供了一個(gè)靈活的結構，可以將應用工作加入其中。這種應用范圍可以從腳本語(yǔ)言到拖拉函數組件。
- 對象庫－電話(huà)處理函數能夠以類(lèi)對象的方式發(fā)布，可以應用在C++, Delphi, Java等非電話(huà)處理語(yǔ)言中，開(kāi)發(fā)者可以使用能夠調用庫函數的標準語(yǔ)言進(jìn)行設計商業(yè)邏輯和應用，對象和結構有時(shí)可以指中間件。
- 控制API－這是設備制造商提供的接口，用來(lái)控制硬件。它依賴(lài)于不同的操作系統，這樣應用程序員不僅要處理商業(yè)邏輯和程序設計，而且還要處理句柄、事件、狀態(tài)、以及電話(huà)硬件設備的封裝接口。
- 話(huà)音API－除了硬件接口以外，也有一些控制API用于其他技術(shù)，如語(yǔ)音合成，語(yǔ)音識別，而且也可以直接控制，通常是在C/C++中，或者在高層語(yǔ)言、庫和程序包中抽象成服務(wù)函數。
那一種最好？答案不僅依賴(lài)于應用和可用產(chǎn)品，還依賴(lài)于您的公司和部門(mén)的開(kāi)支和任務(wù)。區分這些可選方法的問(wèn)題包括：
- 軟件包－如果軟件包涵蓋了您所需要的所有功能，可以采用一個(gè)基本解決方案快速。如果不是這樣，定義和擴展所要開(kāi)發(fā)的系統將非常困難，這取決于系統設計是否容易改變。性能和可擴展性是一個(gè)普遍的問(wèn)題，購買(mǎi)之前必須予以考慮。
- 結構－這些結構將會(huì )有不同的形式，當不是所有的結構都符合您的應用目標時(shí)，這些形式具有或多或少的靈活性，然而這些對于大多數的電話(huà)應用來(lái)說(shuō)，可以簡(jiǎn)化應用程序的編程，一些產(chǎn)品不需要提供硬件的不常用操作的功能。像軟件包一樣，性能很重要，這依賴(lài)于解決方案的通用型和設計中的優(yōu)化程度。
- 對象庫－由于這些對象很少會(huì )針對某一應用，這些組件比軟件包和結構更加靈活。通過(guò)特定接口抽象成通用形式，易于在類(lèi)似的技術(shù)中進(jìn)行移植（像針對自動(dòng)語(yǔ)音識別（ASR），ISDN和CAS網(wǎng)絡(luò )協(xié)議，或者DM/IP板卡和IP連接主媒體處理等等的SpeechWorks,
Nuance）。
- 控制API－這些肯定是控制硬件或者語(yǔ)音引擎的最全面的工具，選擇是根據必須精確管理的詳細程度。需要考慮培訓成本和該選擇的實(shí)現，這不僅是針對應用的初級版本，而且還要針對底層技術(shù)的可改變性。
■ Dialogic® NetMerge™
CT應用開(kāi)發(fā)環(huán)境
Dialogic提供了三種上述可選的清單：
- 一個(gè)控制功能的C/C++ API（R4）
- 一個(gè)電話(huà)結構
- 一個(gè)對象庫
后兩項打包成Dialogic® NetMerge™ CT應用開(kāi)發(fā)環(huán)境（CT ADE），(關(guān)于R4的一些更多的信息，請參見(jiàn)http://www.Dialogic.com/)。
本文后面的部分描述這兩個(gè)CT ADE編程平臺的概念和功能：
- 應用開(kāi)發(fā)語(yǔ)言（ADL）－一種過(guò)程語(yǔ)言，擁有可選的圖形接口，集成了多種電話(huà)應用構建模塊。
- 應用開(kāi)發(fā)ActiveX對象（ADX）－一個(gè)具有COM接口的方法庫，可以集成到Windows下的開(kāi)發(fā)語(yǔ)言中，如C++,
Visual Basic, Delphi，以及.NET語(yǔ)言C#和VB.NET等。
這兩個(gè)平臺的核心是資源管理器，是執行所有電話(huà)交互基本代碼的基本代碼。
資源管理器
資源管理器的核心組件是介于您的編程命令（如ADX中的Play，ADL中的MediaPlay）和底層設備API之間的中間層代碼。例如：如果您需要激活ADL函數TrunkAnswerCall，資源管理器可以決定：
- 使用哪一個(gè)中繼接口
- 進(jìn)行此呼叫是否合法（有呼叫信號嗎？）
- 使用哪一個(gè)API函數：dx_sethook(R4 analog), ccAnswer(R4 PRI),gc_Anser_AnswerCall(R4
Global Call)等等。
為了能得到設備抽象，我們需要定義設備和所有的設備特征。
資源
資源管理器是圍繞著(zhù)資源的概念構建的，技術(shù)上，一個(gè)資源可以產(chǎn)生或者處理一個(gè)語(yǔ)音流，資源可以分成以下幾類(lèi)：
- 中繼接口
- 媒體（播放器/記錄器）
- 傳真（發(fā)送機/接收機）
- 文字到語(yǔ)音轉換（TTS）
- 語(yǔ)音識別
- 會(huì )議
- 一些可以幫助了解這些信息的示例
首先考慮一個(gè)具有4信道的Dialogic® Dialogic™ D4PCI話(huà)音處理板卡，從資源管理器中可以看到一個(gè)信道具有兩個(gè)資源：中繼資源和媒體資源。中繼資源對應電話(huà)線(xiàn)連接器，媒體資源對應可以播放和記錄聲音文件的VOX設備。
通道管理兩個(gè)語(yǔ)音流，呼叫方話(huà)音（同樣包括撥號音和其他音頻）按照下列路徑處理：
呼叫方→模擬電話(huà)線(xiàn)→中繼資源→媒體設備（VOX/Wave記錄器）
在另一個(gè)方向，音頻流在VOX/Wave記錄器產(chǎn)生，通過(guò)中繼接口發(fā)送給電話(huà)線(xiàn)路：
媒體資源（VOX/Wave記錄器）→中繼資源→模擬電話(huà)線(xiàn)→呼叫方
正如這個(gè)例子所示，語(yǔ)音流從一個(gè)資源輸出有時(shí)可以作為另一資源的輸入，對于D4PCI卡，媒體和中繼設備是硬件，可以實(shí)現從一個(gè)輸出而輸入到另外一個(gè)資源，反之一樣。對于高端設備，可以控制這種傳輸的路由（例如，SC和CT總線(xiàn)上的設備）。
另外一個(gè)例子，考慮Dialogic® Dialogic™ D4JCTLS融合通信卡，該卡具有4個(gè)中繼接口（稱(chēng)為L(cháng)SI設備）和4個(gè)播放器/記錄器（VOX設備），資源管理器認為L(cháng)SI是一個(gè)中繼資源，一個(gè)VOX是一個(gè)媒體資源。從資源管理器的角度看，該卡和D4PCI相似，主要不同是可以通過(guò)CT總線(xiàn)改變路由資源。
一個(gè)T-1 PRI ISDN接口卡，如Dialogic® Dialogic™ DTI240SC卡，可以被資源管理器作為23個(gè)中繼資源，每一個(gè)都各作為話(huà)音（B）信道。換句話(huà)說(shuō)，一個(gè)中繼資源對應一個(gè)T-1時(shí)隙。在ISDN電路上的其他信令（數據、D）信道不作為資源管理器的資源（它不處理任何話(huà)音）。在大多數情況下，D信道的存在和管理對于資源管理器的用戶(hù)是隱藏的。例如：如果一個(gè)T-1緩存一個(gè)LOS狀態(tài)（信號丟失，D信道故障），則用于B信道傳輸的23個(gè)資源管理器中繼資源的每一個(gè)都轉為網(wǎng)絡(luò )故障狀態(tài)（后面會(huì )有更多的資源狀態(tài)介紹）。如果一個(gè)B信道需要發(fā)起呼叫，此呼叫需要向D信道發(fā)送數據包，資源管理器可以像普通模擬中繼中發(fā)起呼叫類(lèi)似一樣，通過(guò)DTMF撥號發(fā)起呼叫。
資源狀態(tài)將底層的技術(shù)事件和命令結果集合到操作資源狀態(tài)中。大多數情況下，您在編寫(xiě)應用時(shí)不用分析這些狀態(tài)變化，然而，如果需要分析，這些邏輯呼叫處理可以給出一些意想不到的狀態(tài)。
資源狀態(tài)
對于每一個(gè)資源（中繼、媒體、傳真、TTS、語(yǔ)音識別、會(huì )議），資源管理器預定義了一些狀態(tài)，例如，一個(gè)中繼資源可以震鈴響應或者斷開(kāi)，一個(gè)媒體資源可以播放和記錄。
一個(gè)資源狀態(tài)可以在兩種方法下改變：主動(dòng)請求（外部事件的結果），或者資源管理器函數調用的結果。
一個(gè)主動(dòng)請求狀態(tài)改變的例子是一個(gè)中繼資源在有呼叫呼入時(shí)從空閑轉換到振鈴狀態(tài)。
一個(gè)函數調用的狀態(tài)改變的例子是通過(guò)函數調用，可以使空閑的媒體資源轉到播放狀態(tài)，來(lái)響應一個(gè)播放命令。
能夠執行改變資源管理器資源狀態(tài)的函數被稱(chēng)為命令。例如，ADL函數MediaPlay以及ADX方法PlayWave都調用了資源管理器的命令。
資源管理器嚴格遵守了如下規則：
- 每條命令都有一套指定的狀態(tài)，這些狀態(tài)可以合法的執行命令。通常情況下，資源都是處于空閑狀態(tài)，如此命令才能夠合法執行。同時(shí)對于大多數命令來(lái)說(shuō)，每條命令只能在一種狀態(tài)下執行（there
is only one state in which the command can be issued.）。但對于A(yíng)bort和Reset命令來(lái)說(shuō)，卻是例外的。
- 如果命令執行失敗，資源的狀態(tài)不會(huì )改變。
- 如果命令執行成功，資源的狀態(tài)馬上就會(huì )改變。對每一個(gè)命令，該狀態(tài)都是確定的，因此一旦命令執行成功，應用程序便無(wú)需檢查資源是否進(jìn)入給定的那個(gè)狀態(tài)。例如，如果Play函數沒(méi)有報錯，資源肯定已經(jīng)進(jìn)入播放狀態(tài)。
每個(gè)資源都是以初始狀態(tài)開(kāi)始的。ADL和ADX的這種狀態(tài)對于用戶(hù)來(lái)說(shuō)通常是不可見(jiàn)的，因此用戶(hù)通常無(wú)法在這種環(huán)境下找到資源。當設備初始化完畢時(shí)，它進(jìn)入空閑狀態(tài)然后開(kāi)始準備接收命令。
對于所有類(lèi)型的資源管理器資源來(lái)說(shuō)，這些狀態(tài)和命令都是通用的：
- 初始狀態(tài)
- 空閑狀態(tài)
- 復位命令
- 復位狀態(tài)
- 退出命令
- 退出狀態(tài)
需要注意的是，資源管理器所定義的空閑不同于底層API所定義的"空閑"狀態(tài)。例如，在R4 API中，當LSI設備不再進(jìn)行處理工作或者摘機時(shí)，就會(huì )被認為是空閑狀態(tài)。如果與之相連的VOX設備正在播放或者錄音，那么則會(huì )被認為處于"繁忙"狀態(tài)。R4
API無(wú)法跟蹤呼叫的邏輯狀態(tài)（是連接狀態(tài)還是斷開(kāi)狀態(tài)），除非通過(guò)間接的途徑比如檢測當前掛鉤開(kāi)關(guān)的狀態(tài)，以及檢測線(xiàn)路中是否有環(huán)路電流。這種方法并不十分可靠，因為即使呼叫沒(méi)有斷開(kāi)，也有可能在線(xiàn)路中存在短時(shí)間的脈沖電流。相反，在資源管理器中，空閑狀態(tài)意味著(zhù)肯定沒(méi)有呼叫處理。一個(gè)呼叫會(huì )將繼電器資源置于連接狀態(tài)。
簡(jiǎn)表
資源管理器簡(jiǎn)表是一個(gè)和Windows注冊表很類(lèi)似的數據庫。簡(jiǎn)表中存儲了如下的信息：
- 按照資源掃描器的掃描結果記錄了所安裝硬件設備的詳細信息。（如下有具體描述）
- 用戶(hù)自定義的硬件配置信息，該信息是資源掃描器所無(wú)法檢測出來(lái)的
- 用戶(hù)自定義的選項，諸如缺省的話(huà)音語(yǔ)言（英語(yǔ)、西班牙語(yǔ)等等）
正在運行的應用程序（ADL和ADX）只能讀取簡(jiǎn)表，而且必須在這些應用程序運行之前初始化完畢。
簡(jiǎn)表中不存儲動(dòng)態(tài)改變的信息，比如當前設備狀態(tài)等。
簡(jiǎn)表中的表項都有名稱(chēng)和數值。表項的名稱(chēng)類(lèi)似于文件系統的路徑名。所有的名稱(chēng)都是從根開(kāi)始，用反斜線(xiàn)（\）標明。例如，資源管理器內部所常用的一個(gè)簡(jiǎn)表表項是：
\TechCount=4
TechCount的數值就是這臺PC上所安裝的不同的資源管理技術(shù)的數目（一項技術(shù)就是一個(gè)特定的硬件和API的組合，比如R4
VOX）。
簡(jiǎn)表無(wú)法存儲數值的名稱(chēng)。所有數值名稱(chēng)實(shí)際上都是以整數形存儲的。用于數值名稱(chēng)的整數數組是預先定義好的。為了方便用戶(hù)的閱讀，系統提供了可顯示字符串的窗口，資源管理的功能就是將內部存儲的整數數值轉換成可以在窗口中顯示的字符串，或者反之。這樣作可以應用更加高效的查詢(xún)算法，因此在資源管理器應用程序運行之后就可以更快的訪(fǎng)問(wèn)簡(jiǎn)表。用來(lái)代表數值名稱(chēng)的整數值有時(shí)被稱(chēng)為RegIDs（注冊標識），這是因為內部的資源管理代碼是將簡(jiǎn)表看作是注冊表。
和Windows注冊表不同，用戶(hù)應用程序代碼無(wú)法直接訪(fǎng)問(wèn)簡(jiǎn)表，并且無(wú)法建立新的表項名稱(chēng)。簡(jiǎn)表只是供資源管理器內部使用的。
資源掃描器
檢測已經(jīng)安裝的硬件以及驅動(dòng)器的配置信息通常是很重要又很復雜的任務(wù)。傳統的API具有獨特的不等的功能用來(lái)查詢(xún)已經(jīng)安裝的配置信息。通常，重要的信息是無(wú)法取得的。
在資源管理器簡(jiǎn)表中建立硬件/驅動(dòng)器配置數據庫需要兩個(gè)步驟：
-
首先運行資源掃描器，它會(huì )從可用的設備API中提取所有可用的配置信息。硬件或者驅動(dòng)器配置一旦改變，就需要重新運行資源掃描器。
-
第二步是"人工的"升級簡(jiǎn)表。這一步是增加無(wú)法自動(dòng)加入的配置信息，因此必須由用戶(hù)進(jìn)行處理。例如，對于一個(gè)E-1/R2中繼器，用戶(hù)必須指定用于R2協(xié)議的參數，這個(gè)參數是根據國家不同而不同的。對于模擬中繼器，用戶(hù)必須判斷呼叫方ID是否可用。對于T-1
CAS中繼器，用戶(hù)必須指定需要使用哪種全程呼叫協(xié)議來(lái)為PBX或者CO交換提供接口。
在運行時(shí)建立設備掃描步驟有些困難：
- 掃描需要花費很多時(shí)間，這會(huì )減慢應用程序啟動(dòng)的速度。在需要的時(shí)候才啟動(dòng)資源掃描器，可以使應用程序啟動(dòng)得更快。
- 新版本的硬件通常會(huì )和老的API不相兼容，或者會(huì )引入新的用于配置信息的API。通過(guò)將掃描代碼和運行代碼進(jìn)行分離，我們便可以更加容易的建立可以適應最新軟件版本的掃描器。
特定技術(shù)接入（Technology-Specific Access）
資源管理器建立了一種較高層次的抽象，這樣應用程序的編程就可以做到對API的透明性（比如相同的一套功能可以工作在所有支持電話(huà)的API上，也可以工作在支持各種繼電器的API之上）。只有應用一些特定的技術(shù)才可以使用一些不常用的API。對于這樣的情況，可以通過(guò)指令或者數據識別符（RegIDs）以及命令來(lái)執行指令或者訪(fǎng)問(wèn)數據（比如，GetInt[get
integer value]以及SetInt[set integer value]或者布爾形以及字符串形的副本（counterparts
for Boolean and string values）的方法來(lái)調用層次較低的API。
對于電話(huà)硬件編程來(lái)說(shuō)，這些功能通常是不需要的，但是對于更多高級的操作卻是可用的。該功能按照如下的描述直接轉換成硬件API功能的執行。
舉例：為傳真操作建立重試策略：
SetInt R4GrtFaxRetryStrategy
利用這個(gè)REGID來(lái)建立
m_gfqRecord.retry_strategy API 單元
舉例：在DCB會(huì )議設備上建立數字檢測功能：
SetInt R4DcbConfEnableDigitDetection
利用這個(gè)REGID來(lái)直接訪(fǎng)問(wèn)
dcb_setdigitmsk(handle, Confld, Value, CBA_SETMSK)API函數來(lái)實(shí)現數字檢測功能。
舉例：利用Global Call為數字中繼器建立設備模板（ device mask）：
SetInt R4GcEnableMask
利用這個(gè)REGID可以直接訪(fǎng)問(wèn)帶有GCACT_ADDMSK參數的gc_SetEvtMsk API函數。
對于電話(huà)設備有300多個(gè)這樣的指定技術(shù)接入函數，對于TTS、語(yǔ)音識別以及聲音媒體特性則有更多這樣的函數。任何沒(méi)有被抽象倒高層API的電話(huà)操作都可以通過(guò)直接調用函數得以實(shí)現。
除此以外，硬件參數可以在啟動(dòng)的時(shí)候設定。這就可以執行板卡級API呼叫。這些操作所得到的結果都會(huì )被記錄到實(shí)時(shí)的記錄文件中，來(lái)幫助解決配置過(guò)程中所遇到的困難。
■ 應用程序開(kāi)發(fā)語(yǔ)言（ADL）
除了控制電話(huà)設備之外，計算機電話(huà)（CT）程序面臨著(zhù)更多的挑戰。
- 多路呼叫必須一次完成。需要多任務(wù)處理的結構
- 每個(gè)呼叫可能需要不同的對話(huà)以及工作結果。需要呼叫時(shí)的程序選擇功能。
通常程序都會(huì )運行幾天或者幾個(gè)星期。因此設計必須是健壯的（高效的錯誤恢復，以及高密度資源）
- 硬件和軟件的安裝通常都是在遠程進(jìn)行的，因此手持操作并不是永久的解決方案。
- 電話(huà)呼叫過(guò)程是一種實(shí)時(shí)性的活動(dòng)，因此就需要實(shí)時(shí)的錯誤處理工具。
- Dialogic已經(jīng)實(shí)現了這些需求，在其指定電話(huà)語(yǔ)言，ADL，中有更多的描述。接下來(lái)的這部分解釋了支持復雜編程環(huán)境的一些可用的功能。
任務(wù)管理器
ADL支持多任務(wù)環(huán)境，也就是說(shuō)兩個(gè)或者更多的任務(wù)可以同時(shí)執行。即使多個(gè)任務(wù)運行同一個(gè)應用程序，每個(gè)任務(wù)也都有其自己的變量和數組的拷貝，同時(shí)擁有獨立的執行路徑。在多任務(wù)處理環(huán)境中，各個(gè)任務(wù)的執行是彼此獨立的。然而有些時(shí)候需要這些任務(wù)之間進(jìn)行合作或者相互交換信息。這可以通過(guò)信號標識、消息以及全局變量來(lái)實(shí)現。
任務(wù)/中繼的配置
中繼配置程序允許用戶(hù)指定程序的哪一個(gè)功能來(lái)使用系統的中繼線(xiàn)路。當一個(gè)運行ADL項目時(shí)，中繼配置決定了應該啟動(dòng)哪一個(gè)應用程序。
用戶(hù)可以為項目中的任何一個(gè)應用程序分配一個(gè)中繼資源或者多個(gè)中繼資源。也可以根據從那些呼叫線(xiàn)路受到的ANI或者DNIS信息來(lái)決定應該為程序分配哪種資源。
靜態(tài)數據
ADL中的數據區在編譯的時(shí)候是固定的。每個(gè)變量的起始位置在程序的數據區中都是固定的。這樣可以在執行指令的時(shí)候，使ADL更加高效的定位數據。缺省情況下，ADL不會(huì )動(dòng)態(tài)分配內存。這就不需要使用垃圾收集程序，同時(shí)也避免了資源的泄漏。
TCP/IP以及DCOM通訊
利用TCP/IP或者DCOM通訊程序，ADL可以和在本地或者廣域網(wǎng)上的其他應用程序交換信息和數據。這些工具實(shí)現了對任務(wù)、網(wǎng)絡(luò )狀態(tài)以及程序進(jìn)程的遠程監控。
同時(shí)，ADL包含了Windows 服務(wù)的特性，這種特性方便了遠程無(wú)人監守系統的修復。
符號形式的實(shí)時(shí)調試
不同的問(wèn)題需要不同的解決方法。對于定位設計差錯的問(wèn)題，ADL提供了符號形式的調試器。這些差錯是指控制流并不是按照我們的設計進(jìn)行的。一個(gè)指令接著(zhù)一個(gè)指令運行、檢測變量?jì)热菀约霸O定斷點(diǎn)－如今所有通用而又先進(jìn)的調試技術(shù)都集成到了該開(kāi)發(fā)環(huán)境中。
例如需要檢測昨天造成呼叫方在3a.m.掛機時(shí)所發(fā)生的事情，ADL會(huì )記錄一份實(shí)時(shí)的日志，該日志包含了在執行操作期間每一個(gè)動(dòng)作詳細的步驟，也包含了總結性的信息。ADL、資源管理器以及R4的事件、狀態(tài)和運行結果都可以在1/100秒內被捕捉下來(lái)。
◎ 過(guò)程編程
ADL語(yǔ)言也有函數和變量，和C或Basic差不多。
圖5: ADL程序等待一個(gè)呼叫，應答它，播放提示，從呼叫方得到DTMF切入，最后播放基于數字集合的說(shuō)明文件。
◎ 圖形編程
ADL流程圖是ADL Studio的一個(gè)組成部分，它是一個(gè)繪圖工具，可以幫助你創(chuàng )建并編輯電話(huà)應用。你無(wú)需編寫(xiě)代碼，只用在圖中插入模塊，就可在流程圖中畫(huà)出應用。
圖6: 流程圖中的功能塊定義了在什么條件下什么序列下應該執行什么樣的動(dòng)作。
那些模塊是預先定義的ADL庫函數，使用參數（argument）作為模塊的屬性。
圖7: 特性對話(huà)框，用于為PlayPrimpt功能塊設置提示名稱(chēng)和終端數字
◎ 性能和密度
為了要達到API透明性的目標，CT ADE加入了一個(gè)資源管理層，這樣不可避免的會(huì )引入一些開(kāi)銷(xiāo)。但是，通過(guò)最優(yōu)化程序設計，可以使所費開(kāi)銷(xiāo)最小化。但現在，最有意義的是，應該關(guān)注的是應用如何管理多條通道--而不是它處理單獨一條指令流的速度有多快。
在任何應用中，根據程序設計，CPU的使用情況有所不同：
在多個(gè)可執行程序(一個(gè)應用一個(gè)通道)情況下--CPU的開(kāi)銷(xiāo)最大，因為在請求或者為每個(gè)電話(huà)狀態(tài)變化服務(wù)時(shí)，窗口必須從一個(gè)進(jìn)程（程序）切換到另一個(gè)去。
在多線(xiàn)程（一個(gè)進(jìn)程中的每個(gè)線(xiàn)程各有一個(gè)通道）--這種設計下，CPU的性能會(huì )好些，但是仍然需要操作系統切換線(xiàn)程以管理通道，
單線(xiàn)程狀態(tài)機（一個(gè)線(xiàn)程使用所有通道）--狀態(tài)的變化會(huì )即時(shí)通知線(xiàn)程，直接進(jìn)行處理，無(wú)需詢(xún)問(wèn)操作系統。當前通道的數據會(huì )被保存下來(lái)，并獲取下一通道的狀態(tài)數據，繼續處理。
但是，CPU使用效率越高，設計和實(shí)現起來(lái)就越困難。要想創(chuàng )建一個(gè)完整、健壯、靈活的狀態(tài)機，需要多年的努力。這也就是Dialogic提供ADL的原因，它的狀態(tài)機執行可以控制單線(xiàn)程的幾百條通道。
◎ Dialogic標準結果
表1列出了一些實(shí)驗室測試和現場(chǎng)測試的實(shí)際性能結果。
這個(gè)測試中，只使用了可用的CPU時(shí)鐘周期的15％，就處理了所有的API呼叫、操作事件以及狀態(tài)轉換的管理。CPU的其余空閑可以用來(lái)處理其它的應用如業(yè)務(wù)邏輯或者語(yǔ)音合成或語(yǔ)音識別。
用戶(hù)ADL應用
表2中的現實(shí)結果顯示了ADL應用的能力，該應用集成了重要的業(yè)務(wù)功能。還有，如果這些應用比你計劃創(chuàng )建的應用簡(jiǎn)單的話(huà)，也并非是由于限制每塊主板的密度的電話(huà)提取工作的影響。
VOS移植
ADL是VOS（語(yǔ)音操作系統）從Parity軟件（Software）派生出來(lái)的。ADL將全新的一套資源管理功能引入到了VOS中。舊的功能（sc_
，DTI_, GC_…），可以當作是VOS遺留的功能，仍繼續可以使用，這樣就提供了后向兼容性。然而，對于新的工程來(lái)說(shuō)，我們將強力推薦使用資源管理API。
■ 應用開(kāi)發(fā)ActiveX對象（ADX）
組件對象模型（COM）的控制，也指ActiveX對象的控制，包括了一些很有用的服務(wù)，可以將多個(gè)組件合成一個(gè)大的應用。將復雜系統功能分解到面向業(yè)務(wù)的應用中去，這種方法現在很常見(jiàn)，尤其是那些喜歡使用VB或Delphi的圖形化編程環(huán)境的開(kāi)發(fā)者，常用這種方法。
上文中提到的資源管理器提供的所有電話(huà)服務(wù)，都是被封裝在構建模塊中的，這些模塊在開(kāi)發(fā)時(shí)可以看到它們的功能性（方法、參數、變量），要在操作系統上注冊功能性，在執行時(shí)還要創(chuàng )建必要的對象。
圖8: 使用SDX語(yǔ)音方法PlayDate的VB編程，該方法提示基于COM標準的變量。
整套控件叫做ADX，包括：
編程環(huán)境
所有支持COM控件的環(huán)境也都支持ADX對象。Dialogic用的測試語(yǔ)言包括了C＋＋、VB、Delphi、C#以及
VB.NET。現場(chǎng)測試的報告顯示，ADE控件也可成功的應用于JavaScript*網(wǎng)頁(yè)、Visual FoxPro*以及PowerBuilder*。還有第三方產(chǎn)品可以利用其它語(yǔ)音如Java*使用COM控件。
性能和密度
早期的COM對象是用微軟基類(lèi)（MFC，Microsoft Foundation Classes）來(lái)寫(xiě)的。這些類(lèi)是為可視化對象設計的，可以廣泛支持用戶(hù)界面對話(huà)框和文檔處理。用MFC來(lái)編寫(xiě)COM程序，會(huì )使得代碼冗余，COM組件會(huì )有不必要的巨大開(kāi)銷(xiāo)。Dialogic的ADE對象使用了活動(dòng)模板庫（Active
Template Library）用以取代MFC。ATL是專(zhuān)為COM開(kāi)發(fā)設計的，可以是開(kāi)發(fā)出的COM構件腳本小而效率高。
采用與使用ADL時(shí)一樣的基準來(lái)設計和配置，一個(gè)使用ADX語(yǔ)音控制的C＋＋多線(xiàn)程程序，其CPU的利用率為ADL的2倍，但是仍有70％可以給數據和其它邏輯處理使用。如果使用一個(gè)雙處理器CPU的話(huà)，這些單板的性能還會(huì )提高。
CallSuile移植
ADX是從Parity軟件的CallSuite控件的派生：VoiceBocx*、FaxBocx*、SwitchBocx*、ChatterBocx*、
MatchBocx*以及 NetHub*。雖然在8.3版當中，字面上名字有了些變化，但是控件的名字以及他們的接口特征都是不變的。
■ 新的方向
Dialogic還可以為廣大的CT開(kāi)發(fā)者作些什么呢？以下是一些Dialogic正在考慮的問(wèn)題：
- 語(yǔ)音XML/SALT--自動(dòng)語(yǔ)音服務(wù)使用這些標記語(yǔ)言，可以更好地加強電話(huà)和網(wǎng)絡(luò )服務(wù)間的關(guān)系。你怎樣創(chuàng )建可視的站點(diǎn)，你就可以用同樣的技術(shù)創(chuàng )建語(yǔ)音服務(wù)。從Dialogic的角度來(lái)看現在的VoiceXML平臺，現在對于Dialogic來(lái)說(shuō)，仍是一片待開(kāi)發(fā)的處女地。可以到http://www.Dialogic.com/查閱Dialogic與Microsoft聯(lián)手執行SALT的相關(guān)情況。或者到http://www.microsoft.com去查閱"Microsoft
.NET 語(yǔ)音技術(shù)"。
- 視窗庫（非COM）--雖然Dialogic開(kāi)發(fā)出了最具效率的COM對象，但還是可能會(huì )有一些程序設計和主機語(yǔ)言用C＋＋電話(huà)類(lèi)庫來(lái)支持效果更好。
- Linux*--資源管理器、電話(huà)類(lèi)以及ADL框架的優(yōu)勢。
請讓我們了解您使用這些產(chǎn)品的感受，以及您未來(lái)的需求。請與您的Dialogic經(jīng)銷(xiāo)商（http://www.Dialogic.com/）或者Dialogic產(chǎn)品經(jīng)理CT
ADE, Lyle Cowen (Lyle.Cowen@Dialogic.com; (415)
332-5656, x1310)聯(lián)系。
[ 全文英文版
]
|
