OpenPhone 项目 (http://www.openphone.org/) 有一个简单的目标——让地球上的每台计算机都能打电话。如果一台计算机可以浏览网页并播放互联网广播电台的音频，那么它也应该能够拨打和接听电话。基本技术现在已经可用。OpenPhone 项目旨在促进能够实现这一目标的软件的开发。

IP 语音 书评

互联网电话，或 IP 语音 (VoIP) 技术，在过去几年中取得了长足的进步，但其发展道路上充斥着令人困惑且不断变化的标准。我将旨在介绍互联网电话的技术和标准，希望更多人能够参与 OpenPhone 项目。互联网电话是当今电信领域最令人兴奋和发展最快的领域之一——而且它非常适合 Linux！

让每台计算机都能打电话——这意味着什么？这意味着每台计算机都应该能够充当电话——最好是非常智能且可编程的电话。有几种实用的方法可以实现这一壮举。简单的方法是使用计算机的正常资源来模仿电话的一些功能。例如，使用声卡和麦克风/扬声器进行通信，并使用屏幕弹出对话框或播放声音文件来指示 响铃。另一种更复杂的技术是使用电话接口卡，让您可以将普通电话插入计算机。鉴于当今廉价且功能强大的电话（尤其是无绳电话）以及低成本电话接口卡的可用性，这是 OpenPhone 项目青睐的方法。

电话接口的类型和功能繁多且令人困惑。它们似乎分为两个基本类别：高密度多线路数字接口卡（T-1 或更高）和低密度模拟卡。由于大多数人在家中没有 T-1 电路，因此 OpenPhone 项目专注于低密度模拟卡。这些卡的价格不比一块像样的显卡贵多少，并且提供了一整套使互联网电话能够工作的关键功能。它们最简单的功能是让您将普通的廉价模拟电话插入计算机，并提供对响铃和音频的完全控制。但是，它们还提供对语音质量至关重要的基于硬件的音频压缩。以下将更详细地讨论这项硬件技术。

OpenPhone 项目并非 Linux 独有，尽管它肯定有很强的 Linux 倾向。就像传真机一样，互联网电话的有用性取决于有多少其他设备可以与之互操作。如果基于 Linux 的 OpenPhone 只能呼叫其他 Linux 计算机，那么它的价值有限。但是，如果 OpenPhone 可以呼叫任何其他计算机，无论其操作系统如何，或者世界上任何地方的任何其他电话——那就太强大了！这就是 OpenPhone 项目的目标。

在撰写本文时，OpenPhone 项目正在使用 Quicknet Technologies, Inc. 制造的电话接口卡。Internet PhoneJACK 提供 PCI（外围连接接口）和 ISA（工业标准架构）总线版本，并提供 RJ-11 接口，任何普通模拟电话都可以插入其中。它还具有耳机/麦克风和听筒插孔。Internet LineJACK 具有 RJ-11 POTS（普通老式电话系统）端口和一个额外的 PSTN（公共交换电话网络）端口，用作连接到普通电话系统的网关。Internet LineJACK 目前仅提供 ISA 接口。这些低成本接口卡具有 Linux 和 Win32 驱动程序，并提供使用单个标准电话连接到计算机的能力。更多信息可在 Quicknet 的网站 (http://www.quicknet.net/) 或我在上一期（九月刊）Linux Journal（“Linux 的 IP 语音”）中的文章中找到。

正在与几家其他硬件供应商进行谈判，以参与 OpenPhone 项目。我们鼓励这些供应商为尽可能多的操作系统提供驱动程序，并加入我们，使 OpenPhone 能够在所有平台上工作。

电话可以被认为是包含两个主要部分：用于通信的音频通道和用于控制音频通道的信令通道。在传统的公共交换电话网络 (PSTN) 中，信令发生在电话公司拥有和运营的单独的专用网络上。这个单独的信令网络使用一种称为 7 号信令系统 (SS7) 的协议；它用于控制系统中交换电路的呼叫建立和结束（拆除）。

PSTN 的音频通道部分主要由两部分组成：本地环路和连接所有本地环路的中心局 (CO) 设备。本地环路是进入您的住宅或企业的双绞铜线——模拟线路。CO 设备由高速数字链路组成；这超出了本文的范围。本地环路使用模拟信号将您的语音传输到 CO，在那里它被数字化并发送到呼叫另一端的 CO。另一个 CO 接收数字信号，将其转换回模拟信号，并将其沿模拟线路发送给被叫方。

互联网电话的工作方式相同，只是数字化过程发生在您的计算机上，并且终端站之间的高速数字链路是互联网。您的电话接口（或声卡）将模拟信号转换为数字信号，并以 IP 数据包的形式发送到目的地。目标计算机将其转换回模拟声音信号，并通过您的电话播放出来。很简单，对吧？啊，但像大多数涉及计算机的事情一样，细节才是棘手的部分。

互联网电话必须在通话双方之间传输音频信号——这是基本要求。我们都知道互联网可以传输高保真音频，因为我们中的许多人都使用互联网连接和 PC 听过流媒体音乐或广播节目。然而，互联网电话有点复杂，因为它必须进行全双工（双向）实时音频，并且人耳对延迟非常敏感。延迟太长，通话听起来就像是通过卫星而不是通过互联网传输一样！

带宽也是一个问题，尤其是在拨号上网线路的情况下。在正常的 PSTN 世界中，本地环路上的音频被数字化为 64Kbps 的数字数据流，并呈现给电话公司的 CO 设备，然后 CO 设备压缩数据以通过电话系统骨干网传输。简单的互联网电话软件包使用类似的数字化，从而为全质量语音产生每个方向 64Kbps 的带宽要求。这需要 128Kbps 的带宽，再加上信令和开销的额外带宽，因此这在可能只有 56Kbps 的普通拨号互联网连接上效果不佳。

幸运的是，语音压缩技术已经取得了长足的进步，并且效果非常好。使用当今的语音编码器（编解码器）获得 8:1（或更好）的压缩比是很常见的。现代互联网电话接口卡将这些编解码器作为标准功能提供。

正常的电话系统为语音数据包的流动设置虚拟（或有时是真实的）专用电路。互联网则更加混乱。在互联网上，数据包可能每秒钟采用不同的路由，并且可能无序、延迟、根本不到达或在时间上交错地到达目的地。延迟的数据包可能与丢失的数据包一样糟糕，因为如果数据包没有及时到达并准备好播放，音频中就会出现间隙。乱序的数据包也可能没有用——如果它乱序了，它可能就延迟了。到达目的地的数据包不太可能以整洁有序的方式到达。有时它们花费的时间比平均延迟长或短一点——数据流不均匀。这种交错称为抖动。几种技术用于处理这些问题：实时传输协议 (RTP) 和抖动缓冲区。

音频数据包需要按时且按正确的顺序到达。RTP 是一种用户级协议，它提供了一种将数据封装到数据包中的方法，这些数据包带有足够的信息的时间戳，以允许正确播放音频。该协议有一个配套的控制协议 (RTCP)，它为端点提供了一种了解它们正在接收的服务质量的方法。完整的协议在 RFC1889 中描述，可以在 www.ietf.org/rfc/rfc1889.txt 找到。RTP 的几种实现以各种开源许可证提供。有关更多信息和指向这些库的指针，请参阅资源。

互联网是不可预测的，以良好的可预测速率发送的数据包并不总是以它们发送的速率到达。它们可能比平均延迟稍微早到或晚到。如果数据包稍微晚到，准备播放下一帧音频的音频设备将无内容可播放。这会导致不连续性，从而降低音频质量。在简单的应用程序中，这是一个短暂的静音期，使语音听起来断断续续。在更高级的应用程序中，使用舒适噪声或某种形式的音频混合来掩盖间隙。这会使语音听起来失真或好像在水下一样。顺便说一句，在使用手机或互联网电话时会观察到这些效果——数据包丢失和延迟是所有数字音频应用程序的普遍问题。RTP 提供了一种方法，让应用程序软件知道数据包是否乱序、丢失或过早或过晚到达。然后，应用程序可以对丢失或错序的数据包进行适当的纠正。

解决抖动的最佳解决方案（除了完美的传输路径，这将完全消除抖动）是确保音频设备永远不会“耗尽”。这需要抖动缓冲区。这些缓冲区在开始时存储少量音频，然后稍微领先于数据流，以便始终有音频帧可播放。几个单向实时音频/视频程序会在播放任何声音之前缓冲几秒钟的数据，从而确保它们始终有大量数据可供播放。但是，每个缓冲的帧都会增加延迟，这与语音呼叫尤其相关。如果您缓冲 90 毫秒 (ms) 的数据，您将在单词说出到听到单词之间的时间增加 90 毫秒的延迟。当添加到互联网本身的延迟时，这可能会迅速变得不可接受。有些人认为 200 毫秒的延迟是人耳可以容忍的上限。鉴于许多互联网位置相隔 100 毫秒或更长时间（单向），添加 90 毫秒的抖动缓冲区延迟占可接受延迟的很大一部分。抖动缓冲的需求与减少延迟的需求之间存在微妙的平衡。

抖动缓冲技术是我认为开源社区可以做出重大贡献的领域之一。现在正在进行大量的思考和实验，以寻找在双向实时音频流中使用自适应抖动缓冲区的算法和技术。我怀疑开源社区的共同努力将在明年找到一些针对此问题的出色解决方案。我希望 OpenPhone 项目能够成为加速实现这一目标的催化剂。

标准的 PSTN 数字化技术由 ITU G.711 规范描述。本文档描述了使用每样本 8 位的 8KHz 采样率，有效数据速率为 64Kbps。此技术有两个子集：A-Law 和 Mu-Law。这些是比例因子，它们考虑了人耳的灵敏度，并允许更有效地利用 8 位编码空间来记录人声。两者都得到广泛使用，并被认为是标准编解码器。

然而，64Kbps 对于互联网电话来说太大了。以此方式编码的双向音频仅音频就产生 128Kbps（不包括信令或开销），这使其不适合通过拨号链路使用，并且即使在 LAN 或 WAN 链路上也浪费带宽。语音压缩是答案，并且有几种选项可供选择。

音频编解码器可以在软件中实现，也可以由电话接口卡使用板载 DSP 提供。在负载较轻的 PC 上，编码产生的额外处理负载并不是特别繁重，尽管在负载较重的机器上可能会很繁重。纯软件解决方案可能会增加一些延迟，因为编码通常发生在用户空间程序中，因此受系统负载和调度程序的支配。互联网电话卡使用板载 DSP 执行编码，实际上消除了主机 CPU 上的负载和相关的延迟。

也许互联网电话中最广泛使用的编解码器是 G.723.1。此编解码器提供 6.3 或 5.3Kbps 的数据流，数据包每个包含 30 毫秒的音频。编码需要 7.5 毫秒的前瞻，这与 30 毫秒的帧结合起来，总共产生 37.5 毫秒的编码延迟。这是使用此编解码器的最小理论延迟。当然，实际延迟将包括互联网上的时间和两端的应用程序级处理（以及抖动缓冲区——一定不要忘记）。

G.723.1 是专利技术。专利持有者对其使用收取版税，这使得它不可能在开源软件中使用。但是，大多数电话板（包括 OpenPhone 项目使用的硬件）都将此编解码器作为板价格的一部分包含在内。除了电话接口板优于声卡的其他技术优势外，在卡上包含许可的压缩编解码器可能是我们需要这些卡的最好理由。借助硬件中的编解码器，我们可以编写开源软件，而不会违反任何许可证。我想指出的是，G.723.1 编解码器与 G.723 编解码器（带宽要求高得多的编解码器，其源代码广泛可用，但由于带宽要求高而不经常使用）非常不同。

G.729 和 G.729A 编解码器正在迅速普及。这些编解码器使用 8KHz 采样率、10 毫秒音频帧和 5 毫秒前瞻缓冲区，总共产生 15 毫秒的处理延迟。由于帧只有 10 毫秒长，因此该编解码器受数据包丢失的影响较小——考虑到任何一个数据包的丢失，软件需要恢复的数据更少。G.729A 是编解码器的一个版本，它使用更少的 DSP 资源，使其更容易在低性能（更便宜）的 DSP 芯片上实现。这些编解码器可以提供的音频质量令人震惊。我最近体验了使用 G.729A 编解码器的基于 LAN 的呼叫，并且站在呼叫我的人旁边。我无法检测到直接路径（他的嘴到我的耳朵）和网络链路之间的任何可感知延迟。如果我不知道其他情况，我会发誓这是一个正常的 PSTN 呼叫。此编解码器是互联网电话的未来。

带内信令包括您在通话过程中通常听到的所有音调，包括响铃、忙音、快速忙音和最重要的双音多频数字 (DTMF)。这些音调是使用电话的正常预期部分，但不幸的是，许多音调使用上述算法压缩效果不佳。另一种选择，也是 OpenPhone 项目选择的一种选择，是将这些信号作为实时音频流中的单独数据类型传递。这样做的好处是确保无论需要哪种音频编解码器，信号都能在连接的另一端准确再现，并且减少了传输数据所需的带宽。

此技术在 Internet 草案（请参阅资源）中进行了描述。它基本上指定了一种新的 RTP 数据有效负载类型；应用程序层只需将数据与正常音频一起发送到数据流中。一个非常棘手且需要更多工作的方面是从音频数据流中删除实际音频信号的代码，然后再进行压缩。如果这些音调和信号被压缩，编解码器将在远端扭曲这些信号，从而降低正确检测信号或音调的机会。最好在压缩之前过滤掉这些信号，并直接通过网络传递信号，从而允许另一端以完美的精度再现信号。

在传统的 PSTN 世界中，电话公司拥有一个专用的私有网络来完成所有信令。世界上每个想要与世界其他地方互操作的电话系统都必须使用 SS7 网络并遵守其规则。但是在互联网上，没有单独的专用网络——控制信号和数据信号使用相同的网络。那么，信令是如何工作的呢？这不是很简单。有几种不同的方法可以完成这项工作，并且有几种不同的“标准”可以提供指导。这是对问题和标准的简化。我建议您参阅资源部分，以获取更多详细信息的地点。

当前正在使用几种互联网电话标准：H.323、SIP 和 MGCP 是当前使用的主要标准。我无法希望对这些协议进行快速介绍，但肯定可以提供概述和指向可以了解更多信息的地方的指针。

H.323 是国际电信联盟 (ITU) 建立的一系列协议。它非常复杂，但涵盖了人们希望通过网络进行视听会议或呼叫的大部分内容。H.323 源于电信世界，而不是互联网世界。它是一种二进制协议，使用 ASN.1 表示法/编码进行消息传递。此协议得到广泛使用，并且目前具有最高的使用级别。许多商业软件包都使用 H.323。H.323 的部署非常广泛，以至于许多人认为新的 VoIP 应用程序必须支持该协议。但是，H.323 非常复杂，以至于不同实现之间的互操作性不佳。无论好坏，Microsoft 的 NetMeeting 产品似乎都是衡量互操作性的常见基准。由于 Microsoft 免费提供 NetMeeting，因此它很容易获得，如果产品可以与之互操作，您就可以确保拥有广泛的用户群。有几个优秀的开源项目正在努力为社区提供此协议——最著名的是 OpenH323 项目。这些人现在有一个工作协议栈，能够向 Win32 机器上的 NetMeeting 客户端发出呼叫。这是一个巨大的成功，我希望看到更多的改进，因为此代码在越来越多的项目中使用。OpenPhone 项目将使用 OpenH323 库和 Vovida Networks 从其派生的更精简的“Simple Endpoint Terminal”代码。有关更多信息以及可以获取该代码的位置，请参阅资源。

会话发起协议 (SIP) 在 RFC-2543 中描述。此 IETF 协议源于互联网社区；它的感觉与 HTTP 和类似协议没有太大区别。它是一种基于文本的协议，使用相当简单的命令来完成工作。它更侧重于电话服务，而 H.323 则提供有关完整多媒体视听服务的详细信息。SIP 的普及程度不断提高，因为它相对简单且易于实现。资源部分中提供了一些指向有关 SIP 的更多信息的链接。在撰写本文时，我不知道 SIP 的开源实现，尽管已经有很多关于启动这样一个项目的讨论。OpenPhone 项目非常希望看到这个项目，也许我们可以促进它的启动。如果有人感兴趣，我们当然会为其提供一个家。

媒体网关控制协议 (MGCP) 是一种协议和 API，用于从集中式服务器或“呼叫代理”控制语音网关。该协议是基于文本的，并且相对简单。完整的协议在 IETF 草案中描述（有关链接信息，请参阅资源）。

此协议正在被更广泛地接受，并且被许多人认为优于 H.323。但是，它与 H.323 是可互操作的，因为呼叫代理可以充当 H.323 网守。这可能是 VoIP 呼叫控制的未来发展方向，OpenPhone 项目计划在尽可能的情况下将此协议用作默认协议。Vovida Networks 提供 MGCP 的开源实现（请参阅资源），并且有几个商业版本可用。但是，由于规范尚未获得批准并且略有变化（但很频繁），因此目前无法保证两个不同的 MGCP 实现能够协同工作。这是开源可以为互联网电话做出巨大贡献的领域。Vovida 的 MGCP 实现是在 LGPL 许可下发布的，该许可允许商业用途，而无需发布应用程序的非开源部分的关联源代码。经过改进，这样一个开源 MGCP 可以在各种应用程序和系统中使用，通过使用协议的相同基本代码来确保互操作性。OpenPhone 项目将使用 Vovida 代码进行 MGCP 控制，希望扩展和增强协议以与批准的 MGCP 协议保持同步。

我们设想一个基本应用程序，该应用程序提供了一个框架，用于使用插件模块来实现要执行的各种任务的互联网电话。例如，一个插件模块将提供信令任务，另一个插件模块将提供音频任务（包括 RTP 和抖动缓冲区的使用）。我们设想一个 H.323 模块、一个 SIP 模块和一个 MGCP 模块——用户可以根据互操作性要求选择使用哪个模块。可以根据需要插入新模块，以评估不同的 RTP/抖动缓冲区技术。随着信令或音频传输模块的改进，用户只需放入新模块即可。

使这种方法可行所需的只是一个通用的 API，供应用程序使用以执行基本的高级功能。模块都将提供这些 API 功能；将使用适当的模块来提供实际功能。由于许多人将信令和音频代码称为“堆栈”，因此我们将其称为堆栈适配层 (SAL)。SAL 是一个通用定义的和采用的 API，它将允许应用程序开发人员专注于程序的功能，而堆栈开发人员专注于详细的低级实现。

为了将概念向下扩展一层并提供平台和硬件独立性，我们设想了一个硬件适配层 (HAL)，它提供了一组通用功能来控制和使用硬件。这允许信令/音频堆栈和 SAL 在 HAL 代码之上无缝工作，而与硬件级别使用的互联网电话卡无关。这种方法将使我们能够实现真正的跨平台多供应商互操作性的目标。

SAL 和 HAL 层的设计规范截至撰写本文时正在积极开发中，并且到发布时，我们的网站上应该会有几份白皮书和一些参考代码。我们鼓励积极参与，并启动了一个专门讨论该项目的邮件列表。您可以通过向 developers@openphone.org 发送“subscribe”消息来加入这个由 majordomo 托管的列表。

互联网电话有许多错综复杂的部件协同工作才能使其良好运行。现在有一些程序可以工作——但尚未达到真正有用的水平。这些实现中的大多数都达不到要求，因为它们不使用现代压缩编解码器，或者因为它们不使用 RTP 和良好的抖动缓冲区技术来控制音频流。大多数实现还缺乏一个标准化的信令协议，该协议提供与其他程序的互操作性。OpenPhone 项目旨在提供一个新的、高度灵活的框架，该框架使用插件模块来提供上面讨论的组件。它将基于廉价、易于获得的硬件，这些硬件可以在普通、常用的计算机中使用。OpenPhone 将使用现代技术在任何两台支持电话的计算机之间提供接近长途电话质量的通话，并有望促进互联网电话的发展和普及，直至所有计算机都具备电话功能。

资源