Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Convenzioni

Linee guida di progettazione QoS per collegamenti VoIP over PPP

Priorità rigorosa per il traffico voce (priorità IP RTP o LLQ)

Linee guida per la configurazione di LLQ

Linee guida per la configurazione della priorità IP RTP

Link Fragmentation and Interleaving (LFI): Multilink PPP

cRTP (Compressed Real-time Protocol)

Altri suggerimenti per la riduzione della larghezza di banda

Esempio di rete

Configurazioni

Comandi di verifica e risoluzione dei problemi

Output di esempio di show e debug

Informazioni correlate

Introduzione

In questa configurazione di esempio viene studiato un protocollo VoIP con protocollo PPP (Point to Point Protocol) su una configurazione di linee affittate con larghezza di banda ridotta. Questo documento include informazioni tecniche di base sulle funzionalità configurate, linee guida di progettazione e strategie di verifica e risoluzione dei problemi di base.

Nota: è importante notare che nella configurazione seguente, i due router sono connessi back-to-back su una linea leasing. Nella maggior parte delle topologie, tuttavia, i router abilitati per la voce possono esistere ovunque. Di solito, i router voce usano la connettività LAN ad altri router connessi alla WAN (in altre parole, una linea leasing PPP). Questo è importante perché se i router vocali non sono connessi direttamente tramite PPP su una linea in leasing, tutti i comandi di configurazione WAN devono essere configurati sui router connessi alla WAN e non sui router vocali, come mostrato nelle configurazioni sottostanti.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Le configurazioni presentate in questo documento sono state testate con questa apparecchiatura:

- Due Cisco 3640 con software Cisco IOS® versione 12.2.6a (IP Plus)

- La priorità IP RTP è stata introdotta in Cisco IOS versione 12.0(5)T.

- LLQ è stato introdotto in Cisco IOS versione 12.0(7)T.

- La tecnologia LFI è stata introdotta in Cisco IOS versione 11.3.

- Le versioni Cisco IOS successive alla 12.0.5T contengono miglioramenti significativi delle prestazioni per cRTP.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Linee guida di progettazione QoS per collegamenti VoIP over PPP

In questa sezione vengono fornite le linee guida di progettazione per configurare il protocollo VoIP sulle linee in leasing PPP (con particolare attenzione ai collegamenti a bassa velocità). Esistono due requisiti di base per una buona qualità vocale:

- Ritardo minimo end-to-end e riduzione dell'effetto jitter (variazione del ritardo).

- Requisiti di larghezza di banda del collegamento ottimizzati e progettati correttamente.

Per garantire il rispetto dei requisiti di cui sopra, è necessario attenersi a diverse importanti linee guida:

Orientamento

Descrizione

Priorità rigorosa per il traffico voce (priorità IP RTP o LLQ)

Metodo per fornire priorità assoluta al traffico vocale.

Link Fragmentation and Interleaving (LFI)

Può essere un requisito obbligatorio per i collegamenti a bassa velocità.

Compressione RTP

Non è necessario per garantire una buona qualità vocale, ma riduce il consumo della larghezza di banda delle chiamate. Il consiglio generale relativo alla compressione RTP è quello di applicarla dopo avere una configurazione funzionante con una buona qualità vocale (semplifica la risoluzione dei problemi).

Controllo di ammissione di chiamata (CAC)

Non trattata nel presente documento. La funzione CAC viene utilizzata per controllare il numero di chiamate che è possibile stabilire tramite il collegamento. Ad esempio, se il collegamento WAN tra i due gateway dispone della larghezza di banda necessaria per trasportare solo due chiamate VoIP, l'ammissione di una terza chiamata può compromettere la qualità vocale di tutte e tre le chiamate. Per ulteriori informazioni, fare riferimento a: Controllo di ammissione chiamate VoIP.

In sintesi, per il collegamento PPP a bassa velocità con router/gateway come solo fonti di traffico vocale, sono obbligatorie due funzionalità:

1. Priorità rigorosa per il traffico vocale

2. Link Fragmentation and Interleaving (LFI)

Priorità rigorosa per il traffico voce (priorità IP RTP o LLQ)

A partire dal software Cisco IOS versione 12.2, sono disponibili due metodi principali per assegnare priorità assoluta al traffico vocale:

- Priorità IP RTP (nota anche come PQ/WFQ: Priority Queue/Weighted Fair Queuing )

- Accodamento a bassa latenza (denominato anche PQ/CBWFQ: Coda di priorità/Coda equa ponderata basata su classi).

Priorità IP RTP

Priorità IP RTP crea una coda di priorità rigida per un set di flussi di pacchetti RTP appartenenti a un intervallo di porte di destinazione UDP (User Datagram Protocol). Mentre le porte effettivamente utilizzate vengono negoziate in modo dinamico tra dispositivi finali o gateway, tutti i prodotti Cisco VoIP utilizzano lo stesso intervallo di porte UDP (16384-32767). Dopo aver riconosciuto il traffico VoIP, il router lo posiziona nella coda di priorità rigida. Quando la coda di priorità è vuota, le altre code vengono elaborate in base allo standard WFQ (Weighted Fair Queuing). La priorità IP RTP non diventa attiva finché l'interfaccia non è congestionata. Nell'immagine viene mostrato come funzionare la priorità IP RTP:

Nota: la priorità IP RTP consente la frammentazione della coda di priorità (PQ) quando è disponibile larghezza di banda sulla coda predefinita (WFQ), ma regola rigorosamente il contenuto della coda di priorità in caso di congestione dell'interfaccia.

Accodamento a bassa latenza

LLQ è una funzione che fornisce un PQ rigoroso a CBWFQ (Weighted Fair Queuing) basato su classi. LLQ consente un singolo PQ rigoroso all'interno di CBWFQ a livello di classe. Con LLQ, i dati sensibili al ritardo (nel PQ) vengono rimossi dalla coda e inviati per primi. In un VoIP con implementazione LLQ, il traffico vocale viene posizionato nel PQ rigoroso.

Il PQ è controllato per garantire che le code eque non siano affamate di larghezza di banda. Quando si configura la PQ, si specifica in Kbps la quantità massima di larghezza di banda disponibile per la PQ. Quando l'interfaccia è congestionata, il PQ viene servito finché il carico non raggiunge il valore Kbps configurato nell'istruzione priority. Il traffico in eccesso viene quindi scartato per evitare il problema con la funzione di gruppo di priorità legacy di Cisco, che consiste nel far morire di fame le code con priorità inferiore.

Questo metodo è più complesso e flessibile della priorità IP RTP. La scelta tra i metodi deve essere basata sugli schemi di traffico nella rete reale e sulle effettive esigenze.

Priorità LLQ e IP RTP

La tabella riepiloga le principali differenze tra la priorità LLQ e la priorità IP RTP e fornisce alcune linee guida per l'utilizzo di ciascun metodo.

LLQ (Low-Latency Queuing)

Priorità IP RTP

Associa traffico vocale in base a:

- Elenchi degli accessi (per intervalli di porte UDP, indirizzi host, campi ToS dell'intestazione IP: Precedenza IP, DSCP e altro)

- Intervallo porte IP RTP

- Campi IP ToS (tipo di servizio): DCSP e/o IP Precedence

- Protocolli e interfacce di input

- Tutti i criteri di corrispondenza validi utilizzati in CBWFQ

Vantaggi:

- Maggiore flessibilità su come il traffico viene abbinato e indirizzato ai severi PQ e CBWFQ

- È possibile configurare classi aggiuntive per garantire la larghezza di banda per altro traffico, ad esempio: Segnalazione e video VoIP.

Svantaggi:

- Configurazione complessa

Associa traffico vocale in base a:

- In base all'intervallo di porte UDP RTP: 16384-32767

Vantaggi:

- Configurazione semplice

Svantaggi:

- Traffico RTCP (Segnalazione VoIP) servito nella coda WFQ
Nota: il protocollo RTP utilizza il protocollo RTCP (Real Time Control Protocol) per controllare la consegna dei pacchetti RTP. Mentre le porte RTP usano numeri pari, le porte RTCP usano numeri dispari nell'intervallo 16384-32767. La priorità IP RTP posiziona le porte RTP nel PQ, mentre le porte RTCP sono servite nella coda equa ponderata predefinita.

- Serve il traffico VoIP nella PQ, ma qualsiasi altro traffico che richiede un trattamento preferenziale e la garanzia della larghezza di banda viene servito in WFQ. Mentre WFQ può differenziare i flussi con pesi (basati su IP Precedence), non può garantire la larghezza di banda per qualsiasi flusso.

Linee guida

- La scelta tra queste due opzioni deve essere basata sugli schemi di traffico nella rete reale e sulle effettive esigenze.

- Se si desidera assegnare una priorità assoluta al traffico vocale e il traffico di altro tipo può essere trattato come un unico tipo (dati), la priorità IP RTP rappresenta una soluzione ideale per la rete in uso e offre una configurazione semplice.

- Se si intende assegnare una priorità al traffico vocale in base a criteri diversi dalle porte UDP (ad esempio, DiffServ PHB), è necessario LLQ.

Per ulteriori informazioni sulla correlazione e le differenze tra i metodi di accodamento, vedere Cenni preliminari sulla gestione delle congestioni.

Linee guida per la configurazione di LLQ

Seguire queste linee guida per configurare LLQ:

1. Creare una mappa delle classi per il traffico VoIP e definire i criteri di corrispondenza

Questi comandi spiegano come completare questa attività:

maui-voip-sj(config)#class-map ?

WORD  class-map name

match-all  Logical-AND all matching statements under this classmap

match-any  Logical-OR all matching statements under this classmap

maui-voip-sj(config)#class-map match-all voice-traffic

!-- Choose a descriptive class_name.

maui-voip-sj(config-cmap)#match ?

access-group         Access group

any                  Any packets

class-map            Class map

cos                  IEEE 802.1Q/ISL class of service/user priority values

destination-address  Destination address

input-interface      Select an input interface to match

ip                   IP specific values

mpls                 Multi Protocol Label Switching specific values

not                  Negate this match result

protocol             Protocol

qos-group            Qos-group

source-address       Source address

!-- In this example, the access-group matching option is used for its !-- flexibility (it uses an access-list)

maui-voip-sj(config-cmap)#match access-group ?

<1-2699>  Access list index  name      Named Access List

maui-voip-sj(config-cmap)#match access-group 102

!-- Now, create the access-list to match the class-map access-group:

maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32776

!-- Safest and easiest way is to match with UDP port range 16384-32767 !-- This is the port range Cisco IOS H.323 products utilize to transmit !-- VoIP packets.

Questi elenchi degli accessi possono essere utilizzati anche per associare il traffico vocale al comando match access-group:

access-list 102 permit udp any any precedence critical

!-- This list filters traffic based on the IP packet TOS: Precedence field.

!-- Note: Ensure that other non-voice traffic does NOT uses the

!-- same precedence value.

access-list 102 permit udp any any dscp ef

!-- In order for this list to work, ensure that VoIP packets are tagged with

!-- the dscp ef code before they exit on the LLQ WAN interface.

!-- For more information on DSCP refer to:

!-- Implementing Quality of Service Policies with DSCP

!-- Note: If endpoints are not trusted on their packet marking, you can mark

!-- incoming traffic by applying an inbound service policy on an inbound

!-- interface. This procedure is out of the scope of this doc.

Access-list 102 permit udp host 192.10.1.1 host 192.20.1.1

!-- This access-list can be used in cases where the VoIP devices cannot !-- do precedence or dscp marking and you cannot determine the !-- VoIP UDP port range.

Di seguito sono riportati altri metodi corrispondenti che è possibile utilizzare al posto dei gruppi di accesso:

- A partire da Cisco IOS versione 12.1.2.T, la funzionalità di priorità IP RTP è implementata per LLQ. Questa funzionalità corrisponde al contenuto della classe di priorità esaminando le porte UDP configurate ed è soggetta alla limitazione di servire solo le porte pari nel PQ.

class-map voice

match ip rtp 16384 16383

- Questi due metodi funzionano partendo dal presupposto che i pacchetti VoIP siano contrassegnati sugli host di origine o corrispondano e siano contrassegnati sul router prima di applicare l'operazione LLQ in uscita.

class-map voice

match ip precedence 5

o

class-map voice

match ip dscp ef

Nota: a partire da IOS versione 12.2.2T, i dial-peer VoIP possono contrassegnare i pacchetti di segnalazione e supporto vocale prima dell'operazione LLQ. Ciò consente un modo scalabile di contrassegnare e abbinare pacchetti VoIP tramite valori di codice DSCP per LLQ.

2. Creare una mappa delle classi per la segnalazione VoIP e definire i criteri di corrispondenza (facoltativo)

Questi comandi spiegano come completare questa attività:

class-map voice-signaling

match access-group 103

!

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

Nota: le chiamate VoIP possono essere stabilite usando H.323, SIP, MGCP o Skinny (protocollo proprietario usato da Cisco Call Manager). Nell'esempio si presume che la licenza Fast Connect sia H.323. L'elenco che segue serve come riferimento per le porte usate dai canali di controllo/segnalazione VoIP:

- H.323/H.225 = TCP 1720

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

- H.323/H.245 = TCP 1720 (Fast Connect)

- H.323/H.225 RAS = TCP 1719

- Skinny = TCP 2000-2002 (CM Encore)

- ICCP = TCP 8001-8002 (CM Encore)

- MGCP = UDP 2427, TCP 2428 (CM Encore)

- SIP= UDP 5060, TCP 5060 (configurabile)

3. Creare una mappa dei criteri e associarla alle mappe classi VoIP

Lo scopo della mappa dei criteri è quello di definire la modalità di condivisione o assegnazione delle risorse di collegamento alle diverse classi di mappe. Questi comandi spiegano come completare questa attività:

maui-voip-sj(config)#policy-map VOICE-POLICY

!-- Choose a descriptive policy_map_name.

maui-voip-sj(config-pmap)#class voice-traffic

maui-voip-sj(config-pmap-c)#priority ?

<8-2000000>  Kilo Bits per second

!-- Configure the voice-traffic class to the strict priority !-- Queue (priority command) and assign the bandwidth.

maui-voip-sj(config-pmap)#class voice-signaling

maui-voip-sj(config-pmap-c)#bandwidth 8

!-- Assign 8 Kbps to the voice-signaling class

maui-voip-sj(config-pmap)#class class-default

maui-voip-sj(config-pmap-c)#fair-queue

!-- The remaining data traffic is treated as Weighted Fair Queue

Nota: anche se è possibile accodare vari tipi di traffico in tempo reale al PQ, Cisco consiglia di indirizzare solo il traffico vocale al PQ. Il traffico in tempo reale, come quello video, può introdurre variazioni di ritardo (il PQ è una coda FIFO - First In First Out -). Il traffico vocale richiede che il ritardo non sia variabile per evitare lo jitter.

Nota: la somma dei valori delle istruzioni priority e bandwidth deve essere inferiore o uguale al 75% della larghezza di banda del collegamento. In caso contrario, service-policy non può essere assegnato al collegamento (per visualizzare i messaggi di errore, verificare che la console di registrazione sia abilitata per l'accesso alla console e che terminal monitor sia abilitato per l'accesso telnet).

Nota: quando si configura il VoIP su un collegamento a 64 Kbps per supportare due chiamate vocali, è comune allocare più del 75% (48 Kbps) della larghezza di banda del collegamento al PQ. In questi casi, è possibile usare il comando max-reserve-bandwidth 80 per aumentare la larghezza di banda disponibile all'80% (51 Kbps).

Per ulteriori informazioni sui comandi bandwidth e priority, consultare il documento sul confronto della larghezza di banda e dei comandi priority di un criterio del servizio QoS.

4. Abilita LLQ: Applicazione della mappa dei criteri all'interfaccia WAN in uscita

Questi comandi spiegano come completare questa attività:

maui-voip-sj(config)#interface multilink 1

maui-voip-sj(config-if)#service-policy output VOICE-POLICY

!-- In this scenario (MLPPP LFI), the service policy is applied to !-- the Multilink interface.

Linee guida per la configurazione della priorità IP RTP

Per configurare la priorità IP RTP, attenersi alle seguenti linee guida:

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

Comando

Descrizione

starting-rtp-port-number

Limite inferiore della porta UDP. Il numero di porta più basso a cui vengono inviati i pacchetti. Per VoIP, impostare questo valore su 16384.

port-number-range

L'intervallo di porte di destinazione UDP. Un numero, aggiunto al numero-porta-rtp-iniziale, restituisce il numero di porta UDP più alto. Per VoIP, impostare questo valore su 16383 (32767 - 16384 = 16383)

bandwidth

Larghezza di banda massima consentita (kbps) nella coda di priorità. Impostare questo numero in base al numero di chiamate simultanee supportate dal sistema.

Configurazione di esempio:

interface Multilink1

!--- Some output omitted

bandwidth 64

ip address 172.22.130.2 255.255.255.252

ip tcp header-compression

fair-queue

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

ip rtp priority 16384 16383 45

Link Fragmentation and Interleaving (LFI): Multilink PPP

Mentre i 1500 byte sono una dimensione comune per i pacchetti dati, un tipico pacchetto VoIP (con frame voce G.729) può essere lungo circa 66 byte (20 byte di payload vocale, 6 byte di intestazione layer 2, 20 byte di intestazione RTP e UDP e 20 byte di intestazione IP).

Ora, immaginate un collegamento a una linea affittata a 56 Kbps dove traffico voce e dati coesistano. Se un pacchetto voce è pronto per essere serializzato proprio quando un pacchetto dati inizia a essere trasmesso attraverso il collegamento, allora c'è un problema. Il pacchetto voce sensibile al ritardo deve attendere 214 msec prima di essere trasmesso (ci vogliono 214 msec per serializzare un pacchetto da 1500 byte su un collegamento a 56 Kbps).

Come si può notare, pacchetti dati di grandi dimensioni possono ritardare la consegna di pacchetti voce di piccole dimensioni, riducendo la qualità del riconoscimento vocale. La frammentazione di questi pacchetti di dati di grandi dimensioni in pacchetti più piccoli e l'interfoliazione dei pacchetti voce tra i frammenti riduce la distorsione e il ritardo. La funzione Cisco IOS Link Fragmentation and Interleaving (LFI) aiuta a soddisfare i requisiti di consegna in tempo reale del VoIP. L'immagine mostra il funzionamento di LFI:

Come mostrato nella Tabella 1, il tempo di ritardo della serializzazione (il tempo necessario per posizionare effettivamente i bit su un'interfaccia) introdotto sui collegamenti WAN a bassa velocità può essere significativo, considerando che il ritardo end-to-end unidirezionale di destinazione non dovrebbe superare i 150 ms. (la raccomandazione ITU-T G.114 specifica un massimo di 150 ms da estremità a estremità).

Tabella 1. Ritardo di serializzazione per diverse dimensioni di frame su collegamenti a bassa velocità Ritardo di serializzazione = dimensioni di frame (bit)/larghezza di banda del collegamento (bps)

1 byte

64 Byte

128 Byte

256 Byte

512 Byte

1024 Byte

1500 Byte

56 kbps

143 us

9 ms

18 ms

36 ms

72 ms

144 ms

214 ms

64 kbps

125 us

8 ms

16 ms

32 ms

64 ms

126 ms

187 ms

128 kbps

62,5 us

4 ms

8 ms

16 ms

32 ms

64 ms

93 ms

256 kbps

31 us

2 ms

4 ms

8 ms

16 ms

32 ms

46 ms

512 kbps

15,5 us

1 ms

2 ms

4 ms

8 ms

16 ms

32 ms

768 kbps

10 us

640 us

1.28 ms

2.56 ms

5.12 ms

10.24 ms

15 ms

1536 kbps

5 us

320 us

640 us

1.28 ms

2.56 ms

5.12 ms

7.5 ms

Nota: per le applicazioni voce, il ritardo di serializzazione consigliato (per hop) è 10 ms e non deve superare i 20 ms.

Le dimensioni del frammento di collegamento possono essere configurate in millisecondi (msec) con il comando ppp multilink fragment-delay. LFI richiede che ppp multilink sia configurato sull'interfaccia con ppp multilink interleave attivato. Per ulteriori informazioni sulla configurazione di LFI, consultare la sezione di questo documento.

Nota: nei casi in cui si dispone di più di una connessione half T1 dedicata (768 Kbps), non è necessaria una funzione di frammentazione. (tuttavia, è comunque necessario un meccanismo QoS, ad esempio LLQ o IP RTP Priority). La metà di T1 offre una larghezza di banda sufficiente per consentire ai pacchetti voce di entrare e uscire dalla coda senza problemi di ritardo. Inoltre, in caso di half-T1, potrebbe non essere necessaria la compressione per il protocollo Real-time Protocol (cRTP), che consente di preservare la larghezza di banda comprimendo le intestazioni IP RTP.

cRTP (Compressed Real-time Protocol)

Nota: il protocollo cRTP non è richiesto per garantire una buona qualità della voce. È una funzione che riduce il consumo di larghezza di banda. Configurare cRTP dopo che tutte le altre condizioni sono state soddisfatte e la qualità della voce è buona. Questa procedura consente di risparmiare tempo nella risoluzione dei problemi isolando potenziali problemi cRTP.

Basata sulla RFC 2508, la compressione dell'intestazione RTP comprime l'intestazione IP/UDP/RTP da 40 byte a 2 o 4 byte, riducendo il consumo di larghezza di banda non necessario. Si tratta di uno schema di compressione hop-by-hop; pertanto, il protocollo cRTP deve essere configurato su entrambe le estremità del collegamento (a meno che non sia configurata l'opzione passiva). Per configurare cRTP, utilizzare questo comando a livello di interfaccia:

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

Poiché il processo di compressione può richiedere un elevato utilizzo della CPU, la compressione dell'intestazione RTP viene implementata nei percorsi di commutazione veloce e CEF come versione 12.0(7)T di IOS. A volte queste implementazioni sono interrotte, e quindi l'unico modo in cui funziona sarà elaborato commutato. Cisco consiglia di utilizzare il protocollo cRTP solo con collegamenti inferiori a 768 Kbps, a meno che il router non stia funzionando a una bassa percentuale di utilizzo della CPU. Monitorare l'utilizzo della CPU del router e disabilitare il protocollo cRTP se è superiore al 75%.

Nota: quando si configura il comando ip tcp header-compression, il router aggiunge il comando ip tcp header-compression alla configurazione per impostazione predefinita. Questa opzione viene usata per comprimere i pacchetti TCP/IP delle intestazioni. La compressione delle intestazioni è particolarmente utile nelle reti con una grande percentuale di pacchetti di piccole dimensioni, ad esempio quelle che supportano molte connessioni Telnet. La tecnica di compressione dell'intestazione TCP, descritta completamente nella RFC 1144, è supportata sulle linee seriali usando l'incapsulamento HDLC o PPP.

Per comprimere le intestazioni TCP senza abilitare cRTP, utilizzare questo comando:

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

Per ulteriori informazioni: Protocollo Compressed Real-time Transport

Altri suggerimenti per la riduzione della larghezza di banda

- utilizzare codificatori/decoder a bassa velocità di trasmissione (codec) sui terminali di chiamata VoIP; si consiglia G.729 (8 Kbps). (questo è il codec predefinito sui dial-peer VoIP). Per configurare codec diversi, usare il comando router(config-dial-peer)#codec nel dial-peer voip desiderato.

- Sebbene il DTMF (Dual Tone Multifrequency) venga solitamente trasportato in modo accurato quando si utilizzano codec voce ad alto bit-rate come G.711, i codec a basso bit-rate (come G.729 e G.723.1) sono altamente ottimizzati per i modelli di voce e tendono a distorcere i toni DTMF. Questo approccio può causare problemi di accesso ai sistemi IVR (Interactive Voice Response). Il comando dtmf relay risolve il problema della distorsione DTMF trasportando i toni DTMF "fuori banda" o separatamente dal flusso vocale codificato. Se si utilizzano codec a bassa velocità di trasmissione (G.729, G.723), attivare il relè dtmf sotto il dial-peer VoIP.

- Una conversazione tipica può contenere il 35-50% di silenzio. Utilizzando il rilevamento dell'attività vocale (VAD), i pacchetti di silenzio vengono eliminati. Per la pianificazione della larghezza di banda VoIP, si supponga che il VAD riduca la larghezza di banda del 35%. Il protocollo VAD è configurato per impostazione predefinita nei dial-peer VoIP. Per abilitare o disabilitare il protocollo VAD, usare i comandi router(config-dial-peer)#vad e router(config-dial-peer)# no vad nei dial-peer voip desiderati.

Esempio di rete

Configurazioni

maui-voip-sj (Cisco 3640)

version 12.2service timestamps debug datetime msec

!-- < Some output omitted >

!

hostname maui-voip-sj

!

ip subnet-zero

!

no ip domain-lookup

!

!-- Definition of the voice signaling and traffic class maps !-- "voice-traffic" class uses access-list 102 for its matching criteria. !-- "voice-signaling" class uses access-list 103 for its matching criteria.

Class-map match-all voice-signaling

match access-group 103

class-map match-all voice-traffic

match access-group 102

!

!-- The policy-map defines how the link resources are assigned !-- to the different map classes. In this configuration, strict priority !-- queue is assigned to "voice-traffic" class with (based on ACL in !-- class voice) with max bandwidth = 45 Kbps.

policy-map VOICE-POLICY

class voice-traffic

priority 48

class voice-signaling

bandwidth 8

!-- Assigns a queue for "voice-signaling" traffic that ensures 8 Kbps. !-- Note that this is optional and has nothing to do with good voice !-- quality, but rather a way to secure signaling.

class class-default

fair-queue

!-- The class-default class is used to classify traffic that does !-- not fall into one of the defined classes. !-- The fair-queue command associates the default class WFQ queueing.

!

call rsvp-sync

!

!-- Note that MLPPP is strictly an LFI mechanism. It does not !-- bundle multiple serial interfaces to the same virtual interface as !-- the name stands (This bundling is done for data and NOT recommended !-- for voice). The end result may manifest itself as jitter and no audio.

interface Multilink1

ip address 172.22.130.1 255.255.255.252

ip tcp header-compression iphc-format

service-policy output VOICE-POLICY

!-- LLQ is an outbound operation and applied to the outbound WAN !-- interface.

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

!-- The configured value of 10 sets the fragment size such that !-- all fragments have a 10 ms maximum serialization delay.

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

!

interface Ethernet0/0

ip address 172.22.113.3 255.255.255.0

no keepalive

half-duplex

!

interface Serial0/0

bandwidth 128

!-- the bandwidth command needs to be set correctly for the !-- right fragment size to be calculated.

no ip address

encapsulation ppp

clockrate 128000

ppp multilink

multilink-group 1

!-- This command links the multilink interface to the physical !-- serial interface.

!

router eigrp 69

network 172.22.0.0

auto-summary

no eigrp log-neighbor-changes

!

!-- access-list 102 matches VoIP traffic based on the UDP port range. !-- Both odd and even ports are put into the PQ. !-- access-list 103 is used to match VoIP signaling protocol. In this !-- case, H.323 V2 with fast start feature is used.

access-list 102 permit udp any any range 16384 32767

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

!

voice-port 1/0/0

!

voice-port 1/0/1

!

voice-port 1/1/0

!

voice-port 1/1/1

!

dial-peer cor custom

!

dial-peer voice 1 pots

destination-pattern 5000

port 1/0/0

!

dial-peer voice 2 voip

destination-pattern 6000

session target ipv4:172.22.130.2

maui-voip-austin (Cisco 3640)

version 12.2

service timestamps debug datetime msec

!

hostname maui-voip-austin

!

boot system flash slot1:c3640-is-mz.122-6a.bin

!

ip subnet-zero

!

class-map match-all voice-signaling

match access-group 103

class-map match-all voice-traffic

match access-group 102

!

policy-map voice-policy

class voice-signaling

bandwidth 8

class voice-traffic

priority 48

class class-default

fair-queue

!

interface Multilink1

bandwidth 128

ip address 172.22.130.2 255.255.255.252

ip tcp header-compression iphc-format

service-policy output voice-policy

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

!-- Configure cRTP after you have a working configuration. !-- This helps isolate potential cRTP issues.

!

Interface Ethernet0/0

ip address 172.22.112.3 255.255.255.0

no keepalive

half-duplex

!

interface Serial0/0

bandwidth 128

no ip address

encapsulation ppp

no ip mroute-cache

ppp multilink

multilink-group 1

!

router eigrp 69

network 172.22.0.0

auto-summary

no eigrp log-neighbor-changes

!

access-list 102 permit udp any any range 16384 32767

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

!

voice-port 1/0/0

!

voice-port 1/0/1

!

voice-port 1/1/0

!

voice-port 1/1/1

!

dial-peer cor custom

!

dial-peer voice 1 pots

destination-pattern 6000

port 1/0/0

!

dial-peer voice 2 voip

destination-pattern 5000

session target ipv4:172.22.130.1

Comandi di verifica e risoluzione dei problemi

Prima di provare i comandi di debug, consultare le informazioni importanti sui comandi di debug. Per ulteriori informazioni sui comandi elencati di seguito, vedere la sezione Output di esempio di show e debug di questo documento.

Comandi interfaccia:

- show interface [seriale] | multilink]: utilizzare questo comando per controllare lo stato dell'interfaccia seriale. Accertarsi che l'interfaccia seriale e multilink siano attive e aperte.

- Risoluzione dei problemi relativi alle linee seriali

Comandi LFI:

- show ppp multilink: questo comando visualizza le informazioni sui bundle per i bundle Multilink PPP.

- debug ppp multilink fragments: questo comando debug visualizza informazioni sui singoli frammenti di connessione multipla e sugli eventi di interfoliazione. Questo output del comando identifica anche il numero di sequenza del pacchetto e le dimensioni del frammento.

Comandi di priorità LLQ/IP RTP:

- show policy-map interface multilink interface# - Questo comando è molto utile per visualizzare il funzionamento di LLQ e gli eventuali cali nel PQ. Per ulteriori informazioni sui vari campi di questo comando, consultare il documento sulla descrizione dei contatori di pacchetti in show policy-map interface Output.

- show policy-map policy_map_name: questo comando visualizza informazioni sulla configurazione della mappa dei criteri.

- show queue interface-type interface-number: questo comando elenca la configurazione della coda corretta e le statistiche di una particolare interfaccia.

- Debug priority: questo comando di debug visualizza gli eventi di coda con priorità e indica se si verifica l'eliminazione in questa coda. Fare riferimento anche alla sezione Risoluzione dei problemi di output con Accodamento priorità.

- show class-map nome_classe - Questo comando visualizza informazioni sulla configurazione della mappa di classe.

- show call active voice: questo comando è utile per verificare la presenza di pacchetti persi a livello di DSP.

Altri comandi/riferimenti:

- show ip rtp header-compression: questo comando visualizza le statistiche di compressione dell'intestazione RTP.

- Nozioni fondamentali sulla risoluzione dei problemi e il debug delle chiamate VoIP

- Comandi di debug VoIP

Problemi noti:

- CSCds43465: "LLQ, Policer, Shaper Should Take CRTP Compression Feedback" Per visualizzare le note sulla versione, fare riferimento a Bug ToolKit (solo utenti registrati).

Linee guida:

Di seguito sono riportati alcuni passaggi di base per la risoluzione dei problemi, una volta che il collegamento ppp è attivo e in esecuzione (MLPPP, Fragmentation, Interleaving):

1. show call active voice: consente di verificare la presenza di eventuali pacchetti persi a livello di DSP.

2. show interface - Consente di verificare la presenza di problemi generali relativi alle linee seriali o alle interfacce. I rilasci sull'interfaccia non indicano ancora un problema, ma è preferibile eliminare il pacchetto dalla coda a bassa priorità prima che raggiunga la coda dell'interfaccia.

3. show policy-map interface: consente di verificare la presenza di rilasci LLQ e la configurazione di accodamento. Non devono segnalare alcuna perdita che violi la politica.

4. show ip rtp header-compression: consente di verificare la presenza di problemi specifici del protocollo cRTP.

Output di esempio di show e debug

!----------------------------------------------- !-----------------------------------------------  !---- To capture sections of this output, the LLQ PQ bandwidth !---- was lowered and large data traffic was placed !---- on the link to force some packets drops. !----------------------------------------------- !----------------------------------------------- !---- Packet Drop Verification (During an Active Call) !--- Assuming your ppp link is up and running, the first step of voice !--- quality problems verification is to check for lost packets !--- at the DSP. Note: Use the show call active voice command !--- NOT show call active voice brief

maui-voip-austin#show call active voice

Total call-legs: 2

!--- Indicates that the connection is established and both legs exist

GENERIC:

SetupTime=155218260 ms

Index=1

PeerAddress=5000

PeerSubAddress=

PeerId=2

PeerIfIndex=13

LogicalIfIndex=0

ConnectTime=155218364

CallDuration=00:00:27

CallState=4

!--- indicates that it is the active call !--- (#define D_callActiveCallState_active 4).

CallOrigin=2

ChargedUnits=0

InfoType=2

TransmitPackets=365

TransmitBytes=7300

ReceivePackets=229

ReceiveBytes=4580

VOIP:

!--- For this call, this was the terminating gateway. !--- At this gateway, the call started at the VoIP leg.

ConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

IncomingConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

RemoteIPAddress=172.22.130.1

!--- Indicates from which IP address the RTP stream is originating.

RemoteUDPPort=18778

RemoteSignallingIPAddress=172.22.130.1

!--- Indicates from which IP address signaling messages are coming.

RemoteSignallingPort=11010

RemoteMediaIPAddress=172.22.130.1

RemoteMediaPort=18778

RoundTripDelay=50 ms

SelectedQoS=best-effort

tx_DtmfRelay=inband-voice

FastConnect=TRUE

Separate H245 Connection=FALSE

H245 Tunneling=FALSE

SessionProtocol=cisco

SessionTarget=

OnTimeRvPlayout=4570

GapFillWithSilence=20 ms

GapFillWithPrediction=1840 ms

GapFillWithInterpolation=0 ms

GapFillWithRedundancy=0 ms

HiWaterPlayoutDelay=70 ms

LoWaterPlayoutDelay=51 ms

ReceiveDelay=51 ms

LostPackets=90

EarlyPackets=1

LatePackets=0

!--- Indicates the precense of jitter, lost packets, or !--- corrupted packets.

VAD = enabled

CoderTypeRate=g729r8

CodecBytes=20

GENERIC:

SetupTime=155218260 ms

Index=2

PeerAddress=6000

PeerSubAddress=

PeerId=1

PeerIfIndex=12

LogicalIfIndex=6

ConnectTime=155218364

CallDuration=00:00:34

CallState=4

CallOrigin=1

ChargedUnits=0

InfoType=2

TransmitPackets=229

TransmitBytes=4580

ReceivePackets=365

ReceiveBytes=7300

TELE:

ConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

IncomingConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

TxDuration=35360 ms

VoiceTxDuration=730 ms

FaxTxDuration=0 ms

CoderTypeRate=g729r8

NoiseLevel=-46

ACOMLevel=2

OutSignalLevel=-58

InSignalLevel=-42

InfoActivity=2

ERLLevel=7

SessionTarget=

ImgPages=0Total call-legs: 2

!---------------------------------------------------------- !--- Interface Verification !--- Make sure you see this: !--- LCP Open, multilink Open: Link control protocol (LCP) open statement !--- indicates that the connection is establish. !--- Open:IPCP. Indicates that IP traffic can be transmitted via the PPP link.

maui-voip-sj#show interface multilink 1

Multilink1 is up, line protocol is up

Hardware is multilink group interface

Internet address is 172.22.130.1/30

MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

DTR is pulsed for 2 seconds on reset

LCP Open, multilink Open

Open: IPCP

Last input 00:00:01, output never, output hang never

Last clearing of "show interface" counters 00:25:20

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 91

Queueing strategy: weighted fair

Output queue: 0/1000/64/37/383 (size/max total/threshold/drops/interleaves)

Conversations  0/3/32 (active/max active/max total)

Reserved Conversations 1/1 (allocated/max allocated)

Available Bandwidth 38 kilobits/sec

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

8217 packets input, 967680 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

13091 packets output, 1254194 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

----------------------------------------------------------------

!-- Note: There are no drops at the interface level. !-- All traffic that is dropped due to policing, is !-- dropped before it gets to the interface queue.

maui-voip-austin#show interface

serial 0/0Serial0/0 is up, line protocol is up

Hardware is QUICC Serial

MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,

reliability 255/255, txload 49/255, rxload 47/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

LCP Open, multilink Open

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 00:22:08

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: weighted fair  [suspended, using FIFO]

FIFO output queue 0/40, 0 drops

5 minute input rate 24000 bits/sec, 20 packets/sec

5 minute output rate 25000 bits/sec, 20 packets/sec     4851 packets input, 668983 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

4586 packets output, 657902 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

!----------------------------------- !--- LLQ Verification

maui-voip-austin#show policy-map int multilink 1

Multilink1

Service-policy output: voice-policy

Class-map: voice-signaling (match-all)

!--- This is the class for the voice signaling traffic.

10 packets, 744 bytes

5 minute offered rate 0 BPS, drop rate 0 BPS

Match: access-group 103

Weighted Fair Queueing

Output Queue: Conversation 42

Bandwidth 8 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 10/744

(depth/total drops/no-buffer drops) 0/0/0

Class-map: voice-traffic (match-all)

!--- This is PQ class for the voice traffic.

458 packets, 32064 bytes

5 minute offered rate 0 BPS, drop rate 0 BPS

Match: access-group 102

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 40

Bandwidth 15 (kbps) Burst 375 (Bytes)

!--- Notice that the PQ bandwidth was lowered to force packet drops.

(pkts matched/bytes matched) 458/29647

(total drops/bytes drops) 91/5890

!--- Some packets were dropped. In a well designed link,

!--- there should be no (or few) drops of the PQ class.

Class-map: class-default (match-any)

814 packets, 731341 bytes

5 minute offered rate 27000 BPS, drop rate 0 BPSMatch: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 32

(total queued/total drops/no-buffer drops) 0/0/0

!---------------------------------------------

!--- Verify the class-map configuration

maui-voip-austin#show class-map

Class Map match-all voice-signaling (id 2)

Match access-group  103

Class Map match-any class-default (id 0)

Match any

Class Map match-all voice-traffic(id 3)

Match access-group 102

!--- Verify the access-lists of the class-maps

maui-voip-austin#show access-lists

Extended IP access list 102

permit udp any any range 16384 32767 (34947 matches)

Extended IP access list 103

permit tcp any eq 1720 any (187 matches)

permit tcp any any eq 1720 (86 matches)

!--- Verify the policy-pap configuration

maui-voip-austin#show policy-map voice-policy

Policy Map voice-policy

Class voice-signaling

Weighted Fair Queueing

Bandwidth 8 (kbps) Max Threshold 64 (packets)

Class voice-traffic

Weighted Fair Queueing

Strict Priority

Bandwidth 50 (kbps) Burst 1250 (Bytes)

Class class-default

Weighted Fair Queueing

Flow based Fair Queueing Max Threshold 64 (packets)

---------------------------

!--- Debug priority command provides immediate feedback in case !--- of VoIP packet drops. !--- The output below shows the error message when VoIP packets !--- are being dropped from the strict priority queue.

maui-voip-sj#debug priority

priority output queueing debugging is on

maui-voip-sj#

Mar 17 19:47:09.947: WFQ: dropping a packet from the priority queue 0

Mar 17 19:47:09.967: WFQ: dropping a packet from the priority queue 0

Mar 17 19:47:09.987: WFQ: dropping a packet from the priority queue 0

-------------------------------------------------------------------

!--- Link Fragmentation and Interleaving (LFI) Verification

maui-voip-sj#show ppp multilink

!--- Verify the fragmentation size and multilink

Multilink1, bundle name is maui-voip-austin

Bundle up for 00:08:04

0 lost fragments, 0 reordered, 0 unassigned

0 discarded, 0 lost received, 1/255 load

0x6D received sequence, 0x6E sent sequence

Member links: 1 active, 0 inactive (max not set, min not set)

Serial0/0, since 00:08:09, last rcvd seq 00006C 160 weight

!--- Notice the fragmentation size is 160 Bytes. The link is configured with a !--- bandwidth of 128 kbps and a serialization delay of 10 msec. !--- Fragment Size (in bits) = bandwidth * serialization delay. !--- Note: There are 8 bits in one byte.

-------------------------------------------------------

!--- Link Fragmentation and Interleaving (LFI) Verification !--- Testing Multilink PPP Link LFI !--- This output displays fragmentation and interleaving information !--- when the the 128kbps PPP link is loaded with big data and VoIP packets.

maui-voip-sj#debug ppp multilink fragments

Multilink fragments debugging is on

1w3d: Se0/0 MLP: O frag 800004CF size 160

1w3d: Se0/0 MLP: O frag 000004D0 size 160

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Mu1 MLP: Packet interleaved from queue 40

1w3d: Se0/0 MLP: O ppp IP (0021) size 64

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: O frag 400004D1 size 106

1w3d: Se0/0 MLP: O ppp IP (0021) size 64

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: O ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: I frag 800004E0 size 160 direct

1w3d: Se0/0 MLP: I frag 000004E1 size 160 direct

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

-------------------------------------------------------------------

!--- Sample output of show ip rtp header-compression command

maui-voip-sj#show ip tcp header-compression

TCP/IP header compression statistics:  Interface Multilink1:

Rcvd:    10 total, 6 compressed, 0 errors

0 dropped, 0 buffer copies, 0 buffer failures

Sent:    10 total, 7 compressed,

230 bytes saved, 99 bytes sent

3.32 efficiency improvement factor

Connect: 16 rx slots, 16 tx slots,

2 long searches, 1 misses 0 collisions, 0 negative cache hits

90% hit ratio, five minute miss rate 0 misses/sec, 0 max

----------------------------------------------------------------------

!--- This command displays information of the voip dial-peers command.

maui-voip-sj#show dial-peer voice 2

VoiceOverIpPeer2

information type = voice,

tag = 2, destination-pattern = `6000',

answer-address = `', preference=0,

group = 2, Admin state is up, Operation state is up,

incoming called-number = `', connections/maximum = 0/unlimited,

application associated:

type = voip, session-tMarget = `ipv4:172.22.130.2',

technology prefix:

ip precedence = 0, UDP checksum = disabled,

session-protocol = cisco, req-qos = best-effort,

acc-qos = best-effort,

fax-rate = voice,   payload size =  20 bytes

codec = g729r8,   payload size =  20 bytes,

Expect factor = 10, Icpif = 30,signaling-type = cas,

VAD = enabled, Poor QOV Trap = disabled,

Connect Time = 283, Charged Units = 0,

Successful Calls = 1, Failed Calls = 0,

Accepted Calls = 1, Refused Calls = 0,

Last Disconnect Cause is "10  ",

Last Disconnect Text is "normal call clearing.",

Last Setup Time = 93793451.

-------------------------------------------------------------------------

!---The CPU utilization of the router should not exceed the 50-60 percent !--- during any five-minute interval.

maui-voip-austin#show processes cpu

CPU utilization for five seconds: 12%/8%; one minute: 11%; five minutes: 9%

PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process

1         148    310794          0  0.00%  0.00%  0.00%   0 Load Meter

2          76        23       3304  0.81%  0.07%  0.01%   0 Exec

Informazioni correlate

- Accodamento a bassa latenza

- Panoramica della gestione delle congestioni

- Implementazione di Quality of Service (QoS)

- Voice Over IP - Utilizzo della larghezza di banda per chiamata

- Quality of Service per Voice over IP

- Configurazione di Voice over IP

- Supporto alla tecnologia vocale

- Supporto dei prodotti per le comunicazioni voce e IP

- Risoluzione dei problemi di Cisco IP Telephony

- Supporto tecnico – Cisco Systems