我目前正在使用DirectSound开发应用程序,以便在Intranet上进行通信.我有使用UDP的工作解决方案,但后来我的老板告诉我他想出于某种原因使用TCP/IP.我尝试以与UDP几乎相同的方式实现它,但收效甚微.我得到的基本上只是噪音.其中20%是录制的声音,其余的只是奇怪的噪音.
我猜的原因是TCP需要多次读取所有接受的数据,直到它能够播放我能播放的最终声音.
现在有两个问题:
我在正确的轨道上吗？将TCP/IP用于此类应用(各种语音会议)是否是个好主意？
我在C#中这样做,但我不认为这是特定于语言的.
Thomas Bonin.. 14
不,使用TCP是一个糟糕的主意.在这种情况下UDP将执行得更好,丢弃/不同步数据包无关紧要!
如果您的老板无法理解技术细节,请告诉他或她几乎所有当前存在的VOIP系统都使用UDP并且必须有一个原因:Skype,ventrilo,teamspeak,魔兽世界等等
不,使用TCP是一个糟糕的主意.在这种情况下UDP将执行得更好,丢弃/不同步数据包无关紧要!
如果您的老板无法理解技术细节,请告诉他或她几乎所有当前存在的VOIP系统都使用UDP并且必须有一个原因:Skype,ventrilo,teamspeak,魔兽世界等等
为了正确回答这个问题,我觉得需要解释VoIP的一些关键概念.
首先,UDP是最流行和广泛使用的VoIP方法.请记住,IP网络是分组交换的,非理想的非实时数据通信,不适用于实时VoIP.
为了克服这个问题,使用了UDP.UDP是不可靠和无连接的协议.虽然UDP会丢失数据包,但仍然可以理解语音音频,大脑将有效地补偿错误.这就是为什么你仍然可以通过带有3条信号的手机与某人交谈.
数据包丢失和突发长度
数据包丢失通常是由于拥塞而发生的,因此数据包丢失的数量将取决于网络配置的程度.使用UDP的VoIP中的数据包丢失通常以突发长度发生.甲突发长度是一个在传输连续丢失分组的数目,所以3的突发长度是指在第3级的数据包丢失了.
丢包补偿
在发生分组丢失的情况下,简单的分组丢失补偿技术将会出现问题,并且服务质量将不会受到严重影响,即使在20-30%的分组丢失的情况下,仍然可以理解语音.方法包括:
重复上次成功接收的数据包.
填写 - 在差距中保持沉默.
拼接 - 实际上可以考虑通过将间隙的开始和结束推到一起来消除由突发长度引起的间隙.
插值 - 使用前后语音知识在间隙内插入丢失的数据包,例如在突发长度之前和之后成功接收的数据包之间的平均值.
减小突发长度大小的好方法称为交织,因此增加QoS是交织.块交织功能接收语音并将其分成一组数据包.这些数据包被加载到一个矩阵形状的缓冲区(例如4乘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"揭示了支持这种观点的第一个结果.
TCP是一种可靠的,连接方向的协议,这意味着在传输中丢失的数据包在某些时候将从另一个主机重新发送.这种重传对于实时服务是不切实际的,并且会增加抖动,延迟并且可能增加分组丢失(在某些情况下).
你的问题的答案
我得到的基本上只是噪音.其中20%是录制的声音,其余的只是奇怪的噪音.
TCP不应该引入噪声,它应该引入抖动和延迟.套接字往往具有自动定义的超时时间,您是否定义了超时时间？如果没有,为什么在播放前没有及时收到正确的数据包？
我在正确的轨道上吗？将TCP/IP用于此类应用(各种语音会议)是否是个好主意？
不,不使用TCP/IP这不是一个好主意.您的经理似乎错误地认为任何数据包丢失都是一件可怕的事情.
摘要
这里已经展示了一些通用的关键概念,以尽可能地为这个特定问题提供帮助,但这不应该被认为是详尽无遗的.确保VoIP系统还使用语音编码/信号处理技术的一些基本原理.
要记住的关键点是:
使用UDP进行VoIP.
实现丢包补偿
技术.
块交织器是一种
增加QoS 的简单而有效的方法.
我希望这有帮助.
京公网安备 11010802040832号 | 京ICP备19059560号-6 