VOIP Bandwidth consumption naturally depends on the codec used.
VOIP消耗的带宽一般取决于所使用的语音编码.
When calculating bandwidth, one can't assume that every channel is used all the time. Normal conversation includes a lot of silence, which often means no packets are sent at all.So even if one voice call sets up two 64 Kbit RTP streams over UDP over IP over Ethernet (which adds overhead), the full bandwidth is not used at all times.
计算带宽时,不能假设每一个通道都处于使用状态.正常的通话过程包括一系列的静音,也就意味着并不是一直都有包在传送.所以一个语音呼叫建立两个经过UDP,IP和以太网的64Kbit的RTP流(总开销),全部带宽并末一直被使用.
A codec that sends a 64kb stream results in a much larger IP network stream. The main cause of the extra bandwidth usage is IP and UDP headers. VoIP sends small packets and so, many times, the headers are actually much larger than the data part of the packet.
一个传送64kb流的语音编码很大程度上都是IP网络流的结果.额外的带宽使用主要是IP或UDP头的增加.VOIP只传送少量的包,很多时候,实际上是包头远远大于包数据.
Codec BR NEB
G.711 64 Kbps 87.2 Kbps
G.729 8 Kbps 31.2 Kbps
G.723.1 6.4 Kbps 21.9 Kbps
G.723.1 5.3 Kbps 20.8 Kbps
G.726 32 Kbps 55.2 Kbps
G.726 24 Kbps 47.2 Kbps
G.728 16 Kbps 31.5 Kbps
iLBC 15 Kbps 27.7 Kbps
BR = Bit rate
NEB = Nominal Ethernet Bandwidth (one direction)
根据我的使用经验，8K的G.729加上IP封装后达到32K,为了防封杀，还有的用户使用IP Sec设备将语音做成VPN，这样G.729加上IP封装，再加上VPN会达到60多K。
注:头三段中文是我自己译过来的,所以读起来并不怎么准确,而且会感觉别扭,呵呵.多多包涵了.有兴趣的朋友可以再译一次.以供借鉴.
集群通软交换电话-所需带宽说明
VoIP所需要的带宽，通常取决于它所使用的codec编码方法。在计算带宽时，不能假定每个通道总是在使用之中。通常的会话过程中包括大量的静默时段，就是不发送任何数据包。
一个会话建立了两个64kbps的RTP流，在UDP/IP/Ethernet上,并非在所有的时间都使用全部的带宽。
一种编码方法发送64kbps的数据流，会导致大得多的IP网的数据流，引起额外带宽的主要原因是IP和UDP的报文头.当VoIP发送小的数据包时，在大多数时候，报文头实际上要比包中的数据大得多。
下面的表列出了各种编码方法，所需要的带宽：
|
编码方法 |
编码所需带宽 |
实际所需要的网络带宽 |
|
G.711 |
64 Kbps |
87.2 Kbps |
|
G.729 |
8 Kbps |
31.2 Kbps |
|
G.723.1 |
6.4 Kbps |
21.9 Kbps |
|
G.723.1 |
5.3 Kbps |
20.8 Kbps |
|
G.726 |
32 Kbps |
55.2 Kbps |
|
G.726 |
24 Kbps |
47.2 Kbps |
|
G.728 |
16 Kbps |
31.5 Kbps |
编码所需带宽，是指理论上所需要的带宽。但在实际的传输过程中，还要付出其他的消耗，如报文头。真正需要的带宽是实际所需要的网络带宽，这是大致的数值，而不是严格的精确值。实际所需要的网络带宽通常是以太网所需要的带宽，或者是ppp连接所要的带宽。
QQ使用的编码技术GIPS，实际使用起来感觉声音比较清晰，相对于SIP的编码就显得声音有些不好，请问，GIPS理论占用的带宽有多大？能不能在SIP加入GIPS编码方式？
GIPS公司用的语音编码技术是 iLBC编码。
iLBC 若采30ms一帧，则理论带宽需要13.33 kbps。若20ms 一帧，则理论带宽需要15.2 kbps 。
iLBC的语音质量要比 G.729A好些，但是能够容忍丢失更多的包；也就是在丢包后，iLBC恢复能力更强。
iLBC计算复杂度与G.729A差不多。都是计算度比较复杂的算法。
SIP终端中，也有使用 iLBC编码的。 skype 、QQ在语音编码上并没有什么优势。由于它们是私有协议，目前在穿透私网（NAT）和防火墙上，更好做些，所以媒体流的路径，可能比SIP标准（目前）好做些而已。穿透易，路径选得近些，音质就显得好些。
G711 在大约有 100Kbps 带宽时，有很好的语音质量。
G.726 在大约有 50Kbps 带宽时，有好的语音质量。
G.729 在大约有 30Kbps 带宽时，有好的语音质量。
GIPS公司用的语音编码技术是带宽可变的码率，也就是根据网络实际的带宽状态，调整语音编码的压缩比率。也就是带宽越少，语音压缩得越厉害，失真损失越多；带宽越好，就压缩不厉害，失真损失少。
注意语音编码用的压缩，都是有损压缩，也就压缩后语音会些失真。
iLBC与迅时通信
iLBC背景和优势
iLBC技术与Skype
什么是iLBC？
iLBC是一种专为包交换网络通信设计的编解码，优于目前流行的G.729、G.723.1，对丢包进行了特有处理，既使在丢包率相当高的网络环境下，仍可获得非常清晰的语音效果。
iLBC所占用带宽？
30ms ptime的iLBC所占用的总通信带宽比通常采用的ptime 20ms的G.729的带宽还要小，以下是iLBC与传统编解码占用带宽列表：
iLBC——语音质量的飞跃
语音质量一直是VoIP应用的主要难点，如何保证和提高IP网络传输语音的通话效果，是VoIP应用迫切需要解决的问题。“iLBC”编解码的出现，解决了在包交换的IP网络中，传输语音所遇到的网络丢包严重影响通话质量等实际问题，实现了“语音质量的飞跃”。
下图为在不同的网络丢包环境下，使用iLBC与G.729A、G.723.1编解码的语音质量比较。
图1. iLBC与 G.729A、 G.723.1的比较(Dynastat, Inc)
无论在高丢包率条件下还是在没有丢包的条件下，iLBC的语音质量都优于目前流行的G.723.1, G.729A等标准编解码；而且丢包率越大，使用iLBC的语音质量优势越明显。通常情况下，为了衡量IP网络语音质量，将≥5％丢包率的网络情况定义为VoIP的极限网络条件。经过语音质量测试，即使在5％丢包率的情况下，iLBC仍然能够提供相当于GSM手机的语音质量。
RTP冗余技术简介
众所周知，VoIP是一种利用RTP实时传输协议在包易丢失的Internet网上传输语音数据的技术。RTP基于无连接UDP的应用协议，它不提供语音数据包的重传机制，这就要求VoIP技术在网络传输中应尽可能减少语音数据包的丢失，满足语音传输的实时性要求，减少网络丢包对语音质量的影响。
图1. 常用编码在不同网络丢包条件下的语音质量对比
由上图可见，随着网络丢包率的增加，各种编解码的PESQ[1](Perceptual Evaluation of Speech Quality)分值都有很大程度的下降。为此，迅时通信提出RTP冗余机制，以改善由语音包传送丢失而引起的语音质量。
RTP冗余技术
早在1997年，IETF就已经制定了RFC2198 (RTP Payload for Redundant Audio Data)协议，标准化多媒体应用的RTP冗余技术，以改善在IP网上进行多媒体应用中的质量问题。
[1] 参见国际电联(ITU)的语音质量评估标准P.862，该标准评定的PESQ MOS分值越大，语音质量越好。PESQ MOS分值有效范围为[-0.5,4.5]。
RTP冗余机制是指在RTP语音包里携带当前帧和前几个帧的语音数据，以便在丢包的网络环境下，接收方可以从后续包中获取相关数据，实现对已丢失语音包的重组和恢复，解决由于网络丢包所导致的语音质量问题。
在VoIP应用的RTP冗余机制中，当网关或IAD使用某种规定的编解码（如G729A或iLBC）进行语音数据流的打包时，系统将进行插入冗余语音数据包的处理，对当前帧和前几个帧的净荷语音数据进行RTP封装；在进行语音数据流的解包时，系统将进行去除冗余语音数据的处理，对RTP包进行重组。因此，在网络随机丢包的情况下，如果某一个RTP语音包丢失了，则接收方还可通过后续RTP语音包中的冗余数据对失去的数据进行重组和恢复，解决由于网络丢包所导致的语音质量问题。
迅时通信的RTP冗余机制可有效改善音质，其理论抗随机丢包能力高达75％；其RTP语音包中的冗余帧个数可由用户设置，其设置范围为1－3。然而大量冗余数据也可能会造成网络拥塞增加，加剧网络丢包的问题，这可能会使采用冗余数据试图解决的包丢失问题变得更糟。因此，用户在配置RTP冗余数据多少的时候，需要根据自己的实际网络带宽来进行调整。