Risoluzione dei problemi relativi alla voce Chopy QoS

Introduzione

Affinché Packet Voice sostituisca in modo realistico i servizi di telefonia PSTN (Public Switched Telephone Network) standard, la qualità ricevuta di Packet Voice deve essere comparabile a quella dei servizi telefonici di base. Ciò significa trasmissioni vocali di elevata qualità. Come altre applicazioni in tempo reale, Packet Voice ha un'ampia larghezza di banda ed è sensibile al ritardo. Affinché le trasmissioni vocali siano comprensibili (non discontinue) al destinatario, i pacchetti vocali non possono essere scartati, eccessivamente ritardati o subire ritardi variabili (noti anche come jitter). Questo documento descrive varie considerazioni QoS (Quality of Service) che aiutano a risolvere i problemi relativi alla voce. Le cause principali dei problemi vocali discontinui sono la perdita e il ritardo dei pacchetti vocali.

Prerequisiti

Requisiti

I lettori di questo documento devono conoscere:

• Configurazione di base di Packet Voice (VoIP, Voice over Frame Relay (VoFR) o Voice over ATM (VoATM) in base ai requisiti).

• Conoscenza di base di assegnazione di priorità alla voce, frammentazione, codec diversi e dei relativi requisiti di larghezza di banda.

Componenti usati

Le informazioni di questo documento si applicano a tutte le versioni software e hardware dei gateway voce Cisco.

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.

Cause di voce discontinua

La qualità vocale discontinua è causata da pacchetti voce che vengono variabilmente ritardati o persi nella rete. Quando un pacchetto vocale ritarda il raggiungimento della destinazione, il gateway di destinazione ha una perdita di informazioni in tempo reale. In questo caso, il gateway di destinazione deve prevedere quale potrebbe essere il contenuto del pacchetto perso. La previsione porta alla voce ricevuta che non ha le stesse caratteristiche della voce trasmessa. Questo porta ad una voce ricevuta che sembra robotica. Se un pacchetto vocale viene ritardato oltre la capacità di previsione di un gateway ricevente, il gateway lascia vuoto il gap in tempo reale. Con nulla che riempia quel vuoto alla fine della ricezione, parte del discorso trasmesso è perso. Il risultato è una voce discontinua. Molti dei problemi relativi alla voce vengono risolti garantendo che i pacchetti voce non subiscano ritardi eccessivi (e anche di più, non sempre). A volte, il rilevamento dell'attività vocale (VAD, Voice Activity Detection) aggiunge il ritaglio front-end a una conversazione vocale. Questa è un'altra causa di voce discontinua (o tagliata).

Nelle varie sezioni di questo documento viene spiegato come ridurre al minimo l'istanza della voce discontinua. La maggior parte di queste misure richiede l'introduzione di una variazione minima nella rete vocale.

Requisiti di larghezza di banda

Prima di prendere in considerazione l'applicazione di misure per ridurre al minimo il tremolio, è necessario fornire una larghezza di banda di rete sufficiente a supportare il traffico vocale in tempo reale. Ad esempio, una chiamata VoIP G.711 a 80 kbps (payload 64 kbps + intestazione 16 kbps) ha un suono scadente su un collegamento a 64 kbps perché almeno 16 kbps dei pacchetti (ossia il 20%) vengono scartati. I requisiti di larghezza di banda variano a seconda del codec usato per la compressione. Codec diversi hanno payload e requisiti di intestazione diversi. L'utilizzo di VAD influisce anche sui requisiti di larghezza di banda. Se si utilizza la compressione header (cRTP) del Real Time Protocol (RTP), è possibile ridurre ulteriormente i requisiti di larghezza di banda.

Ad esempio, la larghezza di banda richiesta per una chiamata vocale utilizzando il codec G.729 (payload di 20 byte predefinito) con cRTP è simile a quanto riportato di seguito:

• Payload vocale + compresso (intestazione RTP + intestazione UDP (User Datagram Protocol) + intestazione IP) + intestazione Layer 2

Equivale a:

• 20 byte + compresso (12 byte + 8 byte + 20 byte) + 4 byte

Equivale a:

• 28 byte, poiché la compressione dell'intestazione riduce l'intestazione IP RTP a un massimo di 4 byte. Ciò consente di ottenere 11,2 kbps a una velocità codec di 8 kbps (50 pacchetti al secondo).

Per ulteriori informazioni, consultare il documento sul consumo di larghezza di banda per chiamata Voice over IP.

Priorità traffico voce

Esistono due componenti importanti per assegnare le priorità alla voce. Il primo è classificare e contrassegnare il traffico vocale interessante. La seconda è dare la priorità al traffico vocale segnato come interessante. In queste due sottosezioni vengono illustrati vari approcci per classificare, contrassegnare e assegnare le priorità vocali.

Classificazione e contrassegno

Per garantire la larghezza di banda per i pacchetti VoIP, i dispositivi di rete devono essere in grado di identificare i pacchetti in tutto il traffico IP che li attraversa. I dispositivi di rete utilizzano gli indirizzi IP di origine e di destinazione nell'intestazione IP o i numeri delle porte UDP di origine e di destinazione nell'intestazione UDP per identificare i pacchetti VoIP. Questo processo di identificazione e raggruppamento è denominato classificazione. È la base per fornire qualsiasi QoS.

La classificazione dei pacchetti può richiedere un uso intensivo del processore. Pertanto, la classificazione deve essere effettuata il più lontano possibile dal perimetro della rete. Poiché ogni hop deve ancora stabilire il trattamento che un pacchetto deve ricevere, è necessario avere un metodo di classificazione più semplice ed efficiente nel nucleo della rete. Per semplificare la classificazione, è possibile contrassegnare o impostare il byte ToS (Type of service) nell'intestazione IP. I tre bit più significativi del byte del tipo ToS sono detti bit di precedenza IP. La maggior parte delle applicazioni e dei fornitori attualmente supporta l'impostazione e il riconoscimento di questi tre bit. L'evoluzione del contrassegno consente di utilizzare i sei bit più significativi del byte ToS, denominato DSCP (Differentiated Services Code Point). Fare riferimento alla RFC (Request for Comments).

DiffServ (Differentiated Services) è un nuovo modello in cui il traffico viene gestito da sistemi intermedi con priorità relative basate sul campo ToS. Definito nella RFC 2474 e nella RFC 2475, lo standard DiffServ sostituisce la specifica originale per la definizione della priorità dei pacchetti descritta nella RFC 791. DiffServ aumenta il numero di livelli di priorità definibili riassegnando i bit di un pacchetto IP per identificarne la priorità. L'architettura DiffServ definisce il campo DiffServ. Sostituisce il byte ToS nell'IP V4 per prendere decisioni sul comportamento per-hop (PHB) riguardo la classificazione dei pacchetti e le funzioni di condizionamento del traffico, come la misurazione, la marcatura, il shaping e l'applicazione di policy. Oltre alle RFC menzionate in precedenza, la RFC 2597 definisce le classi di inoltro garantito (Assured Forwarding, AF). Si tratta di una scomposizione dei campi DSCP. Per ulteriori informazioni su DSCP, vedere Implementazione di criteri Quality of Service con DSCP.

Byte ToS - P2 P1 P0 T3 T2 T1 T0 CU

Precedenza IP: tre bit (P2-P0), ToS: quattro bit (T3-T0), CU: un bit

Campo DiffServ - DS5 DS4 DS3 DS2 DS1 DS0 ECN ECN

DSCP: sei bit (DS5-DS0), ECN: due bit

XXX00000 I bit 0, 1, 2 (DS5, DS4, DS3) sono bit di precedenza, dove:

• 111 = Controllo della rete = Precedenza 7

• 110 = Controllo Internetwork = Precedenza 6

• 101 = CRITICO/ECP = Precedenza 5

• 100 = Sostituzione Flash = Precedenza 4

• 011 = Flash = Precedenza 3

• 010 = Immediato = Precedenza 2

• 001 = Priorità = Precedenza 1

• 000 = Routine = Precedenza 0

000XXX00 I bit 3, 4, 5 (DS2, DS1, DS0) sono i bit di ritardo, throughput e affidabilità.

• Bit 3 = Delay [D] (0 = Normale; 1 = Bassa)

• Bit 4 = Velocità effettiva [T] (0 = Normale; 1 = Alta)

• Bit 5 = Affidabilità [R] (0 = Normale; 1 = Alta)

000000XX Bit 6, 7: ECN

In queste due sezioni vengono illustrati due metodi di classificazione e contrassegno.

Peer di composizione voce per classificare e contrassegnare i pacchetti

Con i gateway VoIP Cisco, in genere si utilizzano i peer di composizione vocale per classificare i pacchetti VoIP e contrassegnare i bit di precedenza IP. Questa configurazione mostra come contrassegnare i bit di IP Precedence:

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

Nell'esempio di cui sopra, ogni chiamata VoIP che corrisponde al comando dial-peer voice 100 voip ha tutti i pacchetti del payload vocale impostati con IP Precedence 5. Ciò significa che i tre bit più significativi del byte IP ToS sono impostati su 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

Nell'esempio precedente, per ogni chiamata VoIP che corrisponde al comando dial-peer voice 100 voip, tutti i pacchetti del payload multimediale (pacchetti voce) sono impostati con il modello di bit EF (Expedited Forwarding) 101110. Tutti i pacchetti di segnalazione sono impostati con il modello di bit AF 011010.

Nota: il comando ip qos dscp è supportato dal software Cisco IOS® versione 12.2(2)T. IP Precedence non è più disponibile nel software Cisco IOS versione 12.2T. Tuttavia, lo stesso risultato viene ottenuto con il comando ip qos dscp. IP Precence 5 (101) è mappato all'IP DSCP 10100. Per ulteriori informazioni, consultare il documento sulla classificazione della segnalazione e dei supporti VoIP con DSCP per la qualità del servizio.

CLI QoS modulare per classificare e contrassegnare i pacchetti

Il metodo di classificazione e contrassegno consigliato da utilizzare è la CLI QoS modulare. Questo è un metodo di configurazione basato su modello che separa la classificazione dal criterio. Ciò consente di configurare più funzionalità QoS contemporaneamente per più classi. Utilizzare un comando class-map per classificare il traffico in base a vari criteri di corrispondenza e un comando policy-map per determinare le operazioni da eseguire su ciascuna classe. Applicare il criterio al traffico in entrata o in uscita su un'interfaccia eseguendo il comando service-policy. L'esempio di configurazione mostra come utilizzare la CLI QoS modulare per classificare e contrassegnare i pacchetti:

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 questo esempio di configurazione, tutto il traffico che corrisponde all'Access Control List (ACL) 100 viene classificato come "class voip" e impostato con IP Precedence 5. Ciò significa che i tre bit più significativi del byte IP ToS vengono impostati su 101. ACL 100 corrisponde alle porte UDP più comuni utilizzate dal VoIP. Analogamente, ACL 101 corrisponde allo standard H.323 per il traffico di segnalazione (porta 1720 del protocollo TCP (Transmission Control Protocol)). Tutto il resto del traffico viene impostato con IP Precedence 0. Il criterio è denominato "mqc". Viene applicata al traffico in entrata su Ethernet 0/0.

Assegnazione di priorità

Dopo che ogni hop nella rete è in grado di classificare e identificare i pacchetti VoIP (tramite le informazioni sulla porta/l'indirizzo o il byte ToS), questi hop forniscono a ogni pacchetto VoIP le funzionalità QoS richieste. A questo punto, configurare tecniche speciali per fornire l'accodamento delle priorità in modo da assicurare che i pacchetti di dati di grandi dimensioni non interferiscano con la trasmissione dei dati vocali. Questa condizione è in genere richiesta sui collegamenti WAN più lenti, dove esiste un'alta possibilità di congestione. Una volta che tutto il traffico interessante è posizionato nelle classi QoS in base ai loro requisiti QoS, fornire garanzie di larghezza di banda e servizio di priorità attraverso un meccanismo intelligente di coda di output. Coda di priorità necessaria per VoIP.

Nota:  Utilizzare un meccanismo di accodamento che attribuisca una priorità elevata al VoIP. Tuttavia, si consiglia LLQ (Low Latency Queuing) perché è flessibile e facile da configurare.

LLQ utilizza il metodo di configurazione modulare QoS CLI per fornire priorità a determinate classi e per fornire larghezza di banda minima garantita per altre classi. Durante i periodi di congestione, la coda di priorità viene controllata alla velocità configurata in modo che il traffico di priorità non utilizzi tutta la larghezza di banda disponibile. (Se il traffico con priorità monopolizza la larghezza di banda, impedisce che vengano soddisfatte le garanzie della larghezza di banda per altre classi). Se si esegue il provisioning di LLQ in modo corretto, il traffico che entra nella coda di priorità non deve mai superare la velocità configurata.

LLQ consente inoltre di specificare le profondità della coda per determinare quando il router deve eliminare i pacchetti se vi sono troppi pacchetti in attesa in una determinata coda di classe. È inoltre disponibile un comando class-default che viene utilizzato per determinare il trattamento di tutto il traffico non classificato da una classe configurata. class-default è configurato con un comando fair-queue. Ciò significa che a ogni flusso non classificato viene assegnata una quota approssimativamente uguale della larghezza di banda rimanente.

Nell'esempio viene mostrato come configurare LLQ. Per ulteriori informazioni, fare riferimento a Accodamento a bassa latenza:

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

Nell'esempio, il traffico che corrisponde all'ACL 100 viene classificato come "class voip" (traffico vocale). Viene assegnata una priorità elevata fino a 32 kbps. ACL 100 corrisponde alle porte UDP comuni utilizzate dal VoIP. Access-list 101 corrisponde al traffico di segnalazione H.323 (porta TCP 1720). La classe data1 corrisponde al traffico Web (la porta TCP 80 come appare nell'elenco degli accessi 102) e garantisce 64 kbps. La classe data2 corrisponde al traffico Telnet (porta TCP 23 come nell'ACL 103) e garantisce 32 kbps. La classe predefinita è configurata in modo da assegnare una quota uguale della larghezza di banda rimanente ai flussi non classificati. La politica si chiama "llq". Viene applicato al traffico in uscita su Serial1/0, che ha una larghezza di banda totale di 256 kbps.

Nota: per impostazione predefinita, la larghezza di banda totale garantita e di priorità per tutte le classi deve essere inferiore al 75% della larghezza di banda dell'interfaccia. Modificare questa percentuale utilizzando il comando max-reserve bandwidth interface.

In questa tabella vengono confrontati i diversi meccanismi di accodamento software con i relativi vantaggi e limitazioni.

Meccanismo di accodamento software	Descrizione	Vantaggi	Limitazioni
FIFO (First-In-First-Out)	I pacchetti arrivano e lasciano la coda esattamente nello stesso ordine.	Configurazione semplice e funzionamento rapido.	Non sono possibili servizi di priorità o garanzie di larghezza di banda.1
WFQ (Weighted Fair Queuing)	Algoritmo di hashing che passa in code separate in cui i pesi vengono utilizzati per determinare il numero di pacchetti serviti contemporaneamente. I pesi vengono definiti impostando i valori IP Precedence e DSCP.	Configurazione semplice. Impostazione predefinita per i collegamenti inferiori a 2 Mbps.	Non sono possibili servizi di priorità o garanzie di larghezza di banda.1
CQ (Custom Queuing)	Il traffico viene classificato in più code con limiti di coda configurabili. I limiti della coda vengono calcolati in base alle dimensioni medie del pacchetto, all'MTU (Maximum Transmission Unit) e alla percentuale di larghezza di banda da allocare. I limiti della coda (in numero di byte) vengono rimossi dalla coda per ciascuna coda. Pertanto, fornisce statisticamente la larghezza di banda assegnata.	È disponibile da alcuni anni. Consente l'allocazione approssimativa della larghezza di banda per code diverse.	Non è possibile eseguire operazioni di manutenzione con priorità. Le garanzie di larghezza di banda sono approssimative. Il numero di code è limitato. La configurazione è relativamente difficile.1
PQ (Priority Queuing)	Il traffico viene classificato in code di priorità alta, media, normale e bassa. Il traffico ad alta priorità viene servito per primo, seguito dal traffico a media priorità, normale e a bassa priorità.	È disponibile da alcuni anni. Fornisce servizi di priorità.	Il traffico con priorità più alta riduce le code con priorità più bassa della larghezza di banda. Nessuna garanzia di larghezza di banda.2
CBWFQ (Weighted Fair Queuing) basato su classi	L'interfaccia CLI QoS modulare viene utilizzata per classificare il traffico. Il traffico classificato viene inserito in code con larghezza di banda riservata o in una coda non riservata predefinita. L'utilità di pianificazione gestisce le code in base al peso in modo da rispettare le garanzie di larghezza di banda.	Simile a LLQ, con la differenza che non esiste una coda di priorità. Semplice configurazione e capacità di fornire garanzie di larghezza di banda.	Non è possibile alcuna manutenzione prioritaria.3
Priority Queue Weighted Fair Queuing (PQ-WFQ), denominato anche priorità IP RTP	Un unico comando di interfaccia viene usato per fornire servizi di priorità a tutti i pacchetti UDP destinati a numeri di porta pari all'interno di un intervallo specificato.	Semplice configurazione con un solo comando. Fornisce servizi di priorità ai pacchetti RTP.	Tutto il resto del traffico viene trattato con WFQ. Il traffico RTCP (Real-Time Conferencing Protocol) non ha priorità. Nessuna capacità di larghezza di banda garantita.4
LLQ, precedentemente denominato PQCBWFQ (Priority Queue-Based Weighted Fair Queuing)	La CLI QoS modulare con coda di priorità viene utilizzata per classificare il traffico. Il traffico classificato viene inserito in una coda di priorità, in code di larghezza di banda riservate o in una coda non riservata predefinita. L'utilità di pianificazione serve le code in base ai pesi in modo che il traffico con priorità venga inviato per primo (fino a un certo limite controllato durante la congestione) e che vengano soddisfatte le garanzie di larghezza di banda.	Configurazione semplice. Possibilità di dare priorità a più classi di traffico e assegnare limiti superiori all'utilizzo della larghezza di banda con priorità. È inoltre possibile configurare classi garantite dalla larghezza di banda e una classe predefinita.	Finora non è disponibile alcun meccanismo per fornire più livelli di priorità. Tutto il traffico di priorità viene inviato attraverso la stessa coda di priorità. Classi di priorità separate possono avere limiti di larghezza di banda con priorità superiore separati durante la congestione. Tuttavia, la condivisione della coda di priorità tra le applicazioni può introdurre un effetto jitter.4

1. Non adatto alla voce.

2. Richiede una larghezza di banda garantita per la voce.

3. È necessaria una certa latenza.

4. Sufficiente per la voce.

Ritardo serializzazione

Anche se l'accodamento funziona al meglio e assegna la priorità al traffico vocale, in alcuni casi la coda di priorità è vuota e viene servito un pacchetto di un'altra classe. I pacchetti delle classi di larghezza di banda garantita devono essere serviti in base al peso configurato. Se un pacchetto vocale prioritario arriva nella coda di output mentre questi pacchetti sono in fase di elaborazione, il pacchetto vocale può attendere molto tempo prima di essere inviato. I pacchetti voce subiscono un ritardo di serializzazione quando devono attendere dietro pacchetti di dati più grandi.

Il ritardo di serializzazione può introdurre la forma peggiore di jitter per i pacchetti voce. Se i pacchetti voce devono attendere dietro un pacchetto dati grande 1500 byte, su un collegamento più lento, ciò si traduce in un ritardo enorme. Il ritardo di serializzazione è molto diverso se il pacchetto dati è di 80 byte, come mostrato nell'esempio:

• Ritardo di serializzazione su un collegamento a 64 kbps causato da un pacchetto da 1500 byte = 1500*8/64000 = 187,5 ms.

• Ritardo di serializzazione su un collegamento a 64 kbps dovuto a un pacchetto da 80 byte = 80*8/64000 = 10 ms.

Pertanto, un pacchetto voce deve potenzialmente attendere fino a 187,5 ms prima di essere inviato se rimane bloccato dietro un singolo pacchetto da 1500 byte su un collegamento a 64 kbps. D'altra parte, un altro pacchetto voce deve attendere solo 10 ms al gateway di destinazione. Il risultato è un tremolio enorme che si verifica a causa della varianza nel ritardo tra pacchetti. Sul gateway di origine, i pacchetti voce vengono in genere inviati ogni 20 ms. Con un budget di ritardo end-to-end di 150 ms e rigidi requisiti di jitter, un gap superiore a 180 ms è inaccettabile.

Introdurre un meccanismo di frammentazione che assicuri che le dimensioni di un'unità di trasmissione siano inferiori a 10 ms. Tutti i pacchetti con un ritardo di serializzazione superiore a 10 ms devono essere frammentati in blocchi di 10 ms. Un blocco o frammento di 10 ms è il numero di byte inviati tramite il collegamento in 10 ms. Calcolare le dimensioni utilizzando la velocità di collegamento, come illustrato nell'esempio seguente:

• Dimensione frammentazione = (0,01 secondi * 64.000 bps) / (8 bit/byte) = 80 byte

L'invio di un pacchetto o di un frammento da 80 byte su un collegamento a 64 kbps richiede 10 ms.

In caso di più PVC (Permanent Virtual Circuit) ATM o Frame Relay su una singola interfaccia fisica, configurare i valori di frammentazione (su tutti i PVC) in base al PVC con la larghezza di banda più bassa disponibile. Ad esempio, se vi sono tre PVC con una larghezza di banda garantita di 512 kbps, 128 kbps e 256 kbps, configurare tutti e tre i PVC con una dimensione del frammento di 160 byte (la velocità più bassa è 128 kbps che richiede una dimensione del frammento di 160 byte). Questi valori sono consigliati per velocità di collegamento diverse:

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

Nota: se le dimensioni del frammento sono superiori alle dimensioni MTU del collegamento, non è richiesta alcuna frammentazione. Ad esempio, per un collegamento T1 con MTU di 1500 byte, le dimensioni del frammento sono 1920 byte. Non è richiesta alcuna frammentazione. Le dimensioni della frammentazione del pacchetto non devono mai essere inferiori alle dimensioni del pacchetto VoIP. Non frammentare pacchetti VoIP. La frammentazione di questi pacchetti causa numerosi problemi di impostazione e qualità delle chiamate.

Al momento sono disponibili tre meccanismi di frammentazione dei collegamenti e di interfoliazione. Per ulteriori informazioni sui vari ritardi introdotti in una rete a pacchetti, consultare il documento sulla descrizione del ritardo nelle reti voce a pacchetti. Nella tabella seguente vengono elencati i vantaggi e i limiti di tali funzionalità:

Meccanismo Link Fragmentation and Interleaving (LFI)	Descrizione	Vantaggi	Limitazioni
Frammentazione MTU con WFQ	Comando a livello di interfaccia per modificare le dimensioni della MTU o della MTU IP. Consente di frammentare pacchetti IP di grandi dimensioni in base alle dimensioni MTU specificate. LFI utilizza WFQ per interfoliare i pacchetti in tempo reale tra i frammenti.	Configurazione semplice.	I frammenti vengono ricomposti solo dall'applicazione ricevente. Di conseguenza, l'uso inefficiente della rete. La frammentazione può essere gestita correttamente solo dai pacchetti IP il cui bit DF (Do not Fragment) non è impostato. Elevato utilizzo del processore. Non consigliato.
Protocollo MLPPP (Multilink Point-to-Point Protocol) LFI	Sui collegamenti seriali point-to-point, è necessario configurare prima MLPPP, quindi impostare una dimensione di frammentazione in ms. È inoltre necessario abilitare l'interfoliazione sull'interfaccia a connessione multipla.	I pacchetti vengono frammentati su un'estremità del collegamento e ricomposti sull'altra estremità. È possibile combinare diversi collegamenti in modo che fungano da pipe virtuale di grandi dimensioni.	Disponibile solo sui collegamenti configurati per PPP. Le soluzioni per PPP su Frame Relay o PPP su ATM sono supportate anche nel software Cisco IOS versione 12.1(5)T o successive.
Frammentazione Frame Relay (FRF.12)	Sui PVC Frame Relay, abilitare il comando frame-relay traffic-shaping e impostare le dimensioni della frammentazione nella classe map.	I pacchetti vengono frammentati su un'estremità del PVC e ricomposti sull'altra estremità.	Disponibile solo sui PVC Frame Relay con il comando frame-relay traffic-shaping abilitato.

VAD

Una conversazione vocale regolare consiste in diversi momenti di silenzio. Una tipica conversazione vocale consiste per il 40-50% in silenzio. Poiché non c'è voce che attraversa la rete per il 40% di una chiamata vocale, è possibile risparmiare una parte della larghezza di banda implementando il VAD. Con il VAD, il gateway cerca spazi vuoti nel discorso. Sostituisce questi spazi con rumore di fondo. In questo modo, viene risparmiata una quantità di larghezza di banda. Tuttavia, esiste un compromesso. Si verifica un breve intervallo di tempo (in ordine di millisecondi) prima che i codec rilevino l'attività del discorso e quindi un periodo di silenzio. Questa breve operazione determina il clipping front-end della voce ricevuta. Per evitare l'attivazione durante pause molto brevi e per compensare il clipping, VAD attende circa 200 ms dopo l'interruzione del riconoscimento vocale prima di arrestare la trasmissione. Al riavvio della trasmissione, include i 5 ms di discorso precedenti insieme al discorso corrente. VAD si disattiva automaticamente in una chiamata se il rumore ambientale impedisce di distinguere tra voce e rumore di fondo. Tuttavia, se la larghezza di banda non è un problema, disattivare il VAD.

Sintonizza parametri VAD

Il funzionamento di VAD è determinato da due parametri. Questi sono i comandi music-threshold e voice vad-time.

soglia musica

Viene decisa una soglia iniziale che determina quando il VAD deve diventare attivo. A tal fine, è necessario definire il comando music-threshold threshold_value su una porta voce, come mostrato nell'esempio. L'intervallo per questa impostazione è compreso tra -70 decibel per milliwatt (dBm) e -30 dBm. Il valore predefinito è -38 dBm. Configurando un valore più basso (verso -70 dBm), il VAD diventa attivo a un livello del segnale molto più basso (il volume deve scendere molto basso prima di essere considerato come silenzio). Configurando un valore più alto (vicino a -30 dBm), il VAD diventa attivo anche in caso di una piccola riduzione della potenza del segnale vocale. Permette di controllare il playout per riprodurre i pacchetti dei disturbi più spesso. Tuttavia, ciò a volte determina ritagli audio di minore entità.

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

voice vad-time

Una volta attivato il VAD, il componente del rumore di fondo e del rumore di comfort viene controllato configurando il comando voice vad-time timer_value nella configurazione globale, come mostrato nell'esempio. Questo è il tempo di ritardo in millisecondi per il rilevamento del silenzio e la soppressione della trasmissione di pacchetti voce. Il valore predefinito per il tempo di ritenzione è 250 msec. Ciò significa che entro 250 msec inizia il rumore di comfort. L'intervallo per questo timer è da 250 msec a 65536 msec. Se per questa funzione è stato configurato un valore elevato, il rumore di fondo entra in gioco molto più tardi (il rumore di fondo continua a essere riprodotto). Se questa impostazione è configurata per 65536 msec, il rumore ambientale viene disattivato. Un valore più alto per questo timer è desiderato per una transizione più fluida tra rumore di fondo e rumore di comfort. Lo svantaggio della configurazione del comando voice vad-time ad alto livello è che non consente di risparmiare il 30-35% della larghezza di banda.

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

Esempi di configurazione tipici per QoS

Uno scenario tipico per la configurazione di chiamate VoIP è rappresentato da un collegamento frame-relay o da un collegamento PPP. Questi sono esempi di configurazione per questi scenari.

VoIPoFR - Esempio di configurazione QoS

In questo esempio (che contiene solo le sezioni rilevanti della configurazione), si presume che la velocità del circuito frame relay sia 256 kbps. La velocità CIR (Committed Information Rate) garantita su PVC 100 è di 64 kbps e su PVC 200 è di 192 kbps. Il PVC 100 viene utilizzato per trasportare sia dati che voce. PVC 200 viene utilizzato solo per il trasporto di dati. Esiste un massimo di quattro chiamate vocali simultanee in un determinato momento. Configurare la frammentazione su entrambi i PVC in base al CIR della voce PVC (PVC) con larghezza di banda più bassa. Gli esempi riportati in questo documento indicano che le dimensioni della frammentazione vengono stabilite in base al CIR del PVC 100 (64 kbps). Come mostrato nella tabella della sezione Ritardo di serializzazione, per un collegamento a 64 kbps è richiesta una dimensione di frammentazione di 80 byte. Configurare la stessa dimensione di frammentazione per PVC 200.

Per ulteriori informazioni sulla configurazione di VoIP su Frame Relay, consultare il documento sulla configurazione di VoIP su Frame Relay con Quality of Service (frammentazione, traffic shaping, priorità LLQ / IP RTP).

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

Esempio di configurazione VoIP over PPP - QoS

In questo esempio (che contiene solo le sezioni pertinenti della configurazione), si presume che QoS debba essere configurato per un controller T1 frazionario point-to-point (con dodici canali). Esiste un massimo di quattro chiamate vocali simultanee in un determinato momento. L'attività di configurazione prevede la configurazione dell'interfaccia seriale con incapsulamento PPP, la creazione di un gruppo con connessione multipla (appartenente allo stesso gruppo con connessione multipla) e la configurazione di tutte le funzionalità QoS sull'interfaccia con connessione multipla. Per ulteriori informazioni sulla configurazione di VoIP su PPP, vedere Collegamenti VoIP su PPP con priorità LLQ/IP RTP, 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
!

Variazione e meccanismo di riproduzione

Ci sono sempre alcune entità non controllate in una rete che contribuiscono a ulteriori ritardi e jitter nei pacchetti voce ricevuti. Modificando il buffer di jitter sul gateway di terminazione, il jitter non controllato viene risolto nella rete vocale.

Meccanismo di riproduzione

Il buffer di variazione è un buffer temporale. Viene fornito dal gateway terminante per rendere il meccanismo di riproduzione più efficace. Questo è un diagramma funzionale del meccanismo di riproduzione:

Quando il controllo del playout riceve un pacchetto voce, analizza l'indicatore orario RTP. Se il pacchetto vocale viene ritardato oltre la capacità di attesa del buffer di jitter, il pacchetto viene immediatamente scartato. Se il pacchetto è all'interno della funzionalità di buffer, viene inserito nel buffer di jitter. La posizione del pacchetto nel buffer di jitter dipende dall'indicatore orario RTP calcolato per il pacchetto. Nel caso in cui non vi sia un pacchetto vocale disponibile, il controllo del playout cerca di nasconderlo (prevede il pacchetto mancante). Se è attivata la funzione VAD, viene riprodotto il rumore ambientale.

La responsabilità del controllo del playout è quella di gestire gli eventi relativi a pacchetti persi, pacchetti duplicati, pacchetti danneggiati e pacchetti fuori sequenza. Questi eventi vengono gestiti allineando i pacchetti vocali disturbati, riproducendo il rumore di comfort (se è configurato il VAD), o anche rigenerando i toni multifrequenza (DTMF) dual tone da riprodurre all'host.

L'occultamento di un pacchetto vocale viene effettuato sia per occultamento di previsione che per occultamento di silenzio. L'occultamento delle stime si basa sul pacchetto precedente e sul pacchetto successivo (se disponibile). Offre risultati ottimali con codec a bassa velocità in bit (da 5 kbps a 16 kbps). La perdita dei pacchetti voce per un codec con velocità in bit elevata (da 32 kbps a 64 kbps) può causare un nascondimento delle previsioni insoddisfacente. L'occultamento della previsione inizia quando si verificano ritardi bassi e rari o un numero inferiore di perdite di pacchetti. Un occultamento troppo predittivo può portare a una qualità vocale robotica. L'occultamento del silenzio è la peggiore forma di occultamento della previsione. Entra in gioco quando non ci sono informazioni disponibili da prevedere. È semplicemente un occultamento di fondo. Inizia quando ci sono alti ritardi e un numero maggiore di perdite di pacchetti. L'occultamento di troppo silenzio porta a una qualità della voce discontinua. L'occultamento predittivo è buono per 30 millisecondi dopo i quali entra in gioco il silenzio.

Buffer di variazione

Il tampone di variazione è confinato da un elevato livello d'acqua e da un basso livello d'acqua. Il limite superiore entro il quale un pacchetto deve arrivare per essere trasmesso in tempo reale. I pacchetti che arrivano dopo il limite massimo vengono contrassegnati come pacchetti in ritardo o persi. Il limite minimo dell'acqua è il tempo minimo entro il quale si prevede che un pacchetto arrivi per il playout puntuale. I pacchetti che arrivano prima della soglia minima sono considerati pacchetti precoci (possono comunque essere riprodotti in tempo).

Se il gateway terminante continua a notare un incremento nell'arrivo di pacchetti in ritardo, aumenta il limite massimo. Questo valore per il limite massimo rimane invariato per tutta la durata della chiamata. Il valore viene aumentato fino al valore massimo definito nella configurazione. Analogamente, il gateway terminante osserva il numero di pacchetti ricevuti prima della scadenza. Se questi pacchetti iniziano a frequentare il gateway, riduce il limite minimo. Questo valore rimane invariato per tutta la durata della chiamata. Questa modalità del buffer di jitter è detta "modalità adattiva", in cui il gateway terminante adatta il proprio buffer di jitter in base al modello di traffico. L'altra modalità è "fissa". Nella modalità fissa, esiste un valore iniziale per il livello minimo e il livello massimo. Questo valore si basa sul ritardo ricevuto stimato (vedere la sezione show voice call <port-number> di questo documento).

Per ulteriori informazioni sul buffer di jitter, consultare il documento sulla descrizione della funzione jitter nelle reti voce pacchetto (piattaforme Cisco IOS).

Identificazione del ritardo e dell'instabilità

Questa sezione descrive come identificare l'effetto jitter nella rete.

show call active voice

Il comando show call active voice brief offre molte informazioni su una conversazione in corso. Questo output visualizza alcuni punti importanti tratti da questo comando:

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

Dall'output del comando show call active voice brief, è possibile vedere che tutto ciò che viene ricevuto sulla gamba di telefonia (rx:7044) viene trasmesso alla gamba IP (tx:7044). Lo stesso vale per i pacchetti ricevuti sulle connessioni IP (26165) che vengono inoltrati al collegamento Telefonia (26157). La differenza tra il numero di pacchetti ricevuti sul segmento IP e il numero di pacchetti trasmessi sul segmento Telefonia viene trasferita sui pacchetti in ritardo che non sono consegnati in tempo.

Questo output del comando show call active voice (senza la parola chiave "brief") punta a ulteriori dettagli sui parametri che identificano direttamente la variazione.

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

show voice call <numero-porta>

Il comando show voice call port-number fornisce informazioni utili. Verificare di essere consolati nel gateway o, se si è collegati in modalità Telnet a un gateway, accertarsi di aver emesso il comando terminal monitor dal livello exec.

Nota: questo comando non è disponibile sulle piattaforme AS5x00/AS5x50.

In questo output, il valore per Rx Delay Est (ms) è 71. Questo è il valore corrente del buffer di jitter. Su questo si deduce un valore per il livello massimo e il livello minimo. Un valore iniziale medio per il livello massimo dell'acqua è di 70 msec, mentre per il livello minimo dell'acqua è di 60 msec. Una volta impostato il valore iniziale, il gateway tiene traccia di tutti i pacchetti ricevuti in anticipo o in ritardo. Come si vede nell'output qui, le cadute di occultamento previsione sono vicino a 250 ms, mentre il occultamento silenzio è 30 ms. C'è sempre un valore più alto per l'occultamento della previsione, poiché l'occultamento del silenzio è solo uno scenario peggiore di occultamento della previsione. Per ogni caduta di occultamento di previsione, si verifica un aumento dell'overflow del buffer.

L'eliminazione dei buffer non implica necessariamente un aumento del livello massimo di attenzione. Il limite massimo dell'acqua è il limite superiore del buffer di variazione. Cambia solo se si osserva una tendenza. In altre parole, dovrebbe esserci un flusso continuo di pacchetti in ritardo. Ciò determina un aumento del buffer di jitter. Nell'output qui, una tale tendenza è presente. Pertanto, il livello massimo dell'acqua è aumentato da 70 msec a 161 msec. Se questo valore non viene modificato (e se vengono ancora visualizzati 14 pacchetti in ritardo), significa che si tratta di pacchetti in ritardo sporadici che non formano una tendenza.

Dall'output del comando show call active voice, verificare la presenza di pacchetti persi. Per ogni pacchetto perso, vengono visualizzati due pacchetti fuori sequenza. Questa condizione si verifica nell'output Pkts Rx Non-Seq. Non trattandosi di un valore positivo, si conclude che non vi sono state perdite di pacchetti.

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

Osservate i kit Comfort Tx e Comfort Rx. Come si evince dagli output dell'esempio, si conclude che il telefono collegato a questo router si mantiene per lo più silenzioso in quanto si hanno molti Tx Comfort Pkts. Allo stesso tempo, avete zero Rx Comfort Pkts, il che significa che l'altra estremità parla continuamente.

Confrontare l'output qui riportato con l'output del comando precedente. Il numero di pacchetti in ritardo Rx è aumentato (da 14 a 26). Tuttavia, non vi è alcun incremento nel valore massimo del limite. Ciò significa che i 12 pacchetti sono ritardati sporadicamente. L'overflow del buffer viene aumentato a 910 msec. Tuttavia, poiché non si osserva alcuna tendenza, il livello massimo non viene aumentato.

Nell'output riportato di seguito, è presente un pacchetto Rx Early Pkts: 3. Ciò significa che un pacchetto arriva molto prima del previsto. Come si evince dall'output qui riportato, il buffer Jitter si è allungato per adattarsi a qualsiasi pacchetto più precoce riducendo il livello di bassa marea da 60 a 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

Configurazione del buffer di variazione in un gateway

Le linee guida QoS trattate in questo documento risolvono il problema della qualità della voce, che può risultare discontinua o deteriorata. La configurazione del buffer di ritardo del playout costituisce una soluzione per l'implementazione QoS errata nella rete. Utilizzatelo solo come correzione di stop-gap o come strumento per la risoluzione dei problemi e la riduzione dei problemi di jitter introdotti nella rete.

Modalità Playout-delay

Il buffer di jitter è configurato per la modalità fissa o adattiva. In modalità adattiva, il gateway consente di configurare un valore minimo per il buffer di jitter, un valore massimo e un valore nominale. Il buffer di jitter si aspetta che i pacchetti rientrino nell'intervallo di valori nominali. Il valore nominale deve essere uguale o superiore al minimo e uguale o inferiore al massimo. Il buffer si espande fino al valore massimo configurato. che può estendersi fino a 1700 msec. Un problema della configurazione di un valore massimo elevato è l'introduzione del ritardo end-to-end. Scegliete il valore del ritardo di riproduzione massimo in modo che non introduca ritardi indesiderati nella rete. Questo output è un esempio del buffer di variazione configurato per la modalità adattiva:

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
!

In modalità fissa, il gateway considera il valore configurato per il valore nominale. Anche se consente di configurare i valori minimo e massimo per il ritardo di riproduzione, viene ignorato quando configurato per la modalità fissa. In modalità fissa il valore massimo o minimo del livello rimane sempre costante. Si basa sul valore nominale e sul valore Rx Delay Est (ms). Quindi è possibile che in modalità fissa, si configuri il valore come 200 msec. Tuttavia, se il ritardo ricevuto stimato è vicino a 100 ms, questo è ciò che il limite massimo e il limite minimo sono impostati per l'intera durata della chiamata.

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
!

Per ulteriori informazioni sulla configurazione del ritardo di riproduzione, consultare il documento sui miglioramenti del ritardo di riproduzione per la funzione Voice over IP.

Informazioni correlate

• Implementazione delle policy della qualità del servizio (QoS) con DSCP
• Accodamento a bassa latenza
• Confronto dei comandi di larghezza di banda e priorità di un criterio servizio QoS
• Configurazione della frammentazione e dell'interfoliazione del collegamento per Frame Relay e circuiti virtuali ATM
• Configurazione della frammentazione e dell'interfoliazione dei collegamenti per Multilink PPP
• Supporto alla tecnologia vocale
• Supporto ai prodotti voce e Unified Communications
• Risoluzione dei problemi di Cisco IP Telephony
• Supporto tecnico – Cisco Systems

Cronologia delle revisioni