Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Conventies

QoS-ontwerprichtsnoeren voor VoIP over PPP-links

Beperkte prioriteit voor Voice Traffic Engineering (IP RTP-prioriteit voor LLQ)

LLQ-configuratierichtlijnen

IP RTP-prioriteitsconfiguratie

Link Fragmentation and Interleaving (LFI): Multilink PPP

Compressed Real-time Protocol (cRTP)

Overige tips voor bandbreedtereductie

Netwerkdiagram

Configuraties

Opdrachten voor verificatie en probleemoplossing

Uitvoer van voorbeeldweergave en debug

Gerelateerde informatie

Inleiding

Deze voorbeeldconfiguratie bestudeert een VoIP met Point to Point Protocol (PPP) over de configuratie van de lage bandbreedte-huurlijn. Dit document bevat achtergrondtechnische informatie over de geconfigureerde functies, ontwerprichtlijnen en basisstrategieën voor verificatie en probleemoplossing.

Opmerking: Het is belangrijk om op te merken dat in de onderstaande configuratie de twee routers via een huurlijn back-to-back-up zijn verbonden. In de meeste topologieën echter, kunnen de spraakenabled routers overal bestaan. Gewoonlijk maken de spraakrouters gebruik van LAN-connectiviteit op andere routers die worden aangesloten op WAN (in andere woorden, een PPP-huurlijn). Dit is belangrijk omdat als uw spraakrouters niet rechtstreeks via PPP over een huurlijn worden verbonden, alle WAN-configuratieopdrachten moeten zijn uitgevoerd op die routers die met WAN zijn verbonden en niet op de spraakrouters, zoals in de onderstaande configuraties wordt weergegeven.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

De configuraties in dit document worden getest met deze apparatuur:

- Twee Cisco 3640s met Cisco IOS® softwarerelease 12.2.6a (IP Plus)

- IP RTP-prioriteit is geïntroduceerd in Cisco IOS release 12.0(5)T.

- LLQ is geïntroduceerd in Cisco IOS release 12.0(7)T.

- LFI is geïntroduceerd in Cisco IOS release 11.3.

- Cisco IOS-releases verder dan 12.0.5T bevat significante verbeteringen van de prestaties voor cRTP.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

QoS-ontwerprichtsnoeren voor VoIP over PPP-links

Deze sectie verschaft ontwerp-richtlijnen om VoIP via PPP-huurlijnen te configureren (met een nadruk op snelle koppelingen). Er zijn twee basisvereisten voor een goede spraakkwaliteit:

- Minimale end-to-end vertraging en voorkoming van oponthoud (vertragingsvariatie).

- Geoptimaliseerde en correct gemanipuleerde vereisten voor linkbandbreedte

Om de bovenstaande eisen te waarborgen, dienen er verschillende belangrijke richtsnoeren te worden gevolgd:

Richtsnoer

Beschrijving

Beperkte prioriteit voor Voice Traffic Engineering (IP RTP-prioriteit voor LLQ)

Methode om een strikte prioriteit te geven aan spraakverkeer.

Link Fragmentation and Interleaving (LFI)

Kan een verplichte eis zijn voor hogesnelheidslijnen.

RTP-compressie

Niet vereist om goede stemkwaliteit te leveren, maar vermindert de consumptie van de vraagbandbreedte. Het algemene advies met betrekking tot RTP-compressie is om deze toe te passen na een werkconfiguratie met een goede spraakkwaliteit (vereenvoudigt de probleemoplossing).

Call Admission Control (CAC)

Niet in dit document behandeld. CAC wordt gebruikt om het aantal oproepen te controleren dat via de link kan worden ingesteld. Als de WAN-verbinding tussen de twee gateways bijvoorbeeld de bandbreedte heeft om slechts twee VoIP-oproepen te verzenden, kan het toegeven van een derde oproep de spraakkwaliteit van alle drie de oproepen verminderen. Zie voor meer informatie: VoIP Call Admission Control.

Om samen te vatten, voor de snelle PPP verbinding met router/gateways als slechts bronnen van spraakverkeer zijn twee eigenschappen verplicht:

1. Beperkte prioriteit voor spraakverkeer

2. Link Fragmentation and Interleaving (LFI)

Beperkte prioriteit voor Voice Traffic Engineering (IP RTP-prioriteit voor LLQ)

Vanaf Cisco IOS-softwarerelease 12.2 zijn er twee primaire methoden om absolute prioriteit te geven aan het spraakverkeer:

- IP RTP-prioriteit (ook PQ/WFQ genoemd): Prioriteitswachtrij / gewogen wachtrij voor eerlijke wachtrij )

- Low Latency Queuing (ook bekend als PQ/CBWFQ: Prioritaire wachtrij/op klasse gebaseerde Weighted Fair Queuing)

IP RTP-prioriteit

IP RTP-prioriteit maakt een rij met strikte prioriteit voor een reeks RTP-pakketstromen die behoren tot een reeks UDP-poorten (User Datagram Protocol). Terwijl de eigenlijke gebruikte poorten dynamisch tussen eindapparaten of gateways worden overeengekomen, gebruiken alle Cisco VoIP-producten hetzelfde UDP-poortbereik (16384-32767). Zodra de router het VoIP-verkeer herkent, plaatst hij het in de strikte prioriteitswachtrij. Wanneer de prioriteitswachtrij leeg is, worden de andere wachtrijen verwerkt volgens de standaard Weighted Fair Queuing (WFQ). IP RTP-prioriteit wordt niet actief totdat er sprake is van congestie in de interface. Dit beeld illustreert de werking van IP RTP-prioriteit:

Opmerking: IP RTP-prioriteit maakt het bursting van de prioriteitswachtrij (PQ) mogelijk wanneer er beschikbare bandbreedte op de standaardwachtrij (WFQ) is, maar houdt strikt toezicht op de prioriteitsinhoud in de wachtrij wanneer er sprake is van congestie op de interface.

Low Latency Queuing

LLQ is een functie die een strikte PQ aan Class-Based Weighted Fair Queuing (CBWFQ) biedt. LLQ maakt één strikt PQ binnen CBWFQ op klassenniveau mogelijk. Met LLQ worden de vertragingsgevoelige gegevens (in het PQ) eerst gedewachtrij geplaatst en verstuurd. In een VoIP met LLQ implementatie, wordt het spraakverkeer in het strikte PQ geplaatst.

Het PQ wordt gecontroleerd om te verzekeren dat de eerlijke rijen niet van bandbreedte uitgehongerd worden. Wanneer u de PQ configureren specificeert u in Kbps de maximale hoeveelheid bandbreedte beschikbaar voor de PQ. Wanneer de interface wordt geblokkeerd, wordt op de PQ onderhoud uitgevoerd totdat de lading de geconfigureerde Kbps-waarde in de prioriteitsverklaring bereikt. Het overmatige verkeer wordt dan gedropt om het probleem met de prioriteit-groepsfunctie van Cisco van de nalatenschap van het honger van de lagere prioriteitsrijen te vermijden.

Deze methode is complexer en flexibeler dan IP RTP-prioriteit. De keuze tussen de methoden moet zijn gebaseerd op de verkeerspatronen in uw echte netwerk en op uw behoeften.

LLQ vs. IP RTP-prioriteit

Deze tabel geeft een samenvatting van de belangrijkste verschillen tussen de LLQ- en IP RTP-prioriteit en geeft een aantal richtlijnen voor het gebruik van elke methode.

Low Latency Queuing (LLQ)

IP RTP-prioriteit

Spraakverkeer aanpassen op:

- Toegangslijsten (voor UDP poortbereik, hosts adressen, IP header ToS-velden: IP-voorrang, DSCP en meer)

- IP RTP-poortbereik

- IP ToS (type service) velden: DCSP en/of IP-voorrang

- Protocollen en ingangsinterfaces

- Alle geldige matchcriteria gebruikt in CBWFQ

Voordelen:

- Meer flexibiliteit bij de manier waarop verkeer wordt afgestemd en wordt gericht op het strikte PQ en CBWFQ

- Kan extra klassen configureren om bandbreedte voor ander verkeer zoals: VoIP-signalering en video.

Nadelen:

- Complexe configuratie

Spraakverkeer aanpassen op:

- Gebaseerd op RTP UDP-poortbereik: 16384-32767

Voordelen:

- Eenvoudige configuratie

Nadelen:

- In de WFQ-wachtrij geplaatst RTCP-verkeer (VoIP-signalering)
Opmerking: Het RTP-protocol gebruikt RTCP (Real Time Control Protocol) om de levering van RTP-pakketten te controleren. Terwijl RTP-poorten even getallen gebruiken, gebruiken RTCP-poorten oneven getallen binnen het bereik van 16384-32767. IP RTP-prioriteit plaatst RTP-poorten in het PQ, terwijl RTCP-poorten worden gediend in de standaard gewogen eerlijke wachtrij.

- Serveert VoIP-verkeer in de hoofdtelefoon, maar al het andere verkeer dat een voorkeursbehandeling en bandbreedtegarantie nodig heeft, wordt in WFQ gediend. Hoewel WFQ stromen met gewichten kan differentiëren (gebaseerd op IP-voorrang), kan dit niet voor de bandbreedtegarantie voor elke stroom zorgen.

Richtsnoeren

- De keuze tussen deze patronen moet zijn gebaseerd op de patronen van het verkeer in uw echte netwerk en uw eigenlijke behoeften.

- Als u strikte prioriteit aan uw stemverkeer moet geven, en ander verkeer kan als één type (gegevens) worden behandeld, dan doet de prioriteit van IP RTP een goed werk voor uw netwerk met een eenvoudige configuratie.

- Als u van plan bent om prioriteit te geven aan spraakverkeer op basis van andere criteria dan UDP-poorten (bijvoorbeeld DiffServ PHB) is LLQ noodzakelijk.

Raadpleeg voor meer informatie over de correlatie en verschillen in wachtrijen methoden het overzicht van congestiebeheer.

LLQ-configuratierichtlijnen

Volg deze richtlijnen op om LLQ te configureren:

1. Een class-kaart maken voor VoIP-verkeer en criteria definiëren

Deze opdrachten leggen uit hoe deze taak kan worden voltooid:

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.

Deze toegangslijsten kunnen ook worden gebruikt om spraakverkeer af te stemmen op de opdracht match Access-group:

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.

Dit zijn andere methoden die kunnen worden gebruikt in plaats van toegangsgroepen:

- Om te beginnen met Cisco IOS release 12.1.2.T wordt IP RTP Priority-functionaliteit geïmplementeerd voor LLQ. Deze optie komt overeen met de inhoud van de prioriteitsklasse op basis van de geconfigureerde UDP-poorten en is onderworpen aan de beperking van het bedienen van alleen maar poorten in de PQ.

class-map voice

match ip rtp 16384 16383

- Deze twee methodes werken onder de veronderstelling dat de pakketten VoIP op de aanvankelijk gastheren worden gemerkt, of in de router worden gematcht en gemarkeerd alvorens de uitgaande LLQ verrichting toe te passen.

class-map voice

match ip precedence 5

of

class-map voice

match ip dscp ef

N.B.: Vanaf IOS release 12.2.2T kunnen VoIP-kiespeers vóór de LLQ-bewerking worden gewaarmerkt op spraakdrager en signaleringspakketten. Dit maakt een schaalbare manier mogelijk om VoIP-pakketten te markeren en aan te passen via DSCP-codewaarden voor LLQ.

2. Een Class Map maken voor VoIP-signalering en Overeenkomstcriteria definiëren (optioneel)

Deze opdrachten leggen uit hoe deze taak kan worden voltooid:

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

Opmerking: VoIP-oproepen kunnen worden ingesteld met behulp van H.323, SIP, MGCP of Skinny (Gepatenteerd protocol dat wordt gebruikt door Cisco Call Manager). Het bovenstaande voorbeeld veronderstelde H.323 Fast Connect. Deze lijst dient als referentie voor de poorten die worden gebruikt door VoIP-signalering/controle-kanalen:

- H.323/H.225 = TCP 1720

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

- 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 (configureerbaar)

3. Maak een beleidskaart en koppel aan de VoIP-lijnkaarten

Het doel van de beleidskaart is te bepalen hoe de verbindingsmiddelen worden gedeeld of toegewezen aan de verschillende kaartklassen. Deze opdrachten leggen uit hoe deze taak kan worden voltooid:

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

Opmerking: Hoewel het mogelijk is om verschillende typen realtime verkeer in de wachtrij te plaatsen voor de PQ, raadt Cisco u aan alleen spraakverkeer naar de PQ te richten. Realtime verkeer, zoals video, kan variatie in vertraging introduceren (de PQ is een FIFO - First In First Out - wachtrij). Spraakverkeer vereist dat vertraging niet-variabel is om jitter te voorkomen.

Opmerking: de som van de waarden voor prioriteit en bandbreedte moet minder dan of gelijk zijn aan 75 procent van de link bandbreedte. Anders kan het service-beleid niet aan de link worden toegewezen (om de foutmeldingen te zien, zorg ervoor dat de houtkapconsole is ingeschakeld voor toegang tot de console en de eindmonitor is ingeschakeld voor toegang tot het net).

Opmerking: bij het configureren van VoIP via een 64 Kbps link om twee spraakoproepen te ondersteunen is het gebruikelijk om meer dan 75% (48 Kbps) van de link bandbreedte aan de PQ toe te wijzen. In dergelijke gevallen kunt u de opdracht max-gereserveerde-bandbreedte 80 gebruiken om beschikbare bandbreedte op te trekken naar 80 procent (51 Kbps).

Voor meer informatie over de bandbreedte en de prioriteit opdrachten, verwijs naar het Vergelijken van de bandbreedte en prioriteitsopdrachten van een QoS Service Policy.

4. LLQ inschakelen: Pas de Policy Map op de uitgaande WAN-interface toe

Deze opdrachten leggen uit hoe deze taak kan worden voltooid:

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-prioriteitsconfiguratie

U kunt IP RTP-prioriteit als volgt configureren:

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

Opdracht

Beschrijving

starting-rtp-port-number

Lage lijn van UDP poort. Het laagste poortnummer waarnaar de pakketten worden verzonden. Stel deze waarde voor VoIP in op 16384.

port-number-range

Het bereik van UDP-doelpoorten. Een getal, dat aan het beginnend-rtp-port-number wordt toegevoegd, geeft het hoogste UDP poortnummer op. Stel deze waarde voor VoIP in op 16383 (32767 - 16384 = 16383)

bandwidth

Maximum toegestane bandbreedte (kbps) in de prioriteitswachtrij. Stel dit nummer in op basis van het aantal gelijktijdige oproepen die het systeem ondersteunt.

Configuratie monster:

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

Terwijl 1500 bytes een veel gebruikte grootte is voor gegevenspakketten, kan een typisch VoIP-pakket (met G.729-spraakframes) rond 66 bytes zijn (20 bytes stemlading, 6 bytes Layer 2 header, 20 bytes RTP & UDP-header en 20 bytes IP-header).

Stel je nu een 56 Kbps huurlijnverbinding voor waar spraak- en gegevensverkeer naast elkaar bestaan. Als een stempakket klaar is om serieel te worden gemaakt op het moment dat een gegevenspakket via de link wordt verzonden, is er een probleem. Het uitgestelde-gevoelige spraakpakket moet 214 msec wachten voordat het wordt overgebracht (het duurt 214 msec om een 1500 bytes-pakket via een 56 Kbps link te serialiseren).

Zoals u kunt zien, kunnen grote gegevenspakketten de levering van kleine spraakpakketten nadelig vertragen, wat de spraakkwaliteit vermindert. Het fragmenteren van deze grote gegevenspakketten in kleinere en het verbinden van spraakpakketten tussen de fragmenten vermindert jitter en vertraging. De functie Cisco IOS Link Fragmentation and Interleaving (LFI) helpt voldoen aan de real-time leveringsvereisten van VoIP. Dit beeld illustreert de werking van LFI:

Zoals in Tabel 1 wordt getoond, kan de hoeveelheid serializatievertraging (de tijd die nodig is om de bits op een interface te zetten) die op snelle WAN-links is geïntroduceerd aanzienlijk zijn, gezien het feit dat de target-end-to-end eenmalige vertraging niet meer dan 150 ms zou moeten bedragen. (ITU-T G.114-aanbeveling specificeert maximaal 150 ms-on-to-end.)

Tabel 1. Vertraging van serialisatie voor verschillende frame-afmetingen bij snelle links serialibreer vertraging = beeldgrootte (bits)/link-bandbreedte (bps)

1 bytes

64 Bytes

128 Bytes

256 Bytes

512 Bytes

1024 Bytes

1500 Bytes

56 kbps

ons 143

9 ms

18 ms

36 ms

72 ms

144 ms

214 ms

64 kbps

vs.

8 ms

16 ms

32 ms

64 ms

126 ms

187 ms

128 kbps

62,5 ons

4 ms

8 ms

16 ms

32 ms

64 ms

93 m

256 kbps

wij

2 ms

4 ms

8 ms

16 ms

32 ms

46 ms

512 kbps

15,5 ons

1 ms

2 ms

4 ms

8 ms

16 ms

32 ms

768 kbps

10 ons

640 vs.

1,28 ms

2,56 ms

5,12 ms

10,24 ms

15 ms

1536 kbps

5 ons

wij 320

640 vs.

1,28 ms

2,56 ms

5,12 ms

7,5 ms

Opmerking: voor spraaktoepassingen is de aanbevolen seriële vertraging (per hopbasis) 10 ms en mag de 20 ms niet overschrijden.

Het grootte van het verbindingsfragment is configureerbaar in milliseconde (msec) tijdmetingen met de vertraging van het opdrachtupp multilink-fragment. LFI vereist dat ppp multilink wordt geconfigureerd op de interface met ppp multilink ingeschakeld. Raadpleeg het gedeelte van dit document voor meer informatie over het configureren van LFI.

Opmerking: In gevallen waarin u meer dan een toegewezen halve T1-verbinding (768 Kbps) hebt, hebt u geen fragmentatiefunctie nodig. (U hebt echter nog steeds een QoS-mechanisme nodig, zoals LLQ of IP RTP-prioriteit). De helft T1 biedt genoeg bandbreedte om spraakpakketten in te voeren en de wachtrij zonder vertraging te verlaten. Mogelijk hebt u geen compressie nodig voor Real-time Protocol (cRTP), dat helpt bandbreedte te besparen door IP RTP-headers te comprimeren, in het geval van een halve T1.

Compressed Real-time Protocol (cRTP)

Opmerking: cRTP is niet vereist om een goede spraakkwaliteit te garanderen. Het is een eigenschap die het bandbreedteverbruik vermindert. Configureer cRTP nadat aan alle andere voorwaarden is voldaan en de spraakkwaliteit goed is. Deze procedure kan de tijd voor het oplossen van problemen opslaan door mogelijke cRTP-problemen te isoleren.

Gebaseerd op RFC 2508, comprimeert de RTP-headercompressie de IP/UDP/RTP-header van 40 bytes naar 2 of 4 bytes, wat onnodig bandbreedteverbruik vermindert. Het gaat om een compressieregeling voor hop; daarom moet cRTP op beide uiteinden van de verbinding worden geconfigureerd (tenzij de passieve optie is ingesteld). Om cRTP te configureren gebruikt u deze opdracht op interfaceniveau:

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

Aangezien het compressieproces CPU-intensief kan zijn, wordt RTP-headercompressie in de snelle switching- en CEF-switchpaden geïmplementeerd als de 12.0(7)T-release van IOS. Soms zijn deze implementaties verbroken en dan is de enige manier waarop werken worden verwerkt, veranderd. Cisco raadt het gebruik van cRTP alleen aan met koppelingen lager dan 768 Kbps, tenzij de router met een laag CPU-gebruikspercentage wordt uitgevoerd. Controleer het CPU-gebruik van de router en schakelt cRTP uit als deze hoger is dan 75%.

Opmerking: Wanneer u de opdracht ip-headercompressie configureren, voegt de router de opdracht ip header-compressie standaard toe aan de configuratie. Dit wordt gebruikt om de TCP/IP-pakketten van de kopregels te comprimeren. De headercompressie is vooral handig op netwerken met een groot percentage kleine pakketten, zoals die ondersteuning van veel Telnet-verbindingen. De TCP-headercompressietechniek, volledig beschreven in RFC 1144, wordt ondersteund op serielijnen met HDLC of PPP-insluiting.

Om de TCP-headers te comprimeren zonder cRTP in te schakelen gebruikt u deze opdracht:

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

Voor meer informatie : Compressed Real-time transportprotocol

Overige tips voor bandbreedtereductie

- Gebruik een lage-bit-rate coder/decoders (codec) op de VoIP-aanroep; G.729 (8 Kbps) wordt aanbevolen. (Dit is de standaardcodec op de VoIP-kiespeers). Om verschillende codecs te configureren gebruikt u de router (configuratie-dial-peers)#codec opdracht onder de gewenste spraak-dial-peer.

- Hoewel duale toonfrequentie (DTMF) doorgaans nauwkeurig wordt getransporteerd wanneer gebruik wordt gemaakt van spraakcodecs met een hoge beeldsnelheid zoals G.711, zijn laag-bits codecs (zoals G.729 en G.723.1) zeer geoptimaliseerd voor spraakpatronen en hebben de neiging DTMF-tonen te vervormen. Deze benadering kan leiden tot problemen bij de toegang tot systemen voor interactieve spraakrespons (IVR). De opdracht dtmf lost het probleem van DTMF-vervorming op door DTMF-tonen "uit-band" te transporteren of van de gecodeerde spraakstroom te scheiden. Als codecs met een lage snelheid (G.729, G.723) worden gebruikt, schakelt u dtmf-relais in onder de VoIP-dial-peer.

- Een typische conversatie kan 35-50% stilte bevatten. Gebruikmakend van VAD (Voice Action Detection) worden stil-pakketten onderdrukt. Ga er voor VoIP-bandbreedteplanning van uit dat VAD de bandbreedte met 35% vermindert. VAD wordt standaard ingesteld onder de VoIP-kiespeers. Om VAD in te schakelen of uit te schakelen, gebruikt u de router (configuratie-dial-peers)#vad en router (configuratie-dial-peers)# geen opdrachten van de VAD onder de gewenste kiestoon-peers.

Netwerkdiagram

Configuraties

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

Opdrachten voor verificatie en probleemoplossing

Voordat u een debug-opdracht probeert, raadpleegt u Belangrijke informatie over debug Commands. Zie het gedeelte Uitvoer en debug van dit document voor meer informatie over de hier genoemde opdrachten.

Interfaceopdrachten:

- interface tonen [seriële] | multilink] - Gebruik deze opdracht om die status van de seriële interface te controleren. Zorg ervoor dat de interface voor seriële en multilink open is.

- Seriële lijnen oplossen

LFI-opdrachten:

- toon PPP multilink-Deze opdracht toont bundelinformatie voor de bundels Multilink PPP.

- debug ppp multilink fragments-This debug opdracht toont informatie over individuele multilink fragmenten en interleaving. Deze opdrachtoutput identificeert ook het sequentienummer van het pakket en de fragmentatiegrootte.

LLQ/IP RTP-prioriteitsopdrachten:

- toon beleid-kaart interface multilink interface#-Deze opdracht is zeer nuttig om de LLQ handeling te zien en om enige druppels in het PQ te zien. Voor meer informatie over de verschillende velden van deze opdracht, raadpleeg het begrip Packet Counters in show policy-map interface output.

- toon beleid-kaart policy_map-name-deze opdracht toont informatie over de beleid-kaart configuratie.

- toon interface-type interface-number-deze opdracht maakt een lijst van eerlijke configuratie en statistieken voor een bepaalde interface.

- Debug prioriteit-Dit debug van opdracht toont prioriteitsgebeurtenissen in de wachtrij en toont of er sprake is van vallen in deze wachtrij. Raadpleeg ook uitvoerdruppels voor probleemoplossing met prioriteitswachtrij.

- Toon class-map class_name —Deze opdracht toont informatie over de class-map configuratie.

- toon vraag actieve stem-Deze opdracht is nuttig om te controleren op verloren pakketten op het DSP niveau.

Overige opdrachten/referenties:

- Toon ip rtp header-compressie-Deze opdracht geeft RTP headercompressiestatistieken weer.

- Problemen oplossen en oplossen van VoIP-gespreksonderwerpen

- VoIP-debug-opdrachten

Bekende problemen:

- CSCds43465: "LLQ, Policer, Shaper zou CRTP-compressie feedback moeten nemen" om release Notes te bekijken, raadpleeg Bug ToolKit (alleen geregistreerde klanten).

Richtsnoeren:

Hier zijn een aantal basisstappen voor het oplossen van problemen, nadat de ppp link in bedrijf is (MLPPP, Fragmentation, Interleaving):

1. toon vraag actieve stem-Gebruik om voor de verloren pakketten op het DSP niveau te controleren.

2. toon interface-gebruik om de algemene serielijn of interfaceproblemen te controleren. De druppels op de interface betekenen nog geen probleem, maar het is beter om het pakket uit de rij met lage prioriteit te laten vallen voordat het de interfacerij bereikt.

3. toon beleid-kaart interface—gebruik om de LLQ-druppels en de configuratie van de wachtrij te controleren. Laat geen druppels melden die het beleid schenden.

4. Toon ip rtp header-compressie-Gebruik om te controleren op de cRTP specifieke problemen.

Uitvoer van voorbeeldweergave en debug

!----------------------------------------------- !-----------------------------------------------  !---- 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

Gerelateerde informatie

- Low Latency Queueing

- Overzicht van congestiebeheer

- Quality-of-Service (QoS) implementeren

- Voice-over-IP - verbruik per gespreksband

- Quality-of-Service voor Voice-over-IP

- Voice-over-IP configureren

- Ondersteuning voor spraaktechnologie

- Productondersteuning voor spraak- en IP-communicatie

- Probleemoplossing voor Cisco IP-telefonie

- Technische ondersteuning - Cisco-systemen