【笔记】各类型应用的QoS需求和推荐方案--1.语音应用
来源:互联网 发布:高维数据稀疏表示 编辑:程序博客网 时间:2024/06/16 22:33
语音应用最大的QoS需求是延迟,如果延迟过大,双方的对话就会很困难,就像我们在电视新闻中经常看到的那样,直播中的不熟练的记者,经常会抢话。
所以设计支持VoIP业务的网络时,一般都遵循ITU 标准G.114,即端到端的延迟应控制在150ms以内,可确保voice的质量能够让用户满意。
相比延迟,网络抖动对voice质量的影响不是那么大,因为在各个网络节点都可以运用缓冲技术来改善网络抖动,从而使前面一段抖动造成的影响不至于蔓延到下一段。
缓冲技术将整个数据流调整为一个拥有一贯延迟值的队列,从而达到不影响播放的目的。
数据丢包在传统印象中,会让语音听上去断断续续,但是实际中因为有了数据包丢包隐藏(PLC)技术,数据包丢失或被丢弃所造成的影响可以被较好改善。最简单的方法是重放最后接收到的样本,并在重放时增加衰减,该技术可以有效解决20ms以下的样本丢失。
语音包所需的带宽是整个网络中最容易被准确估算的,因为语音数据在一个call的过程中是连续的,所以所需的带宽也是基本连续的,相比那些带宽杀手,语音类业务的带宽只是九牛一毛,而且仍然是运营商赚钱的主要手段,所以运营商通常都会用EF标记语音业务,是一种严格优先级队列服务。
总结:
语音应用的QoS需求:
- 单项延迟不超过150ms(也有设备厂商建议值为180ms)
- 单项网路抖动峰值不超过30ms
- 每跳的峰值不超过10ms
- 丢包率不超过1%
- 每个call的保证带宽20-320kbit/s (通常每call 保证20k已经足够)
语音应用的QoS推荐方案(RFC4594 和RFC3246)
- 应为语音流量打上EF(加速转发)/DSCP 46的标记
- 应以EF作为PHB动作来处理语音流量
- 应对语音流量实施准入控制
0 0
- 【笔记】各类型应用的QoS需求和推荐方案--1.语音应用
- 【笔记】各类型应用的QoS需求和推荐方案--2.视频应用
- 有关PBX应用和交互语音应答系统的方案
- IP语音的服务质量(QoS)、带宽需求和安全机制
- 系统和应用需求
- 需求分析方法和需求管理工具的应用
- 各类session监听器的应用
- Redis各类型应用场景
- Redis各类型应用场景
- android应用百度语音识别、语音合成和语音唤醒
- Struts应用的需求分析与设计(摘要二) 收集和分析应用需求
- 各类排序算法比较和应用场景
- 语音技术,应用的变迁
- 基于语音类 应用的识别和 跟踪系统
- android 暂停和继续第三方应用的语音播放
- 超级三星Galaxy S2和语音通话的应用
- android 暂停和继续第三方应用的语音播放
- datasource的应用方案
- macOS Sierra(10.12)系统偏好设置->安全性和隐私->通用中的“任何来源” 选项开与关
- hdu5895 Mathematician QSC(矩阵快速幂+逆元+降幂)
- 大数据学习笔记-------------------(4)
- canvas速查简表
- 3.42
- 【笔记】各类型应用的QoS需求和推荐方案--1.语音应用
- PAT(A) - 1064. Complete Binary Search Tree (30)
- unity直连android真机在Profiler性能分析测试
- IIS7.5 也有Warm Up功能,让ASP.NET 第一次Request不变慢
- 大数据全栈式开发语言 – Python
- 高级测试/测试开发技能
- HTTP状态码详解
- [深度学习论文笔记][Weight Initialization] All you need is a good init
- keystore与pfx互转