我需要一个专家意见,如果我的问题本身是一个混乱的问题,对不起.
我正在阅读有关VOIP应用程序(客户端/服务器)的结构.并且大多数建议将UDP用于语音流.我还检查了一些语音聊天应用程序,如paltalk和inspeak,他们的网站提到他们使用udp语音流,由于以下原因似乎不正确.
我检查了paltalk和inspeak使用的流量/端口.他们打开UDP和TCP端口并使用数据包嗅探器,我可以看到没有太多的UDP通信,但主要是正在进行的TCP通信.
另据我所知,在UDP协议服务器无法向NAT后面的客户端(DSL路由器)发送数据.并且"UDP Braodcast"不是基于"互联网"的语音聊天应用程序的选项.这就是YAHOO在他们的文档中提到的,如果无法进行udp通信,yahoo messenger会切换到tcp.
所以我的问题是......
我在上述陈述中是否理解错误？
如果UDP不可用,那么这些聊天应用程序使用TCP Stream进行语音管理？
由于我经历过TCP语音流造成延迟,没有语音中断但语音延迟,那么语音聊天服务器/客户端通信的最佳结构应该是什么？
到目前为止,我认为,如果客户端将数据作为udp数据包发送到服务器和服务器通过TCP流将数据包分发给客户端,这是一个合适的解决方案吗？我的意思是这是商业语音聊天应用程序的作用吗？
谢谢你的回答将帮助我和很多其他程序员.
JF
UDP 的开销较小（就总数据包大小而言），因此您可以将更多音频压缩到通道带宽中。
UDP 也是不可靠的 - 发送的数据包可能永远不会被接收或可能乱序接收 - 这对于语音应用程序来说实际上是可以的，因为您可以容忍信号质量的一些损失并继续运行。少量丢失的数据包是可以容忍的（与下载文件相反，下载文件时每个字节都很重要）。
你可以使用TCP吗？当然，为什么不......它的开销稍微多一点，但这可能并不重要。
SIP是支持UDP 和TCP 的语音/媒体标准。大多数部署使用 UDP，因为开销较低。
Skype 协议尽可能首选 UDP，并回退到 TCP。
在 SIP 情况下，NAT 问题的解决方法是使用 nat keep-alive 数据包（任何请求/响应数据）来保持通道的正常运行和开放，并利用大多数 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 这样的系统可以提供向分布式客户端传送媒体所需的大部分工具：
| 归档时间： |
|
| 查看次数： |
4393 次 |
| 最近记录： |