RTPサーバーでのジッターの原因
いくつかの通話品質の問題（通話の0.5〜1秒のデッドスポット）を調査しました。同じPBX上の2つの内線間の通話のパケットキャプチャを行いました。 PBXからキャプチャしていたので、Wiresharkがコールのデッドスポットと同期したジッターの巨大なスパイクを報告しているのを見て、かなり驚きました。
私の理解では、ジッターはパケット損失や転送中のレイテンシーによって引き起こされ、RTPストリームはPBXを離れた状態で比較的元の状態である必要があります。しかし、このスパイクは4つのRTPストリームすべて（オフィス1からPBX、オフィス2からPBX、PBXからオフィス1、PBXからオフィス2）に現れました。パケットは、サーバーを離れるまでにすでに状態が悪いようです。
PBXは、Scientific Linux（RHEL）6.9上のAsterisk 13です（新しく更新されたツールとVMXNET3アダプターを備えたVMWare ESXi 5.5ゲストで実行されます）。CPUの使用率は約5〜15％で、ネットワークトラフィックはかなり安定しています。最小限です。この問題のトラブルシューティングはどこで確認できますか？この種の問題の一般的な原因はありますか？問題はサーバーにあるので、外部ネットワーク側の問題を除外できると思いますか？
最後にこれを理解しました！ TLDR：ホストの電源管理を無効にします。
CPU使用率が低いにもかかわらず、これはCPU負荷と関係があると考えました。そのため、呼び出しのデッドスポットに関するこの問題が悪化することを想定して、CPUのロードを実験していました。代わりに、それは完全に消えました。そのため、vCenterのCPU使用率の統計を何度も調べた後、最終的にotherを調べました。そのグラフの線。
これはおそらく多くの人にとってニュースではありませんが、 CPU準備時間 はa VMがCPUを使用する準備ができている時間ですが、物理的なホストがリソースを割り当てることはできません。私が見つけたほとんどの情報源によると、5％未満であれば問題はないと言われていますが、確かに音声ストリームに影響を与えているようです。毎分カットアウトが見られ、グラフには、毎分準備時間の急増も示されました。
それで、なぜこれが高いCPU負荷の間になくなるのか疑問に思い、それはある種の電源管理であるに違いないと考えました。ホストは使用量の増加を確認すると、CPUリソースをVMで一貫して利用できるようにします。そのため、ホストのBIOSで電源管理を無効にしましたet voila：
グラフの終わり近くの準備時間のわずかな増加は、このホストに戻って移行する他のVMの数5に相当します。
通話トレースにごくわずかなジッターが表示され、カットアウトが通話から消えました。さらなる調査によると、これは、遅延の影響を受けやすく、CPUに負荷をかけないワークロードでやや一般的な問題です。電源管理は、CPU使用率が非常に低いことを認識し、プロセッサを抑制できると想定します。
同様の問題がありましたが、さらに悪いことに、Wireshark RTPグラフ、ヒスノイズ、途切れ途切れのオーディオに多くのスパイクがありました。
多くの実験の過程で、CDRデータベースをダンプしましたが、これは1.5GBになりました。私はサイズに気づきましたが、オーディオの問題を修正するまで剪定を延期していました。 B-）
これにより、IVRメッセージのG729へのトランスコーディングなど、オーディオ品質がすぐに向上したようです。
遅延は、 SmokePing トレースからVPSまでも確認できました。