VoIP 通話の実際のデータは RTP を介して運ばれます。RTP は実際には 24 ~ 64Kbps (コーデックによって異なります) しか必要とせず、双方向に UDP アドレスが必要です。時折 RTCP パケットが送信され、ステータスやメトリックなどを報告しますが、実際には必要ありません。
SIP は、コールのセットアップとティアダウンに使用されます。
RTCP パケットは、(最小限の) 通話品質メトリックを伝送します。
コーデックの選択、利用可能な帯域幅、ネットワーク遅延、パケット損失 (RTP は UDP を介しているため、再送信はありません)、ジッター (パケット間の到着遅延、順不同の配信) など、いくつかのパラメータが通話品質に影響します。
(Cicso) スイッチは、ネットワーク パケットをランダムに破棄することでキューの深さを減らす手法である RED を実装します。TCP ネットワーク接続の場合、TCP にはスライディング ウィンドウ プロトコルによる再送信があるため、これは許容されます。また、多くの UDP ベースのプロトコルは、アプリケーションの再送信を実装しています。しかし、RTP にはその贅沢はありません。そのため、音声パケットがランダムに破棄されると、接続の品質が低下します。RED に対する 1 つの解決策は、TCP 接続を介して VoIP をトンネリングすることですが、それは選択されませんでした。
混雑したネットワークは VoIP 通話品質の問題の大きな原因であり、通話の最初の数秒間で測定できます。ジッターによるパケットのドロップとパケットの遅延 (高いネットワーク遅延) は、通話品質の低下の 2 つの主な原因です。私は VoIP のサービス品質監視システムに取り組みましたが、最悪の通話では高ジッタと高遅延 (約 70 ミリ秒以上は悪い) が見られました。待ち時間が長く、混雑したネットワークを避けてください。コード化の選択は、品質に大きな影響を与える可能性があります。圧縮率の高いコーデックは、「効率的」でないコーデックよりもパケット損失による損失が大きいため、より高い帯域幅を使用するコーデックを選択してください (頑張ってください)。
IP ネットワークでは、最高の VoIP 品質を提供するために QoS 保証が必要です。また、TCPIP が QoS を含むように再定義されるまで、VoIP には (潜在的な) 問題が発生します。
あなたのアプローチは近いです。しかし、あなたは測定したい:
- UDP
- パケットロス
- 混雑
- レイテンシー
- パケットのジッター
パケットにタイムスタンプを付けて番号を付ける必要があり、高い遅延や到着間ジッターを検出し、TCP 経由での測定を避ける必要があります (パケットの再送信は品質の数値をゆがめ、TCP はパケットを並べ替えますが、遅延が発生します)。また、両方の品質も知りたいです。通話を改善するには、コーデックの選択が大きな要因になることに気付くかもしれません。
私がモニターを構築するために働いていた会社 (Telchemy) は、品質を測定する製品として VQMon ソフトウェアのライセンスを取得しているため、必要なツールは既に存在します。