Fehlerbehebung: Probleme mit der QoS-Verkabelung

Einleitung

Damit Packet Voice ein realistischer Ersatz für herkömmliche Telefondienste über ein öffentliches Telefonnetz (PSTN) ist, muss die Empfangsqualität von Packet Voice mit der Qualität der grundlegenden Telefondienste vergleichbar sein. Dies bedeutet eine durchgängig hochwertige Sprachübertragung. Wie andere Echtzeitanwendungen verfügt auch Packet Voice über eine breite Bandbreite und ist verzögerungsempfindlich. Damit Sprachübertragungen für den Empfänger verständlich (nicht abgehackt) sind, können Sprachpakete nicht verworfen werden, übermäßig verzögert werden oder unterschiedliche Verzögerungen erleiden (auch als Jitter bezeichnet). In diesem Dokument werden verschiedene Quality of Service (QoS)-Aspekte beschrieben, die bei der Behebung von Problemen mit abgehackten Sprachfunktionen helfen. Die Hauptgründe für abgehackte Sprachprobleme sind verlorene und verzögerte Sprachpakete.

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten über folgende Kenntnisse verfügen:

• Grundlegende Konfiguration von Packet Voice (VoIP, Voice over Frame Relay (VoFR) oder Voice over ATM (VoATM) nach Bedarf).

• Grundlegendes Verständnis von Sprachpriorisierung, Fragmentierung, verschiedenen Codecs und deren Bandbreitenanforderungen.

Verwendete Komponenten

Die Informationen in diesem Dokument gelten für alle Software- und Hardwareversionen der Cisco Sprach-Gateways.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn sich Ihr Netzwerk in der Produktionsumgebung befindet, müssen Sie sich bei jedem Befehl zunächst dessen potenzielle Auswirkungen vor Augen führen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Ursachen für abgehackte Stimme

Eine abgehackte Sprachqualität wird durch eine variable Verzögerung oder einen Verlust von Sprachpaketen im Netzwerk verursacht. Wenn ein Sprachpaket sein Ziel verspätet erreicht, gehen die Echtzeitinformationen des Ziel-Gateways verloren. In diesem Fall muss das Ziel-Gateway den Inhalt des verpassten Pakets vorhersagen. Die Prädiktion führt dazu, dass die empfangene Sprache nicht die gleichen Eigenschaften wie die übertragene Sprache aufweist. Dies führt zu einer empfangenen Stimme, die robotisch klingt. Verzögert sich ein Sprachpaket über die Vorhersagefähigkeit eines empfangenden Gateways hinaus, lässt das Gateway die Echtzeitlücke leer. Ohne diese Lücke auf der Empfangsseite zu füllen, geht ein Teil der übertragenen Sprache verloren. Das Ergebnis ist eine abgehackte Stimme. Viele der abgehackten Sprachprobleme werden behoben, indem sichergestellt wird, dass die Sprachpakete nicht sehr verzögert (und mehr noch, nicht variabel verzögert) werden. Manchmal fügt die Sprachaktivitätserkennung (Voice Activity Detection, VAD) einem Sprachgespräch Front-End-Clipping hinzu. Dies ist eine weitere Ursache für abgehackte (oder abgeschnittene) Stimme.

In den verschiedenen Abschnitten dieses Dokuments wird erläutert, wie Sie das Auftreten abgehackter Stimmen minimieren. Für die meisten dieser Maßnahmen muss ein Mindestmaß an Jitter in Ihrem Sprachnetzwerk gewährleistet sein.

Bandbreitenanforderung

Bevor Sie Maßnahmen zur Minimierung von Jitter ergreifen, stellen Sie eine ausreichende Netzwerkbandbreite bereit, um den Echtzeit-Sprachdatenverkehr zu unterstützen. Ein G.711-VoIP-Anruf mit 80 Kbit/s (Payload von 64 Kbit/s + Header von 16 Kbit/s) klingt bei einer 64-Kbit/s-Verbindung beispielsweise schlecht, da mindestens 16 Kbit/s der Pakete (das sind 20 Prozent) verworfen werden. Die Bandbreitenanforderungen variieren je nach dem für die Komprimierung verwendeten Codec. Verschiedene Codecs haben unterschiedliche Payloads und Header-Anforderungen. Die Verwendung von VAD wirkt sich auch auf die Bandbreitenanforderung aus. Wenn Real Time Protocol (RTP) Header Compression (cRTP) verwendet wird, kann dies die Bandbreitenanforderung weiter senken.

Die erforderliche Bandbreite für Sprachanrufe über den G.729-Codec (Standard-Payload von 20 Byte) mit cRTP beträgt beispielsweise:

• Sprachnutzlast + komprimiert (RTP-Header + User Datagram Protocol (UDP)-Header + IP-Header) + Layer-2-Header

Dies entspricht:

• 20 Bytes + komprimiert (12 Bytes + 8 Bytes + 20 Bytes) + 4 Bytes

Dies entspricht:

• 28 Byte, da durch die Header-Komprimierung der IP-RTP-Header auf ein Maximum von 4 Byte reduziert wird. Das ergibt 11,2 Kbit/s bei einer Codec-Rate von 8 Kbit/s (50 Pakete pro Sekunde).

Weitere Informationen finden Sie unter Voice over IP - Per Call Bandwidth Consumption (Bandbreitennutzung pro Anruf).

Priorität des Sprachdatenverkehrs

Die Priorisierung von Sprache umfasst zwei wichtige Komponenten. Die erste besteht in der Klassifizierung und Kennzeichnung von interessantem Sprachdatenverkehr. Der zweite besteht in der Priorisierung des markierten interessanten Sprachdatenverkehrs. In den beiden Unterabschnitten werden verschiedene Ansätze zum Klassifizieren, Markieren und Priorisieren von Sprache behandelt.

Klassifizierung und Kennzeichnung

Um Bandbreite für VoIP-Pakete zu garantieren, muss ein Netzwerkgerät in der Lage sein, die Pakete im gesamten IP-Datenverkehr, der sie durchfließt, zu identifizieren. Netzwerkgeräte verwenden die Quell- und Ziel-IP-Adresse im IP-Header oder die Quell- und Ziel-UDP-Portnummern im UDP-Header, um VoIP-Pakete zu identifizieren. Dieser Identifizierungs- und Gruppierungsprozess wird als Klassifizierung bezeichnet. Sie stellt die Grundlage für die Bereitstellung von QoS dar.

Die Paketklassifizierung kann prozessorintensiv sein. Daher muss die Klassifizierung so weit wie möglich in Richtung Netzwerk-Edge erfolgen. Da jeder Hop weiterhin eine Entscheidung über die Behandlung treffen muss, die ein Paket erhalten soll, benötigen Sie eine einfachere, effizientere Klassifizierungsmethode im Netzwerkkern. Diese einfachere Klassifizierung wird durch Markieren oder Festlegen des Type of Service (ToS)-Bytes im IP-Header erreicht. Die drei höchstwertigen Bits des ToS-Bytes werden als IP Precedence Bits bezeichnet. Die meisten Anwendungen und Anbieter unterstützen derzeit die Einstellung und Erkennung dieser drei Bit. Die Markierung wird so weiterentwickelt, dass die sechs signifikantesten Bits des ToS-Byte, der Differentiated Services Code Point (DSCP), verwendet werden können. Weitere Informationen finden Sie unter Request for Comments (RFC).

Differentiated Services (DiffServ) ist ein neues Modell, bei dem der Datenverkehr von Zwischensystemen mit relativen Prioritäten behandelt wird, die auf dem ToS-Feld basieren. Der in RFC 2474 und RFC 2475definierte DiffServ-Standard ersetzt die ursprüngliche Spezifikation zur Definition der Paketpriorität, die in RFC 791beschrieben wurde. DiffServ erhöht die Anzahl der definierbaren Prioritätsstufen, indem Bits eines IP-Pakets zur Prioritätsmarkierung neu zugewiesen werden. Die DiffServ-Architektur definiert das DiffServ-Feld. Es ersetzt das ToS-Byte in IP V4, um Per-Hop Behaviour (PHB)-Entscheidungen hinsichtlich der Paketklassifizierung und der Verarbeitung des Datenverkehrs zu treffen, wie z. B. Messungen, Marking, Shaping und Richtlinienvergabe. Zusätzlich zu den zuvor erwähnten RFCs definiert RFC 2597 die Assured Forwarding (AF)-Klassen. Dies ist eine Aufteilung der DSCP-Felder. Weitere Informationen zu DSCP finden Sie unter Implementing Quality of Service Policies with DSCP.

ToS Byte - P2 P1 P0 T3 T2 T1 T0 CU

IP-Rangfolge: drei Bit (P2-P0), ToS: vier Bit (T3-T0), CU: ein Bit

DiffServ-Feld - DS5 DS4 DS3 DS2 DS1 DS0 ECN ECN

DSCP: sechs Bit (DS5-DS0), ECN: zwei Bit

XXX00000 Bits 0, 1, 2 (DS5, DS4, DS3) sind Prioritätsbits, wobei:

• 111 = Netzwerkkontrolle = Rangfolge 7

• 110 = Internetwork Control = Precedence 6

• 101 = KRITIK/ECP = Rangfolge 5

• 100 = Flash Override = Precedence 4

• 011 = Blitz = Rangfolge 3

• 010 = Sofort = Rangfolge 2

• 001 = Priorität = Rangfolge 1

• 000 = Routine = Rangfolge 0

000XXX00 Bits 3, 4, 5 (DS2, DS1, DS0) sind Delay-, Durchsatz- und Zuverlässigkeitsbits.

• Bit 3 = Verzögerung [D] (0 = Normal; 1 = Niedrig)

• Bit 4 = Durchsatz [T] (0 = Normal; 1 = hoch)

• Bit 5 = Zuverlässigkeit [R] (0 = Normal; 1 = hoch)

000000XX Bits 6, 7: ECN

In diesen beiden Abschnitten werden zwei Möglichkeiten für die Klassifizierung und Kennzeichnung beschrieben.

Voice Dial-Peers zum Klassifizieren und Markieren von Paketen

Bei Cisco VoIP-Gateways werden die VoIP-Pakete in der Regel mithilfe von Voice-Dial-Peers klassifiziert und die IP-Rangfolgebits markiert. Diese Konfiguration zeigt, wie die IP-Rangfolge markiert wird:

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip precedence 5

Im obigen Beispiel sind alle Sprachnutzdatenpakete eines VoIP-Anrufs, der mit dem Dial-Peer-Voice-100-VoIP-Befehl übereinstimmt, mit der IP-Rangfolge 5 festgelegt. Dies bedeutet, dass die drei höchstwertigen Bits des IP-ToS-Bytes auf 101 festgelegt sind.

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip qos dscp ef media
ip qos dscp af31 signaling

Im obigen Beispiel werden bei jedem VoIP-Anruf, der mit dem Dial-Peer-Voice-100-VoIP-Befehl übereinstimmt, alle Medien-Nutzdatenpakete (Sprachpakete) mit dem Expedited Forwarding (EF)-Bitmuster 101110 gesetzt. Alle Signalisierungspakete werden mit dem AF-Bitmuster 011010 gesetzt.

Hinweis: Der Befehl ip qos dscp wird seit Version 12.2(2)T der Cisco IOS® Software unterstützt. In Version 12.2T der Cisco IOS Software ist die IP Precedence-Funktion nicht mehr verfügbar. Dasselbe wird jedoch mit dem Befehl ip qos dscp erreicht. Die IP-Rangfolge 5 (101) ist IP DSCP 101000 zugeordnet. Weitere Informationen finden Sie unter Klassifizieren von VoIP-Signalisierung und Medien mit DSCP für QoS.

Modulare QoS-CLI zum Klassifizieren und Markieren von Paketen

Die empfohlene Klassifizierungs- und Markierungsmethode ist die modulare QoS-CLI. Dabei handelt es sich um eine vorlagenbasierte Konfigurationsmethode, die die Klassifizierung von der Richtlinie trennt. Auf diese Weise können mehrere QoS-Funktionen für mehrere Klassen gemeinsam konfiguriert werden. Verwenden Sie einen class-map-Befehl, um Datenverkehr anhand verschiedener Abgleichskriterien zu klassifizieren, und einen policy-map-Befehl, um zu bestimmen, was mit den einzelnen Klassen geschehen soll. Wenden Sie die Richtlinie auf eingehenden oder ausgehenden Datenverkehr an einer Schnittstelle an, indem Sie den Befehl service-policy eingeben. Dieses Konfigurationsbeispiel zeigt die Verwendung der modularen QoS-CLI zum Klassifizieren und Markieren von Paketen:

access-list 100 permit udp any any range 16384 32767
access-list 101 permit tcp any any eq 1720
!
class-map match-all voip
match access-group 100
class-map match-all control
match access-group 101
!
policy-map mqc
class voip
set ip precedence 5
class control
set ip precedence 5
class class-default
set ip precedence 0
!
interface Ethernet0/0
service-policy input mqc

In diesem Konfigurationsbeispiel wird jeder Datenverkehr, der mit der Zugriffskontrollliste (ACL) 100 übereinstimmt, als "class voip" klassifiziert und mit der IP-Rangfolge 5 festgelegt. Dies bedeutet, dass die drei höchstwertigen Bits des IP-ToS-Bytes auf 101 festgelegt sind. Die ACL 100 entspricht den von VoIP verwendeten allgemeinen UDP-Ports. Ebenso stimmt die ACL 101 mit dem H.323-Signalisierungsverkehr überein (Transmission Control Protocol (TCP) Port 1720). Der gesamte andere Datenverkehr wird mit der IP Precedence 0 festgelegt. Die Richtlinie wird als "mqc" bezeichnet. Er wird auf eingehenden Datenverkehr über Ethernet 0/0 angewendet.

Priorisierung

Nachdem jeder Hop im Netzwerk in der Lage ist, die VoIP-Pakete zu klassifizieren und zu identifizieren (entweder über Port-/Adressinformationen oder über das ToS-Byte), stellen diese Hops jedem VoIP-Paket die erforderliche QoS bereit. Konfigurieren Sie an diesem Punkt spezielle Techniken für die Einrichtung von Prioritätswarteschlangen, um sicherzustellen, dass große Datenpakete die Sprachdatenübertragung nicht beeinträchtigen. Dies ist in der Regel bei langsameren WAN-Verbindungen erforderlich, bei denen eine hohe Überlastungsgefahr besteht. Sobald der gesamte interessante Datenverkehr auf Basis der QoS-Anforderungen in QoS-Klassen eingeteilt wurde, stellen Sie Bandbreitengarantien bereit und stellen über einen intelligenten Warteschlangenmechanismus für die Ausgabe Prioritätsdienste bereit. Für VoIP ist eine Prioritätswarteschlange erforderlich.

Anmerkung:  Verwenden Sie jeden Warteschlangenmechanismus, der VoIP effektiv hohe Priorität einräumt. Es wird jedoch empfohlen, Low Latency Queuing (LLQ) durchzuführen, da es flexibel und einfach zu konfigurieren ist.

LLQ verwendet die modulare QoS-CLI-Konfigurationsmethode, um bestimmten Klassen Priorität einzuräumen und eine garantierte Mindestbandbreite für andere Klassen bereitzustellen. Während Zeiten der Überlastung wird die Richtlinie für die Prioritätswarteschlange mit der konfigurierten Geschwindigkeit ausgeführt, sodass der Prioritätsdatenverkehr nicht die gesamte verfügbare Bandbreite beansprucht. (Wenn der vorrangige Datenverkehr ein Monopol auf die Bandbreite hat, wird verhindert, dass Bandbreitengarantien für andere Klassen erfüllt werden.) Wenn Sie LLQ korrekt bereitstellen, sollte der Datenverkehr, der in die Prioritätswarteschlange gelangt, niemals die konfigurierte Rate überschreiten.

LLQ ermöglicht außerdem die Festlegung von Warteschlangentiefen, um zu bestimmen, wann der Router Pakete verwerfen muss, wenn in einer bestimmten Klassenwarteschlange zu viele Pakete warten. Es gibt auch einen class-default-Befehl, der verwendet wird, um die Behandlung des gesamten Datenverkehrs zu bestimmen, der nicht durch eine konfigurierte Klasse klassifiziert ist. Die Standardklasse wird mit dem Befehl fair-queue konfiguriert. Dies bedeutet, dass jedem nicht klassifizierten Fluss ein ungefähr gleicher Anteil der verbleibenden Bandbreite zugewiesen wird.

Dieses Beispiel zeigt, wie LLQ konfiguriert wird. Weitere Informationen finden Sie unter Low Latency Queuing:

access-list 100 permit udp any any range 16384 32000
access-list 101 permit tcp any any eq 1720
access-list 102 permit tcp any any eq 80
access-list 103 permit tcp any any eq 23
!
class-map match-all voip
match access-group 100
class-map match-all voip-control
natch access-group 101
class-map match-all data1
match access-group 102
class-map match-all data2
match access-group 103
!
policy-map llq
class voip
priority 32
class voip-control
bandwidth 8
class data1
bandwidth 64
class data2
bandwidth 32
class class-default
fair-queue
!
interface Serial1/0
bandwidth 256
service-policy output llq

In diesem Beispiel wird jeder Datenverkehr, der mit ACL 100 übereinstimmt, als "Class VoIP" (Sprachdatenverkehr) klassifiziert. Er erhält eine hohe Priorität von bis zu 32 Kbit/s. ACL 100 entspricht den von VoIP verwendeten gemeinsamen UDP-Ports. Die Zugriffsliste 101 entspricht dem H.323-Signalisierungsverkehr (TCP-Port 1720). Class data1 stimmt mit dem Web-Datenverkehr überein (TCP-Port 80, siehe Zugriffsliste 102) und garantiert 64 Kbit/s. Class Data2 entspricht Telnet-Datenverkehr (TCP-Port 23, wie in ACL 103 gezeigt) und garantiert 32 Kbit/s. Die Standardklasse ist so konfiguriert, dass nicht klassifizierte Datenflüsse einen gleichen Anteil der verbleibenden Bandbreite erhalten. Die Richtlinie wird als "llq" bezeichnet. Sie wird auf ausgehenden Datenverkehr mit der Serial1/0-Schnittstelle angewendet, die eine Bandbreite von insgesamt 256 Kbit/s aufweist.

Hinweis: Standardmäßig muss die garantierte Gesamtbandbreite und Prioritätsbandbreite für alle Klassen weniger als 75 Prozent der Schnittstellenbandbreite betragen. Ändern Sie diesen Prozentsatz, indem Sie den Befehl max-reserved bandwidth interface (Schnittstelle für max-reservierte Bandbreite) eingeben.

In dieser Tabelle werden die verschiedenen Warteschlangenmechanismen der Software mit ihren jeweiligen Vorteilen und Einschränkungen verglichen.

Warteschlangenmechanismus für Software	Beschreibung	Vorteile	Einschränkungen
FIFO (First-In-First-Out)	Pakete kommen an und verlassen die Warteschlange in genau derselben Reihenfolge.	Einfache Konfiguration und schnelle Bedienung.	Keine vorrangigen Serviceleistungen oder Bandbreitengarantien möglich.1
Weighted Fair Queuing (WFQ)	Ein Hashing-Algorithmus, der in separate Warteschlangen fließt, in denen die Anzahl der gleichzeitig verarbeiteten Pakete anhand von Gewichtungen bestimmt wird. Sie definieren Gewichtungen, indem Sie die IP-Rangfolge und die DSCP-Werte festlegen.	Einfache Konfiguration. Standard für Verbindungen unter 2 Mbit/s.	Keine vorrangigen Serviceleistungen oder Bandbreitengarantien möglich.1
Benutzerdefiniertes Queuing (CQ)	Der Datenverkehr wird anhand konfigurierbarer Warteschlangengrenzen in mehrere Warteschlangen klassifiziert. Die Warteschlangenbeschränkungen werden auf der Grundlage der durchschnittlichen Paketgröße, der Maximum Transmission Unit (MTU) und des Prozentsatzes der zuzuweisenden Bandbreite berechnet. Warteschlangenbegrenzungen (in Byte) werden für jede Warteschlange aus der Warteschlange entfernt. Daher wird die zugewiesene Bandbreite statistisch bereitgestellt.	Seit einigen Jahren verfügbar. Sie ermöglicht die ungefähre Bandbreitenzuweisung für verschiedene Warteschlangen.	Eine vorrangige Wartung ist nicht möglich. Die Bandbreitengarantien sind Näherungswerte. Es gibt eine begrenzte Anzahl von Warteschlangen. Konfiguration ist relativ schwierig.1
Priority Queuing (PQ)	Der Datenverkehr wird in Warteschlangen mit hoher, mittlerer, normaler und niedriger Priorität klassifiziert. Der Datenverkehr mit hoher Priorität wird zuerst verarbeitet, gefolgt von Datenverkehr mit mittlerer, normaler und niedriger Priorität.	Seit einigen Jahren verfügbar. Es bietet vorrangige Wartung.	Durch Datenverkehr mit höherer Priorität wird die Bandbreite der Warteschlangen mit niedrigerer Priorität eingeschränkt. Es sind keine Bandbreitengarantien möglich.2
Class-Based Weighted Fair Queuing (CBWFQ)	Die modulare QoS-CLI dient zur Klassifizierung des Datenverkehrs. Der klassifizierte Datenverkehr wird in reservierte Bandbreitenwarteschlangen oder eine nicht reservierte Standardwarteschlange gestellt. Ein Scheduler bedient die Warteschlangen auf der Grundlage von Gewichtungen, sodass die Bandbreitengarantien eingehalten werden.	Ähnlich wie LLQ, mit dem Unterschied, dass es keine Prioritätswarteschlange gibt. Einfache Konfiguration und Bandbreitengarantien	Eine vorrangige Wartung ist nicht möglich.3
Priority Queue Weighted Fair Queuing (PQ-WFQ), auch als IP RTP Priority bezeichnet	Mit einem einzigen Schnittstellenbefehl wird die Prioritätswartung für alle UDP-Pakete bereitgestellt, die für gerade Portnummern innerhalb eines bestimmten Bereichs bestimmt sind.	Einfache Konfiguration mit nur einem Befehl Prioritätswartung für RTP-Pakete	Der restliche Datenverkehr wird mit WFQ verarbeitet. Der RTCP-Datenverkehr (Real-Time Conferencing Protocol) wird nicht priorisiert. Keine garantierte Bandbreitenleistung.4
LLQ (Priority Queue Class-Based Weighted Fair Queuing, PQCBWFQ)	Die modulare QoS-CLI mit Prioritätswarteschlange dient zur Klassifizierung des Datenverkehrs. Der klassifizierte Datenverkehr wird einer Prioritätswarteschlange, reservierten Bandbreitenwarteschlangen oder einer nicht reservierten Standardwarteschlange zugewiesen. Ein Scheduler bedient die Warteschlangen anhand von Gewichtungen, sodass der Prioritätsverkehr zuerst gesendet wird (bis zu einem bestimmten Grenzwert bei Überlastung) und die Bandbreitengarantien erfüllt werden.	Einfache Konfiguration. Möglichkeit, mehreren Datenverkehrsklassen Priorität einzuräumen und die Bandbreitennutzung zu begrenzen. Sie können auch bandbreitengarantierte Klassen und eine Standardklasse konfigurieren.	Es gibt noch keinen Mechanismus für die Bereitstellung mehrerer Prioritätsebenen, da der gesamte Prioritätsdatenverkehr über dieselbe Prioritätswarteschlange gesendet wird. Separate Prioritätsklassen können während einer Überlastung separate Bandbreitengrenzen mit höherer Priorität haben. Die gemeinsame Nutzung von Prioritätswarteschlangen durch mehrere Anwendungen kann jedoch zu Jitter führen.4

1. Nicht geeignet für Sprache.

2. Garantierte Bandbreite für Sprachanwendungen

3. Wartezeiten müssen berücksichtigt werden.

4. Ausreichend für Sprachkommunikation.

Serialisierungsverzögerung

Selbst wenn die Warteschlange optimal funktioniert und Sprachverkehr priorisiert, kann es vorkommen, dass die Prioritätswarteschlange leer ist und ein Paket einer anderen Klasse verarbeitet wird. Pakete aus garantierten Bandbreitenklassen müssen auf Basis ihrer konfigurierten Gewichtung verarbeitet werden. Wenn ein priorisiertes Sprachpaket in der Ausgabewarteschlange ankommt, während diese Pakete verarbeitet werden, kann das Sprachpaket eine beträchtliche Zeit warten, bevor es gesendet wird. Bei Sprachpaketen treten Serialisierungsverzögerungen auf, wenn sie hinter größeren Datenpaketen warten müssen.

Eine Serialisierungsverzögerung kann bei Sprachpaketen die schlimmste Form von Jitter verursachen. Wenn die Sprachpakete hinter einem Datenpaket von bis zu 1500 Byte auf einer langsameren Verbindung warten müssen, bedeutet dies eine enorme Verzögerung. Die Serialisierungsverzögerung unterscheidet sich erheblich, wenn das Datenpaket 80 Byte umfasst, wie in diesem Beispiel gezeigt:

• Serialisierungsverzögerung auf einer 64-Kbit/s-Verbindung aufgrund eines 1500-Byte-Pakets = 1500*8/64000 = 187,5 ms.

• Serialisierungsverzögerung auf einer 64-Kbit/s-Verbindung aufgrund eines 80-Byte-Pakets = 80*8/64000 = 10 ms.

Daher muss ein Sprachpaket potenziell bis zu 187,5 ms warten, bevor es gesendet wird, wenn es hinter einem einzelnen 1500-Byte-Paket auf einer 64-Kbit/s-Verbindung stecken bleibt. Andererseits muss ein anderes Sprachpaket am Ziel-Gateway nur 10 ms warten. Dies führt zu einem enormen Jitter, der aufgrund der unterschiedlichen Paketverzögerungen auftritt. Auf dem ursprünglichen Gateway werden Sprachpakete in der Regel alle 20 ms gesendet. Bei einem End-to-End-Verzögerungsbudget von 150 ms und strengen Jitter-Anforderungen ist eine Lücke von mehr als 180 ms nicht akzeptabel.

Einführung eines Fragmentierungsmechanismus, der sicherstellt, dass eine Übertragungseinheit kleiner als 10 ms ist. Pakete mit einer Serialisierungsverzögerung von mehr als 10 ms müssen in 10 ms-Blöcke fragmentiert werden. Ein 10-ms-Block oder -Fragment ist die Anzahl der Bytes, die über die Verbindung in 10 ms gesendet werden. Berechnen Sie die Größe mithilfe der Verbindungsgeschwindigkeit, wie in diesem Beispiel gezeigt:

• Fragmentierungsgröße = (0,01 Sekunden * 64.000 Bit/s) / (8 Bit/Byte) = 80 Byte

Das Senden eines 80-Byte-Pakets oder -Fragments über eine 64-Kbit/s-Verbindung dauert 10 ms.

Bei mehreren ATMs oder Frame Relay Permanent Virtual Circuits (PVCs) auf einer einzigen physischen Schnittstelle müssen Sie die Fragmentierungswerte (auf allen PVCs) auf der Basis des PVC mit der geringsten verfügbaren Bandbreite konfigurieren. Wenn es beispielsweise drei PVCs mit einer garantierten Bandbreite von 512 Kbit/s, 128 Kbit/s und 256 Kbit/s gibt, konfigurieren Sie alle drei PVCs mit einer Fragmentgröße von 160 Byte (die niedrigste Geschwindigkeit beträgt 128 Kbit/s, für die eine Fragmentgröße von 160 Byte erforderlich ist). Diese Werte werden für unterschiedliche Verbindungsgeschwindigkeiten empfohlen:

Link Speed (kbps)         Fragmentation Size (bytes) 
56                                  70 
64                                  80 
128                                 160 
256                                 320 
512                                 640 
768                                 960 
1024                                1280 
1536                                1920

Hinweis: Wenn die Fragmentgröße größer als die Verbindungs-MTU-Größe ist, ist keine Fragmentierung erforderlich. Für eine T1-Verbindung mit einer MTU von 1.500 Byte beträgt die Fragmentgröße beispielsweise 1.920 Byte. Daher ist keine Fragmentierung erforderlich. Die Größe der Paketfragmentierung sollte niemals kleiner als die VoIP-Paketgröße sein. Fragmentieren Sie VoIP-Pakete nicht. Eine Fragmentierung dieser Pakete verursacht zahlreiche Probleme bei der Anrufeinrichtung und -qualität.

Derzeit stehen drei Mechanismen für die Fragmentierung und Verschachtelung von Verbindungen zur Verfügung. Weitere Erläuterungen zu verschiedenen Verzögerungen in einem Paketnetzwerk finden Sie unter Understanding Delay in Packet Voice Networks. In dieser Tabelle sind die jeweiligen Vorteile und Einschränkungen aufgeführt:

LFI-Mechanismus (Link Fragmentation and Interleaving)	Beschreibung	Vorteile	Einschränkungen
MTU-Fragmentierung mit WFQ	Befehl auf Schnittstellenebene zum Ändern der MTU-Größe oder der IP-MTU-Größe. Wird verwendet, um große IP-Pakete auf die angegebene MTU-Größe zu fragmentieren. LFI verwendet WFQ, um Echtzeitpakete zwischen den Fragmenten zu verschachteln.	Einfache Konfiguration.	Fragmente werden nur von der empfangenden Anwendung wieder zusammengesetzt. Daher ineffiziente Nutzung des Netzwerks. Nur IP-Pakete, bei denen das DF-Bit (Do Not Fragment) nicht gesetzt ist, können die Fragmentierung gut handhaben. Sehr prozessorintensiv. Nicht empfohlen.
Multilink Point-to-Point Protocol (MLPPP)-LFI	Auf seriellen Point-to-Point-Verbindungen muss zunächst MLPPP konfiguriert werden, dann muss eine Fragmentierungsgröße in ms festgelegt werden. Interleaving muss auch auf der Multilink-Schnittstelle aktiviert sein.	Pakete werden an einem Ende des Links fragmentiert und am anderen wieder zusammengesetzt. Mehrere Verbindungen können als große virtuelle Pipe kombiniert werden.	Nur für Verbindungen verfügbar, die für PPP konfiguriert sind. Lösungen für PPP over Frame Relay oder PPP over ATM werden ebenfalls von der Cisco IOS Software, Version 12.1(5)T oder höher, unterstützt.
Frame-Relay-Fragmentierung (FRF.12)	Auf Frame-Relay-PVCs muss der Frame-Relay-Traffic-Shaping-Befehl aktiviert und unter "map-class" eine Fragmentierungsgröße festgelegt werden.	Die Pakete werden an einem Ende des PVC fragmentiert und am anderen wieder zusammengesetzt.	Nur auf Frame-Relay-PVCs mit aktiviertem Frame-Relay-Traffic-Shaping-Befehl verfügbar.

VAD

Ein normales Sprachgespräch besteht aus mehreren Momenten der Stille. Ein typisches Sprachgespräch besteht aus 40 bis 50 Prozent Stille. Da für 40 Prozent eines Sprachanrufs keine Sprachverbindungen über das Netzwerk übertragen werden, kann durch die Bereitstellung von VAD Bandbreite eingespart werden. Bei VAD sucht das Gateway nach Sprachlücken. Es ersetzt diese Lücken durch Komfortgeräusche (Hintergrundgeräusche). Dadurch wird eine Menge an Bandbreite eingespart. Es gibt jedoch einen Zielkonflikt. Es gibt eine kurze Zeit (in der Größenordnung von Millisekunden), bevor die Codecs Sprachaktivität erkennen, gefolgt von einer Phase der Stille. Diese geringe Zeit führt zum Front-End-Clipping der empfangenen Sprache. Um eine Aktivierung während sehr kurzer Pausen zu vermeiden und das Clipping zu kompensieren, wartet VAD nach Sprachstopps ca. 200 ms, bevor die Übertragung gestoppt wird. Beim Neustart der Übertragung werden die vorherigen 5 ms Sprache zusammen mit der aktuellen Sprache verwendet. VAD deaktiviert sich bei einem Anruf automatisch, wenn Umgebungsgeräusche verhindern, dass es zwischen Sprach- und Hintergrundgeräuschen unterscheidet. Wenn die Bandbreite kein Problem darstellt, deaktivieren Sie das VAD.

VAD-Parameter anpassen

Es gibt zwei Parameter, die die Funktion von VAD bestimmen. Dies sind die Musik-Schwellwert- und Sprach-Vad-Time-Befehle.

musikalische Schwelle

Es wird ein anfänglicher Schwellenwert festgelegt, der bestimmt, wann die VAD aktiv werden muss. Dies wird durch Definieren des Befehls music-threshold threshold_value auf einem Sprach-Port gesteuert, wie in diesem Beispiel gezeigt. Der Bereich hierfür liegt zwischen -70 Dezibel pro Milliwatt (dBm) und -30 dBm. Der Standardwert hierfür ist -38 dBm. Wenn Sie einen niedrigeren Wert einstellen (bis -70 dBm), wird VAD bei einer viel niedrigeren Signalstärke aktiviert (die Lautstärke muss wirklich niedrig sinken, bevor sie als Stille angesehen wird). Wenn Sie einen höheren Wert (näher bei -30 dBm) konfigurieren, wird VAD auch bei einem geringen Rückgang der Sprachsignalstärke aktiviert. Es treibt die Wiedergabe, um Komfort-Geräuschpakete öfter spielen. Dies führt jedoch manchmal zu einem geringfügigen Abschneiden von Audio.

3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#music-threshold ?
WORD Enter a number b/w (-70 to -30)
3640-6(config-voiceport)#music-threshold -50
3640-6(config-voiceport)#end
3640-6#
3640-6#show run | be voice-portvoice-port 3/0/0 music-threshold -50

Voice Vad Time

Sobald das VAD aktiviert ist, wird die Komponente von Hintergrundgeräuschen und Komfortgeräuschen durch Konfigurieren des Befehls voice vad-time timer_value unter der globalen Konfiguration gesteuert, wie in diesem Beispiel gezeigt. Dies ist die Verzögerungszeit in Millisekunden für die Pausenerkennung und Unterdrückung der Sprachpaketübertragung. Der Standardwert für die Haltezeit beträgt 250 ms. Das bedeutet, dass innerhalb von 250 msec Komfortgeräusche einsetzen. Der Bereich für diesen Zeitgeber liegt zwischen 250 ms und 65536 ms. Wird dafür ein hoher Wert eingestellt, kommt viel später Komfortgeräusch ins Spiel (Hintergrundgeräusch wird weiterhin abgespielt). Wenn dies für 65536 ms konfiguriert ist, wird das Komfortgeräusch ausgeschaltet. Für einen sanfteren Übergang zwischen Hintergrundgeräusch und Komfortgeräusch ist ein höherer Wert für diesen Timer erwünscht. Der Nachteil bei der Konfiguration des Sprach-VAD-Zeit-Befehls auf eine hohe Ebene ist, dass die gewünschte Bandbreiteneinsparung von 30 bis 35 Prozent nicht erreicht wird.

3640-6#
3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice vad-time ?
<250-65536> milliseconds
3640-6(config)#voice vad-time 750
3640-6(config)#end
3640-6#
3640-6#
3640-6#
3640-6#show run | be vad-time voice vad-time 750

Typische Konfigurationsbeispiele für QoS

Ein typisches Szenario für die Einrichtung von VoIP-Gesprächen findet entweder über eine Frame-Relay-Verbindung oder eine PPP-Verbindung statt. Dies sind Konfigurationsbeispiele für diese Szenarien.

VoIPoFR - QoS-Konfigurationsbeispiel

In diesem Beispiel (das nur relevante Ausschnitte der Konfiguration enthält) wird angenommen, dass die Frame-Relay-Schaltungsgeschwindigkeit 256 kbps beträgt. Die garantierte Committed Information Rate (CIR) für PVC 100 beträgt 64 kbps und für PVC 200 192 kbps. PVC 100 wird für die Übertragung von Daten und Sprache verwendet. PVC 200 wird nur für die Übertragung von Daten verwendet. Es können jeweils maximal vier Anrufe gleichzeitig getätigt werden. Konfigurieren Sie die Fragmentierung auf beiden PVCs basierend auf der CIR des Sprach-PVCs mit der niedrigsten Bandbreite. Basierend auf den Beispielen in diesem Dokument bedeutet dies, dass die Fragmentierungsgröße auf der CIR-Stufe von PVC 100 (64 Kbit/s) festgelegt wird. Wie in der Tabelle im Abschnitt zur Serialisierungsverzögerung dargestellt, ist für eine 64-Kbit/s-Verbindung eine Fragmentierungsgröße von 80 Byte erforderlich. Dieselbe Fragmentierungsgröße muss für PVC 200 konfiguriert werden.

Weitere Einzelheiten zur Konfiguration von VoIP over Frame Relay finden Sie unter VoIP over Frame Relay with Quality of Service (Fragmentation, Traffic Shaping, LLQ/IP RTP Priority).

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoFR
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Serial4/0:0
bandwidth 256
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial4/0:0.1 point-to-point
bandwidth 64
ip address 10.10.10.10 255.255.255.0
frame-relay ip rtp header-compression
frame-relay interface-dlci 100
 class voice
!
interface Serial4/0:0.2 point-to-point
bandwidth 192
ip address 20.20.20.20 255.255.255.0
frame-relay interface-dlci 200
class data
!
map-class frame-relay data
frame-relay fragment 80
frame-relay adaptive-shaping becn
frame-relay cir 256000
frame-relay bc 32000
frame-relay be 0
frame-relay mincir 192000
frame-relay fair-queue
!
map-class frame-relay voice
frame-relay fragment 80
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 640
frame-relay be 0
frame-relay mincir 64000
service-policy output VoIPoFR
!
!
access-list 101 permit tcp any any eq 1720
!
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1

VoIP over PPP - QoS-Konfigurationsbeispiel

In diesem Beispiel (das nur relevante Konfigurationsabschnitte enthält) wird davon ausgegangen, dass die QoS für einen Punkt-zu-Punkt-T1-Kontroller (der zwölf Kanäle hat) konfiguriert werden muss. Es können jeweils maximal vier Anrufe gleichzeitig getätigt werden. Die Konfigurationsaufgabe umfasst die Konfiguration dieser seriellen Schnittstelle mit PPP-Kapselung, die Umwandlung dieser Schnittstelle in eine Multilink-Gruppe, die Erstellung einer Multilink-Schnittstelle (die zu derselben Multilink-Gruppe gehört) und die Konfiguration der gesamten QoS auf der Multilink-Schnittstelle. Weitere Informationen zur Konfiguration von VoIP über PPP finden Sie unter VoIP über PPP Links with Quality of Service (LLQ / IP RTP Priority, LFI, cRTP).

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoPPP
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Multilink7
bandwidth 768
ip address 10.10.10.10 255.255.255.0
ip tcp header-compression iphc-format
service-policy output VoIPoPPP
no cdp enable
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 7
ip rtp header-compression iphc-format
!
!
interface Serial4/0:0
bandwidth 768
no ip address
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 7
!
!
access-list 101 permit tcp any any eq 1720
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1
!

Jitter- und Playout-Mechanismus

Es gibt immer einige unkontrollierte Einheiten in einem Netzwerk, die zu weiteren Verzögerungen und Jitter in den empfangenen Sprachpaketen beitragen. Durch die Änderung des Jitter-Puffers auf dem Abschluss-Gateway wird der unkontrollierte Jitter im Sprachnetzwerk behoben.

Playout-Mechanismus

Der Jitter-Puffer ist ein Zeitpuffer. Er wird durch das Abschlussgateway bereitgestellt, um die Abspielmechanik effektiver zu gestalten. Dies ist ein Funktionsdiagramm des Ausspielmechanismus:

Wenn die Wiedergabesteuerung ein Sprachpaket empfängt, analysiert sie den RTP-Zeitstempel. Verzögert sich das Sprachpaket über die Haltekapazität des Jitter-Puffers hinaus, wird das Paket sofort verworfen. Wenn sich das Paket innerhalb der Pufferkapazität befindet, wird es in den Jitter-Puffer verschoben. Die Position dieses Pakets im Jitter-Puffer hängt vom für das Paket berechneten RTP-Zeitstempel ab. Falls kein Sprachpaket verfügbar ist, versucht die Wiedergabesteuerung, es zu verbergen (sagt das verpasste Paket voraus). Wenn VAD aktiviert ist, wird ein Komfortgeräusch wiedergegeben.

Die Verantwortung der Wiedergabesteuerung besteht darin, die Ereignisse von verlorenen Paketen, duplizierten Paketen, beschädigten Paketen und nicht sequenzierten Paketen zu verarbeiten. Diese Ereignisse werden durch die zeitliche Ausrichtung der Jitter-Sprachpakete, die Wiedergabe von Komfort-Geräuschen (falls VAD konfiguriert ist) oder sogar die Regeneration von DTMF-Tönen (Dual Tone Multifrequency), die an den Host ausgegeben werden sollen, behandelt.

Das Verbergen eines Sprachpakets erfolgt entweder durch Verbergen von Prognosen oder durch Verbergen von Pausen. Die Vorhersageverschleierung basiert auf dem vorherigen Paket und dem nächsten Paket (falls verfügbar). Es funktioniert am besten mit Codecs mit niedriger Bitrate (5 Kbit/s bis 16 Kbit/s). Der Verlust von Sprachpaketen für einen Codec mit hoher Bitrate (32 Kbit/s bis 64 Kbit/s) kann möglicherweise zu einem Verbergen der Prognose führen. Bei geringen und seltenen Verzögerungen oder einer geringeren Anzahl an Paketverlusten beginnt die Vorhersage zu verschleiern. Ein zu hohes Maß an Verschleierung der Prognosen kann zu einer Qualität der Roboterstimme führen. Schweigen Verheimlichung ist die schlimmste Form der Vorhersage Verheimlichung. Sie kommt ins Spiel, wenn keine Informationen verfügbar sind, die man vorhersagen kann. Es ist einfach eine Hintergrunderkundung. Er beginnt, wenn es zu großen Verzögerungen und einer höheren Anzahl an Paketverlusten kommt. Zu viel Stille und Verschleierung führen zu abgehackter Sprachqualität. Die Vorhersage Verbergen ist gut für 30 msec, nach dem die Stille Verbergen ins Spiel kommt.

Jitter-Puffer

Der Jitter-Puffer wird durch eine hohe und eine niedrige Wassermarke begrenzt. Das Hochwasserzeichen ist die obere Zeitgrenze, innerhalb derer ein Paket erwartet wird, um pünktlich ausgespielt zu werden. Pakete, die nach der Wassermarke eintreffen, werden als verspätete Pakete oder verlorene Pakete markiert. Die Niedrigwassermarke ist die minimale Zeit, innerhalb der ein Paket erwartet wird, um pünktlich ausgespielt zu werden. Pakete, die vor der Wassermarke ankommen, werden als frühe Pakete angesehen (sie können noch pünktlich ausgespielt werden).

Wenn das terminierende Gateway bei der Ankunft verspäteter Pakete weiterhin einen inkrementellen Anstieg erkennt, erhöht dies die Wassermarke. Dieser Wert für die Wassermarke bleibt während der gesamten Dauer des Anrufs gleich. Dieser Wert wird bis zu einem in der Konfiguration definierten Maximum erhöht. In ähnlicher Weise beobachtet das terminierende Gateway die Anzahl der frühzeitig empfangenen Pakete. Wenn diese Pakete das Gateway häufig nutzen, wird die Wassermangelrate reduziert. Dieser Wert bleibt während der gesamten Dauer des Anrufs gleich. Dieser Modus des Jitter-Puffers wird als "adaptiver Modus" bezeichnet, bei dem das terminierende Gateway seinen Jitter-Puffer anhand des Datenverkehrsmusters anpasst. Der andere Modus ist "fester Modus". Im Festmodus gibt es einen Anfangswert für die Niedrigwassermarke und die Hochwassermarke. Dieser Wert basiert auf der geschätzten empfangenen Verzögerung (siehe Abschnitt Show Voice Call <Port-Nummer> in diesem Dokument).

Weitere Informationen zu Jitter-Puffer finden Sie unter Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms).

Erkennung von Verzögerungen und Jitter

In diesem Abschnitt wird beschrieben, wie Sie Jitter in Ihrem Netzwerk identifizieren.

Anruf aktive Stimme anzeigen

Der Befehl show call active voice brief enthält zahlreiche Informationen zu einem laufenden Gespräch. In dieser Ausgabe werden einige wichtige Punkte angezeigt, die Sie von diesem Befehl gelernt haben:

11E4 : 2170927hs.1 +600 pid:10 Answer 1000 active
dur 00:08:43 tx:26157/522967 rx:7044/139565
Tele 3/0/0:9: tx:151310/755/0ms g729r8 noise:-62 acom:0 i/0:-56/-48 dBm
11E4 : 2171198hs.1 +329 pid:20 Originate 2000 active
dur 00:08:43 tx:7044/139565 rx:26165/523127
IP 30.30.30.29:18682 rtt:51ms pl:148590/290ms lost:0/0/15 delay:65/60/132ms g729r8

Aus der Ausgabe des Befehls show call active voice brief wird angezeigt, dass alles, was auf der Telefonie-Verbindung (rx:7044) empfangen wird, an die IP-Verbindung (tx:7044) übertragen wird. Dasselbe gilt für auf den IP-Zweigen (26165) empfangene Pakete, die an den Telefonie-Zweig (26157) weitergeleitet werden. Die Differenz zwischen der Anzahl der auf der IP-Strecke empfangenen Pakete und der Anzahl der auf der Telefonie-Strecke übertragenen Pakete ergibt sich aus verspäteten Paketen, die nicht rechtzeitig eintreffen.

Diese Ausgabe des Befehls show call active voice (ohne das Schlüsselwort "brief") verweist auf weitere Details zu Parametern, die Jitter direkt identifizieren.

GapFillWithSilence=850 ms
GapFillWithPrediction=9230 ms
GapFillWithInterpolation=0 ms
GapFillWithRedundancy=0 ms

show voice call <Portnummer>

Der Befehl show voice call port-number liefert nützliche Informationen. Stellen Sie sicher, dass Sie entweder im Gateway installiert sind, oder dass Sie, wenn Sie über Telnet mit einem Gateway verbunden sind, den Befehl terminal monitor von der Führungsebene ausgegeben haben.

Hinweis: Dieser Befehl ist auf den AS5x00-/AS5x50-Plattformen nicht verfügbar.

In dieser Ausgabe ist der Wert für Rx Delay Est (ms) 71. Dies ist der aktuelle Jitter-Pufferwert. Darauf wird ein Wert für die Hochwassermarke und die Niederwassermarke abgeleitet. Ein mittlerer Anfangswert für die Hochwassermarke beträgt 70 msec, während der für die Niedrigwassermarke 60 msec beträgt. Sobald ein Anfangswert festgelegt ist, verfolgt das Gateway alle empfangenen frühen oder verspäteten Pakete. Wie in der Ausgabe hier zu sehen ist, sind die Vorhersage Verbergen fällt in der Nähe von 250 ms, während die Stille Verbergen sind 30 ms. Es gibt immer einen höheren Wert für Vorhersage Verheimlichung, da Schweigen Verheimlichung ist nur ein schlimmeres Fall Szenario der Vorhersage Verheimlichung. Bei jedem Prediction Concealment Tropfen steigt der Pufferüberlauf.

Wenn Sie sehen, dass Puffer weggeworfen wird, bedeutet das nicht unbedingt, dass Sie eine Erhöhung der Wassermarke sehen. Die hohe Wassermarke ist die obere Grenze des Jitter-Puffers. Sie ändert sich nur, wenn ein Trend beobachtet wird. Mit anderen Worten, es sollte einen kontinuierlichen Strom verspäteter Pakete geben. Dadurch wird der Jitter-Puffer erhöht. In der hier vorliegenden Ausgabe liegt ein solcher Trend vor. Daher wird die Hochwassermarke von 70 msec auf 161 msec erhöht. Wenn dieser Wert nicht geändert wird (und Sie immer noch 14 verspätete Pakete sehen), impliziert dies, dass es sich um sporadische verspätete Pakete handelt, die keinen Trend darstellen.

Achten Sie an der Ausgabe des Befehls show call active voice auf verlorene Pakete. Für jedes verlorene Paket werden zwei Pakete angezeigt, die nicht in der richtigen Reihenfolge sind. Dies wird bei der Ausgabe von Rx Non-Seq Pkts angezeigt. Da es sich nicht um einen positiven Wert handelt, wird der Schluss gezogen, dass auch keine Paketverluste aufgetreten sind.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 195, Tx Sig Pkts: 0, Tx Comfort Pkts: 10
Tx Dur(ms): 192070, Tx Vox Dur(ms): 388, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 9604, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
Rx Dur(ms): 192070, Rx Vox Dur(ms): 191560, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 0, Rx Late Pkts: 14
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 71
Rx Delay Lo Water Mark(ms): 60, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 250, Interpolate Conceal(ms): 0
Silence Conceal(ms): 30, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 500, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -49.9 from PBX/Phone, Tx -41.7 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.1
TDM Bgd Levels(dBm0): -58.9, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

Beachten Sie die Tx Comfort Pkte und Rx Comfort Pkte. Aus den Beispielausgängen wird geschlossen, dass das an diesen Router angeschlossene Telefon größtenteils ruhig bleibt, da Sie viele Tx Comfort Pkte haben. Gleichzeitig haben Sie Null Rx Comfort Pkte, was bedeutet, dass das andere Ende ständig spricht.

Vergleichen Sie die Ausgabe hier mit der vorherigen Ausgabe. Es gibt eine erhöhte Anzahl von Rx Late Pkts (von 14 auf 26). Es erfolgt jedoch keine Erhöhung des Hochwassermarkenwertes. Dies zeigt an, dass die 12 Pakete sporadisch verzögert werden. Der Pufferüberlauf-Rückwurf wird auf 910 ms erhöht. Da jedoch keine Tendenz zu beobachten ist, wird die hohe Wassermarke nicht erhöht.

In der Ausgabe hier haben Sie ein Rx Early Pkts: 3. Das bedeutet, dass ein Paket viel früher eintrifft, als erwartet wird. Wie aus der Ausgabe hier zu sehen, hat sich der Jitter-Puffer gedehnt, um für weitere frühe Pakete durch die Verringerung der Niedrigwassermarke von 60 auf 51 aufnehmen.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 209, Tx Sig Pkts: 0, Tx Comfort Pkts: 11
Tx Dur(ms): 337420, Tx Vox Dur(ms): 416, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 16843, Rx Signal Pkts: 0, Rx Comfort Pkts: 1
Rx Dur(ms): 337420, Rx Vox Dur(ms): 335920, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 3, Rx Late Pkts: 26
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 72
Rx Delay Lo Water Mark(ms): 51, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 510, Interpolate Conceal(ms): 0
Silence Conceal(ms): 70, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 910, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -51.5 from PBX/Phone, Tx -44.1 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.9
TDM Bgd Levels(dBm0): -61.3, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

Jitter-Puffer auf einem Gateway konfigurieren

Die in diesem Dokument behandelten QoS-Richtlinien berücksichtigen das Problem der abgehackten oder verschlechterten Sprachqualität. Die Konfiguration des Playout-Verzögerungspuffers ist eine Problemumgehung für eine fehlerhafte QoS-Implementierung im Netzwerk. Verwenden Sie diesen Service nur zur Behebung von Unterbrechungen oder als Tool zur Fehlerbehebung und Eingrenzung der im Netzwerk auftretenden Jitter-Probleme.

Playout-Verzögerungsmodus

Der Jitter-Puffer wird für den Festmodus oder den adaptiven Modus konfiguriert. Im adaptiven Modus können Sie mit dem Gateway einen Minimalwert für den Jitter-Puffer, einen Maximalwert und einen Nominalwert konfigurieren. Der Jitter-Puffer erwartet, dass die Pakete innerhalb des Nennwertbereichs ankommen. Der Nominalwert muss entweder gleich oder größer als das Minimum und gleich oder kleiner als das Maximum sein. Der Puffer wird auf den konfigurierten Maximalwert erweitert. Dies kann bis zu 1700 ms reichen. Ein Problem bei der Konfiguration eines hohen Maximalwerts ist die Einführung einer End-to-End-Verzögerung. Wählen Sie den Wert für die maximale Wiedergabeverzögerung aus, sodass keine unerwünschten Verzögerungen im Netzwerk entstehen. Diese Ausgabe ist ein Beispiel für den Jitter-Puffer, der für den adaptiven Modus konfiguriert wurde:

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode adaptive
3640-6(config-voiceport)#playout-delay maximum 400
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#playout-delay minimum low
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay maximum 400
playout-delay nominal 70
playout-delay minimum low
playout-delay mode adaptive
!

Im Modus "Fixed" prüft das Gateway den konfigurierten Wert für "nominal". Obwohl es Ihnen erlaubt, den minimalen und maximalen Wert für die Wiedergabeverzögerung zu konfigurieren, wird es ignoriert, wenn es für den Festmodus konfiguriert ist. Im Festbetrieb bleibt der hohe Wassermarkierungswert bzw. der niedrige Wassermarkierungswert immer konstant. Er basiert auf dem Nominalwert und auf dem Rx-Verzögerungswert (ms). Es ist also möglich, dass Sie im Festmodus den Wert auf 200 ms konfigurieren. Liegt die geschätzte Empfangsverzögerung jedoch nahe bei 100 ms, wird dies für die gesamte Anrufdauer auf die High-Water-Marke und die Low-Water-Marke gesetzt.

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode fixed
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay mode fixed
playout-delay nominal 70
!

Weitere Informationen zur Konfiguration der Wiedergabeverzögerung finden Sie unter Playout Delay Enhancements for Voice over IP (Verbesserungen der Wiedergabeverzögerung für Voice-over-IP).

Zugehörige Informationen

• Implementieren von Quality-of-Service-Richtlinien mit DSCP
• Low Latency Queueing
• Vergleich der Bandbreiten- und Prioritätsbefehle einer QoS-Dienstrichtlinie
• Konfiguration der Link-Fragmentierung und des Interleaving für Frame-Relay- und ATM-Virtual Circuits
• Konfiguration der Link-Fragmentierung und des Interleaving für Multilink-PPP
• Sprachtechnologiesupport
• Produktsupport für Sprach- und Unified Communications
• Fehlerbehebung bei Cisco IP-Telefonie
• Technischer Support – Cisco Systems