排除Catalyst 9000交换机上的网络相关音频问题

简介

本文档介绍如何在IP语音(VoIP)环境中排除与网络相关的音频问题。

要求

Cisco 建议您了解以下主题：

• 服务质量
• VoIP网络
• SPAN（交换机端口分析器）
• Wireshark

使用的组件

本文档中的信息基于以下软件和硬件版本：

• Catalyst 9200
• Catalyst 9300
• Catalyst 9400
• Catalyst 9500
• Catalyst 9600

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

在VoIP基础设施中，音频质量可能会受到网络相关问题的影响，这些问题包括：

• 语音或断断续续的音频中断。
• 单向音频.
• 不是隔离给单个用户，而是隔离给具有共同特征的一组用户，例如共享同一VLAN或共享同一接入交换机。

为了排除与网络相关的问题，语音数据包的源与目的地之间必须有一个清晰的拓扑。问题的诊断可以从网络中交换或路由语音数据包的任何点开始，但建议从接入层开始排除故障并转到路由层。

网络图

在路径中选择一个捕获点。它可以是A（最接近一个IP电话）、B（路由前）、C（最接近目标）。

SPAN捕获通常在两个方向（TX和RX）上进行，以便识别会话的两端，并从捕获中提取相应的音频，以及其他变量（如抖动或丢包）以供进一步分析。

确定捕获点后，在交换机上设置SPAN配置。

Switch(config)#monitor session 1 source interface Gig1/0/1 both
Switch(config)#monitor session 1 destination interface Gig1/0/6 encapsulation replicate 
Switch#show monitor session all
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi1/0/1
Destination Ports : Gi1/0/6
Encapsulation : Replicate
Ingress : Disabled

发起测试呼叫，以捕获来自使用Wireshark的PC/笔记本电脑中所选捕获点的音频流。

捕获分析

1.打开使用Wireshark捕获的数据包并导航到Statistics > Conversations。根据相关设备的IP地址（IP电话源和目标）查找音频会话。

2.通常，音频流由UDP协议承载，并且大多数时候未以正确的格式进行解码，Wireshark无法提取嵌入其中的音频。然后，下一步是将UDP数据流解码为音频格式，默认情况下使用RTP。右键单击流的任何数据包，然后单击Decode as。

3.查找Current列并选择RTP。Click OK.

Wireshark将整个UDP流解码为RTP，我们现在可以分析内容。

注意:RTP Player能够播放已安装插件支持的任何编解码器。RTP Player支持的编解码器取决于您使用的Wireshark版本。官方版本包含由Wireshark开发人员维护的所有插件，但是自定义/分发版本不包括其中的一些编解码器。要检查您的Wireshark安装的编解码器插件，请执行以下操作：打开帮助>关于Wireshark。选择Plugins选项卡。在Filter by type菜单中，选择Codec。

4.检查RTP统计信息，查看音频流中是否存在任何抖动或丢失。要查看分析，请导航到Telephony > RTP > RTP Stream Analysis。

抖动：通过网络发送语音数据包的时间延迟。这通常是由网络拥塞或路由变化引起的。此测量值必须小于30ms。

丢失：未作为音频流的一部分接收的数据包。丢包率不得超过1%。

5.在Telephony > RTP > RTP Streams中转换来自此流的音频

6.选择要将其转换为音频的流，然后单击播放流。

必须显示音频波，并且播放按钮可用于收听音频数据。听到音频有助于确定流中是否存在语音波动或单向音频问题。

7.单击导出>文件同步音频，将流导出到扩展名为.wav的音频文件中。

故障排除

使用SPAN功能通过Wireshark收集和分析捕获后，我们了解问题是否可能与抖动、丢包或单向音频有关。如果在数据包捕获中发现任何问题，下一步是检查捕获的设备，查找可能会影响RTP音频流的常见问题。

断断续续的音频

带宽不足、抖动和/或丢包可能是音频捕获中听到语音中断或失真的常见原因。

1.检查捕获上的抖动是否大于30毫秒。如果是，则表明数据包接收存在时间延迟，这可能是由于QoS策略或路由问题造成的。

2.检验捕获时丢失的数据包是否大于1%。如果此值很高，则需要查找沿音频流路径的数据包丢弃。

3.检查路径中涉及的入口和出口接口上是否存在丢包。

Switch#show interface Gi1/0/1 | inc drops
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
0 unknown protocol drops

Switch#show interfaces Gi1/0/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi1/0/1 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Gi1/0/1 0 0 0 0 0 0

验证接口上不存在递增输入/输出丢弃或其他递增错误。

4.检查路径中涉及的接口上的QoS出口策略。确保您的流量在优先级队列中映射/分类，并且此队列中没有丢弃。

Switch#show platform hardware fed switch 1 qos queue stats interface Gi1/0/1
----------------------------------------------------------------------------------------------
AQM Global counters
GlobalHardLimit:  3976   |   GlobalHardBufCount: 0
GlobalSoftLimit: 15872   |   GlobalSoftBufCount: 0

----------------------------------------------------------------------------------------------
High Watermark Soft Buffers:  Port Monitor Disabled
----------------------------------------------------------------------------------------------
Asic:0 Core:1 DATA Port:0 Hardware Enqueue Counters
----------------------------------------------------------------------------------------------
 Q Buffers          Enqueue-TH0          Enqueue-TH1          Enqueue-TH2             Qpolicer
   (Count)              (Bytes)              (Bytes)              (Bytes)              (Bytes)
-- ------- -------------------- -------------------- -------------------- --------------------
 0       0                    0               707354              2529238                    0 <<< Priority Q
 1       0                    0                    0              1858516                    0
 2       0                    0                    0                    0                    0
 3       0                    0                    0                    0                    0
 4       0                    0                    0                    0                    0
 5       0                    0                    0                    0                    0
 6       0                    0                    0                    0                    0
 7       0                    0                    0                    0                    0
Asic:0 Core:1 DATA Port:0 Hardware Drop Counters
--------------------------------------------------------------------------------------------------------------------------------
 Q             Drop-TH0             Drop-TH1             Drop-TH2             SBufDrop              QebDrop         QpolicerDrop
                (Bytes)              (Bytes)              (Bytes)              (Bytes)              (Bytes)              (Bytes)
-- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
 0                    0                    0                    0                    0                    0                    0 <<< Priority Q Drops
 1                    0                    0                    0                    0                    0                    0
 2                    0                    0                    0                    0                    0                    0
 3                    0                    0                    0                    0                    0                    0
 4                    0                    0                    0                    0                    0                    0
 5                    0                    0                    0                    0                    0                    0
 6                    0                    0                    0                    0                    0                    0
 7                    0                    0                    0                    0                    0                    0 

注：如果发生丢弃，请确保使用DSCP加速转发(EF)标记正确分析语音流量，并确认没有其他欺诈流错误地标记了EF位，从而拥塞优先级队列。

单向音频

电话呼叫建立后，只有一方收到音频。此问题的常见原因与连通性问题、路由问题或NAT/防火墙问题有关。

1.对目的子网或目的网关执行ping操作以确认存在双向可达性。

Switch#ping 192.168.1.150
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.150, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

2.从源子网到目的子网执行traceroute，反之亦然。这有助于检查路径中有多少跳，以及它是否对称。

Switch#traceroute 192.168.1.150
Type escape sequence to abort.
Tracing the route to 192.168.1.150
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.2.12 2 msec * 1 msec
2 192.168.1.12 2 msec * 1 msec
3 192.168.1.150 2 msec 2 msec 1 msec

3.检查每个子网的网关设备是否具有最佳路由，以及是否不存在可能影响通信的对称路径。

提示：常见的单向音频问题与防火墙规则或NAT问题上的ACL配置错误有关。建议验证这些情况是否可能会影响音频流流。

4.在检测到音频流量的最后一台设备上捕获数据包以获取故障方向。这有助于隔离音频流丢失的路径设备。这一点非常重要，因为可以通过NAT或防火墙设备允许ping流量，但可以阻止或无法正确转换特定音频流量。

相关信息

• 思科技术支持和下载