语音应用程序接口(API)的几种分类

 ----为了使数据   与话音网络协同工作，就需要用到语音应用程序接口(API)。利用这些接口建立应用程序，可   以在应用层连接不同的系统。API的特点在于它从硬件层中抽象出来，开发人员可以不用再为   每种不同的硬件写专用的代码，而且可以利用系统独特的能力而无须编写功能重复的代码，   因此给开发人员带来极大的方便。另外，并非只有开发人员重视API，管理者也同样如此。因为，   利用适当的API，可以使用升级的、性能改善后的应用程序而无须更换硬件。有哪一个管理者   不想保留现有的硬件投资呢？    
   
  ---然而，语音应用程序接口正处在逐步发展的过程中，所以并非十分完善，也尚未在CTI业界得到广泛的使用。但是，开发者又必须选择一种功能强大而且稳 定持久的API才能保证CTI设备应有的功能，这的确   是个矛盾。基于这种情况，我们就需要正视一些问题，例如各种API彼此有什么不   同？它们之间是否能够互相兼容？目前使用哪一种API更能发挥CTI的最大优势   ？对于那些正在开发CTI应用、沟通数据与语音通信的人来说，目前回答这个问题   可能还为时过早。不过有一点很清楚，那就是基于技术不能持久稳定的API进行产   品开发只能是浪费时间，很可能会错失良机。以下是我们对目前API的一些分析，   供开发者参考。    
   
  当   前   流   行   的API    
  ----   计算机语音集成系统中有三种流行的应用   程序接口：微软公司的语音应用程序接口TAPI、Novell和AT＆T的语音服务器应用   程序接口（TSAPI）和Sun公司的Java语音应用程序接口。TSAPI是首先成功的API。而TAPI   出现的较晚，已经经过了两次修正。尽管很多人抱怨这些修正版的出现不够及时，但   是我们应该看到，每一次修正都是极大的改善。尽管JTAPI的出现比TAPI还要晚，但   在某些方面比TAPI更加稳定，而且在很多CTI产品中已使用这种API。现在，我们就来   详细地了解这些API。    
  ----·   TAPI    
   
  ----目前，TAPI已嵌入到微软的各种操作系   统之中。在WindowsNT4.0和Workstation4.0中内嵌了对TAPI2.0版的支持。TAPI   2.1版性能又有所提高，而且纠正了很多错误。该版API可以在微软的Web站点上   获得。另外，所有运行Windows95操作系统的计算机都支持TAPI1.4的应用，它与TAPI   2.0是完全兼容的。微软的TAPI3.0目前仍在测试过程中，所以开发人员既可以   使用TAPI2.0，也可以使用TAPI2.1。在WindowsNT5.0Beta中包括了TAPI3.0，   不过要得到该测试版，你就必须是微软开发者阵营的成员。    
   
  ----TAPI目前的版本可以区分不同的媒体流（   如数据、语音和传真）和发送到某些应用和设备的呼叫。例如，可将传真来话转到   传真应用或传真机上。    
   
  ---TAPI是视窗开放服务结构（WOSA）的一部   分。与其他WOSA服务一样，TAPI有两种接口：第一种是为开发人员编写软件的应用   程序接口；第二种是服务提供者接口，它提供了一种连接到某一特定设备的方法。    
   
  ----   在TAPI3.0中，服务提供者接口扩充了   连接到IP电话的功能。也就是说，TAPI3.0从连接层上抽象出来，因此开发应用时   无须考虑是否连接到了公用交换电话网（PSTN）、ISDN网络、程控交换机或是IP网   络上。    
   
  ----TAPI3.0呈现的其他特性还包括对Unicode   的支持以及对通用串行总线（USB）和ActiveX控件的支持。利用这些ActiveX控件，   开发者能够利用基于组件的图形环境，避免了大量烦琐的编程。特别是开发者可   以结合一些小的专用程序来创建大型应用。由于很多组件是可重复使用的（目前，   开发人员可使用微软的1000多个可重用ActiveX控件），因此开发者的工作主要集   中在开发那些特定的应用程序。在这种方式下，编制程序变得越来越快而且允许   更高层次的定制化。    
   
  ----TAPI3.0也将支持ActiveX目录集成、统   一呼叫控制和媒体流，而且提供了一个面向对象的与编程语言无关的API，以及与WIN3.2   驱动模型（WDM）一致的流式结构。总之，TAPI3.0可以让开发者创建可升级的语   音服务器应用。    
   
  ----   然而应当指出的是，有很多应用已经是TAPI   力所不能及的，例如仅仅使用TAPI1.4和TAPI2.0对呼叫中心的应用还不够。而TAPI   2.1中有很多需要完善的地方，这些最终将在TAPI3.0中得到解决，同时给开发   人员提供了建立CTI应用所需的所有工具。TAPI3.0对ACD（自动呼叫分配）、代理、   群组和路由的支持使它完全能够胜任呼叫中心应用的创建。    
   
  ----·   TSAPI    
   
  ----Novell和AT＆T公司开发的TSAPI，其主   要任务是将程控交换机或中央电话系统与Netware网络集成在一起。TSAPI是最早   的语音应用程序接口，而且在市场方面也获得过一些成功，与后期出现的TAPI和JTAPI   相比略显优势。然而，虽然TSAPI早期比较成功，但却因为公司不太关注市场策略，   加上昂贵的客户许可证费用使得它失去了发展的动力。Novell公司的早期合作伙   伴朗讯目前继续对TSAPI进行开发。    
   
  ----TSAPI的安装通常需要将Netware文件服   务器放置在电话室中或较近电话室的地方，并与程控交换机有物理的连接。在客   户端，市场上的一些第三方TSAPI应用程序可以执行一些呼叫控制功能。当TSAPI   应用程序运行在PC上时，来话呼叫能够执行一个wav文件，通过多媒体计算机的音   箱发出振铃信号。    
   
  ----   用TSAPI建立的应用在计算机和桌面之   间有一个逻辑的连接，因此TSAPI倾向于成为一个完全呼叫控制API。通过这些连   接在任一端的TSAPI应用就可以完成呼叫控制。另外，呼叫控制也能委派给第三方   来完成（TSAPI提供对第三方的支持）。    
   
  ----   与TAPI不一样的是，TSAPI支持所有主要   的操作系统，包括Windows各种版本、OS/2和Unix。很明显，TSAPI这种支持多平台   的特性吸引了越来越多的公司，因此运行在异种环境下的应用是值得重视的。由   于采用客户/服务器结构的设计，TSAPI能够在计算机与电话之间没有物理连接   的情况下依然工作。也就是说，没有必要在每台计算机上都要有硬件连接的电话。   显然，这种特性能够节省大量投资。但是由于计算机与电话之间是非物理的连接，   也使得TSAPI应用不能识别媒体流。例如，使用TSAPI不能自动将传真转接到传真   应用，而这种能力正是TAPI的特点。    
   
  ----·   JTAPI    
   
  ---JTAPI是Sun公司提供的Java语言应用程   序接口。SUN与其他诸如Intel、Lucent、Nortel和Novell一起开发了JTAPI的规范。JTAPI   本质上是一套可重用的语音呼叫控制对象，它能在一些基于Java的电话应用中使   用，而这些电话应用能够运行在任何带有Java虚拟机和JTAPI电话子系统的计算   机上。正是由于JTAPI基于Java的特性，使得JTAPI对象独立于任何操作系统和硬   件平台，从而支持跨平台的应用。JTAPI定义了一套类库，包含一套电话功能和扩   充功能。开发者可使用它开发一些个人应用，例如一套扩充处理任务，包括呼叫路   由、在多组呼叫者之间建立电话会议等。    
   
  ----JTAPI正朝着混合型电话的方向发展，结   合了传统的电话服务和Web处理能力，如浏览、收发电子邮件等。Sun公司与Nortel   目前正在合作使用JTAPI开发一种互连网络的通信设备，它能够通过Internet连   接到任何一部电话、桌面计算机和网络计算机。JTAPI能与其他的API，诸如TAPI、TSAPI   等一起工作来处理语音，而且由于JTAPI的开放性，将来很可能会成为ECTF所认可   的标准。    
   
  分   析   比   较    
  ----综上所述，TAPI是目前电话应用中较为流行   的API。如果你有一个基于NT的网络，而且考虑基于服务器的电话，就可以选择TAPI。TAPI   也适合于一些小型企业，可能这些企业更希望在计算机与电话之间建立直接的连接，   利用网络和TAPI的媒体处理能力在整个网络中传送语音。    
  ----TSAPI比较适合于运行在各种各样的Netware   网络环境中。尽管其费用较高，但与其他非WindowsNT环境中实现的应用相比，其   费用还是较为廉价的。可取代TSAPI的是基于客户模式的TAPI1.3，它需要在每台   计算机中加入一块语音板卡。    
   
  ----JTAPI的优越性胜过TAPI和TSAPI。JTAPI   主要集中在应用软件，而TAPI和TSAPI主要集中在与计算机连接的电话网络中。JTAPI   提供给开发者一种方法，用面向对象的编程模式定义CTI函数，而这种模式允许编   程人员建立由公共的CTI函数组构成的对象库。例如，IBM引入了JavaBeans，开发   者可使用这种可重用的软件对象创建呼叫中心应用，其中包括传输对象、应答对   象和电话会议对象，并且将数据与主叫用户联系在一起。微软的TAPI目前缺乏这   些能力。    
   
  ----   很多开发人员目前正在考虑另外一种API，   那就是S.100规范。S.100规范由ECTF开发，目前主要是提供一种方式，满足TAPI中   所不具备的开发需要。然而，自从S.100定义以来，TAPI发生了很大的变化，而且   将来TAPI功能也会变得越来越强大。TAPI3.0不但提供了S.100中所有的功能，而   且还有S.100所缺乏的一些增强特性。