减少VoIP时延的方法

　　最近几年，VoIP已经发展成为倍受人们瞩目的技术，但VoIP的不断普及并不意味着它是很容易实现的。事实正好相反，如果在大范围推广这项技术以前不做好充分的准备工作，VoIP的实现将会非常困难。VoIP对时延是非常敏感的，这就要求使用者要检查自己的网络基础结构，以确定VoIP在自己的网上是否能够正常地工作。


　　会话的时延要求


　　由于实时语音会话对时延非常敏感，所以在讲到VoIP时就不能不提到网络时延。当单向时延超过四分之一秒时，接收的人就很难分辨出讲话者是否已经结束谈话了，这就增大了通话双方同时说话的几率。ITU-T的 G.114建议规定了电话语音传输往返最大时延是300ms, 这就是说150ms单向时延是可以接受的。对于VoIP应用，150ms的单向时延可以看成是一条黄色警戒线，而250ms的单向时延则是一条红色的报警线。

　　VoIP的实现是基于IP网络的，IP网络可以是企业内部的局域网或者是互联网。一般来说，语音信息从发送端由专用分组交换机（PBX）发送，通过源端的网关、局域网、路由器，再进入基于IP的网络，流出IP网络后到达目的端的PBX，最后到达接收方的电话。在这个过程中，有几个地方会造成语音数据的时延。

　　首先，模拟语音信号由PBX发送至语音网关，网关在给语音信号编码时会加入一定的时延，具体的时延大小与网关采用的语音编码器有关。语音信号编码完后要封装成数据包经过LAN传送到路由器。路由器会根据数据包大小和网络接入线路速度的不同而产生不同程度的时延。数据包进入IP网络后，还要经过一个或多个路由器路由才能到达网络的出口,这些路由器也在不同程度上增加了时延。这个时延的大小是不确定的，它主要由数据包从进入网络到流出网络所路经的路由器的个数、各个路由器的处理速度以及各个路由器的载荷所决定。总的时延包括了语音传输数据包在通过局域网时产生的时延和通过广域的IP网络时的时延。

　　一般情况下，网络的总时延最低为80.5ms, 而最高能达到314ms。80.5ms的时延是可以接受的，而超过150ms的时延对语音信号的分辨十分不利，特别是单向时延达到314ms的最高上限时，VoIP的语音延时已经完全无法让人接受了。虽然从源端接入到IP网络与最后从IP网络输出到目的端的时延范围相同，但是在源端的工序时延和目的端的是不同的，语音数据压缩与解压的时延也是不相同的。下面将对各种时延进行分析，并找出降低时延的可行的调整方法。


　　语音编码


　　在VoIP环境下，多数网关采用混合编码技术对模拟语音信号进行数字化处理。混合编码器结合了波形编码和语音编码。采用混合编码技术时，语音的模拟信号经过抽样后，各种语音参数被提取出来，编码时并不直接对音调、音量和其他语音参数进行编码，而是将提取出来的语音参数信息合成语音抽样数据段。合成语音数据段的过程一般需要20ms。合成的信号再与原始抽样信号进行比较，如果两个信号之间的差别在预先设定的允许范围内，就不再对语音参数进行调整；否则，要对参数进行调整以得到一个合适的调整值。通过对提取的语音参数进行调整，可以提供最接近原始声音波形信号的合成信号。提取的语音参数确定下来以后，编码器将其与电报密码本内预先保存好的参数进行比较，如果匹配，就用编码本内的参数取代相应的语音参数。使用电报密码本内的参数目的是减少所要传输的数据量。

　　混合编码技术采用的是叫做受激线性预测编码器CELP的一系列语音编码器。同系列不同型号的CELP编码器的速率与它们的算法时延成反比，也就是说，越高的语音编码速率其编码时所产生的延时越小。G.728、G.729和G.723.1编码器是很多VoIP网关所采用的语音编码器。G.728是一种低时延的CELP，其时延大约为2.5ms，而它输出的数字语音数据速率是16kbps。G.729速率为8kbps，时延为10ms。G.723.1是一种多速编码器，它可以工作在5.3kbps和6.3kbps两种速率下，时延都接近30ms。由于每种编码器生成语音数据段都要20ms，所以相应的总时延分别为22.5ms、30ms和50ms。

　　一种有效减少单向时延的方法是更换语音编码器。例如，用G.728替换G.723.1可以减少大约27.5ms的单向时延。多数网关设备都支持6到10种类型的语音编码器，因此，适当地选择语音编码器可以显著地减少单向时延。


　　源端进程时延


　　源端的进程时延包括很多部分，其中有数字化语音及生成数据报产生的时延，把数据报传到LAN上的时延，路由器将其从LAN上提取出来的时延。

　　如果LAN的吞吐量较高，那么其信号冲突的程度就会较高。高冲突程度使通过网络的时延变高。这种情况下，应该考虑升级LAN或者将其分成几个网，也可以考虑绕过这个LAN。如果需要绕过繁忙的LAN，可以给路由器添加语音模块，将PBX的线直接连接到路由器，这样数据报就不用经过LAN了。虽然这些本地结构的改变只能降低很少的时延，但是在多个地方降低少量的时延就会有显著的效果，这对于VoIP能够正常工作是必要的。


　　网络接入


　　数据报进入和输出IP网络的时延与相应的网络接入线路的工作速率有关，也与所采用的语音编码方式有关系。举例来说，语音编码方式生成8kbps的数字信号，那么每20ms的就会抽样生成160bit的信号。这20字节即160bit的数据被封装在IP数据报内，实时传输协议（RTP）的报头添加到数字语音抽样信号的头部作为前缀。RTP报头中包括的时间信息可以使语音抽样信号在进入目的端的闪存后，还原成抽样信号并去除在数据流通过网络时产生的时间抖动。RTP报头有16个字节，再加上UDP的8个字节的头信息，最后，还要再添加上20个字节的IP报头信息，这样，20字节的数字化语音信号就组成了一个64字节的数据报。如果接入IP网络的接入线路是64kbps的速率，那么把这些以8kbps的速率编码产生的20ms的报文传送到网络上的时延是8ms。如果采用T1的接入速率（1.544Mbps），则接入线路的时延是0.334ms。这个例子表明，采用不同速率的接入线路对时延的影响会有大约7.67ms的不同。同样，数据从网络输出时也会有相同的情况。这样通过在收发端采用高速的接入线路就可以减少大约15ms的时延。


　　目的端进程时延


　　数据流经IP网络后抵达目的网。目的网的路由器都设有访问表，访问表中有一系列的指令，根据这些指令，对接收到的每个数据报的各个字段都要进行检查。访问表的基本作用是保障接入网络设备的安全，它还可以根据报文类型的不同来改变报文的传输速度。许多安全程序都通过在访问表的顶端加入反欺骗指令来完善扩展访问表。反欺骗指令根据RFC 1918列出的地址来检查每个数据报的源地址、回送地址和目标网络地址。抵达网络的数据报中应不包含RFC 1918中的地址，那些在源地址字段包含这些地址的数据报将被抛弃。虽然反欺骗指令在当今的网络操作环境下是必要的，但是它们也造成了时延，因为它要求为抵达的数据报建立缓冲区，再根据列表中的指令检查相应字段的值，看其是否与预定值匹配，最后报文将会被抛弃或者传送给路由器。由于每个数据报都要按指令逐条进行比较，所以，不管是发现匹配还是比较到列表的尾部都将会产生时延，特别当路由器比较旧时，所产生时延就更严重了。 

　　要得到最小时延，解决的方法就是用处理器更快的路由器来取代老的路由器。另一种更有吸引力的方法是，在访问表的顶端添加指令，允许将数字化语音数据报传送到网关。这样，即使出现最坏的情况也只是一个带有欺骗地址的数据报被当成一份数字语音信号传送给网关，使得谈话的人听到一些杂音而已。在访问表顶端加入相应指令能够减少部分目的端的时延，而不会对安全性产生影响。


　　闪存


　　闪存位于每个网关的接收器中，用来临时存储数据。它通过一种机制可以消除数据报之间的随机时延，这些随机时延是数据报通过网络时产生的。多数网关都提供了一个设置选项让管理员来设置闪存的大小，设置的范围从0ms到255ms。实际上，IP报头和UDP报头在数据报进入闪存之前都已经被剥掉了，而RTP的报头只有在实际数据被解包时才被去除。这是因为RTP报头包括了每个抽样信号的时间信息，可以让抽样信号在闪存内能够在适当的时间解包。闪存的典型设置值是10ms和20ms。虽然较高的设置值可以提高重建语音的质量，但是设得太高会使数据报的时延超过150ms。


　　网络传输时延


　　网络传输延时表示通过IP网络的单向时延。如果经过Internet，很多因素可以影响数据流而且不受控制，这些因素包括语音数据报传输过程中必经路由器的流量状况、每个路由器的处理能力、连接路由器线路的带宽、网络进入点和输出点之间路由器的数目等。ISP可能会提供端到端的服务等级协议（SLA）保证,但不管有没有SLA，在Internet上实现一个VoIP应用程序之前都要考虑先运行Ping和Traceroute程序。

　　向目的网络的路由器发出Ping命令可以得到往返的时延，此时间除以2就得出了单向时延的近似值。如果单向时延超过了允许的范围，就要使用Traceroute命令了。Traceroute可以显示到达目的网经过的每一跳的时延。仔细检查经过的路由就可以发现一个或者更多个潜在的超载路由器，这些路由器会造成较多的时延。最好的方法是ISP用新的路由器来替换老路由器或者增加网络带宽。

　　使用Ping和Traceroute命令时，应该注意要在一天的各个时段进行测试，并且测试若干天，才能保证能够获得准确的数据。另外需要注意，第一次运行程序可能会得到混乱的时延值，这是因为运行时要输入目的IP地址，如果输入的主机名不是预定的IP地址，程序要进行DNS解析，从而使第一个往返时延增加。

《中国计算机报》2000/08/17

转自：http://www.ctiforum.com/technology/Voip/08/voip0805.htm