VoIP与常见编码的带宽计算

简介: VoIP与常见编码的带宽计算

持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第28天,点击查看活动详情


VoIP(Voice over IP,基于IP的语音通信)通信需要一定的网络传输质量保证,但目前的Internet不能满足这一要求,导致当前的VoIP业务在稳定性和服务质量上不如人意。因此需要针对实时语音通信的特点设计合适的协议和通信机制,以最大限度地提高业务质量。具体来说,与实时语音通信有关的QoS包括带宽、延时和丢失率三方面。


1、带宽


为了保证语音质量不致太差,需要保证在任何情况下语音传输也能获得一定带宽。然而当前Interent并不提供这样的保证,而且由于传统路由器不提供拥塞控制功能,因此过大的语音流量将导致路由器的拥塞雪崩,使传输效果迅速恶化。


voip带宽计算方法与所选用的编码方法有关,而与哪个厂家的没有什么关系。语音编码的带宽和实际所占用的带宽是不同的,语音编码的带宽是实际语音包的带宽,而语音包在IP网络上传输时,还需要增加各种包头,如RTP包头、UDP包头、IP包头。由于语音包本身很小,所以相对而言这些额外的带宽是很可观的。公式如下:


带宽 = 包长度×每秒包数(1000/打包间隔ms)

= 包长度×(每秒包数)

= (Ethernet头 + IP头 + UDP头 + RTP头 + 有效载荷) ×(每秒包数)

= (208bit + 160bit + 64bit + 96bit + 有效载荷) × (每秒包数)

= (528bit + 采样数据个数×采样数据长度 ) × (每秒包数)

= (528bit + (采样频率/每秒包数)×采样数据长度 )× (每秒包数)

= (528×1000/打包间隔ms)bit + 采样频率×采样数据长度

= (528/打包间隔ms + 采样速率)Kbit/s

根据各种编码方式,得出:

G711:20ms打包,带宽为 ( 528/20 + 64) Kbit/s=90.4 Kbit/s

G729:20ms打包,带宽为 ( 528/20 + 8 ) Kbit/s= 34.4 Kbit/s

G723:5.3k,30ms打包,带宽为 ( 528/30 + 5.3 ) Kbit/s=22.9 Kbit/s


打包时间越长,所占用的实际带宽越小,但时延越大。业界一般按照下表提供的IP网带宽系数(IP包大小)和以太网带宽系数(Ethernet帧大小)来设计网络带宽:

编解码技术 速率(Kbps) 打包周期(ms) IP网带宽系数 以太网带宽系数
G.711 a/u  64 20 1.25  1.41
G.729 a/b 8 20  0.38 0.54
G.723.1(5.3kbit/s)  5.3 30 0.27 0.37
G.723.1(6.3Kbit/s) 6.3 30 0.25 0.36
H.263(384Kbit/s)  ≈384 10  6 6.2

备注:采用某种编码方式时,用64K乘以相应的带宽系数就可以得出其实际占用的带宽。当然如果是中继接口,还需要考虑信令占据一定的带宽,一般按照2.5%来计算。

 

2、延时

传输一般数据时没有延时的限制,但实时语音传输要求端对端时延不能太大。对于语音业务这类实时性要求非常高的业务,要保证语音的质量,语音的全程往返时延应当控制在450ms内为宜(根据ITU-T标准)。这有两个原因:

  • 一个原因是因为语音必须在接收端连续地放出来,如果语音包不及时到达,播放便会停下来,人耳便会感觉到语音的间断,这是不能接受的。
  • 另一个原因是因为在实时通信中,延误太久才到达的语音包对收听者来说已失去意义了,和丢失没有两样,这也是不能接受的。

\

3、丢失率

VoIP利用RTP实时传输协议传送数据。RTP是一个基于无连接UDP的应用协议,UDP是无连接的,它不会对数据包的传送提供应答和跟踪,这样RTP也不会重新传送网络的丢包,这就要求网络传输中应尽可能减少数据包的丢失。

\

4、RTP


TCP是面向连接的,它提供高可靠性服务;UCP是无连接的,它提供高效率的服务。高可靠性的TCP用于一次传输要交换大量报文的情况,高效率的UDP用于一次交换少量的报文或实时性要求较高的信息。 实时传输协议RTP提供具有实时特征的、端到端的数据传输业务,可以用来传送声音和活动图像数据。通常RTP的协议数据单元是用UDP分组来承载的。而且为了尽量减少时延,话音净荷通常都很短。这种IP话音分组的开销很大,约为66%~80%。


RTP本身没有提供任何确保及时传送的机制,也没有提供任何传输质量保证的机制,因而业务质量完全由下层网络的质量来决定。同时,RTP不保证数据包按序号传送,即使下层网络提供可靠性传送,也不能保证数据包的顺序到达。包含在RTP中的序列号就是供接收方重新对数据包排序之用。与RTP相配套的另一个协议是RTCP协议,RTCP是RTP的控制协议,它用于监视业务质量并与正在进行的会话者传送信息


相关文章
|
8月前
|
编解码 监控 前端开发
GB/T28181-2016传输要求和Android平台设备接入技术实现
GB/T28181-2016公共安全视频监控联网系统 信息传输、交换、控制技术要求相关的传输要求如下:
146 1
|
8月前
|
编解码 监控 网络协议
Android平台GB28181设备接入侧(编码前|编码后|RTSP|RTMP)支持功能浅析
在之前,我有写过Android平台GB28181设备接入模块的好多blog,包括参数设置、功能支持与扩展等,以数据接入为例,支持的数据类型涉及编码前、编码后或直接流数据(RTSP或RTMP流)。可用于如智能监控、智慧零售、智慧教育、远程办公、生产运输、智慧交通、车载或执法记录仪等场景。
124 0
|
8月前
|
编解码 Android开发 开发者
Android平台GB28181设备接入模块如何实现实时视频和本地录像双码流编码
我们在做Android平台GB28181设备接入模块的时候,遇到这样的场景,比如执法记录仪或智慧工地等场景下,由于GB28181设备接入模块,注册到国标平台后,平时只是心跳保持,或还有实时位置订阅,查看视频的时候,是按需看,而且有时候,网络环境并不是太好,所以,催生了这样一个诉求:部分开发者希望能本地录像的时候,录制高分辨率(比如1920*1080),国标平台侧发起实时视频查看请求的时候,上传低分辨率(如1280*720)数据,有点类似于IPC的主码流和子码流。
|
9月前
|
编解码 前端开发 Android开发
Android平台GB28181设备接入模块之按需编码和双码流编码
Android平台GB28181设备接入模块之按需编码和双码流编码
|
9月前
|
编解码 缓存 监控
GB28181设备接入侧如何支持H.265?
GB28181设备接入侧如何支持H.265?
141 0
|
10月前
|
编解码 C++
国标GB28181协议客户端开发(四)实时视频数据传输
国标GB28181协议客户端开发(四)实时视频数据传输
322 0
|
10月前
|
编解码 监控 数据安全/隐私保护
国标GB28181协议客户端开发(三)查询和实时视频画面
国标GB28181协议客户端开发(三)查询和实时视频画面
357 0
|
10月前
|
算法 物联网
m基于matlab的无线自组网性能仿真,包括端到端时延,吞吐量,初入网时间,迟入网时间,网络建立时间
m基于matlab的无线自组网性能仿真,包括端到端时延,吞吐量,初入网时间,迟入网时间,网络建立时间
208 0
|
存储 编解码 网络架构
传输时延和传播时延(补充:频段,信道带宽,数据速率的区别,以及帧大小和帧长)
传输时延和传播时延(补充:频段,信道带宽,数据速率的区别,以及帧大小和帧长)
584 0
HIMA B5233-2 采样率带宽通常是指基带带宽
HIMA B5233-2 采样率带宽通常是指基带带宽
HIMA B5233-2 采样率带宽通常是指基带带宽