Comprensione dell'instabilità nelle reti voce dei pacchetti (piattaforme Cisco IOS)
Sommario
Introduzione
Questo documento descrive l'effetto jitter e come misurarlo e compensarlo.
Prerequisiti
Requisiti
Questo documento è utile per conoscere i seguenti argomenti:
-
Configurazione vocale base di Cisco IOS®
-
Conoscenze base di Quality of Service (QoS)
Componenti usati
Le informazioni riportate in questo documento si applicano a gateway e router voce Cisco IOS.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Convenzioni
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Jitter nelle reti voce dei pacchetti
L'instabilità è definita come una variazione nel ritardo dei pacchetti ricevuti. Sul lato di invio, i pacchetti vengono inviati in un flusso continuo tra loro in modo uniforme. A causa di congestione della rete, code non corrette o errori di configurazione, questo flusso stabile può diventare nodulare o il ritardo tra ciascun pacchetto può variare anziché rimanere costante.
Questo diagramma mostra come viene gestito un flusso costante di pacchetti.
Quando un router riceve un flusso audio RTP (Real-Time Protocol) per il protocollo VoIP (Voice over IP), deve compensare il jitter rilevato. Il meccanismo che gestisce questa funzione è il buffer di ritardo del playout. Il buffer del ritardo di riproduzione deve memorizzare questi pacchetti e quindi riprodurli in un flusso costante ai processori di segnale digitali (DSP) per riconvertirli in un flusso audio analogico. Il buffer del ritardo di playout è anche noto come buffer de-jitter.
Il diagramma mostra come viene gestito lo jitter.
Se il jitter è così grande da causare la ricezione di pacchetti fuori dall'intervallo di questo buffer, i pacchetti fuori intervallo vengono scartati e le interruzioni vengono udite nell'audio. Per perdite minime come un pacchetto, il DSP interpola ciò che ritiene debba essere l'audio e nessun problema è percepibile. Quando l'instabilità è superiore a quella che il DSP è in grado di fare per recuperare i pacchetti mancanti, si verificano problemi audio.
Questo diagramma mostra come viene gestito il jitter eccessivo.
Determinare la gravità della variazione
Completando questi passaggi, è possibile confermare la presenza di un tremolio eccessivo in Cisco IOS.
-
Quando una chiamata è attiva e si sospetta un tremolio, Telnet viene connesso a uno dei gateway interessati.
-
Abilitare Terminal Monitor per visualizzare i messaggi della console tramite la sessione Telnet.
Nota: questo passaggio non è necessario se si è connessi alla porta della console.
-
Immettere il comando show voice call summary. Viene visualizzato un output simile al seguente:
PORT CODEC VAD VTSP STATE VPM STATE ============ ======== === ==================== ====================== 1/0/0 - - - FXSLS_ONHOOK 1/0/1 g729r8 y S_CONNECT FXSLS_CONNECT
Selezionare la chiamata in cui si verifica lo jitter. Nell'esempio, questo valore è 1/0/1.
-
Per visualizzare la chiamata specifica, immettere il comando show voice call.
Nell'esempio, questo valore è show voice call 1/0/1. L'output restituito proviene dal DSP che gestisce la chiamata ed è simile al seguente:
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 -
Visualizzare la sezione ***DSP VOICE VP_ERROR STATISTICS*** nell'output.
In questa sezione è possibile esaminare diversi parametri. Il principale è il numero di byte ignorati (ms) rilevati. In questo modo vengono contati i pacchetti non compresi nell'intervallo per il buffer di ritardo del playout (scartati). Questo può avere un certo valore in esso, purché non aumenta costantemente. È normale ottenere degli overflow quando si avvia una chiamata, ma questo valore non deve aumentare quando si ripete il comando show voice call X/X/X. Questo numero è un'indicazione diretta di una variazione eccessiva.
Per impostazione predefinita, questo buffer viene eseguito in modalità adattiva in cui si regola dinamicamente in base alla quantità di variazione presente (fino a un punto). Configurare il comando playout-delay per modificare i valori predefiniti per il comportamento dinamico del buffer di deformazione. Questo buffer può essere impostato anche in modalità fissa. In questo modo è possibile risolvere alcuni problemi di jitter. Per ulteriori informazioni, fare riferimento a Miglioramenti del ritardo di riproduzione per Voice over IP.
Quali Sono Le Cause Dell'Instabilità?
Lo jitter è in genere causato da una congestione della rete IP. La congestione può verificarsi alle interfacce del router o in una rete del provider o del vettore se il provisioning del circuito non è stato eseguito correttamente.
Considerazioni sull'incapsulamento
Il punto più semplice e migliore da cui iniziare a cercare jitter è l'interfaccia del router, poiché si ha il controllo diretto su questa parte del circuito. Il modo in cui rintracciate la sorgente dello jitter dipende in gran parte dall'incapsulamento e dal tipo di collegamento in cui avviene lo jitter. In genere, i circuiti ATM non subiscono jitter quando configurati correttamente a causa della velocità costante delle celle interessate. Ciò garantisce una latenza molto uniforme. Se in un ambiente ATM si nota una variazione, è necessario esaminare la configurazione ATM. Se la funzione ATM funziona correttamente (senza celle eliminate), l'instabilità non è un problema. Nell'incapsulamento del protocollo PPP (Point-to-Point Protocol), la variazione è quasi sempre dovuta al ritardo di serializzazione. Questa funzionalità può essere gestita facilmente con Link Fragmentation and Interleaving sul collegamento PPP. La natura del PPP significa che gli endpoint PPP comunicano direttamente tra loro, senza una rete di switch. In questo modo, l'amministratore di rete può controllare tutte le interfacce coinvolte.
Variazione in un ambiente Frame Relay
Per individuare lo jitter in un ambiente Frame Relay, è necessario utilizzare tre parametri:
Per configurazioni di esempio e informazioni relative alla configurazione di questo elemento, fare riferimento a VoIP su Frame Relay con Quality of Service.
Traffic Shaping
È necessario accertarsi di configurare il traffico che lascia il router in modo che corrisponda alla velocità effettiva di commit delle informazioni (CIR, Committed Information Rate) fornita dal vettore. Verificarlo guardando le statistiche Frame Relay e controllando con il vettore. Per prima cosa è necessario esaminare le statistiche di Frame Relay. Usare il comando show frame-relay pvc xx , dove xx è il numero DLCI (Data-Link Connection Identifier). L'output dovrebbe essere simile al seguente:
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
Fare riferimento alla descrizione show frame-relay pvc per una spiegazione completa di tutti i campi.
Cosa cercare
Quello di cui dovreste preoccuparvi nell'output del comando sono i valori che mostrano se c'è stata congestione nella rete del frame. Questi valori sono i parametri FECN (forward explicit congestion notification), BECN (backward explicit congestion notification) e DE (rigetto idoneo). Dal momento che Cisco non invia nessuno dei due pacchetti, occorre preoccuparsi solo dei pacchetti di input. È possibile che uno o più di questi valori vengano incrementati. Dipende dal tipo e dalla configurazione dei frame switch usati dal provider. In termini generali, se si dispone di Traffic Shaping Frame Relay e si è configurati per lo stesso CIR del circuito, questi valori non devono mai aumentare. Se vedete che questi valori aumentano e corrispondono al vero CIR del circuito, qualcosa nella rete del frame provider non è configurato correttamente.
Un buon esempio è l'acquisto di un circuito CIR zero, ma con un valore burst. Alcuni fornitori vendono il circuito virtuale permanente (PVC) zero CIR. Questa operazione è ideale per i dati, ma causa problemi con la qualità della voce. Se si controlla l'output del comando da un circuito CIR zero, il numero di pacchetti DE o FECN è uguale al numero di pacchetti di input. Per fare un ulteriore passo avanti, se il provisioning del PVC del vettore è pari a 128 kbs e il CIR del router è impostato su 512 kbs, questi contatori vengono incrementati (a una velocità inferiore). Tenere presente che si esaminano solo i pacchetti che entrano nell'interfaccia del router e che questa velocità è controllata dai parametri di traffic-shaping configurati sul router all'estremità opposta del PVC. Al contrario, è possibile controllare gli input sull'altro router tramite i quali i parametri di traffic shaping vengono configurati sull'estremità locale.
È molto importante non superare il CIR per il PVC fornito dal vettore. Puoi essere al di sotto di questo CIR senza problemi. Tuttavia, se lo si supera, si verificherà una congestione.
Il motivo per cui si è in grado di individuare la congestione è che il CIR configurato per un PVC specifico su uno switch di frame determina la velocità con cui il traffico viene passato dallo switch (per quel PVC). Quando il CIR configurato sullo switch di frame viene superato dalla velocità dati effettiva che riceve, deve inserire nel buffer i frame che superano il CIR finché non è disponibile la capacità per inoltrare i pacchetti nel buffer. Ogni pacchetto memorizzato nel buffer ottiene il bit DE o il bit FECN impostato dal frame switch.
Come sempre, si desidera anche esaminare attentamente le statistiche dell'interfaccia e cercare eventuali cadute o errori per essere certi che tutto funzioni correttamente a livello fisico. A tale scopo, utilizzare il comando show interface.
In questo caso, la relazione con il jitter è che, quando alcuni pacchetti devono essere memorizzati nel buffer della rete del frame, hanno una latenza maggiore per raggiungere il router remoto. Tuttavia, quando non vi è congestione, queste vengono gestite nel tempo di latenza previsto. Ciò causa una variazione nel delta time tra i pacchetti ricevuti sul router remoto. Da qui, jitter.
Frammentazione
La frammentazione è associata più al ritardo di serializzazione che all'instabilità. Tuttavia, in determinate condizioni, può essere la causa di tremolio. È necessario configurare sempre la frammentazione nella classe mappa Frame Relay quando si esegue la voce su pacchetti. La configurazione di questo parametro ha due effetti sull'interfaccia. Il primo effetto è la frammentazione di tutti i pacchetti di dimensioni superiori a quelle specificate. Il secondo effetto è meno evidente, ma altrettanto importante. Se si controlla l'interfaccia su cui è configurata la frammentazione, si osserverà l'effetto del comando. Senza frammentazione, la strategia di accodamento mostrata nell'output del comando show interface x mostra che la coda FIFO (First In First Out) è in uso. Dopo aver applicato la frammentazione alla classe Frame Relay map, l'output di questo comando visualizza la strategia di coda come Dual-FIFO. In questo modo viene creata la coda di priorità utilizzata per il traffico vocale sull'interfaccia. È consigliabile impostare il valore di frammentazione sui valori consigliati nella sezione Fragmentation del documento VoIP over Frame Relay with QoS. Se si verificano ancora problemi di jitter al valore consigliato, abbassare il valore di frammentazione un passo alla volta finché la qualità della voce non diventa accettabile.
Accodamento
Esistono due metodi di coda generalmente accettati per il traffico VoIP in questo tipo di ambiente:
Si consiglia di utilizzare uno dei due metodi, ma non entrambi. Se, in base alla documentazione, l'operazione di accodamento risulta corretta, è possibile concludere che la coda funziona correttamente e che il problema si trova altrove. L'accodamento in genere non è una causa di instabilità, poiché le variazioni di ritardo da esso create sono relativamente piccole. Tuttavia, se i pacchetti VoIP non vengono accodati correttamente e vi sono dati sullo stesso circuito, può verificarsi uno jitter.
Conclusioni
Lo jitter è una variazione della latenza dei pacchetti voce. I DSP all'interno del router possono compensare una certa variazione, ma possono essere superati da una variazione eccessiva. Il risultato è una scarsa qualità della voce. La causa di questo tremolio è che un pacchetto viene messo in coda o ritardato in qualche punto del circuito, senza ritardi o code per altri pacchetti. Ciò provoca una variazione della latenza. L'instabilità può essere causata sia da una configurazione errata del router sia da una configurazione errata del PVC da parte del vettore o del provider.
Feedback