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

ダウンロードオプション

PDF (1.2 MB)
Adobe Reader を使ってさまざまなデバイスで表示
ePub (829.7 KB)
iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
Mobi (Kindle) (938.9 KB)
Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示

Updated: 2014 年 7 月 28 日

Document ID:117881

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

概要

問題

概要

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

問題

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

IP フォン A（セントラルサイト A） > 2960 スイッチ > ルータ > WAN ルータ（セントラルサイト） > IPWAN > WAN ルータ（サイト B） > ルータ > 2960 > IP フォン B

このシナリオで発生する問題は、IP フォン A から IP フォン B へのビデオコールが、セントラルサイト A からブランチサイト B に向かってビデオ品質が低下し、セントラルでは良かった品質がブランチ側では悪くなることです。

ブランチ IP フォンのストリーミング統計での受信側損失パケットを参照してください。

解決方法

品質の悪化はブランチ側においてのみ見られ、セントラルサイトでの画像は良好なので、セントラルサイトからブランチサイトまでのネットワーク上でパケットの損失が発生しているものと考えられます。

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 フォン（192.168.10.146）からブランチ IP フォン（192.168.207.231）への RTP ストリームに注目します。 WANが中央WANルータからブランチWANルータへのストリームでパケットをドロップすると、このストリームはブランチWANルータでパケットを失います。問題を切り分けるには、wiresharkのフィルタオプションを使用します。

Wireshark でキャプチャを開きます。
フィルタip.src==192.168.10.146 && ip.dst==192.168.207.231を使用します。これにより、中央のIP電話からブランチのIP電話へのすべてのUDPストリームがフィルタリングされます。
ここではブランチ側のキャプチャについてのみ分析を実行しますが、セントラルキャプチャに対してもこれらの手順を実行する必要があることに注意してください。
このスクリーンショットでは、UDP ストリームは送信元と宛先の IP アドレスの間でフィルタリングされ、2 つの UDP ストリームが含まれます（UDP ポート番号を区別されます）。これはビデオコールなので、2 つのストリームがあります。音声とビデオです。この例の 2 つのストリームは次のとおりです。
- ストリーム 1:UDP 送信元ポート:20560、宛先ポート:20800
- ストリーム 2:UDP 送信元ポート:20561、宛先ポート:20801
ストリームからパケットを 1 つ選択し、パケットを右クリックします。
[Decode As...] を選択して、「RTP」と入力します。
[Accept] をクリックして [OK] をクリックし、ストリームを RTP としてデコードします。

1 つのストリームは RTP としてデコードされ、もう 1 つはデコードされていない UDP のままです。
デコードされていないストリームからパケットを選択し、RTP としてデコードします。これにより、オーディオストリームとビデオストリームの両方が RTP にデコードされます。

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

問題はビデオ品質のみになりました。ビデオ RTP ストリームに注目し、このストリームの UDP ポート番号を使用して他のストリームを除外します。
パケットの 1 つを選択してポート番号を表示します。Wireshark ユーティリティの下部ペインに、UDP ポートの情報が表示されます。前のスクリーンショットでは、ビデオストリームのパケットの 1 つが選択されており、送信元ポート（20568）と宛先ポート（20808）の情報を下部ペインで見ることができます。

ヒント：(ip.src==192.168.10.146 && ip.dst==192.168.207.231) && （udp.port eq 20568およびudp.port eq 20808）のフィルタを使用します。このスクリーンショットではビデオ RTP ストリームのみが示されています。

注：このストリームの最初と最後の RTP シーケンス番号を記録しておきます。

抽出されたビデオ RTP ストリームの最初の RTP シーケンス番号は 45514、最後のシーケンス番号は 50449 です。
最初と最後の RTP シーケンス番号のパケットが、両方のキャプチャ（たとえば、セントラルキャプチャとブランチキャプチャ）に存在することを確認し、ストリームの SSRC が両方のキャプチャで一致することに注意します。
最初と最後の RTP ストリームの間のパケットだけに一致するようにフィルタを調整します。

キャプチャが同時に取得されず、両者の間にわずかな遅延がある場合は、シーケンス番号を使用してストリームを調整します。

注：ブランチサイトが 45514 の後にいくつかのシーケンス番号を開始している可能性があります。
開始と終了のシーケンス番号を選択します。これらのパケットは両方のキャプチャに存在し、開始と終了の 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 )
```
キャプチャが同時に取得された場合は、両方のキャプチャの開始または終了時に失われたパケットはありません。キャプチャの 1 つの開始または終了時にいくつかのパケットが含まれない場合は、両方のパケットで失われたキャプチャの最初のシーケンス番号または最後のシーケンス番号を使用して、両方のキャプチャのフィルタを調整します。同じシーケンス番号の間に（RTP シーケンス番号範囲）両方のポイントでキャプチャされたパケットを観察します。

フィルタを適用すると、セントラルサイトとブランチサイトの表示は次のようになります。

セントラルサイト:

ブランチサイト:

Wireshark ユーティリティの下部ペインで、両方のキャプチャのフィルタ処理されたパケット数に注意してください。[Displayed] の数は、指定したフィルタ条件に一致するパケットの数を示します。

開始（45514）と終了（50449）の RTP シーケンス番号の間で指定したフィルタ条件に一致するパケットの数は、セントラルサイトでは 4,936 個であるのに対し、ブランチサイトでは 4,737 個だけです。これは、199個のパケットの損失を示します。これらの199個のパケットは、このドキュメントの最初に示すブランチ側のIP電話のストリーミング統計情報で見られる「Rcvr Lost Pkts」の数199個に一致9個です。

これにより、Rcvr Lost Packets のすべてが WAN 上のネットワーク損失で実際に失われたことがわかります。以上が、ネットワークドロップが疑われる音声とビデオの品質の問題に対処するときに、ネットワークのパケット損失ポイントを分離する方法です。