9

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

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

现在有两个问题：

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

14 回答 14

14

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

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

于 2009-12-22T14:39:08.010 回答
8

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

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

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

数据包丢失和突发长度

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

丢包补偿

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

  1. 重复上次成功接收的数据包。

  2. 填补 - 在空白处播放沉默。

  3. 拼接 - 实际上，这可以考虑通过将间隙的开始和结束推到一起来消除由突发长度引起的间隙。

  4. 插值 - 使用之前和之后的语音知识在间隙内插值丢失的数据包，例如在突发长度之前和之后成功接收的数据包之间的平均值。

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

替代文字 http://img688.imageshack.us/img688/3962/capturevnk.png

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

替代文字 http://img338.imageshack.us/img338/6566/captureec.png

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

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

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

回答您的问题

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

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

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

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

概括

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

要记住的关键点是：

  • 为 VoIP 使用 UDP。

  • 实施丢包补偿
    技术。

  • 块交织器是一种简单而
    有效的提高 QoS 的方法。

我希望这有帮助。

于 2010-05-10T23:50:35.810 回答
3

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

于 2009-12-22T14:45:07.403 回答
1

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

于 2009-12-22T14:38:22.970 回答
1

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

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

于 2009-12-22T14:42:21.547 回答
1

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

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

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

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

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

于 2009-12-22T15:55:40.537 回答
1

我开发了一个语音操作 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 搜索指向文档的流输出的链接。

于 2010-07-02T21:57:52.507 回答
0

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

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

于 2009-12-22T14:45:04.593 回答
0

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

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

于 2009-12-22T14:49:00.437 回答
0

TCP 不应引入任何噪声。抖动和滞后，是的（特别是如果您的链接有损）；但完全没有噪音。您的编程有些可疑。

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

于 2009-12-22T15:06:42.777 回答
0

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

于 2009-12-22T15:23:22.417 回答
0

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

于 2009-12-22T15:37:28.170 回答
0

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

于 2010-05-11T20:41:40.333 回答
0

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

于 2010-12-06T20:58:38.093 回答