Problemen met QoS Choppy Voice oplossen

Inleiding

Packet Voice kan alleen een realistische vervanging zijn voor standaardtelefoniediensten met openbaar telefoonnetwerk (PSTN) als de ontvangen kwaliteit van Packet Voice vergelijkbaar is met die van basistelefoondiensten. Dit betekent consequent hoogstaande spraakuitzendingen. Net als andere real-time toepassingen heeft Packet Voice een brede bandbreedte en is het gevoelig voor vertraging. Spraaktransmissies kunnen niet worden gedropt, overmatig vertraagd of een verschillende vertraging oplopen (ook wel jitter genoemd) om ze verstaanbaar (niet choppy) te maken voor de ontvanger. Dit document beschrijft verschillende QoS-overwegingen (Quality of Service) die helpen bij het oplossen van problemen met veranderlijke spraak. De belangrijkste redenen voor choppy spraakproblemen zijn verloren en vertraagde spraakpakketten.

Voorwaarden

Vereisten

Lezers van dit document dienen hiervan op de hoogte te zijn:

• Basisconfiguratie van Packet Voice (VoIP, Voice over Frame Relay (VoFR) of Voice over ATM (VoATM) volgens hun vereisten).

• Basiskennis van spraakprioritering, fragmentatie, verschillende codecs en hun bandbreedtevereisten.

Gebruikte componenten

De informatie in dit document is van toepassing op alle software en hardwareversies van Cisco Voice Gateways.

De informatie in dit document is gebaseerd op apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als u in een live netwerk werkt, zorg er dan voor dat u de potentiële impact van iedere opdracht begrijpt voor u deze gebruikt.

Conventies

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

Oorzaken van Choppy Voice

De veranderlijke stemkwaliteit wordt veroorzaakt door spraakpakketten die of veranderlijk worden vertraagd of in het netwerk verloren. Wanneer een spraakpakket wordt vertraagd bij het bereiken van zijn bestemming, heeft de bestemminggateway een verlies van informatie in real time. In dit geval, moet de bestemminggateway voorspellen wat de inhoud van het gemiste pakket kan zijn. De voorspelling leidt ertoe dat de ontvangen stem niet de zelfde kenmerken heeft als de overgebrachte stem. Dit leidt tot een ontvangen stem die robotisch klinkt. Als een spraakpakket wordt vertraagd voorbij het voorspellingsvermogen van een ontvangende gateway, verlaat de gateway de real-time kloof leeg. Met niets om die kloof aan het ontvangende eind te dichten, is een deel van de uitgezonden toespraak verloren gegaan. Dit resulteert in veranderlijke stem. Veel van de veranderlijke stemkwesties worden opgelost door ervoor te zorgen dat de stempakketten niet zeer vertraagd zijn (en meer dan dat, niet veranderlijk vertraagd). Soms voegt voice activity detectie (VAD) front-end knippen toe aan een spraakgesprek. Dit is een andere oorzaak van veranderlijke (of geknipte) stem.

De verschillende secties in dit document tonen hoe u de instantie van de hakkerige stem kunt minimaliseren. De meeste van deze maatregelen vereisen het verzekeren van de introductie van minimum jitter in uw spraaknetwerk.

Bandbreedtevereiste

Alvorens u overweegt om het even welke maatregelen toe te passen om jitter te minimaliseren, voorziening voldoende netwerkbandbreedte om stemverkeer in real time te steunen. Een 80 kbps G.711 VoIP-oproep (payload 64 kbps + header 16 kbps) klinkt bijvoorbeeld slecht via een 64 kbps-link omdat ten minste 16 kbps van de pakketten (wat 20 procent is) worden weggelaten. De bandbreedtevereisten variëren op basis van de codec die voor compressie wordt gebruikt. Verschillende codecs hebben verschillende payloads en headervereisten. Het gebruik van VAD beïnvloedt ook het bandbreedtevereiste. Als Real Time Protocol (RTP)-headercompressie (cRTP) wordt gebruikt, kan het de bandbreedtevereiste verder verlagen.

De bandbreedte die nodig is voor een spraakoproep met behulp van de G.729 codec (standaard 20 bytes payload) met cRTP is bijvoorbeeld als volgt:

• Voice payload + gecomprimeerde (RTP-header + User Datagram Protocol (UDP) header + IP-header) +Layer 2-header

Dit komt overeen met:

• 20 bytes + gecomprimeerd (12 bytes + 8 bytes + 20 bytes) + 4 bytes

Dit is gelijk aan:

• 28 bytes, omdat de headercompressie de IP RTP header reduceert tot een maximum van 4 bytes. Dit levert 11,2 kbps op bij een codec-snelheid van 8 kbps (50 pakketten per seconde).

Raadpleeg voor meer informatie Voice over IP - Per Call Bandbreedteconsumptie.

Prioriteit spraakverkeer

Er zijn twee belangrijke componenten in het prioriteren van spraak. De eerste is het classificeren en markeren van interessant spraakverkeer. De tweede prioriteit is het gemarkeerde interessante spraakverkeer. De twee subsecties bespreken hier verschillende benaderingen voor het classificeren, markeren en prioriteren van spraak.

Classificatie en markering

Om de bandbreedte voor VoIP-pakketten te waarborgen, moet een netwerkapparaat de pakketten kunnen identificeren in al het IP-verkeer dat er doorheen stroomt. Netwerkapparaten gebruiken het IP-adres van de bron en van de bestemming in de IP-header of de UDP-poortnummers van de bron en de bestemming in de UDP-header om VoIP-pakketten te identificeren. Dit identificatie- en groeperingsproces wordt classificatie genoemd. Het is de basis voor het verstrekken van QoS.

Packet classificatie kan processorintensief zijn. Daarom moet de classificatie zo ver mogelijk naar de rand van het netwerk worden doorgevoerd. Omdat elke hop nog een bepaling over de behandeling moet maken zou een pakket moeten ontvangen, moet u een eenvoudigere, efficiëntere classificatiemethode in de netwerkkern hebben. Deze eenvoudiger classificatie wordt bereikt door de byte Type of Service (ToS) in de IP-header te markeren of in te stellen. De drie belangrijkste bits van de ToS-byte worden IP-prioriteitsbits genoemd. De meeste toepassingen en leveranciers ondersteunen momenteel het instellen en herkennen van deze drie bits. De markering is in ontwikkeling zodat de zes belangrijkste bits van de ToS-byte, genaamd het Differentiated Services Code Point (DSCP), kunnen worden gebruikt. Raadpleeg het verzoek om opmerkingen (RFC).

Gedifferentieerde services (DiffServ) is een nieuw model waarin verkeer wordt behandeld door intermediaire systemen met relatieve prioriteiten op basis van het ToS-veld. De DiffServ-standaard wordt gedefinieerd in RFC 2474 en RFC 2475 en vervangt de oorspronkelijke specificatie voor het bepalen van de pakketprioriteit die in RFC 791 is beschreven. DiffServ verhoogt het aantal definieerbare prioriteitsniveaus door bits van een IP-pakket opnieuw toe te wijzen voor prioriteitsmarkering. De DiffServ-architectuur definieert het DiffServ-veld. Het vervangt de ToS-byte in IP V4 om Per-Hop Behavior (PHB)-beslissingen te maken over pakketclassificatie en functies voor traffic conditionering zoals metering, markering, vormgeving en toezicht. Naast de eerder genoemde RFC’s definieert RFC 2597 de Assure Forwarding (AF)-klassen. Dit is een uitsplitsing van de DSCP-velden. Raadpleeg voor meer informatie over DSCP Quality of Service Policies implementeren met DSCP.

ToS-byte - P2 P1 P0 T3 T2 T1 T0 CU

IP-voorrang: drie bits (P2-P0), ToS: vier bits (T3-T0), CU: eentonig

DiffServ-veld - DS5 DS3 DS2 DS1 DS0 ECN

DSCP: zes bits (DS5-DS0), ECN: twee bits

XXX00000 bits 0, 1, 2 (DS5, DS4 en DS3) zijn prioriteitsbits, waarbij:

• 111 = Netwerkcontrole = voorrang 7

• 110 = Internetwork Control = voorrang 6

• 101 = CRITIC/ECP = Voorrang 5

• 100 = Flash-opheffing = voorrang 4

• 011 = Flitser = Voorrang 3

• 010 = Onmiddellijk = Voorrang 2

• 001 = Prioriteit = Voorrang 1

• 000 = Routine = Voorrang 0

000XX00 bits 3, 4, 5 (DS2, DS1, DS0) zijn vertragings-, doorvoersnelheid- en betrouwbaarheidsbits.

• bit 3 = Vertraging [D] (0 = Normaal; 1 = Laag)

• bit 4 = doorvoersnelheid [t] (0 = normaal; 1 = Hoog)

• bit 5 = Betrouwbaarheid [R] (0 = Normaal; 1 = Hoog)

000000XX bits 6, 7: ECN

In deze twee paragrafen worden twee manieren besproken waarop classificatie en markering plaatsvinden.

Spraakkiespeers om pakketten te classificeren en te markeren

Met Cisco VoIP-gateways gebruikt u meestal spraakdial-peers om de VoIP-pakketten te classificeren en de IP-prioriteitsbits te markeren. Deze configuratie toont hoe de IP-prioriteitsbits moeten worden gemarkeerd:

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

In het bovenstaande voorbeeld heeft elke VoIP-oproep die overeenkomt met de opdracht 100 voip van de dial-peers alle spraakpakketten die zijn ingesteld met IP-voorrang 5. Dit betekent dat de drie belangrijkste bits van de IP ToS-byte zijn ingesteld op 101.

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

In het bovenstaande voorbeeld heeft elke VoIP-oproep die overeenkomt met de opdracht 100 voip van de dial-peer alle media payloadpakketten (spraakpakketten) die zijn ingesteld met EF-101110 (Expedited Forwarding). Alle signaleringspakketten worden ingesteld met AF-011010.

Opmerking: de opdracht ip qos DSCP wordt ondersteund sinds Cisco IOS®-softwarerelease 12.2(2)T. De IP-voorrang is niet langer beschikbaar in Cisco IOS-softwarerelease 12.2T. Hetzelfde wordt echter bereikt met de opdracht ip qos dscp. IP-voorrang 5 (101): kaarten naar IP DSCP 101000. Raadpleeg VoIP-signalering en media voor DSCP-classificatie voor QoS voor meer informatie.

Modulaire QoS CLI voor classificatie en markering van pakketten

De aanbevolen classificatie- en markeringsmethode is de modulaire QoS CLI. Dit is een op een sjabloon gebaseerde configuratiemethode die de classificatie van het beleid scheidt. Hierdoor kunnen meerdere QoS-functies voor meerdere klassen tegelijk worden geconfigureerd. Gebruik een class-map opdracht om verkeer te classificeren op basis van verschillende matchcriteria en een policy-map opdracht om te bepalen wat er moet gebeuren met elke klasse. Pas het beleid op inkomend of uitgaand verkeer op een interface toe door het bevel dienst-beleid uit te geven. Dit configuratievoorbeeld laat zien hoe u modulaire QoS CLI kunt gebruiken om pakketten te classificeren en te markeren:

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 dit configuratievoorbeeld wordt elk verkeer dat overeenkomt met ACL (toegangscontrolelijst) 100 geclassificeerd als "class voip" en ingesteld met IP prioriteitsniveau 5. Dit betekent dat de drie belangrijkste bits van de IP ToS-byte zijn ingesteld op 101. ACL 100 komt overeen met de gebruikelijke UDP-poorten die door VoIP worden gebruikt. Op dezelfde manier komt ACL 101 overeen met H.323 signaleringsverkeer (TCP-poort (Transmission Control Protocol) 1720). Al het andere verkeer is ingesteld met IP-voorrang 0. Het beleid wordt "mqc" genoemd. Het wordt toegepast op inkomend verkeer op Ethernet 0/0.

Prioriteren

Nadat elke hop in het netwerk de VoIP-pakketten kan classificeren en identificeren (via poort/adresinformatie of via de ToS-byte), voorzien deze hop elk VoIP-pakket van de vereiste QoS. Op dat punt, vorm speciale technieken om prioriteit het een rij vormen te verstrekken om ervoor te zorgen dat de grote gegevenspakketten zich niet in de transmissie van spraakgegevens mengen. Dit is meestal vereist bij langzamere WAN-links waar een hoge kans op stremming is. Zodra al het interessante verkeer in QoS-klassen is geplaatst die op hun QoS-vereisten zijn gebaseerd, bieden u bandbreedtegaranties en prioritair onderhoud door een intelligent mechanisme voor outputwachtrijen. Er is een prioriteitswachtrij vereist voor VoIP.

Opmerking:  Gebruik een wachtrij-mechanisme dat VoIP effectief hoge prioriteit geeft. LLQ (Low Latency Queuing) wordt echter aanbevolen omdat het systeem flexibel en gemakkelijk te configureren is.

LLQ gebruikt de modulaire QoS CLI-configuratiemethode om prioriteit te geven aan bepaalde klassen en om gegarandeerde minimumbandbreedte voor andere klassen te bieden. Tijdens perioden van stremming wordt de prioriteitswachtrij gecontroleerd aan de ingestelde snelheid, zodat het prioriteitsverkeer niet alle beschikbare bandbreedte opgebruikt. (Als het prioritaire verkeer de bandbreedte monopoliseert, verhindert het bandbreedtegaranties voor andere klassen worden ontmoet.) Als u LLQ correct provisioneert, zou het verkeer dat in de prioriteitswachtrij gaat nooit de ingestelde snelheid moeten overschrijden.

LLQ laat ook wachtrijdiepten toe worden gespecificeerd om te bepalen wanneer de router pakketten moet laten vallen als er teveel pakketten zijn die in om het even welke bepaalde klassenrij wachten. Er is ook een class-default opdracht die wordt gebruikt om de behandeling te bepalen van al het verkeer dat niet geclassificeerd is door een geconfigureerde klasse. Het class-default is geconfigureerd met een fair-wachtrij commando. Dit betekent dat elke niet geclassificeerde stroom een ongeveer gelijk aandeel van de resterende bandbreedte krijgt.

Dit voorbeeld toont hoe LLQ te vormen. Raadpleeg voor meer informatie 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 dit voorbeeld wordt elk verkeer dat overeenkomt met ACL 100 geclassificeerd als "class voip" (dit betekent spraakverkeer). Het heeft een hoge prioriteit tot 32 kbps. ACL 100 komt overeen met de gebruikelijke UDP-poorten die door VoIP worden gebruikt. Access-list 101 past het H.323 signaleringsverkeer aan (TCP-poort 1720). Class data1 matcht webverkeer (TCP-poort 80 zoals in toegangslijst 102) en garandeert 64 kbps. Class data2 matcht Telnet verkeer (TCP poort 23 zoals in ACL 103) en garandeert 32 kbps. De standaardklasse wordt geconfigureerd om een gelijk deel van de resterende bandbreedte te geven aan niet-geclassificeerde stromen. Het beleid wordt "llq" genoemd. Het wordt toegepast op uitgaand verkeer op Serial1/0, die een totale bandbreedte van 256 kbps heeft.

Opmerking: standaard moet de totale gegarandeerde bandbreedte en prioriteitsbandbreedte voor alle klassen minder zijn dan 75 procent van de interfacebandbreedte. Wijzig dit percentage door het bevel van de maximum-gereserveerde bandbreedteinterface uit te geven.

In deze tabel worden verschillende mechanismen voor softwarewachtrijen vergeleken met hun respectieve voordelen en beperkingen.

Mechanisme voor wachtrijen voor software	Beschrijving	Voordelen	Beperkingen
First-In-First-Out (FIFO)	Pakketten komen aan en verlaten de wachtrij in precies dezelfde volgorde.	Eenvoudige configuratie en snelle werking.	Geen prioriteit onderhoud of bandbreedte garanties mogelijk.1
Weighted Fair Queuing (WFQ)	Een hakalgoritme dat in afzonderlijke rijen stroomt waar de gewichten worden gebruikt om te bepalen hoeveel pakketten tegelijkertijd worden onderhouden. U definieert gewichten door IP-voorrang en DSCP-waarden in te stellen.	Eenvoudige configuratie. Standaard op koppelingen van minder dan 2 Mbps.	Geen prioriteit onderhoud of bandbreedte garanties mogelijk.1
Aangepaste wachtrij (CQ)	Het verkeer wordt geclassificeerd in meerdere wachtrijen met configureerbare wachtrijlimieten. De wachtrijlimieten worden berekend op basis van de gemiddelde pakketgrootte, maximale transmissie-eenheid (MTU) en het percentage van de bandbreedte die moet worden toegewezen. Wachtrijlimieten (in aantal bytes) worden voor elke wachtrij uit de wachtrij gehaald. Daarom verstrekt het statistisch de toegewezen bandbreedte.	Is al een paar jaar beschikbaar. Het staat benaderende bandbreedtetoewijzing voor verschillende rijen toe.	Geen prioritair onderhoud is mogelijk. De garanties van de bandbreedte zijn benaderend. Er zijn een beperkt aantal wachtrijen. Configuratie is relatief moeilijk.1
Prioriteitswachtrij (PQ)	Het verkeer is geclassificeerd in wachtrijen met hoge, gemiddelde, normale en lage prioriteit. Het prioriteitsverkeer wordt eerst onderhouden, gevolgd door middelgroot, normaal en laag prioriteitsverkeer.	Is al een paar jaar beschikbaar. Het verleent prioritaire het onderhouden.	Verkeer met hogere prioriteit verhongert de lagere prioriteitswachtrijen van bandbreedte. Er zijn geen bandbreedtegaranties mogelijk.2
Op klasse gebaseerde Weighted Fair Queuing (CBWFQ)	Modulaire QoS CLI wordt gebruikt om verkeer te classificeren. Geclassificeerd verkeer wordt in gereserveerde bandbreedtewachtrijen of een standaard ongereserveerde wachtrij geplaatst. Een plannerservice de wachtrijen op basis van gewichten, zodat de bandbreedtegaranties worden gehonoreerd.	Gelijkaardig aan LLQ, behalve dat is er geen prioriteitsrij. Eenvoudige configuratie en mogelijkheid om bandbreedtegaranties te bieden.	Prioritair onderhoud is niet mogelijk.3
Priority Queue Weighted Fair Queuing (PQ-WFQ), ook IP RTP-prioriteit genoemd	Een enkele interfaceopdracht wordt gebruikt voor prioritair onderhoud van alle UDP-pakketten die bestemd zijn voor even poortnummers binnen een bepaald bereik.	Eenvoudige, één opdrachtconfiguratie. Biedt prioriteit aan RTP-pakketten.	Al het andere verkeer wordt behandeld met WFQ. Realtime Conferencing Protocol (RTCP)-verkeer krijgt geen prioriteit. Geen gegarandeerde bandbreedtemogelijkheid.4
LLQ, voorheen Priority Queue, op klasse gebaseerde Weighted Fair Queuing (PQCBWFQ)	Modulaire QoS CLI met prioriteitswachtrij wordt gebruikt om verkeer te classificeren. Geclassificeerd verkeer wordt geplaatst in een prioriteitswachtrij, gereserveerde bandbreedtewachtrijen of een standaard ongereserveerde wachtrij. Een plannerservice de wachtrijen op basis van gewichten, zodat het prioriteitsverkeer eerst wordt verzonden (tot een bepaalde gepoliceerde limiet tijdens stremming) en de bandbreedtegaranties worden gehaald.	Eenvoudige configuratie. Mogelijk om prioriteit te geven aan meerdere verkeersklassen en bovenste grenzen te geven aan prioritair bandbreedtegebruik. U kunt ook bandbreedte gegarandeerde klassen en een standaard klasse configureren.	Geen mechanisme om meerdere prioriteitsniveaus te bieden, al het prioriteitsverkeer wordt via dezelfde prioriteitswachtrij verzonden. De afzonderlijke prioriteitsklassen kunnen afzonderlijke hogere prioriteitsbandbreedtegrenzen tijdens congestie hebben. Het delen van prioriteitswachtrij tussen toepassingen kan echter jitter.4 introduceren

1. Niet geschikt voor spraak.

2. Behoefte aan bandbreedte gegarandeerd voor spraak.

3. Latentie moet worden verzorgd.

4. Voldoende voor spraak.

Serialisatievertraging

Zelfs als het een rij vormen op zijn best werkt en spraakverkeer prioriteert, zijn er tijden wanneer de prioriteitsrij leeg is en een pakket van een andere klasse wordt onderhouden. Pakketten van gegarandeerde bandbreedteklassen moeten worden onderhouden op basis van hun geconfigureerd gewicht. Als een prioritair spraakpakket in de uitvoerwachtrij aankomt terwijl deze pakketten worden onderhouden, kan het spraakpakket een aanzienlijke hoeveelheid tijd wachten voordat het wordt verzonden. De pakketten van de stem ervaren rangschikkingsvertraging wanneer zij achter grotere gegevenspakketten moeten wachten.

De vertraging van de rangschikking kan de slechtste vorm van jitter voor stempakketten introduceren. Als de spraakpakketten moeten wachten achter een gegevenspakket dat zo groot is als 1500 bytes, op een langzamere link, vertaalt dit zich in een grote vertraging. De serialisatievertraging is heel anders als het gegevenspakket 80 bytes is, zoals in dit voorbeeld:

• Serialisatievertraging op een 64 kbps link als gevolg van een 1500 bytes pakket = 1500*8/64000 = 187.5 ms.

• Serialisatievertraging op een 64 kbps link als gevolg van een 80 bytes pakket = 80*8/64000 = 10 ms.

Daarom moet een spraakpakket mogelijk tot 187,5 ms wachten voordat het wordt verzonden als het vast komt te zitten achter een enkel pakket van 1500 bytes op een 64 kbps link. Aan de andere kant, een ander spraakpakket moet slechts 10 ms op de bestemminggateway wachten. Dit resulteert in een grote jitter die optreedt vanwege de variantie in de interpakketvertraging. Op de voortkomende gateway, worden de spraakpakketten gewoonlijk verzonden om de 20 ms. Met een end-to-end budget van 150 ms en strikte jittervereisten is een gat van meer dan 180 ms onaanvaardbaar.

Introduceer een fragmentatiemechanisme dat ervoor zorgt dat de grootte van één transmissieeenheid minder dan 10 ms is. Pakketten die meer dan 10 ms serialisatievertraging hebben, moeten worden gefragmenteerd in 10 ms-chunks. Een 10 ms chunk of fragment is het aantal bytes dat over de link wordt verzonden in 10 ms. Bereken de grootte met behulp van de koppelingssnelheid, zoals in dit voorbeeld:

• Fragmentation size = (0,01 seconden * 64.000 bps) / (8 bits/byte) = 80 bytes

Het duurt 10 ms om een pakket of fragment van 80 bytes te verzenden via een 64 kbps link.

In het geval van meerdere ATM of Frame Relay Permanent Virtual Circuits (PVC’s) op één fysieke interface configureert u fragmentatiewaarden (op alle PVC’s) op basis van het PVC dat de laagste beschikbare bandbreedte heeft. Als er bijvoorbeeld drie PVC’s zijn met een gegarandeerde bandbreedte van 512 kbps, 128 kbps en 256 kbps, configureer dan alle drie PVC’s met een fragmentgrootte van 160 bytes (de laagste snelheid is 128 kbps, waarvoor een fragmentgrootte van 160 bytes vereist is). Deze waarden worden aanbevolen voor verschillende koppelingssnelheden:

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

Opmerking: geen fragmentatie is vereist als de fragmentgrootte groter is dan de koppeling MTU-grootte. Bijvoorbeeld, voor een T1 verbinding met een 1500 byte MTU, is de fragmentgrootte 1920 bytes. Daarom is geen fragmentatie vereist. De grootte van de pakketfragmentatie zou nooit lager moeten zijn dan de het pakketgrootte van VoIP. VoIP-pakketten niet fragmenteren. Het fragmenteren van deze pakketten veroorzaakt talrijke vraagopstelling en kwaliteitskwesties.

Er zijn momenteel drie mechanismen voor koppelingsfragmentatie en interleaving beschikbaar. Voor verdere uitleg van verschillende vertragingen die in een pakketnetwerk zijn geïntroduceerd, raadpleegt u Vertraging begrijpen in Packet Voice-netwerken. Deze tabel geeft een overzicht van de voordelen en beperkingen:

Link Fragmentation and Interleaving (LFI)-mechanisme	Beschrijving	Voordelen	Beperkingen
MTU fragmentatie met WFQ	Opdracht Interfaceniveau om MTU-grootte of IP MTU-grootte te wijzigen Gebruikt om grote IP pakketten te fragmenteren aan gespecificeerde MTU grootte. LFI gebruikt WFQ om real-time pakketten tussen de fragmenten door te laten lopen.	Eenvoudige configuratie.	Fragmenten worden alleen door de ontvangende applicatie gereconstrueerd. Daarom is inefficiënt gebruik van het netwerk noodzakelijk. Alleen IP-pakketten met de optie Geen fragment (DF)-bit niet instellen kunnen fragmentatie goed verwerken. Zeer processorintensief. Niet aanbevolen.
Multilink Point-to-Point Protocol (MLPPP) LFI	Op point-to-point seriële links moet MLPPP eerst worden geconfigureerd en moet vervolgens een fragmentatiegrootte in ms worden ingesteld. Interleaving moet ook zijn ingeschakeld op de interface van de multilink.	De pakketten zijn versplinterd op één eind van de verbinding en bij andere opnieuw gemonteerd. Verscheidene verbindingen kunnen worden gecombineerd om als grote virtuele pijp te fungeren.	Alleen beschikbaar op koppelingen die zijn geconfigureerd voor PPP. Oplossingen voor PPP via Frame Relay of PPP over ATM worden ook ondersteund in Cisco IOS-softwarerelease 12.1(5)T of hoger.
Frame Relay Fragmentation (FRF.12)	Op Frame Relay PVC’s moet de opdracht Frame Relay Traffic Shaping worden ingeschakeld en moet een fragmentatiegrootte worden ingesteld onder de kaartklasse.	De pakketten zijn gefragmenteerd op één eind van pvc en aan de andere opnieuw gemonteerd.	Alleen beschikbaar op Frame Relay PVC’s met de opdracht Frame Relay Traffic Shaping ingeschakeld.

VAD

Een regulier spraakgesprek bestaat uit verschillende momenten van stilte. Een typisch gesproken woord bestaat uit 40 tot 50 procent stilte. Aangezien er geen spraak door het netwerk gaat voor 40 procent van een spraakoproep, kan enige bandbreedte worden opgeslagen door VAD te implementeren. Met VAD kijkt de gateway uit naar spraakgaten. Het vervangt deze gaten door comfortgeluid (achtergrondgeluid). Aldus, wordt een hoeveelheid bandbreedte opgeslagen. Er is echter sprake van een afweging. Er is een kleine tijd (in volgorde van milliseconden) voordat de codecs spraakactiviteit detecteren, gevolgd door een periode van stilte. Deze kleine tijd resulteert in het front-end knippen van ontvangen stem. Om activering tijdens zeer korte pauzes te vermijden en om het knippen te compenseren, wacht VAD ongeveer 200 ms nadat de toespraak stopt alvorens de transmissie te stoppen. Na het hervatten van de transmissie, bevat het de vorige 5 ms van toespraak samen met de huidige toespraak. VAD schakelt zichzelf automatisch uit op een oproep als omgevingsgeluid voorkomt dat er onderscheid wordt gemaakt tussen spraak- en achtergrondgeluid. Als de bandbreedte echter geen probleem is, schakelt u de VAD uit.

Tune VAD-parameters

Er zijn twee parameters die de werking van VAD bepalen. Dit zijn de opdrachten muziek-drempel en spraak vad-tijd.

muziekdrempel

Een eerste drempelwaarde wordt bepaald die bepaalt wanneer VAD actief moet worden. Dit wordt gecontroleerd door de muziek-drempel drempelwaarde opdracht op een spraak-poort te definiëren, zoals in dit voorbeeld wordt getoond. Het bereik hiervoor is van -70 decibels per Milliwatt (dBm) tot -30 dBm. De standaardwaarde hiervoor is -38 dBm. Als u een lagere waarde instelt (naar -70 dBm), wordt VAD actief met een veel lagere signaalsterkte (het volume moet heel laag dalen voordat het als stilte wordt beschouwd). Als u een hogere waarde instelt (dichter bij -30 dBm), wordt VAD actief voor zelfs een kleine daling in de sterkte van het spraaksignaal. Het drijft de playout om comfort geluidspakketten vaker te spelen. Dit leidt soms echter tot een klein knipsel van 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

spraakvad-tijd

Zodra de VAD actief wordt, wordt de component van achtergrondruis en comfortruis bepaald door de spraak vad-time timer_value-opdracht te configureren onder de globale configuratie, zoals in dit voorbeeld wordt getoond. Dit is de vertragingstijd in milliseconden voor stiltedetectie en onderdrukking van spraakpakkettransmissie. De standaardwaarde voor de houdtijd is 250 msec. Dit betekent dat binnen 250 msec comfort lawaai begint. Het bereik van deze timer is 250 msec tot 65536 msec. Als hiervoor een hoge waarde is ingesteld, komt comfort ruis veel later in het spel (achtergrondruis blijft spelen). Als dit voor 65536 msec is ingesteld, wordt de comfortruiming uitgeschakeld. Een hogere waarde voor deze timer is gewenst voor een vloeiende overgang tussen achtergrondruis en comfortruis. Het nadeel aan het configureren van de spraak vad-time opdracht op een hoog niveau is dat het niet de gewenste 30 tot 35 procent bandbreedte besparing.

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 configuratievoorbeelden voor QoS

Een typisch scenario voor het instellen van VoIP-oproepen is via een Frame Relay-link of via een PPP-link. Dit zijn configuratievoorbeelden voor deze scenario's.

VoIPoFR - QoS-configuratievoorbeeld

In dit voorbeeld (dat alleen relevante secties van de configuratie bevat) wordt aangenomen dat de frame-relay-circuitsnelheid 256 kbps is. De gegarandeerde gecommitteerde informatiesnelheid (CIR) op PVC 100 is 64 kbps en op PVC 200 is 192 kbps. PVC 100 wordt gebruikt om zowel gegevens als spraak te dragen. PVC 200 wordt uitsluitend gebruikt voor het vervoer van gegevens. Een maximum van vier gelijktijdige stemoproepen bestaat op elk gegeven moment. Configuratie van fragmentatie op beide PVC’s op basis van de CIR van de laagste bandbreedte-spraak-PVC (PVC-transportstem). Gebaseerd op de voorbeelden in dit document, betekent dat de fragmentatiegrootte wordt bepaald gebaseerd op PVC 100's CIR (die 64 kbps is). Zoals in de tabel van de sectie Serialization Delay wordt getoond, is voor een 64 kbps link een fragmentatiegrootte van 80 bytes vereist. De zelfde fragmentatiegrootte moet voor PVC 200 worden gevormd.

Raadpleeg voor meer informatie over de configuratie van VoIP via Frame Relay VoIP via Frame Relay met Quality of Service (Fragmentation, Traffic Shaping, LLQ/IP RTP-prioriteit).

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

In dit voorbeeld (dat alleen relevante secties van de configuratie bevat) wordt aangenomen dat de QoS moet worden geconfigureerd voor een point-to-point fractionele T1-controller (die twaalf kanalen heeft). Een maximum van vier gelijktijdige stemoproepen bestaat op elk gegeven moment. De configuratietaak houdt in dat deze seriële interface met PPP-insluiting moet worden geconfigureerd, dat deze deel uitmaakt van een multilink-groep, een multilink-interface moet worden gemaakt (die tot dezelfde multilink-groep behoort) en alle QoS op de multilink-interface moet worden geconfigureerd. Raadpleeg voor meer informatie over de configuratie van VoIP over PPP VoIP over PPP Links with Quality of Service (LLQ/IP RTP-prioriteit, 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- en playout-mechanisme

Er zijn altijd enkele ongecontroleerde entiteiten in een netwerk die bijdragen aan verdere vertragingen en jitter in de ontvangen spraakpakketten. Door de jitterbuffer op de eindigende gateway te wijzigen wordt de ongecontroleerde jitter opgelost in het spraaknetwerk.

mechanisme voor playout

De jitterbuffer is een tijdbuffer. Het wordt verstrekt door de het eindigen gateway om het playout mechanisme effectiever te maken. Dit is een functioneel diagram van het afspeelmechanisme:

Wanneer de afspeelcontrole een spraakpakket ontvangt, analyseert het de RTP-tijdstempel. Als het spraakpakket langer wordt uitgesteld dan de holdingcapaciteit van de jitter-buffer, wordt het pakket onmiddellijk gedropt. Als het pakket binnen de buffercapaciteit valt, wordt het in de jitterbuffer geplaatst. De locatie van dit pakket in de jitter buffer is afhankelijk van de RTP-tijdstempel die voor dat pakket is berekend. In de gebeurtenis is er geen beschikbaar spraakpakket, probeert de afspeelcontrole het te verbergen (voorspelt het gemiste pakket). Als VAD is ingeschakeld, wordt comfort ruis afgespeeld.

De verantwoordelijkheid van de playout controle is om de gebeurtenissen van verloren pakketten, gedupliceerde pakketten, bedorven pakketten, en uit-van-opeenvolgingspakketten te behandelen. Deze gebeurtenissen worden behandeld door de tijd uit te lijnen de uitgelijnde spraakpakketten, het spelen van comfort lawaai (als VAD is geconfigureerd), of zelfs het regenereren van dual tone multifrekwentie (DTMF) tonen om te worden gespeeld aan de host.

Het verbergen van een spraakpakket gebeurt door het verbergen van een voorspelling of door het verbergen van een stilte. Het verbergen van voorspellingen is gebaseerd op het vorige pakket en het volgende pakket (indien beschikbaar). Het werkt het beste met lage bitrate codecs (5 kbps tot 16 kbps). Verlies van spraakpakketten voor een hoge bitrate codec (32 kbps tot 64 kbps) kan mogelijk resulteren in slechte voorspellingsverborgen. Het verhullen van voorspellingen begint wanneer er weinig en zeldzame vertragingen of een lager aantal pakketverlies zijn. Te veel verhulling van voorspellingen kan leiden tot robotspraakkwaliteit. Het stilzwijgen is de slechtste vorm van het verbergen van voorspellingen. Het speelt een rol als er geen informatie beschikbaar is om te voorspellen. Het is eenvoudigweg een verhulling van de achtergrond. Het begint wanneer er hoge vertragingen en meer pakketverlies zijn. Te veel stilzwijgen verhulling leidt tot haperende stemkwaliteit. De voorspellingsverberging is goed voor 30 msec waarna het stilzwijgen in het spel komt.

Jitter Buffer

De jitterbuffer wordt begrensd door een hoog watermerkteken en een laag watermerkteken. Het hoge watermerk is de hoogste tijdslimiet waarbinnen een pakket naar verwachting zal aankomen voor on-time playout. Pakketten die na de hoge watermarkering aankomen, worden gemarkeerd als late pakketten of verloren pakketten. Het lage watermerk is de minimumtijd waarbinnen een pakket naar verwachting op tijd zal aankomen voor playout. Pakketten die aankomen voor de lage watermarkering worden beschouwd als vroege pakketten (het kan nog steeds op tijd worden gespeeld).

Als de afsluitende gateway een toename blijft zien in de aankomst van late pakketten, verhoogt het de hoge watermarkering. Deze waarde voor een hoog watermerk blijft tijdens de gehele duur van de oproep gelijk. Dit wordt verhoogd tot een maximum dat in de configuratie is gedefinieerd. Op een gelijksoortige manier observeert de afsluitende gateway het aantal vroege ontvangen pakketten. Als deze pakketten beginnen de toegangspoort te bezoeken, vermindert het de laagwatermarkering. Deze waarde blijft gelijk tijdens de duur van de oproep. Deze modus van jitterbuffer wordt "adaptieve modus" genoemd, waarbij de afsluitende gateway de jitterbuffer aanpast op basis van het verkeerspatroon. De andere modus is "vaste modus". In de vaste modus is er één beginwaarde voor de laagwatermarkering en de hoogwatermarkering. Deze waarde is gebaseerd op de geschatte ontvangen vertraging (zie de sectie spraakoproep <poortnummer> van dit document).

Raadpleeg Jitter in Packet Voice Networks (Cisco IOS-platforms) voor meer informatie over jitterbuffer.

Vertraging en jitter identificeren

In deze sectie wordt beschreven hoe u jitter in uw netwerk kunt identificeren.

toon vraag actieve stem

De show call active voice opdracht geeft veel informatie over een lopende gesprek. Deze output toont sommige belangrijke punten die van dit bevel worden geleerd:

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

Van de output van het bevel van de showvraag de actieve stem korte, ziet u dat wat op het been van de Telefonie wordt ontvangen (rx:7044) aan het IP been (tx:7044) wordt overgebracht. Hetzelfde geldt voor pakketten die op de IP-poten (26165) worden ontvangen en naar het telefoniegedeelte (26157) worden doorgestuurd. Het verschil in het aantal pakketten dat op het IP-deel wordt ontvangen ten opzichte van het aantal pakketten dat op het telefoniedeel wordt verzonden, wordt bijgedragen aan late pakketten die het niet op tijd halen.

Deze output van de show call active voice commando (zonder het "korte" sleutelwoord) wijst naar verdere details over parameters die jitter direct identificeren.

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

spraakoproep tonen <poortnummer>

Het poortnummer-opdracht voor spraakoproep in de show biedt nuttige informatie. Zorg ervoor dat u in de gateway bent getroost of als u in een gateway bent geTelneted, zorg ervoor dat u de opdracht voor de eindmonitor vanaf het exectieniveau hebt uitgegeven.

Opmerking: deze opdracht is niet beschikbaar voor het AS5x00/AS5x50-platform.

In deze output is de waarde voor Rx Delay Test (ms) 71. Dit is de huidige waarde van de jitterbuffer. Hierop wordt een waarde voor het hoge en het lage waterniveau afgeleid. Een gemiddelde initiële waarde voor de hoge waterlijn is 70 msec, terwijl die voor de lage waterlijn 60 msec bedraagt. Zodra een eerste waarde is ingesteld, houdt de gateway bij welke vroege pakketten of late pakketten zijn ontvangen. Zoals te zien is in de output hier, zijn de voorspellingsverzegeling dalingen bijna 250 ms, terwijl de stilte verzwijging 30 ms is. Er is altijd een hogere waarde voor het verbergen van voorspellingen, omdat het verbergen van stilte slechts een slechter geval van het verbergen van voorspellingen is. Voor elke Voorspelling verberging daling, is er een verhoging van de buffer overflow verwerping.

Als je de buffer ziet weggooien, betekent dit niet per se dat je een stijging ziet in de hoge watermarkering. De hoge watermarkering is de bovengrens van de jitterbuffer. Het verandert alleen als een trend wordt waargenomen. Met andere woorden, er moet een continue stroom van late pakketten zijn. Dit resulteert in een verhoging van de jitterbuffer. In de productie hier is een dergelijke trend aanwezig. Daarom wordt het hoogwaterniveau verhoogd van 70 msec tot 161 msec. Als deze waarde niet wordt veranderd (en als je nog steeds 14 late pakketten ziet), impliceert dit dat dit sporadische late pakketten zijn, niet een trend.

Van de output van het bevel van de showvraag actieve stem, let op verloren pakketten. Voor elk verloren pakket, ziet u twee pakketten die uit opeenvolging zijn. Dit is te zien op de Rx Non-Seq Pkts uitvoer. Aangezien de waarde niet positief is, wordt geconcludeerd dat er ook geen pakketverlies is opgetreden.

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

Neem de Tx Comfort Pkts en Rx Comfort Pkts in acht. Als uit de voorbeeldoutput, wordt geconcludeerd dat de telefoon die met deze router wordt aangesloten meestal stil houdt aangezien u veel van Pkts van Tx Comfort hebt. Op hetzelfde moment heb je Rx Comfort Pkts, wat betekent dat het andere uiteinde voortdurend spreekt.

Vergelijk de output hier met de vorige beveloutput. Er is een verhoogd aantal Rx Late Pkts (van 14 tot 26). De waarde van het hoogwaterniveau neemt echter niet toe. Dit duidt erop dat de 12 pakketten sporadisch worden vertraagd. De Buffer Overflow verwerping wordt verhoogd tot 910 msecs. Aangezien er echter geen trend wordt waargenomen, wordt de hoogwatergrens niet verhoogd.

In de output hier, heb je een Rx Vroege Pkts: 3. Dit betekent dat een pakketje veel aankomt voordat het wordt verwacht. Zoals uit de output hier te zien is, heeft de Jitter buffer zich gespannen om voor meer vroege pakketten te kunnen voorzien door het lage waterniveau te verlagen van 60 naar 51.

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 Buffer op een gateway configureren

De QoS richtlijnen die in dit document worden behandeld behandelen de veranderlijke of verslechterde stemkwaliteitskwestie. De configuratie van de buffer van de playout-vertraging is een tijdelijke oplossing voor onjuiste QoS-implementatie in het netwerk. Gebruik dit alleen als een stop-gap fix of als een tool voor probleemoplossing en het verkleinen van de jitter problemen die in het netwerk geïntroduceerd worden.

Modus voor playout-vertraging

De jitterbuffer is ingesteld voor de vaste of de adaptieve modus. In de adaptieve modus kunt u met de gateway een minimumwaarde voor de jitterbuffer, een maximumwaarde en een nominale waarde instellen. De jitterbuffer verwacht dat de pakketten binnen het nominale waardebereik aankomen. De nominale waarde dient gelijk te zijn aan of groter dan het minimum en gelijk te zijn aan of kleiner dan het maximum. De buffer breidt zich uit tot de maximum geconfigureerde waarde. Dit kan tot 1700 msec verlengen. Een probleem bij het configureren van een hoge maximale waarde is de introductie van end-to-end vertraging. Kies de waarde van maximale playout-vertraging zodat het geen ongewenste vertraging in het netwerk introduceert. Deze output is een voorbeeld van de jitterbuffer die voor adaptieve modus is geconfigureerd:

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
!

Onder de vaste modus bekijkt de gateway de ingestelde waarde voor nominaal. Hoewel het u toestaat om de minimum en maximum waarde voor playout-vertraging te vormen, wordt het genegeerd wanneer gevormd voor vaste wijze. In de vaste modus blijft de hoogwatermarkering of de laagwatermarkering altijd constant. Deze is gebaseerd op de nominale waarde en de Rx Delay Est (ms) waarde. Zo is het mogelijk dat onder de vaste modus, u de waarde configureren als 200 msec. Als de geschatte ontvangen vertraging echter dicht bij 100 ms ligt, is dat wat het hoge waterniveau en het lage waterniveau voor de gehele duur van de oproep zijn.

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
!

Raadpleeg Verbeteringen in afspeelvertraging voor Voice over IP voor meer informatie over de configuratie van afspeelvertraging.

Gerelateerde informatie

• Quality-of-Service beleid met DSCP implementeren
• Low Latency Queueing
• Vergelijken van de bandbreedte en prioriteit van een QoS-servicebeleid
• Link Fragmentation and Interleaving configureren voor Frame Relay en virtuele ATM-circuits
• Link Fragmentation and Interleaving configureren voor Multilink PPP
• Spraaktechnologie-ondersteuning
• Productondersteuning voor spraak en Unified Communications
• Probleemoplossing voor Cisco IP-telefonie
• Technische ondersteuning – Cisco Systems