Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

QoS-Designrichtlinien für VoIP over PPP-Links

Strict Priority für Sprachverkehr (IP RTP Priority oder LLQ)

LLQ-Konfigurationsrichtlinien

IP RTP Priority Configuration-Richtlinien

Link Fragmentation and Interleaving (LFI): Multilink PPP

Komprimiertes Real-Time Protocol (cRTP)

Weitere Tipps zur Bandbreitenreduzierung

Netzwerkdiagramm

Konfigurationen

Befehle zur Überprüfung und Fehlerbehebung

Beispielausgabe und Debugausgabe

Zugehörige Informationen

Einführung

In dieser Beispielkonfiguration wird ein VoIP mit Point-to-Point-Protokoll (PPP) über eine Leasing-Leitungskonfiguration mit niedriger Bandbreite untersucht. Dieses Dokument enthält technische Hintergrundinformationen zu den konfigurierten Funktionen, Designrichtlinien sowie grundlegende Verifizierungs- und Fehlerbehebungsstrategien.

Hinweis: In der unten stehenden Konfiguration ist zu beachten, dass die beiden Router Back-to-Back-Verbindungen über eine Mietleitung aufweisen. In den meisten Topologien können die sprachfähigen Router jedoch überall vorhanden sein. In der Regel verwenden die Sprach-Router LAN-Verbindungen zu anderen Routern, die mit dem WAN verbunden sind (d. h. eine PPP-Standleitung). Dies ist wichtig, da alle WAN-Konfigurationsbefehle auf den mit dem WAN verbundenen Routern und nicht auf den Sprach-Routern konfiguriert werden müssen, wenn die Sprach-Router nicht direkt über PPP über eine Mietleitung verbunden sind, wie in den nachfolgenden Konfigurationen gezeigt.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Die in diesem Dokument vorgestellten Konfigurationen wurden mit den folgenden Geräten getestet:

- Zwei Cisco 3640s mit Cisco IOS® Software Release 12.2.6a (IP Plus)

- IP RTP Priority wurde in Cisco IOS Release 12.0(5)T eingeführt.

- LLQ wurde in Cisco IOS Version 12.0(7)T eingeführt.

- LFI wurde in Cisco IOS Version 11.3 eingeführt.

- Cisco IOS-Versionen über 12.0.5T hinaus enthalten deutliche Leistungsverbesserungen für cRTP.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

QoS-Designrichtlinien für VoIP over PPP-Links

Dieser Abschnitt enthält Designrichtlinien für die Konfiguration von VoIP-over-PPP-Standleitungen (mit Schwerpunkt auf Verbindungen mit niedriger Geschwindigkeit). Es gibt zwei grundlegende Voraussetzungen für eine gute Sprachqualität:

- Minimale End-to-End-Verzögerung und Jittervermeidung (Verzögerungsschwankungen)

- Optimierte und korrekt konstruierte Anforderungen an die Verbindungsbandbreite

Um die oben genannten Anforderungen zu gewährleisten, sind mehrere wichtige Richtlinien zu beachten:

Leitlinie

Beschreibung

Strict Priority für Sprachverkehr (IP RTP Priority oder LLQ)

Methode zur Festlegung einer strikten Priorität für Sprachdatenverkehr.

Link Fragmentation and Interleaving (LFI)

Bei Verbindungen mit niedriger Geschwindigkeit kann es sich um eine obligatorische Anforderung handeln.

RTP-Komprimierung

Nicht erforderlich, um eine gute Sprachqualität bereitzustellen, sondern reduziert die Bandbreitennutzung. Die allgemeine Empfehlung zur RTP-Komprimierung besteht darin, sie nach einer funktionierenden Konfiguration mit guter Sprachqualität anzuwenden (vereinfacht die Fehlerbehebung).

Call Admission Control (CAC)

Nicht in diesem Dokument behandelt. CAC wird verwendet, um die Anzahl der Anrufe zu steuern, die über die Verbindung hergestellt werden können. Wenn beispielsweise die WAN-Verbindung zwischen den beiden Gateways über die erforderliche Bandbreite für die Übertragung von nur zwei VoIP-Anrufen verfügt, kann die Aufnahme eines dritten Anrufs die Sprachqualität aller drei Anrufe beeinträchtigen. Weitere Informationen finden Sie unter: VoIP-Anrufzugangskontrolle

Zusammenfassend sind für die Niedriggeschwindigkeits-PPP-Verbindung mit Router/Gateways als einzige Quelle für Sprachdatenverkehr zwei Funktionen erforderlich:

1. Strict Priority für Sprachverkehr

2. Link Fragmentation and Interleaving (LFI)

Strict Priority für Sprachverkehr (IP RTP Priority oder LLQ)

Ab Version 12.2 der Cisco IOS-Software gibt es zwei primäre Methoden, um dem Sprachdatenverkehr eine strikte Priorität einzuräumen:

- IP RTP Priority (auch PQ/WFQ genannt): Prioritätswarteschlange/Weighted Fair Queuing)

- Low Latency Queuing (auch PQ/CBWFQ genannt): Prioritätswarteschlange/Class-Based Weighted Fair Queuing).

IP RTP-Priorität

IP RTP Priority erstellt eine Warteschlange mit strikter Priorität für eine Reihe von RTP-Paketflüssen, die zu einem Bereich von UDP-Zielports (User Datagram Protocol) gehören. Während die tatsächlich verwendeten Ports dynamisch zwischen Endgeräten oder Gateways ausgehandelt werden, nutzen alle Cisco VoIP-Produkte denselben UDP-Portbereich (16384-32767). Sobald der Router den VoIP-Datenverkehr erkennt, wird er in die Warteschlange mit strikter Priorität gesetzt. Wenn die Prioritätswarteschlange leer ist, werden die anderen Warteschlangen gemäß dem Standard Weighted Fair Queuing (WFQ) verarbeitet. Die IP RTP-Priorität wird erst aktiviert, wenn eine Überlastung der Schnittstelle vorliegt. Dieses Bild veranschaulicht den Betrieb der IP-RTP-Priorität:

Hinweis: Die IP RTP-Priorität ermöglicht das Bursting der Prioritätswarteschlange (PQ), wenn in der Standardwarteschlange (WFQ) verfügbare Bandbreite verfügbar ist. Bei Überlastung der Schnittstelle wird jedoch der Inhalt der Prioritätswarteschlange strikt geregelt.

Low Latency Queuing

LLQ ist eine Funktion, die ein striktes PQ für Class-Based Weighted Fair Queuing (CBWFQ) bereitstellt. LLQ aktiviert einen einzigen strengen PQ innerhalb der CBWFQ auf Klassenebene. Bei LLQ werden verzögerungsempfindliche Daten (im PQ) zunächst in die Warteschlange gestellt und gesendet. In einem VoIP mit LLQ-Implementierung wird Sprachdatenverkehr in den strikten PQ gesetzt.

Der PQ wird so geregelt, dass sichergestellt wird, dass den fairen Warteschlangen keine Bandbreite fehlt. Wenn Sie den PQ konfigurieren, geben Sie in Kbit/s die maximale verfügbare Bandbreite für den PQ an. Wenn die Schnittstelle überlastet ist, wird der PQ so lange gewartet, bis die Last den konfigurierten Kbit/s-Wert in der Prioritätsanweisung erreicht. Der übermäßige Datenverkehr wird dann fallen gelassen, um das Problem zu vermeiden, dass bei der älteren Prioritätsgruppenfunktion von Cisco Warteschlangen mit niedrigerer Priorität nicht mehr verfügbar sind.

Diese Methode ist komplexer und flexibler als IP RTP Priority. Die Wahl zwischen den Methoden sollte auf den Datenverkehrsmustern in Ihrem tatsächlichen Netzwerk und Ihren tatsächlichen Anforderungen basieren.

LLQ und IP RTP-Priorität

In dieser Tabelle sind die wichtigsten Unterschiede zwischen der LLQ- und der IP-RTP-Priorität zusammengefasst und einige Richtlinien für die Verwendung der einzelnen Methoden aufgeführt.

Low Latency Queuing (LLQ)

IP RTP-Priorität

Sprachverkehr zuordnen basierend auf:

- Zugriffslisten (für UDP-Port-Bereich, Hostadressen, IP-Header-ToS-Felder: IP Precedence, DSCP und mehr)

- IP RTP-Port-Bereich

- IP ToS-Felder (Type of Service): DCSP und/oder IP Precedence

- Protokolle und Eingabeschnittstellen

- Alle gültigen Anpassungskriterien werden im CBWFQ verwendet.

Vorteile:

- Flexiblere Zuordnung des Datenverkehrs zum strikten PQ und CBWFQ

- Kann zusätzliche Klassen konfigurieren, um Bandbreite für anderen Datenverkehr sicherzustellen, z. B.: VoIP-Signalisierung und Video.

Nachteile:

- Komplexe Konfiguration

Sprachverkehr zuordnen basierend auf:

- Basierend auf dem RTP-UDP-Port-Bereich: 16384-32767

Vorteile:

- Einfache Konfiguration

Nachteile:

- RTCP-Datenverkehr (VoIP-Signalisierung) in WFQ-Warteschlange
Hinweis: Das RTP-Protokoll verwendet RTCP (Real Time Control Protocol), um die Übertragung von RTP-Paketen zu steuern. Während RTP-Ports gerade Zahlen verwenden, verwenden RTCP-Ports ungerade Nummern im Bereich von 16384 bis 32767. IP RTP Priority platziert RTP-Ports im PQ, während RTCP-Ports in der Standard Weighted Fair Queue (Standard-gewichtete Fair-Warteschlange) bedient werden.

- Dient für VoIP-Datenverkehr im PQ, aber jeder andere Datenverkehr, der eine bevorzugte Behandlung und Bandbreitengarantie erfordert, wird in WFQ bedient. WFQ kann zwar Datenflüsse mit Gewichtungen (basierend auf IP Precedence) differenzieren, kann jedoch keine Bandbreitengarantie für jeden Datenfluss gewährleisten.

Richtlinien

- Die Auswahl sollte auf den Datenverkehrsmustern in Ihrem Netzwerk und Ihren tatsächlichen Anforderungen basieren.

- Wenn Sie Ihrem Sprachdatenverkehr eine strikte Priorität einräumen müssen und anderer Datenverkehr als ein einziger Typ (Daten) behandelt werden kann, dann ist die IP RTP-Priorität eine gute Aufgabe für Ihr Netzwerk, und das mit einer einfachen Konfiguration.

- Wenn Sie den Sprachdatenverkehr anhand anderer Kriterien als UDP-Ports (z. B. DiffServ PHB) priorisieren möchten, ist LLQ erforderlich.

Weitere Informationen zur Korrelation und den Unterschieden von Warteschlangenmethoden finden Sie unter Übersicht über das Überlastungsmanagement.

LLQ-Konfigurationsrichtlinien

Befolgen Sie die folgenden Richtlinien für die Konfiguration von LLQ:

1. Erstellen einer Klassenzuordnung für VoIP-Datenverkehr und Festlegen von Zuordnungskriterien

In diesen Befehlen wird erklärt, wie diese Aufgabe ausgeführt wird:

maui-voip-sj(config)#class-map ?

WORD  class-map name

match-all  Logical-AND all matching statements under this classmap

match-any  Logical-OR all matching statements under this classmap

maui-voip-sj(config)#class-map match-all voice-traffic

!-- Choose a descriptive class_name.

maui-voip-sj(config-cmap)#match ?

access-group         Access group

any                  Any packets

class-map            Class map

cos                  IEEE 802.1Q/ISL class of service/user priority values

destination-address  Destination address

input-interface      Select an input interface to match

ip                   IP specific values

mpls                 Multi Protocol Label Switching specific values

not                  Negate this match result

protocol             Protocol

qos-group            Qos-group

source-address       Source address

!-- In this example, the access-group matching option is used for its !-- flexibility (it uses an access-list)

maui-voip-sj(config-cmap)#match access-group ?

<1-2699>  Access list index  name      Named Access List

maui-voip-sj(config-cmap)#match access-group 102

!-- Now, create the access-list to match the class-map access-group:

maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32776

!-- Safest and easiest way is to match with UDP port range 16384-32767 !-- This is the port range Cisco IOS H.323 products utilize to transmit !-- VoIP packets.

Diese Zugriffslisten können auch verwendet werden, um Sprachdatenverkehr mit dem Befehl match access-group abzustimmen:

access-list 102 permit udp any any precedence critical

!-- This list filters traffic based on the IP packet TOS: Precedence field.

!-- Note: Ensure that other non-voice traffic does NOT uses the

!-- same precedence value.

access-list 102 permit udp any any dscp ef

!-- In order for this list to work, ensure that VoIP packets are tagged with

!-- the dscp ef code before they exit on the LLQ WAN interface.

!-- For more information on DSCP refer to:

!-- Implementing Quality of Service Policies with DSCP

!-- Note: If endpoints are not trusted on their packet marking, you can mark

!-- incoming traffic by applying an inbound service policy on an inbound

!-- interface. This procedure is out of the scope of this doc.

Access-list 102 permit udp host 192.10.1.1 host 192.20.1.1

!-- This access-list can be used in cases where the VoIP devices cannot !-- do precedence or dscp marking and you cannot determine the !-- VoIP UDP port range.

Hierbei handelt es sich um andere Zuordnungsmethoden, die anstelle von Zugriffsgruppen verwendet werden können:

- Ab Cisco IOS Release 12.1.2.T wird die IP RTP Priority-Funktionalität für LLQ implementiert. Diese Funktion entspricht dem Inhalt der Prioritätsklasse, der die konfigurierten UDP-Ports betrachtet, und unterliegt der Einschränkung, dass nur Ports in der Hauptplatine bedient werden.

class-map voice

match ip rtp 16384 16383

- Bei diesen beiden Methoden wird davon ausgegangen, dass VoIP-Pakete auf den ursprünglichen Hosts markiert oder auf dem Router abgeglichen und markiert werden, bevor der ausgehende LLQ-Vorgang angewendet wird.

class-map voice

match ip precedence 5

oder

class-map voice

match ip dscp ef

Hinweis: Ab IOS Release 12.2.2T können VoIP-Dial-Peers Sprachpakete und Signalisierungspakete vor dem LLQ-Vorgang markieren. Dies ermöglicht eine skalierbare Kennzeichnung und Zuordnung von VoIP-Paketen über DSCP-Codewerte für LLQ.

2. Erstellen einer Klassenzuordnung für VoIP-Signalisierung und Festlegen von Zuordnungskriterien (optional)

In diesen Befehlen wird erklärt, wie diese Aufgabe ausgeführt wird:

class-map voice-signaling

match access-group 103

!

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

Hinweis: VoIP-Anrufe können über H.323, SIP, MGCP oder Skinny (proprietäres Protokoll, das von Cisco Call Manager verwendet wird) eingerichtet werden. Im obigen Beispiel wird von H.323 Fast Connect ausgegangen. Diese Liste dient als Referenz für die Ports, die von VoIP-Signalisierungs-/Steuerungskanälen verwendet werden:

- H.323/H.225 = TCP 1720

- H.323/H.245 = TCP 11xxx (Standard-Connect)

- H.323/H.245 = TCP 1720 (Fast Connect)

- H.323/H.225 RAS = TCP 1719

- Skinny = TCP 2000-2002 (CM Encore)

- ICCP = TCP 8001-8002 (CM-Encore)

- MGCP = UDP 2427, TCP 2428 (CM-Encore)

- SIP= UDP 5060, TCP 5060 (konfigurierbar)

3. Erstellen einer Richtlinienzuordnung und Zuordnen zu den VoIP-Klassenzuordnungen

Der Zweck der Richtlinienzuordnung besteht darin, festzulegen, wie die Link-Ressourcen für die verschiedenen Zuordnungsklassen freigegeben oder zugewiesen werden. In diesen Befehlen wird erklärt, wie diese Aufgabe ausgeführt wird:

maui-voip-sj(config)#policy-map VOICE-POLICY

!-- Choose a descriptive policy_map_name.

maui-voip-sj(config-pmap)#class voice-traffic

maui-voip-sj(config-pmap-c)#priority ?

<8-2000000>  Kilo Bits per second

!-- Configure the voice-traffic class to the strict priority !-- Queue (priority command) and assign the bandwidth.

maui-voip-sj(config-pmap)#class voice-signaling

maui-voip-sj(config-pmap-c)#bandwidth 8

!-- Assign 8 Kbps to the voice-signaling class

maui-voip-sj(config-pmap)#class class-default

maui-voip-sj(config-pmap-c)#fair-queue

!-- The remaining data traffic is treated as Weighted Fair Queue

Hinweis: Obwohl es möglich ist, verschiedene Arten von Echtzeit-Datenverkehr mit dem PQ in eine Warteschlange zu stellen, empfiehlt Cisco, nur Sprachdatenverkehr an diesen weiterzuleiten. Echtzeit-Datenverkehr, z. B. Videodaten, kann zu Schwankungen bei der Verzögerung führen (der PQ ist eine FIFO - First In First Out - Queue (FIFO - First In First Out - Warteschlange). Sprachdatenverkehr erfordert, dass die Verzögerung nicht variabel ist, um Jitter zu vermeiden.

Hinweis: Die Summe der Werte für Prioritäts- und Bandbreitenanweisungen muss kleiner/gleich 75 % der Verbindungsbandbreite sein. Andernfalls kann die Dienstrichtlinie nicht der Verbindung zugewiesen werden (um Fehlermeldungen anzuzeigen, stellen Sie sicher, dass die Protokollierungskonsole für den Konsolenzugriff aktiviert ist und der Terminalmonitor für den Telnet-Zugriff aktiviert ist).

Hinweis: Bei der Konfiguration von VoIP über eine 64-Kbit/s-Verbindung zur Unterstützung von zwei Sprachanrufen ist es üblich, mehr als 75 Prozent (48 Kbit/s) der Verbindungsbandbreite dem PQ zuzuweisen. In solchen Fällen können Sie mit dem Befehl max-reservierte Bandbreite 80 verwenden, um die verfügbare Bandbreite auf 80 Prozent (51 Kbit/s) zu erhöhen.

Weitere Informationen zu Bandbreite und Prioritätsbefehlen finden Sie unter Vergleichen der Bandbreiten- und Prioritätsbefehle einer QoS-Dienstrichtlinie.

4. LLQ aktivieren: Wenden Sie die Richtlinienzuordnung auf die ausgehende WAN-Schnittstelle an.

In diesen Befehlen wird erklärt, wie diese Aufgabe ausgeführt wird:

maui-voip-sj(config)#interface multilink 1

maui-voip-sj(config-if)#service-policy output VOICE-POLICY

!-- In this scenario (MLPPP LFI), the service policy is applied to !-- the Multilink interface.

IP RTP Priority Configuration-Richtlinien

Um die IP RTP-Priorität zu konfigurieren, verwenden Sie die folgenden Richtlinien:

- Router(config-if)#ip rtp priority starting-rtp-port-#port-#-rangebandwidth

Befehl

Beschreibung

starting-rtp-port-number

Untere Grenze des UDP-Ports. Die niedrigste Portnummer, an die die Pakete gesendet werden. Legen Sie für VoIP diesen Wert auf 16384 fest.

port-number-range

Der Bereich der UDP-Zielports. Eine Zahl, die der Start-RTP-Port-Nummer hinzugefügt wurde, ergibt die höchste UDP-Portnummer. Legen Sie für VoIP diesen Wert auf 16383 fest (32767 - 16384 = 16383).

bandwidth

Maximal zulässige Bandbreite (Kbit/s) in der Prioritätswarteschlange. Legen Sie diese Nummer entsprechend der Anzahl der gleichzeitigen Anrufe fest, die das System unterstützt.

Beispielkonfiguration:

interface Multilink1

!--- Some output omitted

bandwidth 64

ip address 172.22.130.2 255.255.255.252

ip tcp header-compression

fair-queue

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

ip rtp priority 16384 16383 45

Link Fragmentation and Interleaving (LFI): Multilink PPP

Während 1.500 Byte eine gemeinsame Größe für Datenpakete sind, kann ein typisches VoIP-Paket (das G.729-Sprach-Frames enthält) etwa 66 Byte (20 Byte Sprach-Nutzlast, 6 Byte Layer-2-Header, 20 Byte RTP- und UDP-Header und 20 Byte IP-Header) betragen.

Stellen Sie sich nun eine 56-Kbit/s-Mietleitung vor, bei der Sprach- und Datenverkehr gleichzeitig übertragen werden. Wenn ein Sprachpaket erst dann serialisiert werden kann, wenn ein Datenpaket über die Verbindung übertragen wird, besteht ein Problem. Das verzögerungsempfindliche Sprachpaket muss 214 ms warten, bevor es übertragen wird (die Serialisierung eines 1500-Byte-Pakets über eine 56-Kbit/s-Verbindung dauert 214 ms).

Wie Sie sehen können, können große Datenpakete die Bereitstellung kleiner Sprachpakete negativ verzögern und die Sprachqualität beeinträchtigen. Durch die Fragmentierung dieser großen Datenpakete in kleinere Datenpakete und die Verschmelzung von Sprachpaketen zwischen den Fragmenten werden Jitter und Verzögerungen reduziert. Die Cisco IOS Link Fragmentation and Interleaving (LFI)-Funktion unterstützt die Erfüllung der Echtzeitbereitstellungsanforderungen von VoIP. Dieses Bild veranschaulicht den Betrieb von LFI:

Wie in Tabelle 1 gezeigt, kann die Anzahl der Serialisierungsverzögerungen (die Zeit, die erforderlich ist, um die Bits auf eine Schnittstelle zu platzieren), die bei WAN-Verbindungen mit niedriger Geschwindigkeit eingeführt werden, erheblich sein, wenn man bedenkt, dass die End-to-End-Verzögerung für eine Richtung 150 ms nicht überschreiten darf. (Die ITU-T G.114-Empfehlung legt eine maximale unidirektionale Durchwahl von 150 ms fest.)

Tabelle 1: Serialisierungsverzögerung bei verschiedenen Frame-Größen bei Low-Speed-Links: Serialisierungsverzögerung = Frame-Größe (Bit)/Link-Bandbreite (bps)

1 Byte

64 Byte

128 Byte

256 Byte

512 Byte

1024 Byte

1500 Byte

56 Kbit/s

143 uns

9 ms

18 ms

36 ms

72 ms

144 ms

214 ms

64 Kbit/s

125 US

8 ms

16 ms

32 ms

64 ms

126 ms

187 ms

128 Kbit/s

62,5 uns

4 ms

8 ms

16 ms

32 ms

64 ms

93 ms

256 Kbit/s

31 uns

2 ms

4 ms

8 ms

16 ms

32 ms

46 ms

512 Kbit/s

15,5 uns

1 ms

2 ms

4 ms

8 ms

16 ms

32 ms

768 Kbit/s

10

640 uns

1,28 ms

2,56 ms

5,12 ms

10,24 ms

15 ms

1536 Kbit/s

5 uns

320 uns

640 uns

1,28 ms

2,56 ms

5,12 ms

7,5 ms

Hinweis: Für Sprachanwendungen beträgt die empfohlene Serialisierungsverzögerung (pro Hop) 10 ms und sollte 20 ms nicht überschreiten.

Die Größe des Link-Fragments kann mithilfe des Befehls ppp multilink fragment-delay in Millisekunden (msec)-Zeitmessungen konfiguriert werden. LFI erfordert die Konfiguration von ppp multilink auf der Schnittstelle, wobei ppp multilink interleave aktiviert ist. Weitere Informationen zum Konfigurieren von LFI finden Sie im Abschnitt dieses Dokuments.

Hinweis: Wenn Sie über mehr als eine dedizierte halbe T1-Verbindung (768 Kbit/s) verfügen, benötigen Sie keine Fragmentierungsfunktion. (Sie benötigen jedoch weiterhin einen QoS-Mechanismus wie LLQ oder IP RTP Priority). Die halbe T1-Leitung bietet genügend Bandbreite, um Sprachpakete in die Warteschlange eindringen und diese unverzüglich verlassen zu können. Möglicherweise benötigen Sie auch keine Komprimierung für Real-Time Protocol (cRTP), wodurch bei einer halben T1-Leitung die Komprimierung von IP-RTP-Headern zur Bandbreiteneinsparung beiträgt.

Komprimiertes Real-Time Protocol (cRTP)

Hinweis: cRTP ist nicht erforderlich, um eine gute Sprachqualität sicherzustellen. Diese Funktion reduziert die Bandbreitennutzung. Konfigurieren Sie cRTP, nachdem alle anderen Bedingungen erfüllt sind und die Sprachqualität gut ist. Dieses Verfahren kann Zeit bei der Fehlerbehebung sparen, indem potenzielle cRTP-Probleme isoliert werden.

Die RTP-Header-Komprimierungsfunktion auf Basis von RFC 2508 komprimiert den IP/UDP/RTP-Header von 40 Byte auf 2 oder 4 Byte und reduziert so die unnötige Bandbreitennutzung. Es handelt sich um ein Hop-by-Hop-Komprimierungsschema. Daher muss cRTP an beiden Enden der Verbindung konfiguriert werden (es sei denn, die passive Option ist konfiguriert). Um cRTP zu konfigurieren, verwenden Sie den folgenden Befehl auf Schnittstellenebene:

- Router(config-if)#ip rtp header-compression [passive]

Da der Komprimierungsprozess CPU-intensiv sein kann, wird die RTP-Header-Komprimierung in die Fast Switching- und CEF-Switching-Pfade als Version 12.0.(7)T von IOS implementiert. Manchmal sind diese Implementierungen kaputt, und dann wird die einzige Verarbeitungsmethode, die funktioniert, umgeschaltet. Cisco empfiehlt die Verwendung von cRTP mit Verbindungen unter 768 Kbit/s, es sei denn, der Router wird mit einer niedrigen CPU-Auslastung ausgeführt. Überwachen Sie die CPU-Auslastung des Routers, und deaktivieren Sie cRTP, wenn es über 75 Prozent liegt.

Hinweis: Wenn Sie die ip rtp-Header-Komprimierung konfigurieren, fügt der Router der Konfiguration den Befehl ip tcp header-pression hinzu. Diese wird verwendet, um die TCP/IP-Pakete der Kopfzeilen zu komprimieren. Die Header-Komprimierung ist besonders für Netzwerke mit einem großen Anteil an kleinen Paketen nützlich, z. B. für Netzwerke, die viele Telnet-Verbindungen unterstützen. Die in RFC 1144 beschriebene Komprimierungstechnik für TCP-Header wird auf seriellen Leitungen mithilfe von HDLC- oder PPP-Kapselung unterstützt.

Um die TCP-Header zu komprimieren, ohne cRTP zu aktivieren, verwenden Sie den folgenden Befehl:

- Router(config-if)#ip tcp header-compression [passive]

Weitere Informationen: Komprimiertes Echtzeit-Transportprotokoll

Weitere Tipps zur Bandbreitenreduzierung

- Verwenden Sie Codec/Decoder mit niedriger Bitrate (Low-Bit-Rate) auf den VoIP-Anrufabschnitten. G.729 (8 Kbit/s) wird empfohlen. (Dies ist der Standardcodec auf den VoIP-Dial-Peers). Um verschiedene Codecs zu konfigurieren, verwenden Sie den Befehl router(config-dial-peer)#codec unter dem gewünschten VoIP-Dial-Peer.

- Obwohl Dual-Tone-Mehrfrequenzwahlverfahren (DTMF) normalerweise bei Verwendung von Sprachcodecs mit hoher Bitrate wie G.711 akkurat übertragen werden, sind Codecs mit niedriger Bitrate (z. B. G.729 und G.723.1) für Sprachmuster hochoptimiert und neigen dazu, DTMF-Töne zu verzerren. Dieser Ansatz kann zu Problemen beim Zugriff auf interaktive Sprachdialogsysteme (IVR) führen. Der dtmf Relay-Befehl löst das Problem der DTMF-Verzerrung, indem DTMF-Töne "Out-of-Band" oder separat vom kodierten Sprachstream übertragen werden. Wenn Codecs mit niedriger Bitrate (G.729, G.723) verwendet werden, aktivieren Sie das dtmf-Relay unter dem VoIP-Dial-Peer.

- Eine typische Konversation kann 35 bis 50 Prozent Schweigen enthalten. Mithilfe von VAD (Voice Activity Detection) werden Pausenpakete unterdrückt. Bei der VoIP-Bandbreitenplanung gehen Sie davon aus, dass VAD die Bandbreite um 35 Prozent reduziert. VAD wird standardmäßig unter den VoIP-DFÜ-Peers konfiguriert. Um VAD zu aktivieren oder zu deaktivieren, verwenden Sie die Befehle router(config-dial-peer)#vad und router(config-dial-peer)# no vad unter den gewünschten VoIP-Dial-Peers.

Netzwerkdiagramm

Konfigurationen

maui-voip-sj (Cisco 3640)

version 12.2service timestamps debug datetime msec

!-- < Some output omitted >

!

hostname maui-voip-sj

!

ip subnet-zero

!

no ip domain-lookup

!

!-- Definition of the voice signaling and traffic class maps !-- "voice-traffic" class uses access-list 102 for its matching criteria. !-- "voice-signaling" class uses access-list 103 for its matching criteria.

Class-map match-all voice-signaling

match access-group 103

class-map match-all voice-traffic

match access-group 102

!

!-- The policy-map defines how the link resources are assigned !-- to the different map classes. In this configuration, strict priority !-- queue is assigned to "voice-traffic" class with (based on ACL in !-- class voice) with max bandwidth = 45 Kbps.

policy-map VOICE-POLICY

class voice-traffic

priority 48

class voice-signaling

bandwidth 8

!-- Assigns a queue for "voice-signaling" traffic that ensures 8 Kbps. !-- Note that this is optional and has nothing to do with good voice !-- quality, but rather a way to secure signaling.

class class-default

fair-queue

!-- The class-default class is used to classify traffic that does !-- not fall into one of the defined classes. !-- The fair-queue command associates the default class WFQ queueing.

!

call rsvp-sync

!

!-- Note that MLPPP is strictly an LFI mechanism. It does not !-- bundle multiple serial interfaces to the same virtual interface as !-- the name stands (This bundling is done for data and NOT recommended !-- for voice). The end result may manifest itself as jitter and no audio.

interface Multilink1

ip address 172.22.130.1 255.255.255.252

ip tcp header-compression iphc-format

service-policy output VOICE-POLICY

!-- LLQ is an outbound operation and applied to the outbound WAN !-- interface.

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

!-- The configured value of 10 sets the fragment size such that !-- all fragments have a 10 ms maximum serialization delay.

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

!

interface Ethernet0/0

ip address 172.22.113.3 255.255.255.0

no keepalive

half-duplex

!

interface Serial0/0

bandwidth 128

!-- the bandwidth command needs to be set correctly for the !-- right fragment size to be calculated.

no ip address

encapsulation ppp

clockrate 128000

ppp multilink

multilink-group 1

!-- This command links the multilink interface to the physical !-- serial interface.

!

router eigrp 69

network 172.22.0.0

auto-summary

no eigrp log-neighbor-changes

!

!-- access-list 102 matches VoIP traffic based on the UDP port range. !-- Both odd and even ports are put into the PQ. !-- access-list 103 is used to match VoIP signaling protocol. In this !-- case, H.323 V2 with fast start feature is used.

access-list 102 permit udp any any range 16384 32767

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

!

voice-port 1/0/0

!

voice-port 1/0/1

!

voice-port 1/1/0

!

voice-port 1/1/1

!

dial-peer cor custom

!

dial-peer voice 1 pots

destination-pattern 5000

port 1/0/0

!

dial-peer voice 2 voip

destination-pattern 6000

session target ipv4:172.22.130.2

maui-voip-austin (Cisco 3640)

version 12.2

service timestamps debug datetime msec

!

hostname maui-voip-austin

!

boot system flash slot1:c3640-is-mz.122-6a.bin

!

ip subnet-zero

!

class-map match-all voice-signaling

match access-group 103

class-map match-all voice-traffic

match access-group 102

!

policy-map voice-policy

class voice-signaling

bandwidth 8

class voice-traffic

priority 48

class class-default

fair-queue

!

interface Multilink1

bandwidth 128

ip address 172.22.130.2 255.255.255.252

ip tcp header-compression iphc-format

service-policy output voice-policy

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

!-- Configure cRTP after you have a working configuration. !-- This helps isolate potential cRTP issues.

!

Interface Ethernet0/0

ip address 172.22.112.3 255.255.255.0

no keepalive

half-duplex

!

interface Serial0/0

bandwidth 128

no ip address

encapsulation ppp

no ip mroute-cache

ppp multilink

multilink-group 1

!

router eigrp 69

network 172.22.0.0

auto-summary

no eigrp log-neighbor-changes

!

access-list 102 permit udp any any range 16384 32767

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

!

voice-port 1/0/0

!

voice-port 1/0/1

!

voice-port 1/1/0

!

voice-port 1/1/1

!

dial-peer cor custom

!

dial-peer voice 1 pots

destination-pattern 6000

port 1/0/0

!

dial-peer voice 2 voip

destination-pattern 5000

session target ipv4:172.22.130.1

Befehle zur Überprüfung und Fehlerbehebung

Bevor Sie Fehlerbehebungsbefehle ausprobieren, lesen Sie die Informationen Wichtige Informationen über Debug-Befehle. Weitere Informationen zu den hier aufgeführten Befehlen finden Sie im Abschnitt Beispielausgabe und Debugausgabe dieses Dokuments.

Schnittstellenbefehle:

- show interface [serial] | multilink] - Verwenden Sie diesen Befehl, um den Status der seriellen Schnittstelle zu überprüfen. Stellen Sie sicher, dass die serielle Schnittstelle und die Multilink-Schnittstelle aktiv und offen sind.

- Fehlerbehebung bei seriellen Leitungen

LFI-Befehle:

- show ppp multilink - Dieser Befehl zeigt Paketinformationen für die Multilink PPP-Pakete an.

- debug ppp multilink fragments - Dieser Debugbefehl zeigt Informationen über einzelne Multilink-Fragmente und Ereignisse, die sich miteinander verbinden. Diese Befehlsausgabe identifiziert auch die Sequenznummer des Pakets und die Fragmentgrößen.

Befehle mit LLQ/IP-RTP-Priorität:

- show policy-map interface multilink interface#: Dieser Befehl ist sehr hilfreich, um den LLQ-Vorgang zu sehen und mögliche Verwerfungen im PQ zu sehen. Weitere Informationen zu den verschiedenen Feldern dieses Befehls finden Sie unter Understanding Packet Counters in show policy-map interface Output.

- show policy-map policy_map_name: Dieser Befehl zeigt Informationen zur Richtlinienzuordnungskonfiguration an.

- show queue interface-type interface-number - Dieser Befehl listet die fair queueing-Konfiguration und Statistiken für eine bestimmte Schnittstelle auf.

- Debug priority (Debug-Priorität): Dieser Debugbefehl zeigt Prioritätswarteschlangen-Ereignisse an und zeigt an, ob diese in dieser Warteschlange verworfen werden. Weitere Informationen finden Sie unter Fehlerbehebung bei Ausgabeverlusten mit Prioritätswarteschlange.

- show class-map class_name: Dieser Befehl zeigt Informationen über die Klassenzuordnungskonfiguration an.

- show call active voice: Dieser Befehl ist hilfreich, um auf DSP-Ebene nach verlorenen Paketen zu suchen.

Weitere Befehle/Verweise:

- show ip rtp header-Komprimierung - Dieser Befehl zeigt Statistiken zur RTP-Header-Komprimierung an.

- Grundlagen von VoIP-Anrufen: Fehlerbehebung und Debuggen

- VoIP-Debug-Befehle

Bekannte Probleme:

- CSCds43465: "LLQ, Policer, Shaper Should Take CRTP Compression Feedback" Um Versionshinweise anzuzeigen, lesen Sie Bug ToolKit (nur registrierte Kunden).

Leitlinien:

Nachfolgend finden Sie einige grundlegende Schritte zur Fehlerbehebung, sobald die ppp-Verbindung aktiv ist (MLPPP, Fragmentation, Interleaving):

1. show call active voice - Überprüfen Sie, ob die Pakete auf DSP-Ebene verloren gehen.

2. show interface - Verwenden Sie diese Option, um nach allgemeinen Problemen mit der seriellen Leitung oder der Schnittstelle zu suchen. Das Verwerfen der Schnittstelle bedeutet noch kein Problem, es ist jedoch besser, das Paket aus der Warteschlange mit niedriger Priorität zu verwerfen, bevor es in die Schnittstellenwarteschlange gelangt.

3. show policy-map interface - Überprüfen Sie, ob die LLQ-Drops und die Warteschlangenkonfiguration eingestellt sind. Sollte keine Fallstricke melden, die gegen die Richtlinie verstoßen.

4. show ip rtp header-Komprimierung - Überprüfen Sie, ob cRTP-spezifische Probleme vorliegen.

Beispielausgabe und Debugausgabe

!----------------------------------------------- !-----------------------------------------------  !---- To capture sections of this output, the LLQ PQ bandwidth !---- was lowered and large data traffic was placed !---- on the link to force some packets drops. !----------------------------------------------- !----------------------------------------------- !---- Packet Drop Verification (During an Active Call) !--- Assuming your ppp link is up and running, the first step of voice !--- quality problems verification is to check for lost packets !--- at the DSP. Note: Use the show call active voice command !--- NOT show call active voice brief

maui-voip-austin#show call active voice

Total call-legs: 2

!--- Indicates that the connection is established and both legs exist

GENERIC:

SetupTime=155218260 ms

Index=1

PeerAddress=5000

PeerSubAddress=

PeerId=2

PeerIfIndex=13

LogicalIfIndex=0

ConnectTime=155218364

CallDuration=00:00:27

CallState=4

!--- indicates that it is the active call !--- (#define D_callActiveCallState_active 4).

CallOrigin=2

ChargedUnits=0

InfoType=2

TransmitPackets=365

TransmitBytes=7300

ReceivePackets=229

ReceiveBytes=4580

VOIP:

!--- For this call, this was the terminating gateway. !--- At this gateway, the call started at the VoIP leg.

ConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

IncomingConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

RemoteIPAddress=172.22.130.1

!--- Indicates from which IP address the RTP stream is originating.

RemoteUDPPort=18778

RemoteSignallingIPAddress=172.22.130.1

!--- Indicates from which IP address signaling messages are coming.

RemoteSignallingPort=11010

RemoteMediaIPAddress=172.22.130.1

RemoteMediaPort=18778

RoundTripDelay=50 ms

SelectedQoS=best-effort

tx_DtmfRelay=inband-voice

FastConnect=TRUE

Separate H245 Connection=FALSE

H245 Tunneling=FALSE

SessionProtocol=cisco

SessionTarget=

OnTimeRvPlayout=4570

GapFillWithSilence=20 ms

GapFillWithPrediction=1840 ms

GapFillWithInterpolation=0 ms

GapFillWithRedundancy=0 ms

HiWaterPlayoutDelay=70 ms

LoWaterPlayoutDelay=51 ms

ReceiveDelay=51 ms

LostPackets=90

EarlyPackets=1

LatePackets=0

!--- Indicates the precense of jitter, lost packets, or !--- corrupted packets.

VAD = enabled

CoderTypeRate=g729r8

CodecBytes=20

GENERIC:

SetupTime=155218260 ms

Index=2

PeerAddress=6000

PeerSubAddress=

PeerId=1

PeerIfIndex=12

LogicalIfIndex=6

ConnectTime=155218364

CallDuration=00:00:34

CallState=4

CallOrigin=1

ChargedUnits=0

InfoType=2

TransmitPackets=229

TransmitBytes=4580

ReceivePackets=365

ReceiveBytes=7300

TELE:

ConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

IncomingConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

TxDuration=35360 ms

VoiceTxDuration=730 ms

FaxTxDuration=0 ms

CoderTypeRate=g729r8

NoiseLevel=-46

ACOMLevel=2

OutSignalLevel=-58

InSignalLevel=-42

InfoActivity=2

ERLLevel=7

SessionTarget=

ImgPages=0Total call-legs: 2

!---------------------------------------------------------- !--- Interface Verification !--- Make sure you see this: !--- LCP Open, multilink Open: Link control protocol (LCP) open statement !--- indicates that the connection is establish. !--- Open:IPCP. Indicates that IP traffic can be transmitted via the PPP link.

maui-voip-sj#show interface multilink 1

Multilink1 is up, line protocol is up

Hardware is multilink group interface

Internet address is 172.22.130.1/30

MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

DTR is pulsed for 2 seconds on reset

LCP Open, multilink Open

Open: IPCP

Last input 00:00:01, output never, output hang never

Last clearing of "show interface" counters 00:25:20

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 91

Queueing strategy: weighted fair

Output queue: 0/1000/64/37/383 (size/max total/threshold/drops/interleaves)

Conversations  0/3/32 (active/max active/max total)

Reserved Conversations 1/1 (allocated/max allocated)

Available Bandwidth 38 kilobits/sec

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

8217 packets input, 967680 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

13091 packets output, 1254194 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

----------------------------------------------------------------

!-- Note: There are no drops at the interface level. !-- All traffic that is dropped due to policing, is !-- dropped before it gets to the interface queue.

maui-voip-austin#show interface

serial 0/0Serial0/0 is up, line protocol is up

Hardware is QUICC Serial

MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,

reliability 255/255, txload 49/255, rxload 47/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

LCP Open, multilink Open

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 00:22:08

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: weighted fair  [suspended, using FIFO]

FIFO output queue 0/40, 0 drops

5 minute input rate 24000 bits/sec, 20 packets/sec

5 minute output rate 25000 bits/sec, 20 packets/sec     4851 packets input, 668983 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

4586 packets output, 657902 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

!----------------------------------- !--- LLQ Verification

maui-voip-austin#show policy-map int multilink 1

Multilink1

Service-policy output: voice-policy

Class-map: voice-signaling (match-all)

!--- This is the class for the voice signaling traffic.

10 packets, 744 bytes

5 minute offered rate 0 BPS, drop rate 0 BPS

Match: access-group 103

Weighted Fair Queueing

Output Queue: Conversation 42

Bandwidth 8 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 10/744

(depth/total drops/no-buffer drops) 0/0/0

Class-map: voice-traffic (match-all)

!--- This is PQ class for the voice traffic.

458 packets, 32064 bytes

5 minute offered rate 0 BPS, drop rate 0 BPS

Match: access-group 102

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 40

Bandwidth 15 (kbps) Burst 375 (Bytes)

!--- Notice that the PQ bandwidth was lowered to force packet drops.

(pkts matched/bytes matched) 458/29647

(total drops/bytes drops) 91/5890

!--- Some packets were dropped. In a well designed link,

!--- there should be no (or few) drops of the PQ class.

Class-map: class-default (match-any)

814 packets, 731341 bytes

5 minute offered rate 27000 BPS, drop rate 0 BPSMatch: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 32

(total queued/total drops/no-buffer drops) 0/0/0

!---------------------------------------------

!--- Verify the class-map configuration

maui-voip-austin#show class-map

Class Map match-all voice-signaling (id 2)

Match access-group  103

Class Map match-any class-default (id 0)

Match any

Class Map match-all voice-traffic(id 3)

Match access-group 102

!--- Verify the access-lists of the class-maps

maui-voip-austin#show access-lists

Extended IP access list 102

permit udp any any range 16384 32767 (34947 matches)

Extended IP access list 103

permit tcp any eq 1720 any (187 matches)

permit tcp any any eq 1720 (86 matches)

!--- Verify the policy-pap configuration

maui-voip-austin#show policy-map voice-policy

Policy Map voice-policy

Class voice-signaling

Weighted Fair Queueing

Bandwidth 8 (kbps) Max Threshold 64 (packets)

Class voice-traffic

Weighted Fair Queueing

Strict Priority

Bandwidth 50 (kbps) Burst 1250 (Bytes)

Class class-default

Weighted Fair Queueing

Flow based Fair Queueing Max Threshold 64 (packets)

---------------------------

!--- Debug priority command provides immediate feedback in case !--- of VoIP packet drops. !--- The output below shows the error message when VoIP packets !--- are being dropped from the strict priority queue.

maui-voip-sj#debug priority

priority output queueing debugging is on

maui-voip-sj#

Mar 17 19:47:09.947: WFQ: dropping a packet from the priority queue 0

Mar 17 19:47:09.967: WFQ: dropping a packet from the priority queue 0

Mar 17 19:47:09.987: WFQ: dropping a packet from the priority queue 0

-------------------------------------------------------------------

!--- Link Fragmentation and Interleaving (LFI) Verification

maui-voip-sj#show ppp multilink

!--- Verify the fragmentation size and multilink

Multilink1, bundle name is maui-voip-austin

Bundle up for 00:08:04

0 lost fragments, 0 reordered, 0 unassigned

0 discarded, 0 lost received, 1/255 load

0x6D received sequence, 0x6E sent sequence

Member links: 1 active, 0 inactive (max not set, min not set)

Serial0/0, since 00:08:09, last rcvd seq 00006C 160 weight

!--- Notice the fragmentation size is 160 Bytes. The link is configured with a !--- bandwidth of 128 kbps and a serialization delay of 10 msec. !--- Fragment Size (in bits) = bandwidth * serialization delay. !--- Note: There are 8 bits in one byte.

-------------------------------------------------------

!--- Link Fragmentation and Interleaving (LFI) Verification !--- Testing Multilink PPP Link LFI !--- This output displays fragmentation and interleaving information !--- when the the 128kbps PPP link is loaded with big data and VoIP packets.

maui-voip-sj#debug ppp multilink fragments

Multilink fragments debugging is on

1w3d: Se0/0 MLP: O frag 800004CF size 160

1w3d: Se0/0 MLP: O frag 000004D0 size 160

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Mu1 MLP: Packet interleaved from queue 40

1w3d: Se0/0 MLP: O ppp IP (0021) size 64

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: O frag 400004D1 size 106

1w3d: Se0/0 MLP: O ppp IP (0021) size 64

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: O ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: I frag 800004E0 size 160 direct

1w3d: Se0/0 MLP: I frag 000004E1 size 160 direct

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

-------------------------------------------------------------------

!--- Sample output of show ip rtp header-compression command

maui-voip-sj#show ip tcp header-compression

TCP/IP header compression statistics:  Interface Multilink1:

Rcvd:    10 total, 6 compressed, 0 errors

0 dropped, 0 buffer copies, 0 buffer failures

Sent:    10 total, 7 compressed,

230 bytes saved, 99 bytes sent

3.32 efficiency improvement factor

Connect: 16 rx slots, 16 tx slots,

2 long searches, 1 misses 0 collisions, 0 negative cache hits

90% hit ratio, five minute miss rate 0 misses/sec, 0 max

----------------------------------------------------------------------

!--- This command displays information of the voip dial-peers command.

maui-voip-sj#show dial-peer voice 2

VoiceOverIpPeer2

information type = voice,

tag = 2, destination-pattern = `6000',

answer-address = `', preference=0,

group = 2, Admin state is up, Operation state is up,

incoming called-number = `', connections/maximum = 0/unlimited,

application associated:

type = voip, session-tMarget = `ipv4:172.22.130.2',

technology prefix:

ip precedence = 0, UDP checksum = disabled,

session-protocol = cisco, req-qos = best-effort,

acc-qos = best-effort,

fax-rate = voice,   payload size =  20 bytes

codec = g729r8,   payload size =  20 bytes,

Expect factor = 10, Icpif = 30,signaling-type = cas,

VAD = enabled, Poor QOV Trap = disabled,

Connect Time = 283, Charged Units = 0,

Successful Calls = 1, Failed Calls = 0,

Accepted Calls = 1, Refused Calls = 0,

Last Disconnect Cause is "10  ",

Last Disconnect Text is "normal call clearing.",

Last Setup Time = 93793451.

-------------------------------------------------------------------------

!---The CPU utilization of the router should not exceed the 50-60 percent !--- during any five-minute interval.

maui-voip-austin#show processes cpu

CPU utilization for five seconds: 12%/8%; one minute: 11%; five minutes: 9%

PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process

1         148    310794          0  0.00%  0.00%  0.00%   0 Load Meter

2          76        23       3304  0.81%  0.07%  0.01%   0 Exec

Zugehörige Informationen

- Low Latency Queuing

- Überlastungsmanagement - Übersicht

- Implementierung von Quality of Service (QoS)

- Voice over IP - Bandbreitennutzung pro Anruf

- Quality of Service für Voice over IP

- Konfigurieren von Voice over IP

- Unterstützung von Sprachtechnologie

- Produkt-Support für Sprach- und IP-Kommunikation

- Fehlerbehebung bei Cisco IP-Telefonie

- Technischer Support - Cisco Systems