サービス品質(QoS) : リアルタイム プロトコル(RTP)

音声とビデオ コールににおける Wireshark のパケット損失分析のための RTP ストリームの解読

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 4 月 23 日) | フィードバック

Table of Contents
          概要
          問題
          解決策

概要

このドキュメントでは、音声およびビデオ コール用の Wireshark で、パケット損失を分析するためにリアルタイム ストリーミング(RTP)ストリームを解読するプロセスについて説明します。 Wireshark フィルタを使用すると、コールの送信元と宛先(またはその近辺)で、同時にパケット キャプチャの分析を行うことができます。 これは、ネットワーク損失が疑いのある状況で、音声およびビデオ品質の問題についてトラブルシューティングを行う必要がある場合に役立ちます。

著者:Cisco TAC エンジニア、Shyam Venkatesh

問題

この例では、次のコール フローを使用します。

IP Phone A(中央サイト A)> 2960 スイッチ > ルータ > WAN ルータ(中央サイト)> IPWAN > WAN ルータ(サイト B)> ルータ > 2960 > IP Phone B

このシナリオでは、IP Phone A から IP Phone B へのビデオ コールにおいて、中央サイト A からブランチ サイト B への過程でビデオ品質が劣化するという問題が発生しています。このとき、中央サイトでの品質には問題がなく、ブランチ サイトでビデオ品質が劣化します。

ブランチ IP Phone のストリーミング統計情報に表示される、レシーバの損失パケットの例を示します。

解決策

品質の劣化はブランチ側でのみ見られ、中央サイト側の品質には問題がないため、中央サイトからブランチ サイトのストリームは、ネットワーク上でパケットを損失したと考えられます。

IP addressing scheme
Central IP phone: 192.168.10.146
Central Gateway: 192.168.10.253
Central WAN router: 192.168.10.254
Branch WAN router: 192.168.206.210
Branch Gateway: 192.168.206.253
Branch IP phone: 192.168.207.231

パケット キャプチャは中央サイトとブランチ WAN ルータで実行され、WAN はこれらのパケットをドロップします。 そこで、中央 IP Phone(192.168.10.146)からブランチ IP Phone(192.168.207.231)までの RTP ストリームに焦点を絞り込みます。 中央 WAN ルータからブランチ WAN ルータへのストリームで WAN がパケットをドロップした場合、このストリームでは、ブランチ WAN ルータでパケット損失が発生します。 問題を特定するには、Wireshark でフィルタ オプションを使用します。

  1. Wireshark のキャプチャを開きます。

  2. フィルタ「ip.src==192.168.10.146 && ip.dst==192.168.207.231」を使用します。 これは中央 IP Phone からブランチ IP Phone までのすべての UDP ストリームをフィルタリングします。

  3. ブランチ側のキャプチャの分析のみを行います。ただし、中央側のキャプチャについてもこの手順を行う必要があります。

  4. このスクリーンショットでは、UDP ストリームは、送信元 IP アドレスと宛先 IP アドレスの間でフィルタリングされ、2 つの UDP ストリームを含んでいます(UDP ポート番号で区別されます)。 これはビデオ コールであるため、 オーディオとビデオの 2 つのストリームがあります。 この例では、2 つのストリームはそれぞれ次のようになります。

    • ストリーム 1: UDP 送信元ポート: 20560、宛先ポート: 20800

    • ストリーム 2: UDP 送信元ポート: 20561、宛先ポート: 20801



  5. いずれかのストリームから 1 つのパケットを選択し、右クリックします。

  6. [Decode As...] を選択し、「RTP」と入力します。

  7. [Accept] をクリックし、[OK] をクリックしてストリームを RTP としてデコードします。



    ここで、1 つ目のストリームは RTP としてデコードされ、もう 1 つのストリームはデコードされていない UDP となります。



  8. デコードされていないストリームからパケットを選択し、RTP としてデコードします。 これにより、音声とビデオの両方のストリームが RTP としてデコードされます。

    : オーディオ ストリームは G.722 コーデック形式で、Dynamic-RTP-97 ペイロード タイプはビデオ RTP ストリームを示します。





    ここで、問題はビデオ品質に絞られます。 ビデオ RTP ストリームに注目し、UDP ポート番号を使用して、このストリームが他のストリームをフィルタリングするようにします。

  9. Wireshark ユーティリティの一番下のペインで、UDP ポート情報を表示するパケットの 1 つを選択し、ポート番号を表示します。 前のスクリーンショットでは、ビデオ ストリームからのパケットの 1 つが選択され、一番下のペインに送信元ポート(20568)と宛先ポート(20808)の情報が表示されています。

    ヒント: フィルタ 「(ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (udp.port eq 20568 and udp.port eq 20808)」を使用します。 このスクリーンショットにはビデオ RTP のみが示されています。



    : このストリームの最初と最後の RTP シーケンス番号を書き留めておきます。







    フィルタリングされたビデオ RTP ストリームの最初の RTP シーケンス番号が 45514 で、最後が 50449 です。

  10. 最初と最後の RTP シーケンス番号パケットが両方のキャプチャ(中央キャプチャとブランチ キャプチャなど)に存在することを確認してください。また、ストリームの SSRC が両方のキャプチャで同じであることに注目してください。
  11. 最初と最後の RTP ストリームの間のパケットのみが一致するようにフィルタを調整します。 

    キャプチャが同時に実行されていない場合は、ストリームの調整にシーケンス番号が使用されますが、その間にわずかな遅延が発生します。

    : ブランチ サイトは、45514 の後のいくつかのシーケンス番号を開始することができます。



  12. 開始および終了シーケンス番号を選択します。 これらのパケットは、両方のキャプチャに存在します。開始 RTP シーケンス番号と終了 RTP シーケンス番号の間のパケットのみを表示するようにフィルタを調整します。 このためのフィルタは次のとおりです。

    (ip.src==192.168.10.146 && ip.dst==192.168.207.231) && (udp.port eq 20568 
    and udp.port eq 20808) && ( rtp.seq>=44514 && rtp.seq<=50449 )


    キャプチャが同時に使用される場合、両方のキャプチャの開始および終了時にパケットは失われません。 開始/終了時にいずれかのキャプチャでパケットがほとんど含まれていないことがわかった場合は、両方のパケットで失われたキャプチャの最初のシーケンス番号または最後のシーケンス番号を使用して、両方のキャプチャのフィルタを調整します。 同じシーケンス番号(RTP シーケンス番号の範囲)間の両方のポイントでキャプチャされたパケットを確認します。

    フィルタを適用すると、中央サイトとブランチ サイトでこれを確認できます。

    中央サイト:



    ブランチ サイト:



    両方のキャプチャの Wireshark ユーティリティの一番下のペインで、フィルタリングされたパケット数に注目してください。 表示されている数は、目的のフィルタ基準に一致するパケットの数を示します。

    中央サイトには 4,936 のパケットがあり、これは開始(45514)RTP シーケンス番号と終了(50449)RTP シーケンス番号の間の目的のフィルタ基準に一致します。一方ブランチ サイトのパケットはわずか 4,737 しかありません。 これは 199 のパケットが損失したことを示します。 この 199 というパケット数が、このドキュメントの最初に記した、ブランチ側 IP Phone のストリーミング統計情報に見られる「Rcvr Lost Pkts」の 199 という数に一致することに注目してください。

    これは、すべての Rcvr Lost Packets が実際に WAN 間でのネットワーク損失であることを示しています。 以上が、ネットワーク損失が疑われる状況で音声/ビデオ品質の問題を処理する際に、ネットワークでパケット損失のポイントを特定する方法です。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 117881