QoS 语音波动问题故障排除

下载选项

PDF (394.9 KB)
在各种设备上使用 Adobe Reader 查看
ePub (98.6 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
Mobi (Kindle) (124.4 KB)
在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看

已更新: 2006 年 2 月 2 日

文档 ID:20371

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

简介

要使分组语音成为标准公共交换电话网络(PSTN)电话服务的现实替代品，所接收的分组语音质量必须与基本电话服务的质量相当。这意味着始终如一的高质量语音传输。与其他实时应用一样，数据包语音具有宽带宽和延迟敏感性。对于要能够理解（不不稳定）到接收方的语音传输，语音数据包不能被丢弃、过度延迟或承受变化的延迟（也称为抖动）。本文档介绍有助于排除不稳定语音问题的各种服务质量(QoS)注意事项。语音问题不稳定的主要原因是语音数据包丢失和延迟。

先决条件

要求

本文档的读者应了解以下内容：

数据包语音(VoIP、帧中继语音(VoFR)或ATM语音(VoATM)的基本配置（根据其要求）。
基本了解语音优先级、分段、不同编解码器及其带宽要求。

使用的组件

本文档中的信息适用于所有思科语音网关软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备创建的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您是在真实网络上操作，请确保您在使用任何命令前已经了解其潜在影响。

规则

有关文件规则的更多信息请参见“ Cisco技术提示规则”。

导致常变语音的原因

语音质量不稳定是由语音数据包在网络中被可变延迟或丢失引起的。当语音数据包延迟到达目的地时，目的网关会丢失实时信息。在这种情况下，目的网关必须预测丢失数据包的内容。该预测导致所接收的语音不具有与所发送的语音相同的特征。这会产生一种听起来像机器人的声音。如果语音分组被延迟超出接收网关的预测能力，则网关将实时间隙留空。由于接收端没有可以填补的空白，所以部分传输的语音会丢失。这会导致语音不稳定。许多不稳定的语音问题都通过确保语音数据包不会非常延迟（而且更多，不会变化延迟）来解决。有时，语音活动检测(VAD)会为语音会话添加前端剪辑。这是语音不稳定（或被剪接）的另一个原因。

本文档中的各个部分说明如何最小化不稳定的语音实例。这些措施大多要求确保在语音网络中引入最小抖动。

带宽要求

在您考虑应用任何措施来尽量减少抖动之前，请调配足够的网络带宽以支持实时语音流量。例如，在64 kbps链路上，80 kbps G.711 VoIP呼叫（64 kbps负载+ 16 kbps报头）听起来不太好，因为至少16 kbps的数据包(20%)被丢弃。带宽要求因用于压缩的编解码器而异。不同的编解码器有不同的负载和报头要求。VAD的使用也会影响带宽需求。如果使用实时协议(RTP)报头压缩(cRTP)，则可进一步降低带宽要求。

例如，使用带cRTP的G.729编解码器（默认20字节负载）的语音呼叫所需的带宽如下：

语音负载+压缩(RTP报头+用户数据报协议(UDP)报头+ IP报头)+第2层报头

这相当于：

20字节+压缩（12字节+ 8字节+ 20字节）+ 4字节

这等于：

28字节，因为报头压缩将IP RTP报头减少到最多4字节。这样，以8 kbps的编解码器速率（每秒50个数据包）生成11.2 kbps。

有关详细信息，请参阅 IP 语音 - 每个呼叫的带宽占用量.

语音数据流优先级

对语音进行优先处理有两个重要组件。第一种是对相关语音流量进行分类和标记。第二个是优先处理标记的有趣语音流量。这两个小节将讨论对语音进行分类、标记和排定优先级的各种方法。

分类和标记

为了保证VoIP数据包的带宽，网络设备必须能够识别流经其的所有IP流量中的数据包。网络设备使用IP报头中的源IP地址和目的IP地址，或UDP报头中的源UDP端口号和目的UDP端口号来标识VoIP数据包。这种识别和分组过程称为分类。它是提供任何QoS的基础。

数据包分类可能会占用大量处理器资源。因此，分类需要尽可能远地向网络边缘进行。由于每一跳仍然需要确定数据包应接收的处理方式，因此您需要在网络核心中采用更简单、更高效的分类方法。这种更简单的分类是通过在IP报头中标记或设置服务类型(ToS)字节来实现的。ToS字节的三个最高有效位称为IP优先位。大多数应用和供应商目前支持设置和识别这三位。标记正在演变，因此可以使用ToS字节的六个最高有效位，称为差分服务代码点(DSCP)。请参阅请求注解(RFC)。

差分服务(DiffServ)是一种新模型，其中流量由具有相对优先级的中间系统根据ToS字段进行处理。DiffServ 标准在 RFC 2474 和 RFC 791 中有所定义，它取代了 RFC 791 中介绍的用于定义数据包优先级的原规范。 DiffServ 通过重新分配优先级标记 IP 数据包的位，增加了可定义的优先级别数量。DiffServ体系结构定义DiffServ字段。它取代IP V4中的ToS字节，对数据包分类和流量调节功能（如计量、标记、整形和管制）做出每跳行为(PHB)决策。除了前面提到的RFC，RFC 2597 还定义了保证转发(AF)类。这是DSCP字段的细分。有关 DSCP 的详细信息，请参阅通过 DSCP 实施服务质量策略。

ToS字节 — P2 P1 P0 T3 T2 T1 T0 CU

IP 优先级:三位(P2-P0),ToS:4位(T3-T0),CU:1位

DiffServ字段 — DS5 DS4 DS3 DS2 DS1 DS0 ECN ECN

DSCP:6位(DS5-DS0),ECN:两位

XXX00000位0、1、2(DS5、DS4、DS3)是优先位，其中：

111 =网络控制=优先级7
110 =网际控制=优先级6
101 =批评/ECP =优先级5
100 =闪存覆盖=优先级4
011 =闪存=优先级3
010 =立即=优先级2
001 =优先级=优先级1
000 =例程=优先级0

000XXX00位3，4，5 (DS2、DS-1，DS-0) 是延迟、吞吐量和可靠性位。

位3 =延迟[D](0 =正常；1 =低)
位4 =吞吐量[T](0 =正常；1 =高)
位5 =可靠性[R](0 =正常；1 =高)

000000XX位6、7:ECN

这两个部分讨论了分类和标记的两种方法。

语音拨号对等体对数据包进行分类和标记

使用Cisco VoIP网关时，您通常使用语音拨号对等体对VoIP数据包进行分类并标记IP优先级位。此配置显示如何标记IP优先级位：

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip precedence 5

在上例中，任何与dial-peer voice 100 voip命令匹配的VoIP呼叫都使用IP Precedence 5设置其所有语音负载数据包。这意味着IP ToS字节的三个最高位设置为101。

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip qos dscp ef media
ip qos dscp af31 signaling

在上例中，任何与dial-peer voice 100 voip命令匹配的VoIP呼叫都将其所有媒体负载数据包（语音数据包）设置为加速转发(EF)位模式101110。所有信令数据包都设置为AF位模式011010。

注意：自Cisco IOS®软件版本12.2(2)T起，就支持ip qos dscp命令。IP优先级在Cisco IOS软件版本12.2T中不再可用。但是，ip qos dscp命令也实现了这一点。IP优先级5(101)映射到IP DSCP 101000。有关详细信息，请参阅使用DSCP对VoIP信令和媒体进行分类以实现QoS。

模块化QoS CLI对数据包进行分类和标记

推荐使用的分类和标记方法是模块化QoS CLI。这是基于模板的配置方法，将分类与策略分离。这允许为多个类同时配置多个QoS功能。使用class-map命令根据各种匹配条件对流量进行分类，并使用policy-map命令确定每个类需要执行什么操作。通过发出service-policy命令将策略应用于接口上的传入或传出流量。此配置示例显示如何使用模块化QoS CLI对数据包进行分类和标记：

access-list 100 permit udp any any range 16384 32767
access-list 101 permit tcp any any eq 1720
!
class-map match-all voip
match access-group 100
class-map match-all control
match access-group 101
!
policy-map mqc
class voip
set ip precedence 5
class control
set ip precedence 5
class class-default
set ip precedence 0
!
interface Ethernet0/0
service-policy input mqc

在此配置示例中，任何与访问控制列表(ACL)100匹配的流量均分类为“class voip”，并使用IP Precedence 5进行设置。这意味着IP ToS字节的三个最高位设置为101。ACL 100与VoIP使用的常见UDP端口匹配。同样，ACL 101匹配H.323信令流量(传输控制协议(TCP)端口1720)。所有其他流量都使用IP优先级0设置。策略称为“mqc”。它应用于Ethernet 0/0上的传入流量。

优先处理

在网络中的每一跳都能够对VoIP数据包进行分类和识别（通过端口/地址信息或通过ToS字节）后，这些跳将为每个VoIP数据包提供所需的QoS。此时，请配置特殊技术来提供优先级队列，以确保大数据包不会干扰语音数据传输。在拥塞可能性较高的较慢WAN链路上，通常需要执行此操作。一旦所有相关流量根据其QoS要求被放入QoS类别，就通过智能输出排队机制提供带宽保证和优先级服务。VoIP需要优先级队列。

注意： 使用任何有效地为VoIP提供高优先级的排队机制。但是，建议使用低延迟队列(LLQ)，因为它灵活且易于配置。

LLQ使用模块化QoS CLI配置方法为特定类提供优先级，并为其他类提供保证的最小带宽。在拥塞期间，优先级队列会按配置的速率进行管制，以便优先级流量不会耗尽所有可用带宽。（如果优先级流量独占带宽，则会阻止满足其他类的带宽保证。）如果正确调配LLQ，进入优先级队列的流量不应超过配置的速率。

LLQ还允许指定队列深度，以确定在任何特定类队列中等待的数据包过多时路由器何时需要丢弃数据包。还有一个class-default命令，用于确定未按配置的类分类的所有流量的处理。class-default配置有fair-queue命令。这意味着每个未分类流量的剩余带宽份额大致相等。

此示例显示如何配置LLQ。有关详细信息，请参阅低延迟队列:

access-list 100 permit udp any any range 16384 32000
access-list 101 permit tcp any any eq 1720
access-list 102 permit tcp any any eq 80
access-list 103 permit tcp any any eq 23
!
class-map match-all voip
match access-group 100
class-map match-all voip-control
natch access-group 101
class-map match-all data1
match access-group 102
class-map match-all data2
match access-group 103
!
policy-map llq
class voip
priority 32
class voip-control
bandwidth 8
class data1
bandwidth 64
class data2
bandwidth 32
class class-default
fair-queue
!
interface Serial1/0
bandwidth 256
service-policy output llq

在本例中，与ACL 100匹配的所有流量均分类为“class voip”（表示语音流量）。它的优先级高达32 kbps。ACL 100与VoIP使用的常见UDP端口匹配。访问列表101匹配H.323信令流量（TCP端口1720）。 Class data1匹配Web流量（访问列表102中显示的TCP端口80），并保证64 kbps。Class data2匹配Telnet流量（ACL 103中显示的TCP端口23），并保证32 kbps。默认类配置为为未分类的流分配等额剩余带宽。策略称为“llq”。它应用于Serial1/0上的传出流量，总带宽为256 kbps。

注意：默认情况下，所有类的总保证带宽和优先级带宽需要小于接口带宽的75%。通过发出max-reserved bandwidth interface命令来修改此百分比。

下表比较了不同的软件排队机制及其各自的优点和局限性。

软件排队机制	描述	好处	限制
先进先出(FIFO)	数据包到达并以完全相同的顺序离开队列。	配置简单，操作快速。	不可能提供优先服务或带宽保证。¹
加权公平队列(WFQ)	一种散列算法，它流入单独的队列，其中权重用于确定一次处理多少个数据包。通过设置IP优先级和DSCP值来定义权重。	配置简单。在小于2 Mbps的链路上默认。	不可能提供优先服务或带宽保证。¹
自定义队列(CQ)	流量被分为多个具有可配置队列限制的队列。队列限制根据平均数据包大小、最大传输单位(MTU)和要分配的带宽百分比计算。队列限制（以字节数为单位）会为每个队列排队。因此，它会统计地提供已分配的带宽。	已有几年时间。它允许对不同队列进行近似带宽分配。	无法提供优先级服务。带宽保证是近似的。队列数量有限。配置相对困难。¹
优先级队列(PQ)	流量分为高优先级、中优先级、普通优先级和低优先级队列。优先处理高优先级流量，然后处理中、正常和低优先级流量。	已有几年时间。它提供优先服务。	更高优先级的流量使较低优先级的带宽队列开始。无带宽保证。²
基于类的加权公平队列(CBWFQ)	模块化QoS CLI用于对流量进行分类。分类的流量会放入保留的带宽队列或默认的未保留队列。调度器根据权重为队列提供服务，从而保证带宽。	与LLQ类似，不过没有优先级队列。简单的配置和提供带宽保证的能力。	无法提供优先服务。³
优先级队列加权公平队列(PQ-WFQ)，也称为IP RTP优先级	单个接口命令用于为指定范围内发往偶数端口号的所有UDP数据包提供优先级服务。	简单，只需一个命令配置。为RTP数据包提供优先级服务。	所有其他流量都使用WFQ处理。实时会议协议(RTCP)流量不按优先顺序排列。没有保证的带宽功能。⁴
LLQ，以前称为基于优先级队列类的加权公平队列(PQCBWFQ)	具有优先级队列的模块化QoS CLI用于对流量进行分类。分类的流量被放入优先级队列、保留的带宽队列或默认的未保留队列。调度器根据权重为队列提供服务，以便首先发送优先级流量（在拥塞期间达到特定的管制限制），并满足带宽保证。	配置简单。能够为多类流量提供优先级，并为优先级带宽利用率提供上限。您还可以配置带宽保证类和默认类。	目前没有提供多个优先级的机制，所有优先级流量都通过同一优先级队列发送。在拥塞期间，单独的优先级类可以有单独的优先级带宽上限。但是，应用程序之间共享优先级队列可能会引起抖动。⁴

不适合语音。
需要语音带宽保证。
需要处理延迟。
足够语音。

串行延迟

即使排队最有效并优先处理语音流量，优先级队列也是空的，并且有时会处理来自其他类的数据包。来自保证带宽类的数据包必须根据其配置的权重进行服务。如果优先级语音数据包在处理这些数据包时到达输出队列，则语音数据包在发送之前可以等待相当长的时间。当语音数据包必须等待较大的数据包之后时，会遇到序列化延迟。

串行化延迟会导致语音数据包抖动的最差形式。如果语音数据包必须在较慢的链路上等待1500字节的数据包后，这将导致巨大的延迟。如果数据包为80字节，则序列化延迟会大为不同，如本例所示：

由于1500字节数据包= 1500*8/64000 = 187.5毫秒，64 kbps链路上的串行化延迟。
由于80字节数据包= 80*8/64000 = 10毫秒，64 kbps链路上的串行化延迟。

因此，如果语音数据包在64 kbps链路上被困在单个1500字节的数据包后面，则可能必须等待187.5毫秒才能发送它。另一方面，另一个语音数据包在目的网关只需等待10毫秒。这会导致由于数据包间延迟的差异而产生巨大的抖动。在始发网关上，语音数据包通常每20毫秒发送一次。由于端到端延迟预算为150 ms，且抖动要求严格，因此180 ms以上的间隙是不可接受的。

引入分段机制，确保一个传输单元的大小小于10毫秒。任何序列化延迟超过10毫秒的数据包都需要分段为10毫秒的数据块。10毫秒区块或分段是链路上以10毫秒为单位发送的字节数。使用链路速度计算大小，如以下示例所示：

分段大小=（0.01秒* 64,000 bps）/（8位/字节）= 80字节

通过64 kbps链路发送80字节数据包或分片需要10毫秒。

如果单个物理接口上有多个ATM或帧中继永久虚电路(PVC)，请根据可用带宽最低的PVC配置分段值（在所有PVC上）。例如，如果有三条PVC的带宽保证为512 kbps、128 kbps和256 kbps，则请将所有三条PVC的分段大小配置为160字节（最低速度为128 kbps，需要160字节的分段大小）。建议将以下值用于不同的链路速度：

Link Speed (kbps)         Fragmentation Size (bytes) 
56                                  70 
64                                  80 
128                                 160 
256                                 320 
512                                 640 
768                                 960 
1024                                1280 
1536                                1920

注意：如果分段大小大于链路MTU大小，则无需分段。例如，对于MTU为1500字节的T1链路，分段大小为1920字节。因此，无需分段。数据包分段大小不应低于VoIP数据包大小。请勿对VoIP数据包进行分段。对这些数据包进行分段会导致大量呼叫建立和质量问题。

目前有三种链路分段和交织机制可用。有关数据包网络中引入的各种延迟的进一步说明，请参阅了解数据包语音网络中的延迟。下表列出了其优势和限制：

链路分段和交织(LFI)机制	描述	好处	限制
使用WFQ的MTU分段	用于更改MTU大小或IP MTU大小的接口级命令。用于将大型IP数据包分段到指定的MTU大小。LFI使用WFQ在分段之间交错实时数据包。	配置简单。	分段仅由接收应用程序重组。因此，网络使用效率低下。只有未设置“不分片(DF)”位的IP数据包才能很好地处理分片。处理器密集型。不推荐.
多链路点对点协议(MLPPP)LFI	在点对点串行链路上，必须首先配置MLPPP，然后以毫秒为单位设置分段大小。还必须在多链路接口上启用交织。	数据包在链路的一端进行分段，在另一端重新组装。多个链路可以组合起来作为大型虚拟管道。	仅在为PPP配置的链路上可用。Cisco IOS软件版本12.1(5)T或更高版本也支持帧中继PPP或ATM PPP的解决方案。
帧中继分片 (FRF.12)	在帧中继PVC上，必须启用frame-relay traffic-shaping命令，并在map-class下设置分段大小。	数据包在PVC的一端分段，在另一端重组。	仅在启用了frame-relay traffic-shaping命令的帧中继PVC上可用。

VAD

定期的语音对话包括几个沉默的时刻。典型的语音对话包括40%到50%的静默。由于40%的语音呼叫没有语音通过网络，因此部署VAD可以节省一些带宽。使用VAD时，网关会查找语音差距。它用舒适噪音（背景噪音）替换这些间隙。因此，节省了带宽量。然而，这是一种取舍。编解码器在检测语音活动之后经过一段静默期之前，有一小段时间（以毫秒为单位）。这一小段时间会导致接收语音的前端剪辑。为避免在极短的暂停期间激活并补偿剪辑，VAD在语音停止后大约等待200毫秒，然后停止传输。在重新开始传输时，它包括前5毫秒的语音以及当前语音。如果环境噪声阻止VAD区分语音和背景噪声，VAD会自动在呼叫中禁用自己。但是，如果带宽不是问题，请关闭VAD。

调整VAD参数

有两个参数决定VAD的功能。这些是music-threshold和voice vad-time命令。

音乐阈值

确定初始阈值，该阈值控制VAD何时需要激活。通过在语音端口上定义music-threshold threshold_value命令来控制此情况，如本例所示。此范围为每毫瓦–70分贝(dBm)至–30 dBm。默认值为–38 dBm。配置较低值（接近–70 dBm）会导致VAD以低得多的信号强度变为活动状态（在将卷视为静默之前，卷必须降低到极低的水平）。配置更高的值（接近–30 dBm）会导致VAD变为活动状态，即使语音信号强度略有下降。它驱动播放，以更频繁地播放舒适的噪音数据包。但是，这有时会导致音频的轻微剪辑。

3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#music-threshold ?
WORD Enter a number b/w (-70 to -30)
3640-6(config-voiceport)#music-threshold -50
3640-6(config-voiceport)#end
3640-6#
3640-6#show run | be voice-portvoice-port 3/0/0 music-threshold -50

voice vad-time

一旦VAD变为活动状态，背景噪声和舒适噪声的组件就通过在全局配置下配置voice vad-time timer_value命令来控制，如本例所示。这是用于无声检测和抑制语音数据包传输的延迟时间（以毫秒为单位）。保留时间的默认值为250毫秒。这意味着在250毫秒内，舒适噪音开始出现。此计时器的范围是250毫秒到65536毫秒。如果为此配置了高值，则舒适噪音会在以后很长时间内开始发挥（背景噪音会继续播放）。如果此配置为65536毫秒，则舒适噪音关闭。对于在背景噪声和舒适噪声之间更平滑地转换，该计时器的值更高。将voice vad-time命令配置到高级的缺点是，它不能实现所需的30%到35%带宽节省。

3640-6#
3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice vad-time ?
<250-65536> milliseconds
3640-6(config)#voice vad-time 750
3640-6(config)#end
3640-6#
3640-6#
3640-6#
3640-6#show run | be vad-time voice vad-time 750

QoS 典型配置示例

设置VoIP呼叫的典型场景是通过帧中继链路或PPP链路。以下是这些场景的配置示例。

VoIPoFR - QoS配置示例

在本示例中（仅包含配置的相关部分），假设帧中继电路速度为256 kbps。PVC 100的保证承诺信息速率(CIR)为64 kbps，PVC 200的保证承诺信息速率(CIR)为192 kbps。PVC 100用于传输数据和语音。PVC 200仅用于传输数据。在任何给定时间，最多存在四个同时进行的语音呼叫。根据最低带宽语音PVC（承载语音的PVC）的CIR配置两个PVC上的分段。根据本文档中的示例，这意味着分段大小取决于PVC 100的CIR(64 kbps)。如串行化延迟部分的表所示，对于64 kbps链路，需要80字节的分段大小。需要为PVC 200配置相同的分段大小。

有关帧中继上VoIP的配置的更多详细信息，请参阅服务质量（分段、流量整形、LLQ/IP RTP优先级）的帧中继上VoIP。

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoFR
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Serial4/0:0
bandwidth 256
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial4/0:0.1 point-to-point
bandwidth 64
ip address 10.10.10.10 255.255.255.0
frame-relay ip rtp header-compression
frame-relay interface-dlci 100
 class voice
!
interface Serial4/0:0.2 point-to-point
bandwidth 192
ip address 20.20.20.20 255.255.255.0
frame-relay interface-dlci 200
class data
!
map-class frame-relay data
frame-relay fragment 80
frame-relay adaptive-shaping becn
frame-relay cir 256000
frame-relay bc 32000
frame-relay be 0
frame-relay mincir 192000
frame-relay fair-queue
!
map-class frame-relay voice
frame-relay fragment 80
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 640
frame-relay be 0
frame-relay mincir 64000
service-policy output VoIPoFR
!
!
access-list 101 permit tcp any any eq 1720
!
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1

基于PPP的VoIP - QoS配置示例

在本示例（仅包含配置的相关部分）中，假设需要为点对点部分式T1控制器（具有十二个信道）配置QoS。在任何给定时间，最多存在四个同时进行的语音呼叫。配置任务包括使用PPP封装配置此串行接口、使其成为多链路组的一部分、创建多链路接口（属于同一多链路组）以及在多链路接口上配置所有QoS。有关PPP上VoIP配置的更多详细信息，请参阅服务质量（LLQ/IP RTP优先级、LFI、cRTP）的PPP上VoIP链路。

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoPPP
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Multilink7
bandwidth 768
ip address 10.10.10.10 255.255.255.0
ip tcp header-compression iphc-format
service-policy output VoIPoPPP
no cdp enable
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 7
ip rtp header-compression iphc-format
!
!
interface Serial4/0:0
bandwidth 768
no ip address
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 7
!
!
access-list 101 permit tcp any any eq 1720
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1
!

抖动和 Playout 机制

网络中总有一些非受控实体导致接收语音数据包的进一步延迟和抖动。通过修改终端网关上的抖动缓冲区，在语音网络中解决不受控的抖动。

播放机制

抖动缓冲区是时间缓冲区。由终端网关提供，使播放机制更有效。以下是播放机制的功能图：

播放控制收到语音数据包时，会分析RTP时间戳。如果语音数据包延迟超过抖动缓冲区的保持容量，则会立即丢弃该数据包。如果数据包在缓冲功能内，它将被置于抖动缓冲区中。此数据包在抖动缓冲区中的位置取决于为该数据包计算的RTP时间戳。如果没有可用的语音数据包，播放控制将尝试隐藏它（预测丢失的数据包）。如果启用VAD，则播放舒适噪音。

播放控制的职责是处理丢失的数据包、重复的数据包、损坏的数据包和无序数据包的事件。这些事件通过时间对齐抖动的语音数据包、播放舒适噪音（如果配置了VAD）或甚至重新生成要向主机播放的双音多频(DTMF)音来处理。

通过预测隐藏或静默隐藏来隐藏语音分组。预测隐藏基于前一个数据包和下一个数据包（如果可用）。它在低比特率编解码器（5 kbps至16 kbps）下最佳。高比特率编解码器（32 kbps至64 kbps）的语音数据包丢失可能导致预测隐藏不良。当存在低且不频繁的延迟或较少的丢包数时，就开始预测隐藏。过多的预测隐藏会导致机器人语音质量。静默隐蔽是预测隐藏的最糟糕形式。当没有可预测的信息时，它就开始发挥作用。它只是背景隐藏。当出现高延迟和更多丢包时，就会开始。过多的沉默掩盖会导致语音质量不稳定。预测隐藏30ms后，静默隐藏得以发挥。

抖动缓冲区

抖动缓冲器由高水位标记和低水位标记限制。高水位标记是数据包预期到达的时间上限，以便按时播放。在高水位标记后到达的数据包被标记为延迟数据包或丢失数据包。低水位标记是数据包预期到达并准时播放的最短时间。在低水位标记之前到达的数据包被视为早期数据包（仍可按时播放）。

如果终端网关继续看到延迟数据包的到达增加，则会增加高水位标记。在呼叫期间，高水位标记的此值保持不变。此值最多可增加到配置中定义的最大值。以类似方式，终端网关观察接收的早期数据包的数量。如果这些数据包开始频繁访问网关，则会降低低水位标记。此值在整个呼叫期间保持不变。这种抖动缓冲区模式称为“自适应模式”，其中终端网关根据流量模式调整其抖动缓冲区。另一种模式是“固定模式”。在固定模式下，低水位和高水位有一个初始值。此值基于估计的接收延迟(请参阅本文档的show voice call <port-number>部分)。

有关抖动缓冲区的更多详细信息，请参阅了解数据包语音网络（Cisco IOS平台）中的抖动。

识别延迟和抖动

本节介绍如何识别网络中的抖动。

show call active voice

show call active voice brief命令可提供有关正在进行的会话的大量信息。此输出显示了从此命令获知的一些重要点：

11E4 : 2170927hs.1 +600 pid:10 Answer 1000 active
dur 00:08:43 tx:26157/522967 rx:7044/139565
Tele 3/0/0:9: tx:151310/755/0ms g729r8 noise:-62 acom:0 i/0:-56/-48 dBm
11E4 : 2171198hs.1 +329 pid:20 Originate 2000 active
dur 00:08:43 tx:7044/139565 rx:26165/523127
IP 30.30.30.29:18682 rtt:51ms pl:148590/290ms lost:0/0/15 delay:65/60/132ms g729r8

从show call active voice brief命令输出中，您会看到电话支路(rx:7044)上收到的任何内容都会传输到IP支路(tx:7044)。在IP支路(26165)上接收的转发到电话支路(26157)的数据包也是如此。 IP支路上接收的数据包数与电话支路上传输的数据包数之间的差异会导致延迟数据包无法及时发送。

show call active voice命令(不带"brief"关键字)的此输出指向有关直接标识抖动的参数的进一步详细信息。

GapFillWithSilence=850 ms
GapFillWithPrediction=9230 ms
GapFillWithInterpolation=0 ms
GapFillWithRedundancy=0 ms

show voice call <port-number>

show voice call port-number命令提供有用的信息。确保在网关中控制台，或者如果您被Telnet到网关，请确保您已从执行级别发出terminal monitor命令。

注意：此命令在AS5x00/AS5x50平台上不可用。

在此输出中，Rx Delay Est(ms)的值为71。这是当前抖动缓冲区值。在此基础上推导了高水印和低水印的值。高水位的平均初始值为70毫秒，低水位的平均初始值为60毫秒。设置初始值后，网关将跟踪收到的任何早期数据包或延迟数据包。如图所示，预测隐藏下降接近250 ms，而静默隐藏为30 ms。由于静默隐藏只是预测隐藏的一个更坏的场景，因此预测隐藏的价值始终较高。对于每个预测隐藏丢弃，缓冲区溢出丢弃的增加。

如果看到缓冲区丢弃，并不一定意味着高水位线会增加。高水位标记是抖动缓冲的上限。只有观察到趋势，它才会更改。换句话说，应该有连续的延迟数据包流。这会增加抖动缓冲区。在此输出中，出现了这种趋势。因此，高水位标记从70毫秒增加到161毫秒。如果此值未更改（如果您仍看到14个延迟数据包），则意味着这些数据包是零星延迟数据包，不会形成趋势。

从show call active voice命令的输出中，查找丢失的数据包。对于每个丢失的数据包，您会看到两个数据包顺序不正确。这在Rx Non-Seq Pkts输出中显示。由于它不是正值，因此得出的结论是也没有任何丢包。

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 195, Tx Sig Pkts: 0, Tx Comfort Pkts: 10
Tx Dur(ms): 192070, Tx Vox Dur(ms): 388, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 9604, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
Rx Dur(ms): 192070, Rx Vox Dur(ms): 191560, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 0, Rx Late Pkts: 14
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 71
Rx Delay Lo Water Mark(ms): 60, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 250, Interpolate Conceal(ms): 0
Silence Conceal(ms): 30, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 500, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -49.9 from PBX/Phone, Tx -41.7 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.1
TDM Bgd Levels(dBm0): -58.9, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

观察Tx Comfort Pkts和Rx Comfort Pkts。从示例输出中得出的结论是，连接到此路由器的电话大多保持安静，因为您有许多Tx Comfort数据包。同时，您的Rx Comfort Pkts为零，这意味着另一端持续发言。

将此处的输出与上一个命令输出进行比较。Rx Late Pkts的数量增加（从14个增加到26个）。但是，高水印值没有增量。这表示12个数据包偶尔会延迟。缓冲区溢出丢弃增加到910毫秒。但是，由于没有观察到趋势，高水位并未增加。

在此输出中，您有Rx Early Pkts:3.这意味着数据包在预期到达之前会提前很多到达。从此处的输出看，抖动缓冲区已经扩展，通过将低水位标记从60减少到51来适应任何早期数据包。

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 209, Tx Sig Pkts: 0, Tx Comfort Pkts: 11
Tx Dur(ms): 337420, Tx Vox Dur(ms): 416, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 16843, Rx Signal Pkts: 0, Rx Comfort Pkts: 1
Rx Dur(ms): 337420, Rx Vox Dur(ms): 335920, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 3, Rx Late Pkts: 26
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 72
Rx Delay Lo Water Mark(ms): 51, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 510, Interpolate Conceal(ms): 0
Silence Conceal(ms): 70, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 910, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -51.5 from PBX/Phone, Tx -44.1 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.9
TDM Bgd Levels(dBm0): -61.3, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

在网关上配置抖动缓冲区

本文档中介绍的QoS准则会解决语音质量问题的不稳定或恶化。配置播放延迟缓冲区是解决网络中QoS实施不当的方法。仅将其用作止隙修复或用于排除和缩小网络中引入的抖动问题的工具。

播放延迟模式

抖动缓冲区配置为固定模式或自适应模式。在自适应模式下，网关允许您为抖动缓冲区配置最小值、最大值和标称值。抖动缓冲区期望数据包到达额定值范围内。额定值必须等于或大于最小值，且等于或小于最大值。缓冲区会扩展到所配置的最大值。这可扩展至1700毫秒。配置高最大值的一个问题是引入端到端延迟。选择最大播放延迟值，以便它不会在网络中引入不需要的延迟。以下输出是为自适应模式配置的抖动缓冲区的示例：

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode adaptive
3640-6(config-voiceport)#playout-delay maximum 400
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#playout-delay minimum low
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay maximum 400
playout-delay nominal 70
playout-delay minimum low
playout-delay mode adaptive
!

在固定模式下，网关会查看配置的额定值。虽然它允许您配置播放延迟的最小值和最大值，但在为固定模式配置时会忽略它。在固定模式下，高水印值或低水印值始终保持恒定。它基于额定值和Rx延迟测试(ms)值。因此，在固定模式下，可以将值配置为200毫秒。但是，如果估计的接收延迟接近100毫秒，那么在整个呼叫期间，高水位标记和低水位标记被设置为。

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode fixed
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay mode fixed
playout-delay nominal 70
!

有关播放延迟配置的详细信息，请参阅IP语音播放延迟增强功能。