基于 TCP/IP 的语音通信答案

【问题标题】：Voice Communication over TCP/IP基于 TCP/IP 的语音通信
【发布时间】：2009-12-22 14:35:06
【问题描述】：

我目前正在开发使用 DirectSound 在 Intranet 上进行通信的应用程序。我有使用 UDP 的有效解决方案，但后来我的老板告诉我他出于某种原因想使用 TCP/IP。我尝试以与 UDP 几乎相同的方式实现它，但收效甚微。我得到的基本上只是噪音。其中 20% 是录制的声音，其余的只是奇怪的噪音。

我猜测原因是 TCP 需要多次读取所有接受的数据，直到它得到我可以播放的最终声音。

现在有两个问题：

我在正确的轨道上吗？将 TCP/IP 用于此类应用程序（各种语音会议）是否是个好主意？
我是在 C# 中做的，但我认为这不是特定于语言的。

【问题讨论】：

绝对不是特定语言..我确定..
原来不是问题 :) 帖子是版主这样编辑的。
除非你的老板是前网络专家/高级程序员，否则只要告诉他继续做他应该擅长的事情：制作幻灯片并将编程留给他的程序员。
您是否使用编解码器来压缩您的音频？一些编解码器生成固定或可变长度的数据帧。当通过UDP传输时，帧开始和数据包开始必须重合。 TCP，作为一种流协议，可能会以不同的方式处理这个问题。您的接收器（解码器）需要确保它与您的数据流帧对齐。

标签： language-agnostic networking tcp udp voip

【解决方案1】：

不，使用 TCP 是一个可怕的想法。在这种情况下，UDP 的性能会更好，并且丢弃/不同步的数据包无关紧要！

如果您的老板无法理解技术细节，请告诉他/她目前几乎所有的 VOIP 系统都使用 UDP，这一定是有原因的：Skype、ventrilo、teampeak、魔兽世界等

【讨论】：

TCP/IP 不是 VoIP 的最佳选择，但它不会受到伤害。只是效率不高。
效率不高 = 质量会更差 = 确实很痛，imo
您始终可以将 TCP 配置为比 NIH over UDP 做得更好。当然，除非有人坚持丢包。
由于重传和只有在所有数据包都在的情况下才会传递数据包，所以 VoIP over tcp/ip 将导致延迟，除非您添加大量缓冲区。但这对于想要低延迟的 VOIP 来说确实是不受欢迎的
TCP 竭尽全力为您提供所有数据，即使这意味着您获得的数据比其他方式晚。但在 VOIP 中，迟到的数据根本就没有用处。

【解决方案2】：

为了正确回答这个问题，我觉得需要解释一下 VoIP 的一些关键概念。

首先，UDP 是 VoIP 的最流行和广泛使用的方法。请记住，IP 网络是分组交换的，非常适合非实时数据通信，而不是为实时 VoIP 设计的。

为了解决这个问题，使用了 UDP。 UDP 是不可靠且无连接的协议。虽然 UDP 会丢包，但语音音频仍然可以理解，大脑会有效地弥补错误。这就是为什么您仍然可以通过 3 格信号的电话与某人通话。

数据包丢失和突发长度

丢包通常是由于拥塞而发生的，因此丢包的数量将取决于网络设备的好坏。使用 UDP 的 VoIP 中的数据包丢失最常发生在突发长度。突发长度是传输中连续丢失的数据包数，因此突发长度为 3 意味着连续丢失 3 个数据包。

丢包补偿

在发生丢包的情况下，简单的丢包补偿技术将会出现，并且服务质量不会受到严重影响，即使在 20-30% 的数据包丢失的情况下，语音仍然可以被理解。方法包括：

成功重复上一次收到数据包。
填补 - 在空白处保持沉默。
拼接 - 实际上这可以是考虑采取删除突发长度引起的间隙通过推动开始和结束间隙在一起。
插值 - 使用知识演讲之前和之后内插丢失的数据包间隙，例如成功接收的数据包之间的平均值在突发长度之前和之后。

一种减小突发长度大小的好方法称为交织，因此提高 QoS 的方法是交织。块交织功能获取语音并将其拆分为一组数据包。这些数据包被加载到矩阵形状的缓冲区中（例如 4 x 4），使用一个函数旋转或转置缓冲区，使数据包不按顺序排列。在接收方，此函数的逆函数用于重新排序数据包。此方法简单有效，见下图：

alt text http://img688.imageshack.us/img688/3962/capturevnk.png

我最近创建了一个小型 VoIP 应用。通过使用 UDP 的无线 LAN。我不太确定您的应用程序的确切要求，但通常 VoIP 应用程序（两台主机之间）可以按如下方式实现：

alt text http://img338.imageshack.us/img338/6566/captureec.png

在图中，应用程序定义了它自己的数据包设计。标头可能只是数据包编号（使用 1 个字节），而有效负载是音频数据（n 个字节，有效负载的大小）。定义它允许更好的数据包补偿技术，并允许编程的逻辑流程。

TCP 对于 VoIP 来说是一个糟糕的选择，原因有很多。 “TCP VoIP”的快速谷歌揭示了为什么第一个结果支持这个view。

TCP 是一个可靠的、面向连接的协议，这意味着在传输中丢失的数据包将在某个时候从另一台主机重新发送。这种重新传输对于实时服务来说是不切实际的，并且会增加抖动、延迟并可能增加丢包率（在某些情况下）。

回答您的问题

我得到的基本上只是噪音。其中 20% 是录制的声音，其余的只是奇怪的噪音。

TCP 不应该引入噪声，它应该引入抖动和延迟。套接字往往有一个自动定义的超时时间，你定义了超时时间吗？如果不是，为什么在播放前没有及时收到正确的数据包？

我在正确的轨道上吗？将 TCP/IP 用于此类应用程序（各种语音会议）是否是个好主意？

不要不使用 TCP/IP，这不是一个好主意。您的经理似乎错误地认为任何数据包丢失都是一件可怕的事情。

总结

这里展示了一些通用的关键概念，以尽可能多地尝试和帮助解决这个特定问题，但是这不应被认为是详尽无遗的。确保 VoIP 系统也使用语音编码/信号处理技术的一些基本原理。

要记住的关键点是：

为 VoIP 使用 UDP。
实现丢包补偿
技术。
块交织器是一个简单的和
提高服务质量的有效方法。

我希望这会有所帮助。

【讨论】：

构建一个简单的语音聊天应用，如你所描述的，不需要SIP，RTP等协议吗？也可以请对Packetisation有所了解。谢谢。
这个答案已经很久了，我会尽力回答你的问题。对于一个非常简单的 Voip 客户端，使用您自己的格式发送原始 UDP 数据包就足够了。打包涉及将您的信息打包成数据包以减少数据包丢失等...通过使用块交织器或您选择的任何方法。

【解决方案3】：

当人们谈论 TCP/IP 堆栈时，他们通常指的是“整个 Internet 协议堆栈”，其中包括 UDP。也许这会让你的经理高兴 ;-)

【讨论】：

我的想法也是如此。如果你的老板没有给出必须是 TCP 的任何理由，我认为他认为 UDP 是“某种非标准的黑客”，特别是如果他说的是 TCP/IP 而不是 UDP。
他告诉我“我已经和世界级的网络专家谈过了。他说使用 UDP 会丢失三分之一的数据包。”我不知道那个“专家”可能是谁，但好吧，无论如何
用语音最好是放一些包而不是有很多延迟
如果老板告诉“网络专家”你正在开发一个 VoIP 软件，“网络专家”会告诉你 UDP 更好，RTP 是要走的路……有什么那个“网络专家”很可疑！

【解决方案4】：

TCP/IP 可以工作；它将提供数据。如果您不担心丢包，它可能不如 UDP 高效，但您应该能够很好地传输数据。

【讨论】：

【解决方案5】：

现代路由器和网络上的 TCP/IP 速度非常快。它不仅能够处理 IP 语音通信。（我自己做过）

我的猜测是您的实现中存在一些与缓冲区大小相关的错误。

【讨论】：

是的，我很确定是我的实现导致了这种情况。我只是想知道我是否应该再花一天时间修复它。

【解决方案6】：

您没有理由通过 TCP 获得噪音，因此它看起来像是您的代码中的错误。事实上，我们收到的大多数流媒体（想想 YouTube）都是通过 TCP 完成的。

TCP 的问题是抖动。您的数据流的交付将被延迟，直到所有数据包都被接收并重新排序。现在，由于多媒体的延迟交付与根本没有交付一样好。这通常比简单地插入丢失的帧是一个更糟糕的选择。如上所述，如果丢包率最低且您的网络速度很快，那应该没有什么区别。

基于 UDP 的 RTP/RTCP 通常用于媒体流的传送。 RTP 在数据包标头中包含诸如序列号之类的内容，允许在可能的情况下将延迟的数据包插入到正确的位置。 RTCP 具有报告功能，允许编解码器适应丢包开始变高的情况。因此，RTP/RTCP 提供了一些但不是全部的 TCP 功能。

对于 TCP 上的流媒体，这可以通过一个大的抖动缓冲区轻松解决。这增加了延迟，但对于单向流，这不是问题。然而，延迟是双向对话流中的一个主要问题。

不过，TCP 的一个主要优点是它比 UDP 更容易穿越防火墙。一个 TCP 会话已建立，防火墙对发送和接收数据都是开放的。这对于 UDP 来说更为复杂，尤其是当人们期待传入的数据流时。有很多方法可以解决这个问题，但它们可能很复杂，并且可能涉及了解会话控制协议（如 SIP 或 RTSP）。

【讨论】：

【解决方案7】：

我开发了一种语音操作 ip 解决方案，用于使用 wave-api 进行双工通信，用于远程控制业余无线电收发器。它适用于 UDP 和 TCI/IP！我每 64 毫秒使用 512 字节缓冲区，8kHz 单波数据。上个月我在美国和欧罗巴之间通过 TCP/IP 很好地工作！现在我的问题是：wave-api 不适用于 Win7，因此我认为 DirectSound 是更好的方法。就在我对 Managed DirectX9 下的实现感到困惑时，我的应用程序是 VB.Net 2008。我使用 DirectSound - ManagedDirectX9 for VB.Net 搜索指向文档的流输出的链接。

【讨论】：

【解决方案8】：

直播数据使用 UDP 有几个主要原因。其中最大的问题是接收迟到的数据与根本不接收一样好，延迟流进行重传肯定不是一个好主意。对于 VoIP，您的延迟容限约为 150 毫秒。任何延迟超过此时间的语音数据包都会引起用户注意。

至于为什么你会收到噪音，你是如何处理由于重传而延迟到达的数据包的？

【讨论】：

【解决方案9】：

取决于底层网络的类型，如果你有 99.9% 可靠性的以太网，我猜 TCP 就可以了。但是，如果您通过 802.11 来执行此操作，那么 TCP 将不是一个好主意。

您可以询问您的老板使用 TCP 的特定原因，然后实施该特定服务，例如基本可靠性或通过 UDP 的纠错服务。您可能还想研究 RTP。(http://en.wikipedia.org/wiki/Real-time_Transport_Protocol)

【讨论】：

【解决方案10】：

TCP 应该不引入任何噪音。抖动和滞后，是的（尤其是如果您的链接有损）；但完全没有噪音。你的程序有问题。

顺便说一句，我同意在这种情况下 UDP 比 TCP 更合适。

【讨论】：

【解决方案11】：

大多数语音应用程序都是使用通过 UDP 端口传输的 RTP 协议构建的。好吧，它们中的大多数都支持编解码器，以确保媒体在从一端流到另一端之前被压缩。与您的老板讨论带宽要求。

【讨论】：

【解决方案12】：

我很确定大多数流式音频/视频都使用 UDP...您可能会丢失一些数据包，但您永远不会注意到。

【讨论】：

【解决方案13】：

如果您收到噪音，您可能超出缓冲区中已成功填充数据包的部分，并播放空/未初始化的缓冲区。

【讨论】：

【解决方案14】：

TCP 比 UDP 慢多少？使用 TCP，如果任何数据包乱序或损坏，您将获得重新传输延迟。我会说有一些方法可以优化 TCP，从而减少延迟。在 Linux 和 Winsock 中都有一个 TCP_NODELAY 选项可供使用。此外，紧凑型编解码器将有助于像 G.729 一样减小有效载荷大小。由于传输是基于接收到的数据包（按顺序 - TCP），因此应该专注于优化数据包大小，使其足够小以减少重传延迟，但又足够大以保持质量流。一个好的 TCP voip 程序将能够动态改变编码质量和数据包大小，发送方必须向接收方发出更改的信号。但实际上，实时使用 TCP 的唯一优点是它不太可能被防火墙阻止。

【讨论】：