在“让 Linux 说话”（LJ，1997 年 1 月）一文中，我演示了 SPO256 文本转语音板的一些有趣应用。在那篇文章中，我简要讨论了使用文本转语音作为电话资源以及使用 Linux 作为电话服务平台的潜力。

谈到“电话服务”或一般计算机电话技术，可能意味着很多事情。计算机电话技术的历史虽然是一个有趣的主题，但不是我们的主要重点。相反，我将讨论 Linux 作为语音应答和路径交换平台、PBX 集成和交换机呼叫控制以及将传统语音应用扩展到互联网的用途。

语音应答包括许多应用，例如传统的语音邮件和交互式语音应答 (IVR) 系统，这些系统用作自动“拨号和调查”机器。这些应用程序通常围绕多通道语音电话板构建，这些板捕获和播放数字化语音，并生成和侦听 DTMF 数字和呼叫进程音。更高级的板卡提供板载 DSP 资源，模拟传真/调制解调器服务并执行语音识别。此类板卡的最大单一供应商是 Dialogic 公司。

PBX 集成涉及直接计算机控制 PBX 交换系统。许多供应商都有专门的板卡和/或串行接口，这些接口运行专有协议以访问不同的交换机功能。通常，PBX 集成以电话服务器或 API 的形式实现，例如 Microsoft TAPI 或 TSAPI（目前仅在 Novell Netware 下支持）。通常，这些 API 为桌面应用程序（例如在桌面上放置电话图像和拨号器，直接将数字电话作为“终端设备”进行控制）实现第一方呼叫控制，或为服务器应用程序（例如 ACD：自动呼叫分配器）实现第三方呼叫控制。

互联网电话的整个领域非常有趣且引人入胜。通常，当人们说“互联网电话”时，首先想到的是那些允许计算机用户通过互联网免费进行低质量国际长途电话的巧妙程序。当这种相同的技术应用于具有足够带宽的私有公司 LAN 时，可以提供廉价的办公室间交换手段（很像专线服务和昂贵的专用 T-1 网络），以及 ACD 代理职位的更好解决方案。

传统的低成本电话解决方案在历史上要么在 MS-DOS（可能带有自定义实时内核）下实现，要么在 OS/2 下实现。由于 CPU 功率的提高，以及同样重要的，附加电话板的日益复杂和强大，对高度专业化的实时操作系统来驱动多通道语音应用程序的需求已经消失。现在，许多这些板卡主要依靠自身管理 I/O 和呼叫状态，只需要偶尔进行直接干预。过去，保证最大中断延迟是评估复杂语音处理系统中实时性能的口头禅；我现在发现支持实时可预测的调度策略更为重要。

虽然 Windows NT 现在通常被吹捧为“电话操作系统”，但仍有几个重要的考虑因素。首先是简单的费用；Windows NT 机器意味着一台带有视频显示的机器。更常见的情况是，电话应用程序部署在专用独立机器上，这些机器位于电话间，理想情况下只需要远程管理。

使 NT 比 Windows 95 更适合作为桌面机器的某些相同优化，反而妨碍了将其用于电话应用程序，或同时用作电话服务器和工作站。例如，人们会发现奇怪的调度怪癖，当 NT 优化的视频驱动程序（现在被赋予最高优先级）更新大面积屏幕时，就会发生这些怪癖。

最后，即使在当今廉价 RAM 的世界中，NT 也至少需要 32MB，而 Linux 在 8MB 或更少的内存中也能流畅运行。即使在低端商品语音市场中，基于 MS-DOS 的语音邮件系统占主导地位，并且 50.00 美元的利润变化可能会决定产品的成败，但这些成本非常重要。现在，想象一下一个 2000 美元的语音邮件系统，或者，更好的是，一个 1000 美元的语音邮件“机器”，具有桌面集成、多站点网络和语音/电子邮件交换，以及该系统将对商业语音邮件市场的底线产生什么影响。

为什么不是 OS/2？嗯，首先总是存在“它会存在多久？”的问题。其次，OS/2 的最后一个非桌面优化版本是 1.3，它仍然是当今语音处理产品中最常用和支持的版本。OS/2 驱动程序支持仍然存在于语音应答 OEM 市场中，但它不是一颗冉冉升起的新星。

为什么不是 DOS？简而言之，人们无法从 DOS 机器轻松运行网络服务。在未来的世界中，语音邮件将必须在桌面上呈现语音消息，无论是通过专有方式还是通过 Web 服务器和标准电子邮件协议。其他高级用户应用程序和网络服务将需要被利用到这些曾经专用的独立语音处理机器上。

那么 Unix 呢？多年来，Unix 的某些变体已成功用于语音处理，通常在垂直市场应用程序中。主要 Unix 供应商完全未能理解 CTI 市场并创建适当的软件许可条款或精简的嵌入式版本，这使得使用这些系统作为通用 CTI 平台的成本高得令人望而却步。例如，用于语音处理的 Unix 机器可能不需要 NFS、许多用户实用程序或 X Windows。但是，它确实需要套接字和一个 Web 服务器来进行管理和桌面电话。似乎没有主要的 Unix 供应商知道如何正确许可这种精简的嵌入式配置。

那么我们还剩下什么？一种能够使用廉价硬件、运行用户和实时调度进程的混合、无需本地控制台即可进行远程管理、集成网络并且能够提供数月无人值守的可靠服务的廉价操作系统。只有 Linux 和 Free-BSD 符合这些标准。

如前所述，大多数供应商都支持某种形式的直接 PBX 集成。从最广泛的意义上讲，到目前为止最常见的集成方法是“呼叫详细信息”。市场上的几乎每个 PBX 都能够生成呼叫详细信息，也可作为串行数据提供，可用于呼叫计费系统。

呼叫详细信息通常由不同制造商的不同格式表示，并且可能在同一基本产品的不同版本中发生变化。信息的种类从有关入站/出站中继线使用情况的简单信息（例如，呼叫号码、日期和时间、持续时间和呼叫分机）到完整的呼叫跟踪，其中详细说明了呼叫通过 PBX 的每个方面。

大多数 PBX 都支持“编程端口”，这些端口本质上是连接到哑终端或运行像 ProComm 这样的终端程序的 PC 的串行端口。这些编程端口通常连接到调制解调器，以允许对 PBX 进行远程维护。

编程端口非常有用，并且经常被忽视。从中可以找到和更改典型 PBX 系统的各个方面，例如寻线组、目录号码分配、振铃和限制模式、呼叫转移、数字电话上的功能按钮等。但是，每件电话设备在处理编程的方式上都不同。富士通 F9600 可能具有最容易集成的命令语言之一，因为编程接口表示为一个 shell，具有类似 shell 的命令语言以及用于成功和失败命令的可预测响应字符串。这使其非常适合与哑串行终端或自动程序控制一起使用。

某些系统（例如日通工 384i）将其程序端口实现为菜单系统，假设维护交换机的技术人员正在使用某种 ANSI 终端。其他具有串行编程接口的系统（例如松下 DBS）的行为和接受命令的方式就好像它们是数字电话一样，并且更加不寻常。这些系统需要大量工作才能从应用程序的角度变得可用。

一种通用的集成形式，虽然没有得到广泛实施，但却是 SMDI。SMDI 是最初由贝尔实验室为中心局自动呼叫应答设备开发的协议。SMDI 在可用时通常用于语音邮件集成。

SMDI 通过串行端口传输，并且涉及一个简单的标准化协议，用于从 PBX 发送命令和接收消息。不幸的是，SMDI 几乎仅限于识别呼叫的来源，当呼叫出现在“消息详细信息”分机（例如，连接的语音邮件系统的分机）上时，以及控制电话上的“消息等待”指示灯。但是，由于此功能对基本语音邮件系统很有用，我们将在本文后面再次讨论 SMDI。

不提供 SMDI 的系统使用音调来表示第三方语音邮件系统的信令和集成。这些音调是 DTMF，并出现在连接的语音邮件或 IVR 应用程序处理其语音路径的端口上。由于这种集成形式非常有限并且涉及语音板卡，因此我将不再进一步讨论它。

这给我们留下了一大类“其他”集成端口。这些通常是带有自定义 API 或通信板卡的串行端口。它们使用专有协议来指示信令和控制活动，因为呼叫进入或从电话交换机发出。

一些供应商非常热衷于为第三方开发呼叫控制应用程序提供支持。特别是 Harris，不仅记录了他们的主要串行控制协议（分别称为 Harris HIL 和 WIL），还向第三方提供了实际的源代码，演示了如何实现他们的协议。其他供应商（例如富士通）向感兴趣的第三方提供其协议的完整技术文档和规范。富士通文档中的英语有点差，但至少他们努力推广他们的接口 (TCSI)。

唉，许多供应商认为有必要对此类信息保密。这样做减缓了通用计算机电话应用程序接口的广泛开发，并将开发限制在非常有限的一组参与者中；即 Novell TSAPI 和 Microsoft TAPI。这种保密墙限制了大多数第三方围绕特定品牌设备的功能集优势创建更高级的集成，并允许制造商挑选谁将被允许直接集成他们的产品。

让我们详细了解一下富士通 F9600 PBX。它包括一个用于编程的串行端口。故障消息和系统状态以及呼叫详细信息也从该端口流出。它有一个可选的板卡，带有一个同步 19.2Kbps TCSI 接口，称为 TCSI。考虑到它是一个低速链路，似乎没有必要。

此外，富士通拥有自己的围绕电话服务器构建的电话架构。此电话服务器在 SCO (ODT 3) Unix 下运行，并为每个端口提供单独的服务器，以及一些应用程序服务器。主电话服务器用于通过 Eicon HDLC/X.25 板卡控制 TCSI 接口。第二个单独的服务器用于控制编程端口。多个应用程序可以驻留在电话服务器上，每个应用程序都使用单独的服务器，并通过 TCP/IP 会话与 MML（PBX 编程接口）和 TCSI 服务器通信。此外，可以在运行 Novell Netware 的单独机器下加载接口驱动程序，以及 Novell Netware 电话服务，以通过 SCO 机器为 PBX 提供 TSAPI 接口。

富士通使用的多层服务器结构使应用程序能够直接利用 TCSI 服务、MML 接口或通用通用 API 集 (TSAPI)。但是，它使用两台单独的机器和操作系统来构建此结构，并且每个低级服务器都没有直接意识到另一个服务器中可能包含的有用信息。

其他供应商完全隐藏了 PBX 的低级接口，并且仅为其交换机提供 TSAPI（或 TAPI）接口。这些接口仅使用在一个端口（呼叫控制端口）上找到的信息，而忽略了编程端口上可用的信息以及通过通用 API 创建远程网络管理的潜力。

实际上，TAPI 和 TSAPI 中表达的通用 API 概念是基于创建模型 PBX 呼叫控制系统作为服务器。应用程序和此通用服务器之间使用单个 API 和单个协议。然后，通过提供较低级别的驱动程序（服务提供商接口）来实现服务器，以弄清楚此通用 PBX 模型如何应用于供应商特定硬件和呼叫控制模型的特殊性。

单模型 API 在两种方式之一中失败。首先，由于无法在通用呼叫控制模型中表示和重新创建特定功能，因此某些模型 API 功能在特定供应商的低级 SPI 驱动程序下不可用。其次，供应商可能支持的超出基本通用模型的真正整洁和独特的功能是不可用的，除非像富士通一样，提供了第二个直接协议服务器。

为了解决免费和开放系统的先进集成中的这些问题和其他问题，我完全放弃了 TSAPI 和 TAPI 中使用的通用 API 和单协议分层模型。我认为更好的解决方案是多协议“TServer”，用作单个统一服务器和网络入口点，用于访问可以从电话交换机进行网络访问的所有服务

松下 DBS 是一种广泛使用的数字混合键控系统（不要与松下 KXT 混淆）。围绕 DBS 创建模型服务器的选择是基于对该交换机内部结构的直接熟悉以及可用于测试的硬件的可用性。

DBS 有两个可用的接口。第一个是内置串行端口，用于编程和呼叫详细信息记录。因此，服务器必须对端口的当前“运行状态”（即，当前是否用于编程）敏感。如前所述，DBS 编程端口的命令表示方式类似于人们从数字按键电话编程交换机的方式。

为了简化 DBS 串行编程以供应用程序使用，我创建了一个简单的协议来发送“更改值”、“获取值”和“清除值”请求，这些请求构成了从电话编程 DBS 的操作的概念核心。这些命令以及受影响值的地址规范构成了我的 DBS 编程协议的基本要素。

DBS 还包括一个可选的 API 卡。此卡有一个用于呼叫控制和交换的串行端口。此低级协议是单向的，并且涉及消息数据包和访问协商协议。该接口是串行的，没有硬件流量控制的规定。消息本质上是在主机和交换机之间交换的，类似于富士通 TCSI、Harris HIL 或其他设备。更高版本的 DBS API 包括两个串行端口，其中一个端口具有扩展功能以支持 Netware TSAPI 服务器。

由于需要维护所有这些协议接口并连接单个网络入口点，因此不能使用单片服务器。由于连接点（API 接口和编程接口）可以同时被多个应用程序用作共享资源，因此 Unix 中常见的简单“fork()”服务器是不合适的。相反，有一组协议服务器连接到一个“交通警察”。这个多协议交通警察将自身绑定到单个网络端口地址，从而从单个网络会话提供通用访问，并充当主 TServer。

在最简单的方法中，每个协议（接口）服务器都作为使用匿名管道的子进程运行。TServer 接受并管理用户应用程序会话。协议服务器的匿名管道非常快，并且需要较低的开销，尤其是在 Linux 中。

在 DBS 中，API 接口部分有多个服务器层。这种分层行为有点像流驱动程序堆栈，它可能可以在可流式传输的 Unix 下实现。

最低层是 DBS 数据包链路驱动程序 (papild)。此驱动程序协商与 DBS 的单向数据包交换，并将 DBS 消息规范化为单个固定数据包。固定大小数据包的原因是允许通过执行原子 read() 和 write() 调用在不同协议层之间传输所有消息。此方法允许干净地跟踪非阻塞管道上的“拆分”消息，该管道已覆盖其缓冲区。

DBS 数据包通道状态驱动程序 (papicsd) 是从 papild 之上的管道构建的第二个流层。此层了解 DBS 的特殊性质，其中所有消息事件都是针对一个或多个通道启动的，这些通道是与 DBS API 卡关联的虚拟站端口。可能生成回复消息的请求在 papicsd 中排队。如果预期回复的请求失败，则 papicsd 层可以生成超时事件。同样，papicsd 层负责冲突解决，当尝试在发生来电的同时将站点摘机时，就会发生这种情况。最后，papicsd 层可以捕获荒谬或毫无意义的命令，例如挂断已知已挂机的端口，并将生成的错误消息返回给应用程序。

通过为 papild 和 papicsd 设置单独的进程，它们变得更易于编写和调试。此外，由于 DBS 没有流量控制，papild 可以专用于 I/O 特定操作，甚至可能在 Linux（2.0 及更高版本）中的实时调度约束内运行。这与非阻塞原子管道作为驱动数据包在协议层上下移动的手段相结合，需要更少的开销，并且比松下最初为 DBS 提供的 QNX 应用程序产品运行得更加流畅。

在编程接口（在 DBS 上标记为 SMDR）上，使用单个进程。当没有活动的编程请求时，它只是为呼叫计费目的假脱机 CDR 数据。当发生编程请求时，服务器将状态更改为编程端口接口服务器，并保持该状态，直到 30 秒过去而没有任何编程请求发出。

除了 TServer 本身之外，papi 堆栈上还有一个协议层。此实用程序层根据实时 DBS API 数据将 DBS API 通道状态映射到站卡和中继线状态。此映射层 papiltu 本质上是一个类似 SPI 的层，因为它以中间形式表示 DBS 的当前状态，就线路和中继线活动而言，这可能比 DBS API 通道架构更有意义。此层还保存 DBS 站目录映射，该映射是在初始化期间从编程接口获知的。它映射和维护的信息通过共享内存块与其他 DBS 相关协议服务器（例如 SMDI 服务器）共享。

通过使用编程端口和 papiltu，papi 协议堆栈能够通过读取当前的 DBS 编程自动配置自身，而无需用户应用程序编程和设置。这取代了笨拙的手动方法，即使用“通道配置”屏幕来单独编程 API 端口配置，就像早期松下应用程序产品中使用的那样。papiltu 功能最初是主 TServer 应用程序服务器的组成部分，但由于对发布 DBS API 资料的限制，它被制成一个单独的层，以便于发布主 TServer 源代码，如果 papi 堆栈源代码都无法发布。此事仍在讨论中。（请参阅文章末尾的评论。）

TServer 线路/中继线状态映射实际上使 TServer 的行为有点像 TAPI 或 TSAPI 的 SPI 层，因为它表示通用 PBX 模型和实际物理模型之间的中间形式。在这种情况下，除了驱动直接硬件接口协议外，我们的 TServer 还可以与逻辑协议驱动程序通信，这些驱动程序未直接连接到任何物理硬件。

一个这样的逻辑协议驱动程序是 DBS SMDI 驱动程序。通过匿名管道连接，就像 papicsd 和 smdr 层驱动程序一样，smdi 协议驱动程序通过返回到 TServer 的连接与共享的 papicsd 通信。由于它不依赖于单个共享硬件资源，就像真正的（物理）驱动程序一样，因此为每个客户端应用程序创建（fork）一个 SMDI 驱动程序的实例。此驱动程序继承为客户端连接接受的 TServer 套接字以及返回 TServer 的管道；因此，SMDI 仿真驱动程序和客户端应用程序之间的通信始终是直接的（即，它没有 TServer 路由开销）。

基于 SMDI 示例，人们可以轻松地创建协议模块和匹配的应用程序接口，以直接完全模拟 TSAPI 或 TAPI 服务。人们还可以直接与供应商特定的硬件协议（例如 papi 层或 SMDR 接口）对话，或创建全新的任意集成协议。TServer 作为单个联系点交通警察，允许客户端执行身份验证并选择客户端应用程序希望使用的接口协议。

DBS 的一个有趣的功能是能够将大型显示电话变成一种简单的终端设备。这允许应用程序控制显示内容，并允许应用程序在按下电话上的按键时接收输入事件。另一个功能是特殊的“热键”（也称为 ACD 键），它充当“注意”键，无论当前电话状态如何，按下时都会生成 API 事件。

我创建的第一个 DBS 应用程序之一是用于将“小程序”附加到电话的简单菜单程序。按下注意键时，会出现一个简单的应用程序菜单，可以从中选择一个应用程序。其中一个应用程序用于立即显示我的服务器的状态信息（有多少用户在线、正常运行时间等），以及用于强制服务器重启的软键菜单项。

我的另一个数字电话应用程序是一个更高级的快速拨号器，它没有容量限制并且可以从电话编程。此应用程序在概念上类似于富士通“按名称拨号”服务器应用程序。DBS 有自己的内部快速拨号目录。由于字母数字文本很难通过电话输入，因此我编写了一个简单的 Visual Basic 程序来连接到 SMDR 编程协议，以便编程 DBS 快速拨号。

一个可能的未来应用程序是使用户能够从桌面或可能从网页编程他们自己的电话。

自由和开放系统在计算机电话技术中存在许多机会，特别是对于那些足够明智的电话供应商，他们通过允许第三方自由解决超出其自身直接范围的问题和应用程序来扩展其营销机会。虽然我选择使用松下 DBS，并接受了对其披露和源代码发布的限制，但其他几家供应商已表示有兴趣让他们的设备在后续文章中进行专题报道。

当我开始撰写本文时，我意识到正在努力创建一个用于电话集成的标准和开放的互联网协议，称为“stp”，简单电话协议。经过一番辩论后，我选择完全拥抱 stp，并且本文中描述的当前软件正在被重写以支持和遵守不断发展的 stp 标准。“SwitchLink”这个名称也被采用（简称 swilink）。我的意图是 swilink 将作为免费和开源软件包广泛提供，以便与所有主流 Linux 发行版一起发布。因此，自由和开放的电话技术将成为 Linux 的常态，而不是例外。

最近，一些主要的电话业务硬件供应商对 Linux 的态度发生了相当大的变化。我现在相信，撰写关于 Linux 作为通用和高性能互联网电话平台的使用的文章的机会可能会比我预期的早得多。

词汇表