VoIP技术(4)--VoIP语音质量保证

5．VoIP语音质量保证策略

影响通信的语音质量的因素很多。在VoIP系统中，虽然与电路交换系统在大多数情况下都是类似的，但也有其不少特殊的因素，如编解码类型、较长的时延、时延抖动、分组的丢失等。

      考虑到传统的电信业务使用线路交换技术，而VOIP使用包交换技术，因此这也是VOIP技术与线路交换技术相比之下需要解决的问题。

5.1 延迟和抖动

VOIP在传输语音、视频等实时性要求很高的数据时会遇到延时与抖动的问题，以下就语音的情况加以描述。

在链路交换的方式下，语音的传输延时取决于信号在线路上的传输速率，我们可以将铜线上信号的传输速率近似地看为光速。而且信号是均匀传输的，因此不存在抖动的问题。

       对于VOIP所采用的包交换方式来说，语音被封装在IP报文中通过数据网络，有多种因素造成延时。

在实际应用中，由于经常出现的网络拥塞现象，延时还会进一步增大。其中绿色部分表示是可改进的地方，下面会有描述。

在发送方来说，某种编码方式的语音帧是以基本恒定的速率产生的。RTP包通过UDP方式在IP网络来传输，而IP网本身就是变化万千的，因而每个RTP包在网上传输的时间各不相同，有时甚至会由于网络阻塞而造成很大的时延或丢包。由于UDP是采用无连接方式，各个分组从发送方到接收方所历经的网络途径也可能不同，从而各个分组的传输时延也各不相同，甚至容易发生分组的到达次序发生变化。

即传输过程中由于每个报文受到的延时是不均匀的，造成接收方并不是以与发送相同的恒定速率与顺序收到报文的现象，就是抖动（Jitter）。如果我们按照接收的速率顺序回放每个报文，就可能听到一团杂音。

5.2 延时和抖动的解决办法

经过测试，我们发现，当延时在150ms以下时，通话双方几乎不能感觉到延时的存在，而当延时在400ms以下时，也是用户能够接受的，当延时进一步增大后，达到800ms以上，正常的通话就无法进行。

对于前面列出的7种延时的因素，我们发现队列延时很小，几乎可以忽略；而编解码的延时是由算法决定的不可减小；在骨干网络中的传输延时也是不可改善的。我们只可能对链路层延时或Jitter Buffer延时进行改善。

如果我们在使用低速串行链路进行传输，那么可以采用IP/UDP/RTP头部压缩策略来减小链路层报文大小，从而降低链路层延时。关于IP/UDP/RTP头部压缩在5.6节会提到。

            接收方收到的语音帧报文由于拥塞及多个路由设备转发后往往会产生不均匀的延时。为了弥补由于网络时延抖动和丢包对语音造成的影响，在接收方使用抖动缓冲器(Jitter Buffer)来进行处理。将收到的报文在Jitter Buffer中排序，并不立即进行解码，当Jitter Buffer中的连续报文达到一定长度时才开始回放报文中包含的语音帧。但是考虑到Jitter Buffer造成的延时，我们需要根据统计到的语音传输情况动态地调整Jitter Buffer的深度，已经有大量的论文介绍了多种Jitter Buffer的算法。当网络时延较大时，应采用较大的缓冲器，这样才能实现对时延抖动的补偿；而当网络时延较小时，应采用较小的缓冲器，否则会增加复用时延。采用一个良好的Jitter Buffer算法可以在尽可能小的延时下，向用户提供尽可能平滑的语音流。

5.3 丢包

丢包现象主要是报文的延时引起的。在设置了一定的Jitter Buffer深度后，当报文由于拥塞等问题被延时后，到达的时间晚于当前的Jitter Buffer深度，我们就必须将该报文丢弃。大多数的丢包都是由这个问题引起的。

由于语音编码方式的采样率往往是非常高的，通常为8000Hz，因此对连续的数个语音帧来说，它们之间的差异是非常小的。所以我们无法从Jitter Buffer中继续取得语音帧时，可以将刚处理过的语音帧重用一次，当然如果无限制地重用一定会造成语音失真(这就是PLC策略)。对于G.729或G.723.1来说，我们设定的重用次数是2次。 丢包还可以通过后面要介绍的QoS、资源预留RVSP等策略来改善。

在前面已经说过，如果丢包现象已经发生，可采取一定策略进行修补，如PLC策略：PLC即Packet Loss Concealment，它是用来弥补语音传输过程中数据包的丢弃所带来的影响。该种技术只是在小丢包率的情况下可以起到很好的补偿效果。在通话过程中，平均丢包率的要求可能会低，但是瞬间的高丢包率可明显影响通话质量。

PLC算法可以在丢包的地方插入静音(最差，影响语音质量)，重放上一语音帧(较好)，以及使用更复杂的算法产生模拟语音包(最好，但消耗DSP资源，影响DSP支持的Channels数量)。

如果在通话过程中存在丢包现象并且未使用PLC策略，我们会觉得通话断断续续的，如果使用一个有效的PLC算法，可以一定程度上弥补丢包所带来的影响。

5.4 回声

回声是在用户交谈时在电话接收器中听到自己的声音。只要定时合适，回声就会消除；如果回声超出25毫秒，它就会使语音恶化，中止交谈。在传统电信网络上，回声通常是由于从四线网络切换到两线本地环时阻抗不匹配产生的，它是由回声消除器控制的。在语音包网络中，回声消除器嵌入到低位速率编解码器上，在每个DSP上运行。回声消除器必须受到等待接收回声的时间总量的限制，这个时间量一般称为回声轨迹。回声轨迹通常为32毫秒。

通常所指的回声有两种，发话回声和受话回声。最主要的是发话回声，讲话者听到自己的被延迟的话音。这种回声是受话方的电气回声或声学回声引起的。另一种就是受话回声，受话方听到发话者两次声音：先是一个大信号，然后是一个被长时间延迟的弱信号。这种回声是在发话回声的基础上，在发话方再次回声造成的。

产生回声的原因主要有两个：声学回声和混合回声。声学回声是指受话方扬声器的部分声音会馈到本机的麦克风。而混合回声相对比较复杂一些。为了使用更少的电线，在传统的电话系统中用两条线来供电并传送双向信号。由于双线连接转换为四线系统的混合线路的不完整性，因阻抗失配而导致的信号反射，称为混合回声，如图11所示，其中菱形的是2/4线转换的混合器

图11 混合回声产生示意图

在VoIP系统，如果所用的设备都是IP话机，那就是只有声学回声，而没有混合回声。而实际上网关会有直接接普通电话机和PBX的媒体网关、接模拟与数字中继的中继网关等设备，这样就会产生混合回声。

回声的限制可以通过引入回声消除器来实现，其基本原理如图12所示。

由图12可知，包含的就是回声消除器。回声可以模型化为信号的叠加，也就是说，Sin中含的回声实际上就Rout的卷积。为了实现回声消除，只要建立一个卷积模型，生成回声的估计值，在Sin中减去回声的估计，当回声的估计值和实际值一致时，就可以完全消除回声；实际上，回声的估计存在一定的偏差，这时就可以自适应修改模型参数，使估计值收敛于实际值。接着，就采用了非线性处理器（NLP）以消除残存的回声。

回声消除器需要卷积运算，因此需要存储被延时的信号，其范围是从0到最大可能的延时，能处理大延时的回声消除器比处理小延时的要贵，可能也体现在Echo Canceller Length这个参数上(不是很确定,后面也设计到这个参数)，因此，应将回声消除器放在离声源越近越好。

图12 回声消除器基本原理

ITU规定了对回声消除器的性能要求，早先的回声消除器标准是ITU的G.165建议，而G.168则提出了一组更严格的要求，但它还不是最严格的。这些标准提供了一系列客观性能测试，但不涉及其实现方法，也不涉及主观性能。

一个好的回声消除器必须很好地去掉回声，包括在通话开始的时候，在通话过程中则要防止任何形式的回声。另外，它还要处理“双讲(double talk)”现象(通话双方同时讲话)，在“双讲”起始和结束的时候都不能影响任何一边的语音信号。回声消除器还要有很好的背景噪声处理能力，包括高背景噪声以及变化的背景噪声，该指标需要优于G.165/G.168标准以支持将来更为严格的ITU回声消除器标准，例如G.168-2002，目前该系列最新标准都到了G.168-2004。实际应用证明，仅仅符合G.165/G.168标准并不保证回声消除器能够满足性能要求。

回声消除器必须具有快速的收敛、低残留回声(收敛深度)、可靠的“双讲”检测能力(既没有偏差，也不损害有效语音)，以及对背景噪声和窄带信号的良好处理，同时还应该支持长达128ms的拖尾(运营商级方案经常规定的指标)，包括支持在整个128ms时间内的多次反射，主要体现在Echo Canceller Length这个参数，；回声消除器还应该支持冗余，并可动态跟踪由会议电话、通话转移以及永久连接脱离所造成的回声路径变化；最后，在四线连接和低混合衰减时还应能正确工作，并具有内置的配置和可测试能力。

 

5.5 静音抑制

为了充分地利用网络带宽，许多算法可以采用无声压缩方案。利用VAD来检测是否存在语音，当检测到没有语音，编码器就不按照通常情况产生正常的语音压缩编码，而是产生较短的静音编码，并由RTP协议告知接受方静音开始；接收方收到后，就开始放CNG，直到恢复正常的语音重新开始。可见，采用静音抑制后，可以在很大程度上降低RTP包发送的数量。G.729算法和G.723.1算法均支持静音抑制。

G.729的静音插入指示语(SID: Silence Insertion Descriptor)帧的帧长同正常帧一样为10ms，而帧的大小为2字节，正常帧的大小为10字节。G.723.1算法的SID帧的帧长为30ms，帧的大小为4字节。这里需要注意的是，在语音突发段的第一个RTP分组的头部的标志位(M)置1。

5.6 语音带宽的保证

            参考4.5节和4.6节关于语音带宽的分析，我们可作另一个假设。假设链路层使用PPP协议，则头部为6字节；IP头部最小为20字节；UDP头部为8字节；RTP头部最小为12字节；Payload部分假设使用G.729编码方式，每个RTP报文包含2个帧，为20字节。我们发现实际数据部分为20字节，但是头部却占了46字节，实际的有效带宽占用为约30%。 如果我们RTP的Payload使用PCM编码方式，这部分将占用64k带宽。

           

对于上面的问题，目前主要有3个解决方案：

<1> 对于刚才所举的例子如果我们采用低速链路上的CRTP协议，可以大大提高带宽利用率。上面例子中的RTP报文在采用CRTP后，可以将报文头部压缩至PPP头部6字节，CRTP头部2字节，这样带宽利用率提高到约71%。目前CRTP使用于2M以下的串行链路，主要在FR、HDLC、PPP协议上使用。据统计，假设采用G.723.1 5.3k编码方式，在不使用CRTP的情况下，带宽占用在18k左右，而使用CRTP后可以降低到低于9k。

<2> 采用更低比特率的压缩编码方法，但该方法可能带来语音质量不好的缺点。

<3> 采用VAD和CNG技术。

            但是，即使我们降低了带宽，仍然有可能遇到语音断续的情况，如：

<1> 队列中有大量其它数据需要传输，导致无法以正常的频率转发语音报文。

<2> 在低速链路上同时存在超长的IP报文需要发送，如一个19200bps的串行链路发送一个1920字节的FTP报文需要约0.8秒时间。假设在该链路上存在一条FTP数据流，每10秒发送一个如上所述的报文，则FTP占用约1.6k带宽；同时进行一次采用CRTP及G.723.1 5.3k编码方式的语音会话，总带宽占用率在不到11k。似乎应该能听到良好的通话效果。可是考虑每次发送FTP报文时，需要延时0.8秒，这时队列中的RTP报文就也被延时了0.8秒。用户会每隔10秒就会有0.8秒听不到语音，这种通话效果是用户无法忍受的。

      

鉴于上面提到的两个缺点，目前有两种策略：

<1> 对于上面提到的第一个问题，可以考虑使用资源预留策略来解决。RFC2205定义了RSVP协议，这个协议为主机上的上层应用提供了一种机制来为指定的应用数据流向IP网络申请指定的服务质量，而实际的流控制策略是由下层的队列QoS策略来实现的。RSVP是一个端到端的协议，但是，在流经过的路径上的所有路由器均需要支持RSVP协议。

注1：资源预留协议（RSVP：Resource Reservation Protocol），它利用RSVP消息，可以在数据传输的全程保留必要的网络资源，同时也确保沿途各路由器的传输调度策略，从而可以对每个数据流的QoS逐个进行控制。

注2：区分服务（DiffServ）将网上传输的所有流划分为多个服务类别，对每个类别提供不同的服务，体系结构上比RSVP简单，实现起来相对容易一些。

目前，由于公共的网络上的路由器的网络设备并不是都支持这些协议，所以在实际中尚存在较大的障碍。

<2> QoS策略：我们可以通过以下的描述对排队策略进行优化，保证VOIP业务的正常进行。可以根据以下的区分策略在链路层设置多个队列，以不同的队列算法调度之。如：根据服务区分策略，根据优先级区分策略，流量均衡策略，拥塞预防策略，根据IP Precedene排列报文发送顺序优先发送报文策略，降低MTU值策略。