介紹
計算機電話系統(tǒng)
Dialogic® NetMerge™ CT應用開發(fā)環(huán)境
應用環(huán)境語言（ADL）
應用開發(fā)ActiveX對象（ADX）
新的方向

■ 介紹

　　本文可以幫助用戶了解Dialogic® NetMerge™ CT應用開發(fā)環(huán)境（CT ADE）對于項目開發(fā)的價值，可以為用戶提供以下有價值的幫助如果用戶：

• 通常是在C/C++中使用硬件API編寫電話應用
• 使用過Dialogic早期產品：VOS和CallSuite
• 曾經使用過其他應用開發(fā)工具
• 剛剛開始進行電話應用開發(fā)

■ 計算機電話應用

　　開始之前，我們應該考慮一下，我們打算使用這種技術做什么，以何種方式應用這種技術。
　　我們的應用需要能夠：

• 檢測和應答到達的呼叫
• 進行呼出呼叫并且檢測結果（忙，無應答，語音應答，機器應答等等）
• 與呼叫方交互（向呼叫方播放語音，來子呼叫者的信號音和語音）
• 與呼叫方交換數(shù)據(jù)（從數(shù)據(jù)庫中讀寫數(shù)據(jù)）
• 控制呼叫（會議，拆線，轉接，保持，重試）

　　這些基本的操作應該能夠在下列環(huán)境中執(zhí)行：

• 多種協(xié)議的網絡中（環(huán)路啟動，T-1/E-1 CAS, ISDN, IP），網絡協(xié)議隨國家而改變
• 多種尺寸的設備中（一個機箱2個模擬端口，一個機箱500個端口，多個協(xié)作的機箱）
• 多種操作系統(tǒng)控制下（Windows, Linux, Unix）
• 與系統(tǒng)管理監(jiān)控器和管理器相連接

　　最后，所有的這些任務都要和商業(yè)邏輯協(xié)調工作，輸入分析，控制操作，和輸出。
　　創(chuàng)建這種應用的可選項有：

• 軟件包－如果您的應用執(zhí)行相當普通的操作，您會發(fā)現(xiàn)完軟件包可以按照您的意愿完成90％的操作，最后可以通過配置和定制滿足最后10％。語音郵件和交互式語音應答（IVR）系統(tǒng)是此類一種普遍的應用。
  
  
• 結構－能夠為您的商業(yè)邏輯提供電話容器的解決方案較少，呼叫控制，呼叫監(jiān)控，呼叫管理組件提供了一個靈活的結構，可以將應用工作加入其中。這種應用范圍可以從腳本語言到拖拉函數(shù)組件。
  
  
• 對象庫－電話處理函數(shù)能夠以類對象的方式發(fā)布，可以應用在C++, Delphi, Java等非電話處理語言中，開發(fā)者可以使用能夠調用庫函數(shù)的標準語言進行設計商業(yè)邏輯和應用，對象和結構有時可以指中間件。
  
  
• 控制API－這是設備制造商提供的接口，用來控制硬件。它依賴于不同的操作系統(tǒng)，這樣應用程序員不僅要處理商業(yè)邏輯和程序設計，而且還要處理句柄、事件、狀態(tài)、以及電話硬件設備的封裝接口。
  
  
• 話音API－除了硬件接口以外，也有一些控制API用于其他技術，如語音合成，語音識別，而且也可以直接控制，通常是在C/C++中，或者在高層語言、庫和程序包中抽象成服務函數(shù)。

　　那一種最好？答案不僅依賴于應用和可用產品，還依賴于您的公司和部門的開支和任務。區(qū)分這些可選方法的問題包括：

• 軟件包－如果軟件包涵蓋了您所需要的所有功能，可以采用一個基本解決方案快速。如果不是這樣，定義和擴展所要開發(fā)的系統(tǒng)將非常困難，這取決于系統(tǒng)設計是否容易改變。性能和可擴展性是一個普遍的問題，購買之前必須予以考慮。
  
  
• 結構－這些結構將會有不同的形式，當不是所有的結構都符合您的應用目標時，這些形式具有或多或少的靈活性，然而這些對于大多數(shù)的電話應用來說，可以簡化應用程序的編程，一些產品不需要提供硬件的不常用操作的功能。像軟件包一樣，性能很重要，這依賴于解決方案的通用型和設計中的優(yōu)化程度。
  
  
• 對象庫－由于這些對象很少會針對某一應用，這些組件比軟件包和結構更加靈活。通過特定接口抽象成通用形式，易于在類似的技術中進行移植（像針對自動語音識別（ASR），ISDN和CAS網絡協(xié)議，或者DM/IP板卡和IP連接主媒體處理等等的SpeechWorks, Nuance）。
  
  
• 控制API－這些肯定是控制硬件或者語音引擎的最全面的工具，選擇是根據(jù)必須精確管理的詳細程度。需要考慮培訓成本和該選擇的實現(xiàn)，這不僅是針對應用的初級版本，而且還要針對底層技術的可改變性。

■ Dialogic® NetMerge™ CT應用開發(fā)環(huán)境

　　Dialogic提供了三種上述可選的清單：

• 一個控制功能的C/C++ API（R4）
• 一個電話結構
• 一個對象庫

　　后兩項打包成Dialogic® NetMerge™ CT應用開發(fā)環(huán)境（CT ADE），(關于R4的一些更多的信息，請參見http://www.Dialogic.com/)。

　　本文后面的部分描述這兩個CT ADE編程平臺的概念和功能：

• 應用開發(fā)語言（ADL）－一種過程語言，擁有可選的圖形接口，集成了多種電話應用構建模塊。
• 應用開發(fā)ActiveX對象（ADX）－一個具有COM接口的方法庫，可以集成到Windows下的開發(fā)語言中，如C++, Visual Basic, Delphi，以及.NET語言C#和VB.NET等。

　　這兩個平臺的核心是資源管理器，是執(zhí)行所有電話交互基本代碼的基本代碼。

　　資源管理器

　　資源管理器的核心組件是介于您的編程命令（如ADX中的Play，ADL中的MediaPlay）和底層設備API之間的中間層代碼。例如：如果您需要激活ADL函數(shù)TrunkAnswerCall，資源管理器可以決定：

• 使用哪一個中繼接口
• 進行此呼叫是否合法（有呼叫信號嗎？）
• 使用哪一個API函數(shù)：dx_sethook(R4 analog), ccAnswer(R4 PRI),gc_Anser_AnswerCall(R4 Global Call)等等。

　　為了能得到設備抽象，我們需要定義設備和所有的設備特征。

　　資源

　　資源管理器是圍繞著資源的概念構建的，技術上，一個資源可以產生或者處理一個語音流，資源可以分成以下幾類：

• 中繼接口
• 媒體（播放器/記錄器）
• 傳真（發(fā)送機/接收機）
• 文字到語音轉換（TTS）
• 語音識別
• 會議
• 一些可以幫助了解這些信息的示例

　　首先考慮一個具有4信道的Dialogic® Dialogic™ D4PCI話音處理板卡，從資源管理器中可以看到一個信道具有兩個資源：中繼資源和媒體資源。中繼資源對應電話線連接器，媒體資源對應可以播放和記錄聲音文件的VOX設備。

　　通道管理兩個語音流，呼叫方話音（同樣包括撥號音和其他音頻）按照下列路徑處理：
　　呼叫方→模擬電話線→中繼資源→媒體設備（VOX/Wave記錄器）

　　在另一個方向，音頻流在VOX/Wave記錄器產生，通過中繼接口發(fā)送給電話線路：
　　媒體資源（VOX/Wave記錄器）→中繼資源→模擬電話線→呼叫方

　　正如這個例子所示，語音流從一個資源輸出有時可以作為另一資源的輸入，對于D4PCI卡，媒體和中繼設備是硬件，可以實現(xiàn)從一個輸出而輸入到另外一個資源，反之一樣。對于高端設備，可以控制這種傳輸?shù)穆酚桑ɡ纾琒C和CT總線上的設備）。

　　另外一個例子，考慮Dialogic® Dialogic™ D4JCTLS融合通信卡，該卡具有4個中繼接口（稱為LSI設備）和4個播放器/記錄器（VOX設備），資源管理器認為LSI是一個中繼資源，一個VOX是一個媒體資源。從資源管理器的角度看，該卡和D4PCI相似，主要不同是可以通過CT總線改變路由資源。

　　一個T-1 PRI ISDN接口卡，如Dialogic® Dialogic™ DTI240SC卡，可以被資源管理器作為23個中繼資源，每一個都各作為話音（B）信道。換句話說，一個中繼資源對應一個T-1時隙。在ISDN電路上的其他信令（數(shù)據(jù)、D）信道不作為資源管理器的資源（它不處理任何話音）。在大多數(shù)情況下，D信道的存在和管理對于資源管理器的用戶是隱藏的。例如：如果一個T-1緩存一個LOS狀態(tài)（信號丟失，D信道故障），則用于B信道傳輸?shù)?3個資源管理器中繼資源的每一個都轉為網絡故障狀態(tài)（后面會有更多的資源狀態(tài)介紹）。如果一個B信道需要發(fā)起呼叫，此呼叫需要向D信道發(fā)送數(shù)據(jù)包，資源管理器可以像普通模擬中繼中發(fā)起呼叫類似一樣，通過DTMF撥號發(fā)起呼叫。

　　資源狀態(tài)將底層的技術事件和命令結果集合到操作資源狀態(tài)中。大多數(shù)情況下，您在編寫應用時不用分析這些狀態(tài)變化，然而，如果需要分析，這些邏輯呼叫處理可以給出一些意想不到的狀態(tài)。

　　資源狀態(tài)

　　對于每一個資源（中繼、媒體、傳真、TTS、語音識別、會議），資源管理器預定義了一些狀態(tài)，例如，一個中繼資源可以震鈴響應或者斷開，一個媒體資源可以播放和記錄。

　　一個資源狀態(tài)可以在兩種方法下改變：主動請求（外部事件的結果），或者資源管理器函數(shù)調用的結果。

　　一個主動請求狀態(tài)改變的例子是一個中繼資源在有呼叫呼入時從空閑轉換到振鈴狀態(tài)。

　　一個函數(shù)調用的狀態(tài)改變的例子是通過函數(shù)調用，可以使空閑的媒體資源轉到播放狀態(tài)，來響應一個播放命令。

　　能夠執(zhí)行改變資源管理器資源狀態(tài)的函數(shù)被稱為命令。例如，ADL函數(shù)MediaPlay以及ADX方法PlayWave都調用了資源管理器的命令。

　　資源管理器嚴格遵守了如下規(guī)則：

• 每條命令都有一套指定的狀態(tài)，這些狀態(tài)可以合法的執(zhí)行命令。通常情況下，資源都是處于空閑狀態(tài)，如此命令才能夠合法執(zhí)行。同時對于大多數(shù)命令來說，每條命令只能在一種狀態(tài)下執(zhí)行（there is only one state in which the command can be issued.）。但對于Abort和Reset命令來說，卻是例外的。
• 如果命令執(zhí)行失敗，資源的狀態(tài)不會改變。
• 如果命令執(zhí)行成功，資源的狀態(tài)馬上就會改變。對每一個命令，該狀態(tài)都是確定的，因此一旦命令執(zhí)行成功，應用程序便無需檢查資源是否進入給定的那個狀態(tài)。例如，如果Play函數(shù)沒有報錯，資源肯定已經進入播放狀態(tài)。

　　每個資源都是以初始狀態(tài)開始的。ADL和ADX的這種狀態(tài)對于用戶來說通常是不可見的，因此用戶通常無法在這種環(huán)境下找到資源。當設備初始化完畢時，它進入空閑狀態(tài)然后開始準備接收命令。

　　對于所有類型的資源管理器資源來說，這些狀態(tài)和命令都是通用的：

• 初始狀態(tài)
• 空閑狀態(tài)
• 復位命令
• 復位狀態(tài)
• 退出命令
• 退出狀態(tài)

　　需要注意的是，資源管理器所定義的空閑不同于底層API所定義的"空閑"狀態(tài)。例如，在R4 API中，當LSI設備不再進行處理工作或者摘機時，就會被認為是空閑狀態(tài)。如果與之相連的VOX設備正在播放或者錄音，那么則會被認為處于"繁忙"狀態(tài)。R4 API無法跟蹤呼叫的邏輯狀態(tài)（是連接狀態(tài)還是斷開狀態(tài)），除非通過間接的途徑比如檢測當前掛鉤開關的狀態(tài)，以及檢測線路中是否有環(huán)路電流。這種方法并不十分可靠，因為即使呼叫沒有斷開，也有可能在線路中存在短時間的脈沖電流。相反，在資源管理器中，空閑狀態(tài)意味著肯定沒有呼叫處理。一個呼叫會將繼電器資源置于連接狀態(tài)。

　　簡表

　　資源管理器簡表是一個和Windows注冊表很類似的數(shù)據(jù)庫。簡表中存儲了如下的信息：

• 按照資源掃描器的掃描結果記錄了所安裝硬件設備的詳細信息。（如下有具體描述）
• 用戶自定義的硬件配置信息，該信息是資源掃描器所無法檢測出來的
• 用戶自定義的選項，諸如缺省的話音語言（英語、西班牙語等等）

　　正在運行的應用程序（ADL和ADX）只能讀取簡表，而且必須在這些應用程序運行之前初始化完畢。

　　簡表中不存儲動態(tài)改變的信息，比如當前設備狀態(tài)等。

　　簡表中的表項都有名稱和數(shù)值。表項的名稱類似于文件系統(tǒng)的路徑名。所有的名稱都是從根開始，用反斜線（\）標明。例如，資源管理器內部所常用的一個簡表表項是：
　　　　　\TechCount=4

　　TechCount的數(shù)值就是這臺PC上所安裝的不同的資源管理技術的數(shù)目（一項技術就是一個特定的硬件和API的組合，比如R4 VOX）。

　　簡表無法存儲數(shù)值的名稱。所有數(shù)值名稱實際上都是以整數(shù)形存儲的。用于數(shù)值名稱的整數(shù)數(shù)組是預先定義好的。為了方便用戶的閱讀，系統(tǒng)提供了可顯示字符串的窗口，資源管理的功能就是將內部存儲的整數(shù)數(shù)值轉換成可以在窗口中顯示的字符串，或者反之。這樣作可以應用更加高效的查詢算法，因此在資源管理器應用程序運行之后就可以更快的訪問簡表。用來代表數(shù)值名稱的整數(shù)值有時被稱為RegIDs（注冊標識），這是因為內部的資源管理代碼是將簡表看作是注冊表。

　　和Windows注冊表不同，用戶應用程序代碼無法直接訪問簡表，并且無法建立新的表項名稱。簡表只是供資源管理器內部使用的。

　　資源掃描器

　　檢測已經安裝的硬件以及驅動器的配置信息通常是很重要又很復雜的任務。傳統(tǒng)的API具有獨特的不等的功能用來查詢已經安裝的配置信息。通常，重要的信息是無法取得的。

　　在資源管理器簡表中建立硬件/驅動器配置數(shù)據(jù)庫需要兩個步驟：

• 首先運行資源掃描器，它會從可用的設備API中提取所有可用的配置信息。硬件或者驅動器配置一旦改變，就需要重新運行資源掃描器。

• 第二步是"人工的"升級簡表。這一步是增加無法自動加入的配置信息，因此必須由用戶進行處理。例如，對于一個E-1/R2中繼器，用戶必須指定用于R2協(xié)議的參數(shù)，這個參數(shù)是根據(jù)國家不同而不同的。對于模擬中繼器，用戶必須判斷呼叫方ID是否可用。對于T-1 CAS中繼器，用戶必須指定需要使用哪種全程呼叫協(xié)議來為PBX或者CO交換提供接口。

　　在運行時建立設備掃描步驟有些困難：

• 掃描需要花費很多時間，這會減慢應用程序啟動的速度。在需要的時候才啟動資源掃描器，可以使應用程序啟動得更快。
  
  
• 新版本的硬件通常會和老的API不相兼容，或者會引入新的用于配置信息的API。通過將掃描代碼和運行代碼進行分離，我們便可以更加容易的建立可以適應最新軟件版本的掃描器。
  

　　特定技術接入（Technology-Specific Access）

　　資源管理器建立了一種較高層次的抽象，這樣應用程序的編程就可以做到對API的透明性（比如相同的一套功能可以工作在所有支持電話的API上，也可以工作在支持各種繼電器的API之上）。只有應用一些特定的技術才可以使用一些不常用的API。對于這樣的情況，可以通過指令或者數(shù)據(jù)識別符（RegIDs）以及命令來執(zhí)行指令或者訪問數(shù)據(jù)（比如，GetInt[get integer value]以及SetInt[set integer value]或者布爾形以及字符串形的副本（counterparts for Boolean and string values）的方法來調用層次較低的API。

　　對于電話硬件編程來說，這些功能通常是不需要的，但是對于更多高級的操作卻是可用的。該功能按照如下的描述直接轉換成硬件API功能的執(zhí)行。

　　舉例：為傳真操作建立重試策略：
　　SetInt R4GrtFaxRetryStrategy
　　利用這個REGID來建立
　　m_gfqRecord.retry_strategy API 單元

　　舉例：在DCB會議設備上建立數(shù)字檢測功能：
　　SetInt R4DcbConfEnableDigitDetection
　　利用這個REGID來直接訪問
　　dcb_setdigitmsk(handle, Confld, Value, CBA_SETMSK)API函數(shù)來實現(xiàn)數(shù)字檢測功能。

　　舉例：利用Global Call為數(shù)字中繼器建立設備模板（ device mask）：
　　SetInt R4GcEnableMask
　　利用這個REGID可以直接訪問帶有GCACT_ADDMSK參數(shù)的gc_SetEvtMsk API函數(shù)。

　　對于電話設備有300多個這樣的指定技術接入函數(shù)，對于TTS、語音識別以及聲音媒體特性則有更多這樣的函數(shù)。任何沒有被抽象倒高層API的電話操作都可以通過直接調用函數(shù)得以實現(xiàn)。

　　除此以外，硬件參數(shù)可以在啟動的時候設定。這就可以執(zhí)行板卡級API呼叫。這些操作所得到的結果都會被記錄到實時的記錄文件中，來幫助解決配置過程中所遇到的困難。

■ 應用程序開發(fā)語言（ADL）

　　除了控制電話設備之外，計算機電話（CT）程序面臨著更多的挑戰(zhàn)。

• 多路呼叫必須一次完成。需要多任務處理的結構
• 每個呼叫可能需要不同的對話以及工作結果。需要呼叫時的程序選擇功能。
  通常程序都會運行幾天或者幾個星期。因此設計必須是健壯的（高效的錯誤恢復，以及高密度資源）
• 硬件和軟件的安裝通常都是在遠程進行的，因此手持操作并不是永久的解決方案。
• 電話呼叫過程是一種實時性的活動，因此就需要實時的錯誤處理工具。
• Dialogic已經實現(xiàn)了這些需求，在其指定電話語言，ADL，中有更多的描述。接下來的這部分解釋了支持復雜編程環(huán)境的一些可用的功能。
  

圖1 在配置中為每一個中繼（信道）指定相同或者不同的任務

　　任務管理器

　　ADL支持多任務環(huán)境，也就是說兩個或者更多的任務可以同時執(zhí)行。即使多個任務運行同一個應用程序，每個任務也都有其自己的變量和數(shù)組的拷貝，同時擁有獨立的執(zhí)行路徑。在多任務處理環(huán)境中，各個任務的執(zhí)行是彼此獨立的。然而有些時候需要這些任務之間進行合作或者相互交換信息。這可以通過信號標識、消息以及全局變量來實現(xiàn)。

　　任務/中繼的配置

　　中繼配置程序允許用戶指定程序的哪一個功能來使用系統(tǒng)的中繼線路。當一個運行ADL項目時，中繼配置決定了應該啟動哪一個應用程序。
用戶可以為項目中的任何一個應用程序分配一個中繼資源或者多個中繼資源。也可以根據(jù)從那些呼叫線路受到的ANI或者DNIS信息來決定應該為程序分配哪種資源。

　　靜態(tài)數(shù)據(jù)

　　ADL中的數(shù)據(jù)區(qū)在編譯的時候是固定的。每個變量的起始位置在程序的數(shù)據(jù)區(qū)中都是固定的。這樣可以在執(zhí)行指令的時候，使ADL更加高效的定位數(shù)據(jù)。缺省情況下，ADL不會動態(tài)分配內存。這就不需要使用垃圾收集程序，同時也避免了資源的泄漏。

　　TCP/IP以及DCOM通訊

　　利用TCP/IP或者DCOM通訊程序，ADL可以和在本地或者廣域網上的其他應用程序交換信息和數(shù)據(jù)。這些工具實現(xiàn)了對任務、網絡狀態(tài)以及程序進程的遠程監(jiān)控。
同時，ADL包含了Windows 服務的特性，這種特性方便了遠程無人監(jiān)守系統(tǒng)的修復。

圖2 Windows服務安裝和控制流程

　　符號形式的實時調試

　　不同的問題需要不同的解決方法。對于定位設計差錯的問題，ADL提供了符號形式的調試器。這些差錯是指控制流并不是按照我們的設計進行的。一個指令接著一個指令運行、檢測變量內容以及設定斷點－如今所有通用而又先進的調試技術都集成到了該開發(fā)環(huán)境中。

圖3 在一個任務中利用符號調試器設置斷點

　　例如需要檢測昨天造成呼叫方在3a.m.掛機時所發(fā)生的事情，ADL會記錄一份實時的日志，該日志包含了在執(zhí)行操作期間每一個動作詳細的步驟，也包含了總結性的信息。ADL、資源管理器以及R4的事件、狀態(tài)和運行結果都可以在1/100秒內被捕捉下來。

圖4 運行時的日志文件顯示按照時間的事件

　　◎ 過程編程

　　ADL語言也有函數(shù)和變量，和C或Basic差不多。

　　　　　

　　圖5: ADL程序等待一個呼叫，應答它，播放提示，從呼叫方得到DTMF切入，最后播放基于數(shù)字集合的說明文件。

　　◎ 圖形編程

　　ADL流程圖是ADL Studio的一個組成部分，它是一個繪圖工具，可以幫助你創(chuàng)建并編輯電話應用。你無需編寫代碼，只用在圖中插入模塊，就可在流程圖中畫出應用。

　　圖6: 流程圖中的功能塊定義了在什么條件下什么序列下應該執(zhí)行什么樣的動作。
　　那些模塊是預先定義的ADL庫函數(shù)，使用參數(shù)（argument）作為模塊的屬性。

　　圖7: 特性對話框，用于為PlayPrimpt功能塊設置提示名稱和終端數(shù)字

　　◎ 性能和密度

　　為了要達到API透明性的目標，CT ADE加入了一個資源管理層，這樣不可避免的會引入一些開銷。但是，通過最優(yōu)化程序設計，可以使所費開銷最小化。但現(xiàn)在，最有意義的是，應該關注的是應用如何管理多條通道--而不是它處理單獨一條指令流的速度有多快。

　　在任何應用中，根據(jù)程序設計，CPU的使用情況有所不同：

　　在多個可執(zhí)行程序(一個應用一個通道)情況下--CPU的開銷最大，因為在請求或者為每個電話狀態(tài)變化服務時，窗口必須從一個進程（程序）切換到另一個去。

　　在多線程（一個進程中的每個線程各有一個通道）--這種設計下，CPU的性能會好些，但是仍然需要操作系統(tǒng)切換線程以管理通道，

　　單線程狀態(tài)機（一個線程使用所有通道）--狀態(tài)的變化會即時通知線程，直接進行處理，無需詢問操作系統(tǒng)。當前通道的數(shù)據(jù)會被保存下來，并獲取下一通道的狀態(tài)數(shù)據(jù)，繼續(xù)處理。

　　但是，CPU使用效率越高，設計和實現(xiàn)起來就越困難。要想創(chuàng)建一個完整、健壯、靈活的狀態(tài)機，需要多年的努力。這也就是Dialogic提供ADL的原因，它的狀態(tài)機執(zhí)行可以控制單線程的幾百條通道。

　　◎ Dialogic標準結果

　　表1列出了一些實驗室測試和現(xiàn)場測試的實際性能結果。

表1 : Dialogic標準結果

　　這個測試中，只使用了可用的CPU時鐘周期的15％，就處理了所有的API呼叫、操作事件以及狀態(tài)轉換的管理。CPU的其余空閑可以用來處理其它的應用如業(yè)務邏輯或者語音合成或語音識別。

　　用戶ADL應用

　　表2中的現(xiàn)實結果顯示了ADL應用的能力，該應用集成了重要的業(yè)務功能。還有，如果這些應用比你計劃創(chuàng)建的應用簡單的話，也并非是由于限制每塊主板的密度的電話提取工作的影響。

表2: 沒有商業(yè)功能集成的ADL應用的性能

　　VOS移植

　　ADL是VOS（語音操作系統(tǒng)）從Parity軟件（Software）派生出來的。ADL將全新的一套資源管理功能引入到了VOS中。舊的功能（sc_ ，DTI_, GC_…），可以當作是VOS遺留的功能，仍繼續(xù)可以使用，這樣就提供了后向兼容性。然而，對于新的工程來說，我們將強力推薦使用資源管理API。

■ 應用開發(fā)ActiveX對象（ADX）

　　組件對象模型（COM）的控制，也指ActiveX對象的控制，包括了一些很有用的服務，可以將多個組件合成一個大的應用。將復雜系統(tǒng)功能分解到面向業(yè)務的應用中去，這種方法現(xiàn)在很常見，尤其是那些喜歡使用VB或Delphi的圖形化編程環(huán)境的開發(fā)者，常用這種方法。

　　上文中提到的資源管理器提供的所有電話服務，都是被封裝在構建模塊中的，這些模塊在開發(fā)時可以看到它們的功能性（方法、參數(shù)、變量），要在操作系統(tǒng)上注冊功能性，在執(zhí)行時還要創(chuàng)建必要的對象。

圖8: 使用SDX語音方法PlayDate的VB編程，該方法提示基于COM標準的變量。

　　整套控件叫做ADX，包括：

• 語音--模擬、數(shù)字、IP和HMP呼叫控制平臺
• 傳真--CP、VFX以及DM3硬件
• 會議--MSI、DCB以及DM3硬件
• 文本轉語音--可以使用 SpeechWorks* Speechify*, Nuance Vocalizer*, L&H Real Speak*, 和 SAPI-compliant 產品
• 自動語音識別--支持SpeechWorks, Nuance,Philips, 以及 Microsoft的產品。

• 網絡集線器--使用TCP/IP和DCOM實現(xiàn)線程間或進程間的數(shù)據(jù)交換。

　　編程環(huán)境

　　所有支持COM控件的環(huán)境也都支持ADX對象。Dialogic用的測試語言包括了C＋＋、VB、Delphi、C#以及 VB.NET�，F(xiàn)場測試的報告顯示，ADE控件也可成功的應用于JavaScript*網頁、Visual FoxPro*以及PowerBuilder*。還有第三方產品可以利用其它語音如Java*使用COM控件。

　　性能和密度

　　早期的COM對象是用微軟基類（MFC，Microsoft Foundation Classes）來寫的。這些類是為可視化對象設計的，可以廣泛支持用戶界面對話框和文檔處理。用MFC來編寫COM程序，會使得代碼冗余，COM組件會有不必要的巨大開銷。Dialogic的ADE對象使用了活動模板庫（Active Template Library）用以取代MFC。ATL是專為COM開發(fā)設計的，可以是開發(fā)出的COM構件腳本小而效率高。

　　采用與使用ADL時一樣的基準來設計和配置，一個使用ADX語音控制的C＋＋多線程程序，其CPU的利用率為ADL的2倍，但是仍有70％可以給數(shù)據(jù)和其它邏輯處理使用。如果使用一個雙處理器CPU的話，這些單板的性能還會提高。

表3: Dialogic標準結果

　　CallSuile移植

　　ADX是從Parity軟件的CallSuite控件的派生：VoiceBocx*、FaxBocx*、SwitchBocx*、ChatterBocx*、 MatchBocx*以及 NetHub*。雖然在8.3版當中，字面上名字有了些變化，但是控件的名字以及他們的接口特征都是不變的。

■ 新的方向

　　Dialogic還可以為廣大的CT開發(fā)者作些什么呢？以下是一些Dialogic正在考慮的問題：

• 語音XML/SALT--自動語音服務使用這些標記語言，可以更好地加強電話和網絡服務間的關系。你怎樣創(chuàng)建可視的站點，你就可以用同樣的技術創(chuàng)建語音服務。從Dialogic的角度來看現(xiàn)在的VoiceXML平臺，現(xiàn)在對于Dialogic來說，仍是一片待開發(fā)的處女地�？梢缘�http://www.Dialogic.com/查閱Dialogic與Microsoft聯(lián)手執(zhí)行SALT的相關情況�；蛘叩�http://www.microsoft.com去查閱"Microsoft .NET 語音技術"。
  
  
• 視窗庫（非COM）--雖然Dialogic開發(fā)出了最具效率的COM對象，但還是可能會有一些程序設計和主機語言用C＋＋電話類庫來支持效果更好。
  
  
• Linux*--資源管理器、電話類以及ADL框架的優(yōu)勢。

　　請讓我們了解您使用這些產品的感受，以及您未來的需求。請與您的Dialogic經銷商（http://www.Dialogic.com/）或者Dialogic產品經理CT ADE, Lyle Cowen (Lyle.Cowen@Dialogic.com; (415) 332-5656, x1310)聯(lián)系。

[ 全文英文版 ]

融合通信專欄>>技術開發(fā)>>