Bestimmen Sie den RTP-Stream für die Analyse von Paketverlusten in Wireshark für Sprach- und Videoanrufe.

Download-Optionen

PDF (1.2 MB)
Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub (836.8 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle) (946.5 KB)
Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen

Aktualisiert:28. Juli 2014

Dokument-ID:117881

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Inhalt

Einführung

Problem

Einführung

In diesem Dokument wird beschrieben, wie der Real-Time Streaming (RTP)-Stream für die Analyse von Paketverlusten in Wireshark bei Sprach- und Videoanrufen entschlüsselt wird. Sie können Wireshark-Filter verwenden, um die gleichzeitige Paketerfassung zu analysieren, die an oder nahe der Quelle und dem Ziel eines Anrufs durchgeführt wird. Dies ist nützlich, wenn Sie Probleme mit der Audio- und Videoqualität beheben müssen, wenn Netzwerkverluste vermutet werden.

Problem

In diesem Beispiel wird dieser Anruffluss verwendet:

IP-Telefon A (zentraler Standort A) > 2960-Switch > Router > WAN-Router (zentraler Standort) > IPWAN > WAN-Router (Standort B) > Router > 2960 > IP-Telefon B

In diesem Szenario besteht das Problem darin, dass Videoanrufe von IP-Telefon A zu IP-Telefon B zu einer schlechten Videoqualität von dem zentralen Standort A zu der Zweigstelle B führen, wo die Zentrale eine gute Qualität hat, die Zweigstelle jedoch Probleme hat.

In der Streaming-Statistik des IP-Telefons der Außenstelle werden verlorene Pakete angezeigt:

Lösung

Schlechte Qualität zeigt sich nur auf der Zweigstelle, und da der zentrale Standort ein gutes Bild sieht, sieht es so aus, als würde der Stream von der Zentrale zur Zweigstelle Pakete über das Netzwerk verlieren.

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

Die Paketerfassungen werden auf dem WAN-Router der Zentrale und Zweigstelle durchgeführt, und das WAN verwirft diese Pakete. Konzentrieren Sie sich auf den RTP-Stream vom zentralen IP-Telefon (192.168.10.146) zum IP-Telefon der Außenstelle (192.168.207.231). Dieser Stream übersieht Pakete auf dem WAN-Router der Außenstelle, wenn das WAN die Pakete im Stream vom zentralen WAN-Router zum WAN-Router der Außenstelle verwirft. Verwenden Sie die Filteroptionen in Wireshark, um das Problem zu isolieren:

Öffnen Sie die Erfassung in Wireshark.
Verwenden Sie den Filter ip.src==192.168.10.146 && ip.dst==192.168.207.231. Dadurch werden alle UDP-Streams vom zentralen IP-Telefon an das IP-Telefon der Außenstelle gefiltert.
Führen Sie die Analyse nur für die Zweigstellenerfassung durch. Beachten Sie jedoch, dass Sie diese Schritte auch für die zentrale Erfassung ausführen müssen.
In diesem Screenshot wird der UDP-Stream zwischen der Quell- und der Ziel-IP-Adresse gefiltert und enthält zwei UDP-Streams (differenziert durch die UDP-Portnummern). Dies ist ein Videoanruf, sodass zwei Streams vorhanden sind: Audio und Video. In diesem Beispiel sind die beiden Streams:
- Stream 1: UDP-Quellport: 20560, Zielport: 20800
- Stream 2: UDP-Quellport: 20561, Zielport: 20801
Wählen Sie ein Paket aus einem der Streams aus, und klicken Sie mit der rechten Maustaste auf das Paket.
Wählen Sie Decode As.. (Decodieren als) aus. und geben Sie RTP ein.
Klicken Sie auf Akzeptieren und OK, um den Stream als RTP zu decodieren.

Ein Stream wird als RTP decodiert, der andere als nicht codiertes UDP.
Wählen Sie ein Paket aus dem nicht codierten Stream aus, und decodieren Sie es als RTP. Dadurch werden Audio- und Videostreams in RTP dekodiert.

Hinweis: Der Audio-Stream hat das Codec-Format G.722, und der Payload-Typ Dynamic-RTP-97 gibt den Video-RTP-Stream an.

Das Problem besteht nun nur noch in der Videoqualität. Konzentrieren Sie sich auf den Video-RTP-Stream, und verwenden Sie die UDP-Portnummern für diesen Stream, um andere Streams herauszufiltern.
Zeigen Sie die Portnummer an, indem Sie eines der Pakete auswählen, das im Wireshark-Dienstprogramm im unteren Bereich die UDP-Portinformationen anzeigt. Im vorherigen Screenshot wird eines der Pakete aus dem Video-Stream ausgewählt. Im unteren Bereich finden Sie die Informationen zu Src Port (20568) und Dst Port (20808).

Tipp: Verwenden Sie diesen Filter: (ip.src==192.168.10.146 && ip.dst==192.168.207.231) & (udp.port eq 20568 und udp.port eq 20808 ). In diesem Screenshot wird nur der Video-RTP-Stream angezeigt.

Hinweis: Notieren Sie die ersten und letzten RTP-Sequenznummern für diesen Stream.

Die erste RTP-Sequenznummer ist 45514, die letzte ist 50449 für den gefilterten Video-RTP-Stream.
Stellen Sie sicher, dass das erste und das letzte RTP-Sequenzzahlpaket in beiden Captures vorhanden sind (z. B. in der Zentrale und in der Zweigstelle), und beachten Sie, dass das SSRC für den Stream in beiden Captures identisch ist.
Der Filter kann so angepasst werden, dass nur die Pakete zwischen dem ersten und dem letzten RTP-Stream übereinstimmen.

Die Sequenznummern werden zur Optimierung des Streams verwendet, falls die Aufnahmen nicht gleichzeitig, sondern mit geringer Verzögerung zwischen den Aufnahmen durchgeführt werden.

Hinweis: Es ist möglich, dass der Zweigstellen-Standort einige Sequenznummern nach 4514 startet.
Wählen Sie eine Start- und eine Endsequenznummer aus. Diese Pakete befinden sich sowohl in den Erfassungen als auch in der Optimierung des Filters, sodass nur die Pakete zwischen der Start- und der End-RTP-Sequenznummer angezeigt werden. Der Filter hierfür ist:
```
(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 )
```
Wenn gleichzeitig Erfassungen durchgeführt werden, werden bei beiden Erfassungen keine Pakete am Anfang oder Ende verpasst. Wenn Sie sehen, dass eine der Erfassungen nicht wenige Pakete am Anfang/Ende enthält, verwenden Sie die erste Sequenznummer oder die letzte Sequenznummer in der Erfassung, die in beiden Paketen verpasst wurde, um den Filter für beide Erfassungen zu verfeinern. Beobachten Sie die Pakete, die an beiden Punkten zwischen denselben Sequenznummern erfasst wurden (RTP-Sequenznummernbereich).

Wenn Sie den Filter anwenden, sehen Sie dies an der Zentrale und in der Zweigstelle:

Zentrale Website:

Zweigstelle:

Beachten Sie die Anzahl gefilterter Pakete im unteren Bereich des Wireshark-Dienstprogramms für beide Erfassungen. Die angezeigte Anzahl gibt die Anzahl der Pakete an, die den gewünschten Filterkriterien entsprechen.

Der zentrale Standort verfügt über 4.936 Pakete, die zwischen dem Start (4514) und dem Ende (50449) der RTP-Sequenznummern den gewünschten Filterkriterien entsprechen, während es in der Außenstelle nur 4.737 Pakete gibt. Dies weist auf einen Verlust von 199 Paketen hin. Beachten Sie, dass diese 199 Pakete mit der Anzahl der "Rcvr Lost Pkts" von 199 übereinstimmen, die in der Streaming-Statistik des IP-Telefons der Außenstelle zu sehen war, die am Anfang dieses Dokuments gezeigt wurde.

Dies bestätigt, dass alle verlorenen Rcvr-Pakete tatsächlich Netzwerkverluste im WAN verursacht haben. Auf diese Weise wird der Punkt des Paketverlusts im Netzwerk isoliert, während Probleme mit der Audio-/Videoqualität bei mutmaßlichen Netzwerkverlusten auftreten.