voip - 语音聊天应用程序(客户端/服务器)的结构？

Question

我需要专家意见，如果我的问题本身是一个令人困惑的问题，我很抱歉。

我正在阅读有关 VOIP 应用程序(客户端/服务器)的结构。大多数情况下，建议将 UDP 用于语音流。我还检查了一些语音聊天应用程序，如 paltalk 和 inspeak，他们的网站提到他们使用 udp 语音流，这似乎不正确，原因如下。

我检查了 paltalk 和 inspeak 使用的流量/端口。他们打开了 UDP 和 TCP 端口，使用数据包嗅探器我可以看到没有太多的 UDP 通信，但主要是 TCP 通信正在进行。

另外据我所知，在 UDP 协议(protocol)中，服务器无法将数据发送到 NAT(DSL 路由器)后面的客户端。并且“UDP Braodcast”不是基于“互联网”的语音聊天应用程序的选项。这就是为什么雅虎在他们的文档中提到，如果无法进行 udp 通信，雅虎信使会切换到 tcp。

所以我的问题是......

我在上述陈述中是否理解错误？

如果 UDP 不可行，那么那些聊天应用程序使用 TCP 流进行语音？

由于我经历过 TCP 语音流会产生延迟，没有语音中断但语音延迟，那么语音聊天服务器/客户端通信的最佳结构应该是什么？

到目前为止，我认为，如果客户端将数据作为 udp 数据包发送到服务器并且服务器通过 TCP 流将数据包分发给客户端，这是一个合适的解决方案吗？我的意思是这就是商业语音聊天应用程序的作用吗？

感谢您的回答将帮助我和许多其他程序员。

杰夫

Answer 1

UDP 的开销较小(就总数据包大小而言)，因此您可以将更多音频压缩到 channel 的带宽中。

UDP 也是不可靠的 - 发送的数据包可能永远不会被接收或可能被乱序接收 - 这对于语音应用程序来说实际上是可以的，因为您可以容忍信号质量的一些损失并继续前进。可以容忍少量丢失的数据包(与下载文件相反，其中每个字节都很重要)。

你可以使用 TCP 吗？当然，为什么不......它的开销略大，但这可能无关紧要。

SIP是支持 UDP 和 TCP 的语音/媒体标准。由于开销较低，大多数部署都使用 UDP。

Skype 协议(protocol)在可能的情况下首选 UDP，并回退到 TCP。

在 SIP 情况下，NAT 问题通过使用 nat keep-alive 数据包(任何请求/响应数据)来保持 channel 打开和打开，并利用大多数 NAT 将在同一源端口上接受连接的事实来解决是从...打开的，这不是万无一失的，并且通常需要代理服务器来调解 2 个 nat'd 对等点之间的连接，但它在许多部署中都有使用。

STUN、TURN 和 ICE 是有助于 NAT 场景的附加方法，尤其是在 p2p(无服务器)情况下。

有关 NAT 问题和媒体的信息:

http://www.voip-info.org/wiki/view/NAT+and+VOIP

http://en.wikipedia.org/wiki/UDP_hole_punching

http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html

如果您正在实现某种语音服务，像 FreeSwitch 这样的系统提供了将媒体传送到分布式客户端所需的大部分工具:

http://www.freeswitch.org/