De betekenis van Jitter in Packet Voice Networks (Cisco IOS-platforms)
Inhoud
Inleiding
In dit document wordt beschreven hoe u het kunt meten en compenseren.
Voorwaarden
Vereisten
Lezers van dit document zouden kennis moeten hebben van deze onderwerpen:
-
Basis Cisco IOS®-spraakconfiguratie
-
Basis begrip van Quality of Service (QoS)
Gebruikte componenten
De informatie in dit document is van toepassing op Cisco IOS spraakgateways en routers.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
Conventies
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
Jitter in Packet Voice-netwerken
Jitter is gedefinieerd als een variatie in de vertraging van ontvangen pakketten. Bij het verzenden worden de pakketten in een ononderbroken stroom verzonden en worden de pakketten gelijkmatig verdeeld. Als gevolg van netwerkcongestie, ongeschikte wachtrijen of configuratiefouten kan deze steady-state klonteren of kan de vertraging tussen elk pakket variëren in plaats van een constante te blijven.
In dit schema is aangegeven hoe een vaste stroom pakketten wordt verwerkt.
Wanneer een router een Real-Time Protocol (RTP) audiostream voor Voice-over-IP (VoIP) ontvangt, moet deze compensatie voor de gebeurtenis die wordt aangetroffen. Het mechanisme dat deze functie verwerkt is de buffer van de afspeelvertraging. De buffer van de uitloopvertraging moet deze pakketten buffer bevatten en dan in een stabiele stroom uitspelen naar de digitale signaalprocessors (DSP's) die moeten worden geconverteerd naar een analoge audiostroom. De buffer van de uitloopvertraging wordt soms ook de dejitterbuffer genoemd.
In dit schema is aangegeven hoe er met Jitter wordt omgegaan.
Als de jitter zo groot is dat er pakketten uit het bereik van deze buffer worden ontvangen, worden de out-of-range pakketten weggegooid en worden de uitgangen in de audio gehoord. Voor verliezen zo klein als één pakje, interpoleert DSP wat het meent dat de audio zou moeten zijn en geen probleem hoorbaar is. Wanneer jitter groter is dan wat DSP kan doen om de ontbrekende pakketten in te vullen, worden de audioproblemen gehoord.
In dit schema is aangegeven hoe er met buitensporige scherpte wordt omgegaan.
Bepaal de ernst van Jitter
De aanwezigheid van buitensporige brief kan door Cisco IOS worden bevestigd door deze stappen te voltooien.
-
Zodra een vraag omhoog en actief is, en jitter wordt vermoed, telnet aan één van de betrokken gateways.
-
Laat de monitor van het terminal toe om console berichten door uw zitting van Telnet te kunnen zien.
Opmerking: deze stap is niet nodig als u bent verbonden met de console-poort.
-
Voer de opdracht voor korte spraakoproepen in. soortgelijke uitvoer wordt weergegeven:
PORT CODEC VAD VTSP STATE VPM STATE ============ ======== === ==================== ====================== 1/0/0 - - - FXSLS_ONHOOK 1/0/1 g729r8 y S_CONNECT FXSLS_CONNECT
Selecteer de aanroep waar de illustrator voorkomt. In dit voorbeeld is het 1/0/1.
-
Om deze specifieke vraag te bekijken, voer de show spraakaanroep opdracht in.
In dit voorbeeld, is het tonen stemvraag 1/0/1. De output die wordt gegeven komt van DSP dat de vraag behandelt en is gelijkaardig aan dit:
1/0/1 vtsp level 0 state = S_CONNECT vpm level 1 state = FXSLS_CONNECT vpm level 0 state = S_UP MS-2621-3B# ***DSP VOICE VP_DELAY STATISTICS*** Clk Offset(ms): 0, Rx Delay Est(ms): 50 Rx Delay Lo Water Mark(ms): 50, Rx Delay Hi Water Mark(ms): 7 ***DSP VOICE VP_ERROR STATISTICS*** Predict Conceal(ms): 0, Interpolate Conceal(ms): 0 Silence Conceal(ms): 0, Retroact Mem Update(ms): 0 Buf Overflow Discard(ms): 0, Talkspurt Endpoint Detect Err: 0 ***DSP VOICE RX STATISTICS*** Rx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: 0 Rx Dur(ms): 150200, Rx Vox Dur(ms): 23740, Rx Fax Dur(ms): 0 Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0 Rx Early Pkts: 0, Rx Late Pkts: 0 ***DSP VOICE TX STATISTICS*** Tx Vox/Fax Pkts: 7129, Tx Sig Pkts: 0, Tx Comfort Pkts: 0 Tx Dur(ms): 150200, Tx Vox Dur(ms): 14259, Tx Fax Dur(ms): 0 ***DSP VOICE ERROR STATISTICS*** Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0 ***DSP LEVELS*** TDM Bus Levels(dBm0): Rx -54.5 from PBX/Phone, Tx -64.7 to PBX/Phone TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +9.9 TDM Bgd Levels(dBm0): -49.4, with activity being voice -
Bekijk het ***DSP VOICE VP_FOUT STATISTICS***-gedeelte in de uitvoer.
In dit hoofdstuk zijn er verschillende parameters om naar te kijken. De belangrijkste is het aantal zichtbare Buf Overflow Discard (ms). Dit telt de pakketten die buiten bereik zijn voor de afspeelvertragingsbuffer (laten vallen). Dit kan enige waarde in hebben, zolang het niet voortdurend toeneemt. Het is normaal om wat overstromen te krijgen wanneer een vraag eerst in werking wordt gesteld, maar deze waarde zou niet moeten stijgen wanneer de opdracht van de showstem X/X/X wordt herhaald. Dit getal is een directe aanwijzing voor excessieve jitter.
Standaard past deze buffer op een adaptieve modus aan, waarbij hij dynamisch de hoeveelheid aanwezige ruimte aanpast (tot een punt). Configureer de opdracht playout-vertraging om de standaardwaarden voor het dynamische gedrag van de de-jitter buffer te wijzigen. Deze buffer kan ook in de vaste modus worden ingesteld. Dit kan een aantal problemen oplossen met jitter. Raadpleeg voor meer informatie de verbeteringen in de lay-out bij de uitgestelde vertraging voor Voice-over-IP.
Wat veroorzaakt Jitter?
Jitter wordt in het algemeen veroorzaakt door congestie in het IP-netwerk. De congestie kan op de routerinterfaces of in een provider- of dragernetwerk optreden als het circuit niet correct is voorzien.
Insluitingsoverwegingen
De makkelijkste en beste plaats om te beginnen met het zoeken naar jitter is bij de routerinterfaces omdat u directe controle hebt over dit deel van het circuit. Hoe u de bron van de jitter volgt, hangt zeer van de insluiting en het type van verbinding af waar de jitter gebeurt. Meestal ervaren ATM-circuits jitter niet wanneer ze correct zijn geconfigureerd vanwege de constante mobiele snelheid in kwestie. Dit geeft een zeer consequent uitstel. Als de jitter in een ATM-omgeving wordt gezien, is een onderzoek van de ATM-configuratie nodig. Wanneer ATM correct werkt (geen ingetrokken cellen) kunt u verwachten dat jitter een niet-probleem is. In Point-to-Point Protocol (PPP)-insluiting is Jitter bijna altijd te wijten aan vertraging van de servering. Dit kan eenvoudig worden beheerd met Link Fragmentation en Interleaving op de PPP-link. De aard van PPP betekent dat PPP eindpunten rechtstreeks met elkaar praten, zonder een netwerk van switches tussen hen. Dit is zodat de netwerkbeheerder controle heeft over alle betrokken interfaces.
Jitter in een Frame Relay-omgeving
Er moeten drie parameters worden gericht om de tekst in een Frame Relay-omgeving te vinden:
Raadpleeg VoIP via Frame Relay met Quality of Service voor configuratie van deze configuratie.
traffic shaping
U moet ervoor zorgen dat u het verkeer vormgeeft dat de router verlaat tot het huidige Committed Information Rate (CIR) dat de luchtvaartmaatschappij biedt. Controleer dit door te kijken naar de Frame Relay-statistieken en controleer deze bij de vervoerder. De eerste plaats om te kijken is naar de Frame Relay statistieken. Gebruik de opdracht frame-relais pvc xx, waarbij xx het DLCI-nummer (Data-Link Connection identifier) is. U zou soortgelijke uitvoer moeten ontvangen:
PVC Statistics for interface Serial0/1 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1 input pkts 103611 output pkts 120054 in bytes 9909818 out bytes 10962348 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 1366 out bcast bytes 448048 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 22:45:57, last time pvc status changed 22:45:57 Queueing strategy: weighted fair Current fair queue configuration: Discard Dynamic Reserved threshold queue count queue count 64 16 0 Output queue size 0/max total 600/drops 18303 fragment type end-to-end fragment size 1600 cir 20000 bc 1000 be 0 limit 125 interval 50 mincir 20000 byte increment 125 BECN response no IF_CONG no frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120 shaping active traffic shaping drops 18303
Raadpleeg de beschrijving van het frame-relais van het frame voor een volledige uitleg van alle velden.
Wat u moet zoeken
Wat u in de opdrachtoutput bezig zou moeten zijn, zijn de waarden die tonen als er opstopping is in het frame-netwerk. Deze waarden zijn de voorwaartse expliciete congestievermelding (FECN), achterwaartse expliciete congestievermelding (BECN) en de in aanmerking komende (DE) parameters van de teruggooi. U dient zich alleen bezig te houden met invoerpakketten omdat Cisco deze niet verzonden. U kunt een of meer van deze waarden zien toenemen. Dit is afhankelijk van het type en de configuratie van de switches van het frame die de provider gebruikt. In algemene termen, als u Frame Relay traffic shaping hebt en voor dezelfde CIR is geconfigureerd als het circuit, zou u deze waardenverhoging nooit moeten zien. Als u deze waardenverhoging ziet en u past de ware CIR van het circuit aan, dan wordt iets in het netwerk van de frame provider niet goed ingesteld.
Een goed voorbeeld hiervan is als je een nul CIR-circuit koopt, maar een barstwaarde heeft. Sommige aanbieders verkopen het nulcr permanent virtueel circuit (PVC). Dit is prima voor gegevens, maar veroorzaakt problemen met de spraakkwaliteit. Als u de opdrachtoutput van een circuit met nul probeert te selecteren, is het aantal D- of FECN-pakketten gelijk aan het aantal ingangspakketten. Om deze stap verder te zetten, als je een PVC hebt dat door de drager is uitgerust met 128 kbs en de CIR van de router is ingesteld op 512 kbs, zie je de toename van deze tellers (in een trager tempo). Denk eraan dat u alleen pakketten kijkt die in de router interface komen en dat dit tarief wordt gecontroleerd door de traffic-shaping parameters die op de router aan het tegenovergestelde einde van PVC zijn geconfigureerd. Omgekeerd controleert u wat er wordt ingevoerd in de andere router waardoor traffic-shaping parameters op het lokale einde zijn ingesteld.
Het is erg belangrijk dat u de CIR niet overschrijdt voor het PVC dat door de drager is bevoorraad. U kunt onder deze CIR zijn zonder problemen. Als je het echter overschrijdt, zie je congestie.
De reden dat u de congestie op deze manier kunt zien is omdat de CIR die voor een specifiek PVC op een frame-switch is ingesteld, de snelheid dicteert dat het verkeer door die switch (voor dat PVC) wordt doorgegeven. Wanneer de geconfigureerde CIR op de frame-switch wordt overschreden door het werkelijk ontvangen gegevenstarief, moet deze de frames buffer vormen die de CIR overschrijden, totdat de capaciteit beschikbaar is om de gebufferde pakketten door te sturen. Elk pakket dat wordt gebufferd krijgt de DE bit set of het FECN bit ingesteld door de frame switch.
Zoals altijd, wilt u ook de interfacestatistieken zorgvuldig onderzoeken, en naar druppels of fouten zoeken om zeker te zijn dat alles correct functioneert op de fysieke laag. Om dit te doen, gebruik de opdracht van de showinterface.
Hoe dit op jitter betrekking heeft is als dit voorkomt, en sommige pakketten moeten in het frame netwerk worden gebufferd, hebben zij een langere vertraging in het krijgen van de verre router. Maar als er geen congestie is, komen ze door in de latentietijd die je normaal verwacht. Dit veroorzaakt een variatie in de delta tijd tussen pakketten die bij de verre router worden ontvangen. Vandaar, Jitter.
fragmentatie
Fragmentation associeert meer met seringsvertraging dan met jitter. Onder bepaalde omstandigheden kan dit echter de oorzaak van de kritiek zijn. Fragmentation moet altijd in de Frame Relay-kaartklasse worden geconfigureerd bij het doen van gepakketeerde spraak. De configuratie van deze parameter heeft twee effecten op de interface. Het eerste effect is dat alle pakketten die groter zijn dan de gespecificeerde grootte gefragmenteerd zijn. Het tweede effect is minder duidelijk, maar is net zo belangrijk. Als je kijkt naar de interface waarop fragmentatie is ingesteld, kun je het effect van deze opdracht zien. Zonder fragmentatie toont de wachtrijstrategie die in de uitvoer van de show interface x opdracht wordt getoond dat first in first out (FIFO) wachtrij in gebruik is. Zodra fragmentatie is toegepast op de Frame Relay-kaartklasse, toont de uitvoer van deze opdracht de wachtrij-strategie als dubbel-FIFO. Dit creëert de prioriteitswachtrij die wordt gebruikt voor spraakverkeer op de interface. Het is sterk gesuggereerd dat de fragmentatiewaarde wordt ingesteld op de waarden die geadviseerd worden in het Fragmentation-gedeelte van VoIP via Frame Relay met QoS-document. Als u nog steeds bittere problemen bij de aanbevolen waarde ervaart, verlaag dan de fragmentatiewaarde één stap tegelijk tot de spraakkwaliteit aanvaardbaar is.
Wachtrijen
Er zijn twee algemeen geaccepteerde wachtrijen methodes die voor VoIP-verkeer in dit soort omgeving worden gebruikt:
De ene methode of de andere moet worden gebruikt, ze moeten niet allebei worden ingesteld. Als de wachtrij volgens de documentatie juist lijkt, kunt u concluderen dat de wachtrij op de juiste manier werkt en dat het probleem elders ligt. Wachtrijen is over het algemeen geen reden tot jitter, omdat de verschillen in vertraging die door deze stijging worden veroorzaakt relatief klein zijn. Als VoIP-pakketten echter niet goed in de wachtrij worden geplaatst en er gegevens in hetzelfde circuit zijn, kan dit resulteren uit jitter.
Conclusie
Jitter is een variatie in pakketlatentie voor spraakpakketten. De DSP's binnen de router kunnen een of andere jitter compenseren, maar kunnen overwonnen worden door overdreven jitter. Dit leidt tot een slechte spraakkwaliteit. De oorzaak van jitter is dat een pakje ergens in het circuit in de wachtrij wordt geplaatst of wordt uitgesteld, waar geen vertraging of wachtrij voor andere pakketten bestaat. Dit veroorzaakt een variatie in latentie. Jitter kan zowel door routerverkeerde configuratie als door PVC-verkeerde configuratie door de drager of leverancier worden veroorzaakt.
Feedback