VOIP语音数据实际码率

VOIP语音引擎编解码器的选择或设计，往往都要考虑带宽占用情况的估计。语音都是分帧来处理，标准编解码器的帧长是一定的，帧长往往决定了语音编解码器的算法延时值。编解码器的算法是VOIP语音时延众多因素的一种。语音变成RTP包往往是时延中很关键的因素。如以语音编解码器的一帧为单位进行打包，那会导致二个问题：一是包太多，会导致服务器处理不了；二是 包头和相关的控制位消耗太多的带宽；一个好处：消除了打包可能造成的时延和丢包对语音音质的影响. 下面的例子就是来自(http://blog.chinaunix.net/space.php?uid=23023613&do=blog&id=2915547). 在这引用一下(基本正解)，主要是展示一下RTP包对带宽占的影响。 　不论在呼叫控制信令上采用何种，语音包的传输基本上都基于RTP（real-time transport protocol RFC 1889／RFC 3350）协议在网络上传输。这是一种为传输实时媒体流而由IETF制定的协议。 　几乎所有的VoIP相关产品，都利用RTP收发语音信息。语音包的结构如下所示，在IP层上封装后被送出到网络上，Payload部分的信息量多少取决于所采用的编码方式。 　一般说来，在VoIP的世界里采用G.729编码的较多，而在运营商提供的IP电话服务中则是G.711较多。G.711是在ISDN网中也被使用的 CODEC，音质较好，但与G.729相比信息量较多。而G.729则是一种压缩率高且音质也较好的CODEC。在传输一路语音信息时，G.711所需的带宽是64kbps，而G.729只需要8kbps。两者一般都以20msec间隔（这个间隔可变）发送数据包，因此我们可以推算出实际的包大小。 　语音信息是一种模拟信号，而将语音转换成数据包首先需要将模拟信号转换为数字信号（数-模转换）。相信大家对此都有所了解，将模拟式的语音信息用数字式传输的过程大致如下图所示。 　现有的电话交换网中采用的编码方式是G.711（PCM），在通话的两端必须采用同样的方式分别进行编码/解码操作才能实现语音通话，这里的编码/解码功能合称为CODEC(COder/DECoder)。　VoIP应用中常见的两种具有代性的CODEC如下： 　G.711（PCM方式：PCM＝脉码调制 ：Pulse Code Modulation） 采样率：8kHz 信息量：64kbps／channel 理论延迟：0.125msec 品质：MOS值4.10 　G.729（CS-ACELP方式：Conjugate Structure Algebraic Code Excited Linear Prediction） 采样率：8kHz 信息量：8kbps／channel 帧长：10msec 理论延迟：15msec 品质：MOS值3.9　接下来就以这两种CODEC为基础进行探讨。光使用CODEC将语音信息数字化还不算是将语音数据包封装完成。 　为了完成封包工作，VoIP终端内置了被称为DSP（Digital Signal Processor）的芯片。简单地说，就是对模拟信号编码后产生的大量数字信息进行实时处理的芯片。 　实际的封包过程，还需要使用RTP协议将语音数据包发送到网络上去。RTP包中，包括载荷类别（CODEC的类别）、序列号（语音包的顺序）、时间戳（语音包的发送间隔）等信息，接受方就以这些信息为基础将收到的数字信息还原为模拟的语音信号。 （4）计算语音数据包的大小和所需带宽　实际的语音信息在IP层上封装后的数据包格式如下。 IP Header(20Byte)+UDP Header(8Byte)+RTP Header(12Byte)+Payload(净载部分，可变长) 　将语音信息封装为IP包在3层以上就必然产生40Byte的额外开销，那么使用G.711/G.729 CODEC分别以20msec周期封装语音信息包的话，所生成的包长度如下。　G.711时 每秒送出的包为：1000／20msec ＝ 50pps 一路语音信息所需的带宽64kbps ＝ 50pps×Payload大小 Payload大小 ＝64000／50＝1280bit＝160byte 语音包的长度为200byte。　G.729时 每秒送出的包为：50pps 一路语音信息所需的带宽8kbps＝50pps×Payload大小 Payload大小＝ 8000／50 ＝160bit＝20byte 语音包的长度为60byte。　在实际应用中具体应该使用哪种CODEC呢？仅从语音通话业务的角度来看是用哪一种CODEC都没有问题的。 　但是，如果需要利用传真服务或是与VoIP运营商互联的话，就必须使用G.711。而拥有多处分支机构的企业，用于分支间互联的往往不会是与LAN等同的10/100Mbps的线路。多数分支甚至还在用128kbps的线路互联。 　此时如果选择G.711的话，光是语音信息就有可能把可用带宽消耗光。有些产品支持为不同的连接对象使用不同的CODEC。利用这一功能，就可以做到在窄带连接上使用G.729，而在宽带连接上使用G.711。如果采用这类产品，为了统一运用管理策略，可以考虑使用“分支间采用G.729；同一LAN内采用G.711”的设计。但如果有需要在分支间使用传真服务，则必须在分支间也使用G.711。 　此外，在进行带宽计算时，还必须考虑二层上的开销。具体到采用以太网传输时，必须加上以太帧的开销。 　以太网传输所需的额外开销包括 前同步(Preamble)：7byte（为了帧发送开始而取同步的信号） SFD：1byte（Start Frame Delimiter：数据帧开始部分） 对端MAC地址：6byte 源MAC地址：6byte 协议：2byte（VLAN时包含于802.1q） 802.1q：4byte（使用VLAN时） FCS：4byte　下面再举两个实例。 实例1：以太帧带VLAN Tag Preamble：7byte SFD：1byte 对端MAC地址：6byte 源MAC地址：6byte 802.1q：4byte（使用VLAN时） FCS：4byte 根据实例1的计算可知，在使用VLAN功能的以太网上，每个三层的数据包需要加上28byte的开销。　实例2：不带VLAN Tag的以太帧 Preamble：7byte SFD：1byte 对端MAC地址：6byte 源MAC地址：6byte 协议类别：2byte FCS：4byte 　 根据实例2的计算可知，无VLAN环境下，每个3层包在以太网上需要的额外开销是26byte。最后来简单计算一下不同CODEC下所需的实际带宽。 计算的前提是RTP包送出间隔为20msec且2层上不使用VLAN，此时每个包需要附加还必须加上40Byte（3层以上的开销）+26Byte（2层的开销）=66Byte的额外开销。而每一秒钟共产生50个包（50pps），因此除了净载的语音信息（64kbps）外开销部分所占用的带宽是 66Byte×8×50=26.4kbps。 由此得出G.711在实际传输中需要占用90.4kbps的带宽，而在实际的网络设计中一般都是按照每路通话100kbps来进行估算的。G.729所占的带宽是34.4kbps，虽然加上额外开销后它所需的带宽仍远低于G.711，但考虑到消耗带宽中包头的开销和净载分别占用的比例，不免令人觉得有些遗憾。 这样，就需要采用包头压缩等技术来进一步提高带宽的利用效率了。 补充一下（http://coolwolf911.iteye.com/blog/416289）： ITU-T（国际电信联盟）的G.729编码方式为例，这是一种8kbit/s的编码算法，该种编码抗随机比特错误的能力与抗随机突发消失帧的能力相同。在噪声较大的环境下，它能有更好的语音质量。 G．729帧长为 10个八位组（octet），有声段帧格式为： 每帧为10ms。 每帧长10个八位组。 每个 RTP包可以放零个、一个或多个 G.729帧。 抽样率8000Hz。 缺省打包时间段20ms。 Internet话音分组传输技术 在IP网中传输层有两个并列的协议：TCP和UDP。 TCP是面向连接的，它提供高可靠性服务；UCP是无连接的，它提供高效率的服务。 高可靠性的TCP用于一次传输要交换大量报文的情况，高效率的UDP用于一次交换少量的报文或实时性要求较高的信息。 实时传输协议RTP提供具有实时特征的、端到端的数据传输业务，可以用来传送声音和活动图像数据，在这项数据传输业务中包含了装载数据的标识符、序列号、时戳以及传送监视。通常RTP的协议数据单元是用UDP分组来承载的。而且为了尽量减少时延，话音净荷通常都很短。图3表示一个IP话音分组的结构，图中 IP，UDP和RTP的控制头都按最小长度计算。 这种IP话音分组的开销很大，约为66％～80％。于是有人提出了组合RTP分组的概念 采用这种组合复用方法的确可以大大提高传输效率，但是目前尚无标准。 如果支持RTP的网络能提供组播功能，则它也可用组播方式将数据送给多个目的用户。 RTP 本身没有提供任何确保及时传送的机制，也没有提供任何传输质量保证的机制，因而业务质量完全由下层网络的质量来决定。同时，RTP不保证数据包按序号传送，即使下层网络提供可靠性传送，也不能保证数据包的顺序到达。包含在RTP中的序列号就是供接收方重新对数据包排序之用。 与RTP相配套的另一个协议是RTCP协议。RTCP是RTP的控制协议，它用于监视业务质量并与正在进行的会话者传送信息。 因此，我们可以根据这个图３计算出每路G.729编码的带宽占用量： 带宽占用＝传输的总字节数 / 传输的总时间 带宽＝(20byte（IP头）+8byte（UDP头）+12byte（RTP头）+20byte(数据))/２０ms =60byte/20ms 以上计算公式含义为：每20ms，需要传输的字节数包括20个字节的IP包头，8个字节的UDP包头，12各字节的RTP包头，20字节的语音数据共60字节，结果为：3 byte/ms=3000 byte/s=24000bit/s＝24kbit/s。 因此，理论上G.729中每个数据包包含两帧语音的编码方式，占用带宽24kbit/s，而又有封装效率的估算公式为： 　　 封装效率=[（压缩后的语音包× n × 帧长/ 8）] / [（压缩后的语音包× n× 帧长/ 8 ）＋40] 。 n表示打进n个语音包。 以G.729信源编码为例，如一个RTP包打进一个语音包，则实际传送码流为40kbit/s，时延约为 10 ms； 如打两个语音包，则实际传送码流为24kbit/s，时延约为 20 ms； 如打四个语音包，实际传送码流为16kbit/s，时延为40ms。 为保证编码打包的时延，若将缺省语音包的数量定为两个，实际传送码流即为24kbit/s，而不是8kbit/s。 因此对于语音业务这类实时性要求非常高的业务，要保证语音的质量，根据ITU-T标准语音的全程往返时延应当控制在450ms为宜，编码打包后形成的单位码流通常是在20kbit/s。 由以上论述我们知道，每路G.729编码的IP语音占用约20Kbit/s的带宽，实际占用的总带宽数＝语音总路数*20Kbit/s。 语音编解码方式及其所占用的带宽的关系 语音编码的带宽和实际所占用的带宽是不同的，语音编码的带宽是实际语音包的带宽，而语音包在IP网络上传输时，还需要增加各种包头，如RTP包头、UDP包头、IP包头。由于语音包本身很小，所以相对而言这些额外的带宽是很可观的。在下表中列出了各种编码方式下的打包时长以及所对应的实际带宽。 实际带宽与语音编码和打包时长的关系： 语音编解码 打包时长 语音数据带宽 实际所占带宽 G.723.1(5.3K) 30ms 5.3K 5.3*(20+40)/20 = 16.2K G.723.1(5.3K) 60ms 5.3K 5.3*(40+40)/40 = 10.6K G.723.1(6.3K) 30ms 6.3K 6.3*(24+40)/24 = 16.8K G.723.1(6.3K) 60ms 6.3K 6.3*(48+40)/48 = 11.6K G.729 20ms 8K 8*(20+40)/20 = 24K G.729 60ms 8K 8*(60+40)/60 = 13.3K 由上表可以很明显的看出，打包时间越长，所占用的实际带宽越小，但时延越大。 说明 1、RTP包头：12bytes UDP包头：8bytes IP包头：20bytes。 2、表中的带宽计算中没有包含物理帧头，需根据具体网络而定。 3、表中的带宽计算中，没有考虑静音检测。静音检测的效率按60％计算。 音频： 名称 采样率 采样精度 占用带宽(kbps) G.723.1 8k 16bit 5.3 ~ 6.3kbps ILBC 8k 16bit 13.33 ~ 15.2kbps CCITT A-LAW 8k 16bit 64 ~ 128kbps 视频： 图像分辨率 —— 帧数 占用带宽(kbps) 160 × 120 —— 5 ~ 30fps 　　20 ~ 100kbps 176 × 144 —— 5 ~ 25fps 20 ~ 110kbps 320 × 240 —— 5 ~ 30fps 40 ~ 200kbps 352 × 288 —— 5 ~ 25fps 40 ~ 220kbps 640 × 480 —— 5 ~ 30fps 120 ~ 1000kbps 720 × 576 —— 5 ~ 25fps 120 ~ 1500kbps 国际电信联盟 G 系列典型语音压缩标准的参数比较 算法 类型 码率 (kbit/s) 算法延时 (ms) G.711 A-Law / μ -Law 64 0 G.722 SB-ADPCM 64/56/48 0 G.723.1 MP-MLQ/ACELP 6.3/5.3 37.5 G.726 ADPCM 16/24/32/40 0 G.727 Embedded ADPCM 16/24/32/40 0 G.728 LD-CELP 16 < 2 G.729 CS-ACELP 8 15 分类: 音频算法研究与应用