调查一些通话质量问题（通话中 0.5 - 1 秒的死点）我捕获了同一 PBX 上两个分机之间的电话通话的数据包。由于我是从 PBX 捕获的，因此我很惊讶地看到 Wireshark 报告了抖动的巨大峰值，与通话中的死点同步：
我的理解是抖动是由数据包丢失和/或传输延迟引起的，离开 PBX 的 RTP 流应该相对完美。但这个峰值出现在所有四个 RTP 流中（办公室 1 到 PBX、办公室 2 到 PBX、PBX 到办公室 1、PBX 到办公室 2），因此看起来数据包在离开服务器时就已经很差了。
PBX 是运行在 Scientific Linux (RHEL) 6.9 上的 Asterisk 13（在 VMWare ESXi 5.5 客户机上运行，带有最新更新的工具和 VMXNET3 适配器）。CPU 使用率稳定在 5-15% 左右，网络流量极小。我可以在哪里查找以解决此问题？此类问题是否有常见原因？我假设问题出在服务器上，因此我可以排除外部网络方面的问题？
答案1
终于搞明白了！TLDR：禁用主机上的电源管理。
尽管 CPU 使用率很低，但我们仍然认为这与 CPU 负载有关。因此，我们尝试降低 CPU 负载，预计通话死点问题会变得更糟。相反，它完全消失了。因此，在多次查看 vCenter 中的 CPU 使用率统计数据后，我终于研究了其他该图上的线。
这对很多人来说可能不是什么新闻，但我发现CPU 就绪时间是虚拟机准备好使用 CPU，但主机无法分配物理资源的时间量。我发现的大多数资料都说，低于 5% 不会有问题，但这似乎确实对我们的语音流产生了影响。我们每分钟都看到断线，图表还显示每分钟的就绪时间都在激增。
所以我开始好奇为什么在 CPU 负载高时这种情况会消失，并认为这一定是某种电源管理。当主机看到使用率增加时，它会让 CPU 资源始终可供虚拟机使用。所以我在主机的 BIOS 中禁用了电源管理，瞧：
图表末尾附近的就绪时间略有增加对应于另外六个虚拟机迁移回该主机。
现在，通话轨迹显示的抖动量可以忽略不计，通话中断也消失了。进一步的研究表明，对于延迟敏感且 CPU 非密集型的工作负载来说，这是一个相当常见的问题。电源管理看到非常低的 CPU 使用率，并认为它可以限制处理器，尽管它不应该这样做！
答案2
我遇到了类似的问题，但情况更糟，Wireshark RTP 图中出现许多尖峰、嘶嘶声和断断续续的音频。
在多次实验中，我抛弃了CDR数据库，已增长至 1.5GB。我注意到了大小，但推迟了修剪，直到我修复了音频问题。B-)
这显然立即改善了音频质量，包括将 IVR 消息转码为 G729。
从以下方面也可以看出延迟烟平追踪到 VPS。