Verstehen von Jitter in Packet Voice Networks (Cisco IOS-Plattformen)
Inhalt
Einführung
In diesem Dokument werden Jitter und deren Messung und Ausgleich beschrieben.
Voraussetzungen
Anforderungen
Die Leser dieses Dokuments sollten folgende Themen kennen:
-
Grundlegende Cisco IOS®-Sprachkonfiguration
-
Grundlegendes Verständnis von Quality of Service (QoS)
Verwendete Komponenten
Die Informationen in diesem Dokument gelten für Cisco IOS Voice Gateways und Router.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
Jitter in Packet Voice Networks
Jitter wird als Variation der Verzögerung empfangener Pakete definiert. Auf der Senderseite werden Pakete in einem kontinuierlichen Stream gesendet, wobei die Pakete gleichmäßig verteilt sind. Aufgrund von Netzwerküberlastungen, ungeeigneten Warteschlangen oder Konfigurationsfehlern kann dieser stetige Stream langsam werden, oder die Verzögerung zwischen den einzelnen Paketen kann variieren, anstatt konstant zu bleiben.
Dieses Diagramm zeigt, wie ein stetiger Paketstrom verarbeitet wird.
Wenn ein Router einen Real-Time Protocol (RTP)-Audio-Stream für Voice over IP (VoIP) empfängt, muss er den aufgetretenen Jitter kompensieren. Der Mechanismus, der diese Funktion behandelt, ist der Playout-Verzögerungspuffer. Der Play-Out-Verzögerungspuffer muss diese Pakete puffern und anschließend in einem stetigen Stream an die digitalen Signalprozessoren (DSPs) übertragen, um sie in einen analogen Audio-Stream zurückkonvertieren zu können. Der Wiedergabepuffer wird auch als De-Jitter-Puffer bezeichnet.
Dieses Diagramm veranschaulicht den Umgang mit Jitter.
Wenn der Jitter so groß ist, dass er Pakete aus dem Bereich dieses Puffers empfängt, werden die Pakete außerhalb der Reichweite verworfen, und im Audio werden Verwerfungen ausgegeben. Bei Verlusten, die so klein wie ein Paket sind, interpoliert der DSP, was er für die Audioübertragung hält und kein Problem hörbar ist. Wenn der Jitter das überschreitet, was der DSP tun kann, um die fehlenden Pakete auszugleichen, sind Audioprobleme zu hören.
Dieses Diagramm veranschaulicht, wie exzessiver Jitter behandelt wird.
Bestimmen des Schweregrads von Jitter
Durch Ausführung dieser Schritte kann das Vorhandensein von übermäßigem Jitter durch Cisco IOS bestätigt werden.
-
Sobald ein Anruf aktiv ist und Jitter vermutet wird, wird Telnet zu einem der beteiligten Gateways weitergeleitet.
-
Aktivieren Sie Terminal Monitor, um Konsolenmeldungen über Ihre Telnet-Sitzung anzeigen zu können.
Hinweis: Dieser Schritt ist nicht erforderlich, wenn Sie an den Konsolenport angeschlossen sind.
-
Geben Sie den Befehl show voice call summary ein. Eine ähnliche Ausgabe wird angezeigt:
PORT CODEC VAD VTSP STATE VPM STATE ============ ======== === ==================== ====================== 1/0/0 - - - FXSLS_ONHOOK 1/0/1 g729r8 y S_CONNECT FXSLS_CONNECT
Wählen Sie den Anruf aus, bei dem der Jitter auftritt. In diesem Beispiel ist es 1/0/1.
-
Geben Sie den Befehl show voice call ein, um diesen Anruf anzuzeigen.
In diesem Beispiel wird der Sprachanruf 1/0/1 angezeigt. Die Ausgabe stammt vom DSP, der den Anruf verarbeitet, und ähnelt der folgenden:
1/0/1 vtsp level 0 state = S_CONNECT vpm level 1 state = FXSLS_CONNECT vpm level 0 state = S_UP MS-2621-3B# ***DSP VOICE VP_DELAY STATISTICS*** Clk Offset(ms): 0, Rx Delay Est(ms): 50 Rx Delay Lo Water Mark(ms): 50, Rx Delay Hi Water Mark(ms): 7 ***DSP VOICE VP_ERROR STATISTICS*** Predict Conceal(ms): 0, Interpolate Conceal(ms): 0 Silence Conceal(ms): 0, Retroact Mem Update(ms): 0 Buf Overflow Discard(ms): 0, Talkspurt Endpoint Detect Err: 0 ***DSP VOICE RX STATISTICS*** Rx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: 0 Rx Dur(ms): 150200, Rx Vox Dur(ms): 23740, Rx Fax Dur(ms): 0 Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0 Rx Early Pkts: 0, Rx Late Pkts: 0 ***DSP VOICE TX STATISTICS*** Tx Vox/Fax Pkts: 7129, Tx Sig Pkts: 0, Tx Comfort Pkts: 0 Tx Dur(ms): 150200, Tx Vox Dur(ms): 14259, Tx Fax Dur(ms): 0 ***DSP VOICE ERROR STATISTICS*** Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0 ***DSP LEVELS*** TDM Bus Levels(dBm0): Rx -54.5 from PBX/Phone, Tx -64.7 to PBX/Phone TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +9.9 TDM Bgd Levels(dBm0): -49.4, with activity being voice -
Zeigen Sie den Abschnitt ***DSP VOICE VP_ERROR STATISTICS*** in der Ausgabe an.
In diesem Abschnitt gibt es mehrere Parameter zum Betrachten. Die Hauptangabe ist die Anzahl der Buf Overflow Discard (ms), die angezeigt wird. Dabei werden die Pakete berücksichtigt, die außerhalb des Bereichs für den Playout-Verzögerungspuffer (verworfen) liegen. Dies kann einen gewissen Wert haben, solange es nicht ständig zunimmt. Es ist normal, dass bei der ersten Initiierung eines Anrufs einige Überläufe auftreten. Dieser Wert sollte jedoch nicht größer werden, wenn der Befehl show voice call X/X/X wiederholt wird. Diese Zahl ist ein direkter Hinweis auf übermäßigen Jitter.
Standardmäßig wird dieser Puffer in einem adaptiven Modus ausgeführt, bei dem er sich dynamisch an die Anzahl der vorhandenen Jitter anpasst (bis zu einem Punkt). Konfigurieren Sie den Befehl play-out-delay, um die Standardeinstellungen für das dynamische Verhalten des De-Jitter-Puffers zu ändern. Dieser Puffer kann auch im festen Modus eingestellt werden. Dies kann einige Probleme mit Jitter beheben. Weitere Informationen finden Sie unter Verbesserungen bei der Playout-Verzögerung für Voice-over-IP.
Was verursacht Jitter?
Jitter wird im Allgemeinen durch eine Überlastung des IP-Netzwerks verursacht. Die Überlastung kann entweder an den Router-Schnittstellen oder in einem Provider- oder Carrier-Netzwerk auftreten, wenn die Leitung nicht richtig bereitgestellt wurde.
Überlegungen zur Kapselung
Die einfachste und beste Stelle, um nach Jitter zu suchen, ist die Router-Schnittstelle, da Sie direkt die Kontrolle über diesen Teil der Schaltung haben. Wie Sie die Quelle des Jitters ermitteln, hängt in hohem Maße von der Kapselung und dem Link ab, auf dem der Jitter auftritt. In der Regel treten bei ATM-Schaltkreisen bei korrekter Konfiguration aufgrund der verwendeten konstanten Zellfrequenz keine Jitter auf. Dadurch wird eine sehr konsistente Latenz erreicht. Wenn in einer ATM-Umgebung Jitter auftritt, ist eine Prüfung der ATM-Konfiguration erforderlich. Wenn der Geldautomat korrekt funktioniert (keine verlorenen Zellen), können Sie erwarten, dass Jitter kein Problem ist. Bei der PPP-Kapselung (Point-to-Point Protocol) ist Jitter fast immer auf Serialisierungsverzögerungen zurückzuführen. Dies kann problemlos mithilfe von Link Fragmentation and Interleaving auf der PPP-Verbindung verwaltet werden. PPP-Endpunkte kommunizieren also direkt miteinander, ohne dass ein Netzwerk von Switches zwischen ihnen vorhanden ist. Dadurch hat der Netzwerkadministrator die Kontrolle über alle beteiligten Schnittstellen.
Jitter in Frame-Relay-Umgebungen
Drei Parameter müssen adressiert werden, um Jitter in einer Frame-Relay-Umgebung zu finden:
Beispielkonfigurationen und Informationen zur Konfiguration dieser Konfiguration finden Sie unter VoIP over Frame Relay with Quality of Service.
Traffic Shaping
Sie müssen sicherstellen, dass Sie den Datenverkehr, der den Router zu der vom Carrier bereitgestellten tatsächlichen Committed Information Rate (CIR) überträgt, selbst gestalten. Überprüfen Sie dies anhand der Frame Relay-Statistiken, und wenden Sie sich an den Carrier. Der erste Blick richtet sich an die Statistiken zum Frame-Relay. Verwenden Sie den Befehl show frame-relais pvc xx, wobei xx die DLCI-Nummer (Data-Link Connection Identifier) ist. Sie sollten eine ähnliche Ausgabe erhalten:
PVC Statistics for interface Serial0/1 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1 input pkts 103611 output pkts 120054 in bytes 9909818 out bytes 10962348 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 1366 out bcast bytes 448048 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 22:45:57, last time pvc status changed 22:45:57 Queueing strategy: weighted fair Current fair queue configuration: Discard Dynamic Reserved threshold queue count queue count 64 16 0 Output queue size 0/max total 600/drops 18303 fragment type end-to-end fragment size 1600 cir 20000 bc 1000 be 0 limit 125 interval 50 mincir 20000 byte increment 125 BECN response no IF_CONG no frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120 shaping active traffic shaping drops 18303
Eine vollständige Erläuterung aller Felder finden Sie in der Beschreibung zum show frame-relais pvc.
Worauf sollten Sie achten?
Bei der Befehlsausgabe sollten die Werte berücksichtigt werden, die anzeigen, ob im Frame-Netzwerk eine Überlastung aufgetreten ist. Bei diesen Werten handelt es sich um die Forward Explicit Congestion Notification (FECN), die Backward Explicit Congestion Notification (BECN), und die zulässigen Parameter werden verworfen. Sie sollten sich nur um Eingabepakete kümmern, da Cisco keine dieser Pakete sendet. Sie sehen möglicherweise einen oder mehrere dieser Werte inkrementiert. Dies hängt vom Typ und der Konfiguration der Frame-Switches ab, die der Anbieter verwendet. Wenn Frame Relay Traffic Shaping vorhanden ist und für dieselbe CIR wie der Circuit konfiguriert ist, sollten diese Werte niemals erhöht werden. Wenn Sie diese Werte inkrementieren und mit der tatsächlichen CIR des Schaltkreises übereinstimmen, ist etwas im Netzwerk des Frame-Providers nicht richtig konfiguriert.
Ein gutes Beispiel hierfür ist der Erwerb einer CIR-Schaltung ohne CIR-Unterstützung, jedoch mit einem Burst-Wert. Einige Anbieter verkaufen den CIR-Permanent Virtual Circuit (PVC) ohne CIR. Dies ist in Ordnung für Daten, verursacht aber Probleme bei der Sprachqualität. Wenn Sie die Befehlsausgabe aus einem CIR-Schaltkreis Null betrachten, entspricht die Anzahl der DE- oder FECN-Pakete der Anzahl der Eingangspakete. Wenn Sie eine PVC-Karte mit 128 Kbit/s und 512 Kbit/s für die CIR-Adresse des Routers haben, sehen Sie diese Zählerinkrementierung (langsamer), um diesen Schritt weiter zu gehen. Denken Sie daran, dass Sie nur Pakete betrachten, die an die Router-Schnittstelle gesendet werden, und dass diese Rate durch die Traffic-Shaping-Parameter gesteuert wird, die auf dem Router am anderen Ende der PVC konfiguriert sind. Umgekehrt steuern Sie, welche Datenverkehrsgestaltungsparameter am lokalen Ende für den anderen Router konfiguriert werden.
Es ist sehr wichtig, dass Sie die CIR für die vom Carrier bereitgestellte PVC nicht überschreiten. Sie können sich unter dieser CIR befinden, ohne Probleme zu haben. Wenn Sie diese jedoch überschreiten, wird es zu Überlastung kommen.
Der Grund für die Überlastung ist, dass die CIR, die für eine bestimmte PVC auf einem Frame-Switch konfiguriert ist, die Übertragungsrate für den Datenverkehr durch diesen Switch vorgibt (für diese PVC). Wenn die konfigurierte CIR auf dem Frame-Switch durch die tatsächliche Datenrate überschritten wird, müssen die Frames, die die CIR überschreiten, gepuffert werden, bis die Kapazität für die Weiterleitung der gepufferten Pakete verfügbar ist. Jedes gepufferte Paket erhält entweder das DE-Bit-Set oder das FECN-Bit, das vom Frame-Switch festgelegt wird.
Wie immer sollten Sie auch die Schnittstellenstatistiken genau untersuchen und nach Verwerfungen oder Fehlern suchen, um sicherzustellen, dass alle Komponenten auf der physischen Ebene korrekt funktionieren. Verwenden Sie dazu den Befehl show interface (Benutzeroberfläche anzeigen).
In Bezug auf Jitter haben diese Pakete eine höhere Latenz beim Erreichen des Remote-Routers, wenn sie im Frame-Netzwerk gepuffert werden müssen. Wenn jedoch keine Überlastung auftritt, wird die Latenzzeit erreicht, die normalerweise erwartet wird. Dies führt zu einer Schwankung der Delta-Zeit zwischen Paketen, die am Remote-Router empfangen werden. Daher Jitter.
Fragmentierung
Durch die Fragmentierung wird der Serialisierungsverzögerung mehr zugeordnet als Jitter. Unter bestimmten Umständen kann es jedoch zu Jitter kommen. Fragmentierung sollte immer in der Frame-Relay-Map-Klasse konfiguriert werden, wenn Sprachpakete verwendet werden. Die Konfiguration dieses Parameters hat zwei Auswirkungen auf die Schnittstelle. Der erste Effekt besteht darin, dass alle Pakete, die größer als die angegebene Größe sind, fragmentiert sind. Der zweite Effekt ist weniger offensichtlich, aber genauso wichtig. Wenn Sie sich die Schnittstelle ansehen, auf der die Fragmentierung konfiguriert ist, können Sie die Auswirkungen dieses Befehls sehen. Ohne Fragmentierung zeigt die in der Ausgabe des Befehls show interface x dargestellte Warteschlangenstrategie, dass die erste Warteschlange (FIFO) verwendet wird. Nachdem die Fragmentierung auf die Frame-Relay-Zuordnungsklasse angewendet wurde, zeigt die Ausgabe dieses Befehls die Warteschlangenstrategie als Dual-FIFO an. Dadurch wird die Prioritätswarteschlange erstellt, die für Sprachdatenverkehr auf der Schnittstelle verwendet wird. Es wird dringend empfohlen, den Fragmentierungswert auf die Werte festzulegen, die im Abschnitt Fragmentierung des VoIP over Frame Relay mit QoS empfohlen werden. Wenn Sie immer noch Jitter-Probleme mit dem empfohlenen Wert feststellen, reduzieren Sie den Fragmentierungswert Schritt für Schritt, bis die Sprachqualität akzeptabel wird.
Warteschlangenverwaltung
In dieser Art von Umgebung werden zwei allgemein akzeptierte Warteschlangenmethoden für VoIP-Datenverkehr verwendet:
Die eine oder die andere Methode sollte verwendet werden. Sie sollten nicht beide konfiguriert werden. Wenn die Warteschlangenoperation gemäß der Dokumentation korrekt aussieht, können Sie daraus schließen, dass die Warteschlange ordnungsgemäß funktioniert und das Problem an anderer Stelle liegt. Warteschlangen sind im Allgemeinen keine Jitter-Ursache, da die durch sie verursachten Verzögerungsvariationen relativ gering sind. Wenn VoIP-Pakete jedoch nicht ordnungsgemäß in die Warteschlange gestellt werden und Daten auf demselben Schaltkreis vorhanden sind, kann Jitter zu einem Ergebnis führen.
Schlussfolgerung
Jitter ist eine Variante der Paketlatenz für Sprachpakete. Die DSPs im Router können Jitter kompensieren, können aber durch übermäßigen Jitter überwunden werden. Dies führt zu einer schlechten Sprachqualität. Die Ursache für Jitter ist, dass ein Paket irgendwo in der Leitung in die Warteschlange gestellt oder verzögert wird, ohne dass Verzögerungen oder Warteschlangen für andere Pakete auftraten. Dies führt zu einer Schwankung der Latenz. Jitter kann sowohl durch eine fehlerhafte Router-Konfiguration als auch durch eine fehlerhafte PVC-Konfiguration durch den Carrier oder Anbieter verursacht werden.
Feedback