Gestione della qualità della voce con CVM e Telemate

Introduzione

In questo documento viene spiegato come usare Cisco Voice Manager e Telemate per gestire la qualità della voce in una rete VoIP. Tutti i contenuti si basano su un'implementazione reale di telefonia IP. Scopo principale del documento è descrivere l'applicazione dei prodotti e non il loro utilizzo. Si presume che l'utente conosca CVM e Telemate e abbia accesso alla documentazione necessaria. Per un elenco dei documenti utili, vedere Informazioni correlate.

Quando si gestisce una rete VoIP su larga scala, è necessario disporre degli strumenti necessari per monitorare e segnalare in modo obiettivo la qualità della voce nella rete. Non è possibile basarsi esclusivamente sul feedback dell'utente, in quanto è soggettivo e incompleto. CVM, insieme a Telemate, può fornire parte di questa funzione. Riporta la qualità della voce utilizzando il fattore di pianificazione della riduzione di valore/riduzione di valore calcolata (Icpif) calcolato da un gateway IOS per ogni chiamata. Questo consente al gestore della rete di identificare i siti con problemi di scarsa qualità vocale e di gestirli in modo appropriato.

Una volta identificati i siti con problemi, potrebbero essere necessari altri strumenti per risolvere i possibili problemi di QoS della rete. Due strumenti sono Internetwork Performance Monitor (IPM) e Cisco Service Assurance Agent (CSAA). Questi argomenti sono trattati in un altro documento pubblicato sul nostro sito Web.

Prerequisiti

Requisiti

Questo documento è utile per conoscere i seguenti argomenti:

• Cisco Voice Manager e telemate

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

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.

Panoramica sulla qualità vocale

Le sezioni seguenti forniscono una panoramica dei problemi relativi alla qualità vocale:

• Misurazione della qualità vocale
• Panoramica su ITU G.113

Misurazione della qualità vocale

Lo standard ITU G.113 specifica come misurare la qualità della voce. Questo metodo richiede che sia possibile determinare la qualità delle chiamate vocali calcolando l'Icpif. I gateway basati su IOS calcolano il valore Icpif per ogni chiamata e lo registrano come parte del record CDR. Inoltre, può inviare una trap QoV (Quality of Voice) tramite SNMP se il valore Icpif di una chiamata supera un valore preimpostato. Ciò significa che i gateway dispongono di capacità di misurazione della qualità vocale incorporate. È sufficiente raccogliere queste misurazioni e analizzare i dati per individuare eventuali tendenze.

La qualità vocale VoIP è influenzata principalmente dalla QoS della rete. L'analisi delle chiamate si concentrerà quindi sull'identificazione dei problemi di qualità vocale per ciascun sito. Se è possibile identificare siti con un elevato numero di chiamate con scarsa qualità vocale, è possibile concentrarsi su qualsiasi problema QoS nel percorso di rete da e verso tali siti.

Panoramica su ITU G.113

La sezione seguente è solo una breve panoramica; consultate lo standard G.113 per informazioni più dettagliate.

L'idea generale di G.113 è quella di calcolare un fattore di riduzione di valore per ogni apparecchiatura lungo il percorso vocale e poi aggiungerlo per ottenere la riduzione di valore totale. Esistono diversi tipi di menomazioni (rumore, ritardo, eco, ecc.) e l'ITU le suddivide in cinque categorie. Aggiungili per ottenere la perdita di valore totale Itot:

Itot = Io + Iq + Idte + Idd + Ie

Ciascuno di essi è definito come segue (utilizzando la terminologia ITU):

• Io - Insufficienze causate da un livello di rumorosità complessivo non ottimale e/o da un livello di rumore di circuito elevato.

• Iq - le riduzioni di valore causate dalla quantizzazione della distorsione del tipo PCM.

• Idte—menomazioni causate dall'eco dell'interlocutore.

• Idd: difficoltà di comunicazione vocale causate da lunghi tempi di trasmissione unidirezionali (ritardo).

• Ie - danni causati da apparecchiature speciali, in particolare codec a bassa velocità di bit non di forma d'onda.

Quando il software Cisco IOS calcola Itot, ignora Io e Iq come trascurabili e imposta Idte su 0. Il valore Idd è derivato dalla tabella seguente, derivata da G.113:

Ritardo	Idd
150	0
200	3
250	10
300	15
400	25
500	30
600	35
800	40

Normalmente Ie è un valore fisso, a seconda solo del tipo di codec. G.113 specifica i valori per i codec generalmente utilizzati dai gateway Cisco, come mostrato nella tabella seguente:

Codice	Ie
G.711	0
G.729/G.729a	10

Tuttavia, poiché questi codec vengono utilizzati in un ambiente packet voice, il danno effettivo dipende dalla perdita di pacchetti. Maggiore è la perdita di pacchetti, maggiore è la perdita di dati. I tecnici Cisco hanno misurato la qualità della voce con PSQM (ITU P.861) a livelli di perdita dei pacchetti discreti. La tabella seguente mostra i valori di distorsione vocale relativi ai livelli di perdita dei pacchetti per i codec specificati:

Percentuale perdita pacchetti	G.711	G.729/G.729a
0	0	10
1	8	15
2	12	20
3	18	25
4	22	30
5	26	34
6	28	38
7	30	40
8	32	42
9	34	44

Come previsto, G.729 è più suscettibile alla perdita di pacchetti rispetto a G.711.

La qualità della voce dipende dalla percezione e dalle aspettative dell'uomo. Le aspettative in termini di livelli di servizio degli utenti di telefoni cellulari sono inferiori a quelle degli utenti di linee fisse. Ne teniamo conto nel calcolare l'Icpif riducendo l'Itot in base al fattore di aspettativa umana A. La formula è:

Icpif = Itot - A

G.113 fornisce anche fattori di aspettativa per le reti voce tipiche. Vedere la tabella seguente:

Metodo di accesso alla rete voce	Fattore previsto A
PSTN linea fissa convenzionale	0
Local Area wireless (telefono cordless)	5
Wireless ad ampio raggio (cellulare)	10
Satellite	20

G.113 ha anche una tabella che mappa il valore Icpif e la qualità della voce. La tabella riportata di seguito illustra la procedura.

Metodo di accesso alla rete voce	Fattore previsto A
5	Molto buono
10	Buono
20	Adeguato
30	Maiuscole/minuscole
45	Limitazione eccezionale dei casi
55	Utenti che probabilmente si lamentano fortemente

Un valore Icpif pari a zero per una chiamata è un punteggio perfetto. Questo dovrebbe essere il nostro obiettivo per le reti VoIP.

In una rete voce tradizionale, il progettista calcolerebbe il budget totale per la riduzione di valore.

Ad esempio, Io = 0; Iq = 0 Idte = 0; Idd = 3; Ie = 7, che dà Itot = 10.

Se l'utente accede alla rete da un telefono senza fili, il fattore massimo di attesa che è possibile sottrarre è 5, quindi il risultato finale è:

Icpif = Itot - A = 10 - 5 = 5

In base alla tabella precedente, è quindi probabile che gli utenti percepiscano la qualità della voce come molto buona.

In questo documento viene descritta una soluzione che utilizza il valore Icpif per il monitoraggio della qualità vocale anziché per scopi di pianificazione.

Gestione della qualità della voce con CVM e Telemate

Nelle sezioni seguenti viene descritto come gestire la qualità vocale con CVM e Telemate:

• Limitazioni
• Configurazione gateway
• Architettura CVM e Telemate
• Telematica directory
• Reporting

Limitazioni

Anche se la soluzione proposta presenta dei limiti, non sembra essere disponibile alcun altro strumento scalabile. Le limitazioni note includono:

• Solo le chiamate effettuate tramite un gateway sono soggette al controllo di qualità. Impossibile misurare le chiamate da IPhone a IPhone. Il gateway non rileva queste chiamate e CallManager non supporta attualmente G.113.

• Per il calcolo dell'Icpif, viene presa in considerazione solo la perdita e il ritardo dei pacchetti. Echo non è incluso nei calcoli Icpif. Pertanto, una chiamata può soffrire di eco grave e ottenere comunque un punteggio Icpif perfetto.

• La qualità della voce viene misurata solo nella direzione IPhone-to-gateway. Il valore Icpif in una rete voce di pacchetto è probabilmente asimmetrico nelle due direzioni. Qualsiasi problema QoS di rete unidirezionale nella direzione da gateway a IPhone non si rifletterà nel valore Icpif calcolato dal gateway.

• In genere, i problemi di qualità vocale sono più frequenti sulle WAN. La soluzione discussa si adatta meglio a un ambiente con gateway centralizzati, in quanto le chiamate da IPhone su siti remoti devono attraversare la WAN per accedere ai gateway. Se i gateway sono distribuiti (ad esempio, ogni sito remoto è servito da un gateway locale), la maggior parte delle chiamate al gateway non attraversa la WAN. Le chiamate VoIP sulla WAN saranno principalmente da IPhone a IPhone e non sono visibili al gateway.

Configurazione gateway

Come parte della soluzione proposta, tutti i gateway devono essere configurati per la raccolta CDR:

dial-control-mib max-size <max-number-of-cdr>
dial-control-mib retain-timer 600

La funzionalità Trap QoV deve essere abilitata anche per tutti i gateway. Questa funzione è disabilitata per impostazione predefinita:

Calibra#show dial-peer voice 99 | include QOV|Icpif
Expect factor = 0, Icpif = 20,
VAD = enabled, Poor QOV Trap = disabled,

Questa funzionalità è abilitata su base dial-peer VoIP aggiungendo quanto segue:

dial-peer voice XYZ voip
snmp enable peer-trap poor-qov
icpif <threshold>
expect-factor 0

Al termine di una chiamata, il gateway calcola la riduzione di valore totale (Itot) per la chiamata. Sottrae quindi il fattore previsto configurato da Itot per ottenere il valore Icpif effettivo. Se questo numero supera la soglia Icpif, viene inviata una trap QoV. La durata della chiamata deve essere di almeno 10 secondi affinché il gateway possa calcolare il valore Icpif per la chiamata.

Di seguito è riportato un esempio di configurazione del gateway:

dial-peer voice XYZ voip
icpif 10
expect-factor 5

Si supponga che una chiamata venga completata con un valore Itot di 20. Il gateway sottrae quindi un fattore previsto di 5 da questo numero, dando un valore Icpif di 15. Poiché 15 è maggiore di 10, il gateway genera una trap SNMP QoV.

A livello globale, è necessario consentire l'invio di trap QoV alla CVM:

snmp-server enable traps voice poor-qov
snmp-server host 10.x.x.x.x public<----- CVM station

I gateway vocali generano trap SNMP di collegamento/collegamento verso il basso ogni volta che una chiamata viene configurata o disattivata. Ciò può comportare un numero enorme di trap su gateway ad alta densità. Assicurarsi di disattivare queste trap aggiungendo il seguente comando:

interface serial1/0:15no snmp trap link-status

Architettura CVM e Telemate

CVM e Telemate sono applicazioni completamente separate. Come suggerisce il nome, CVM è un prodotto sviluppato da Cisco. Telemate, d'altro canto, è un prodotto di terze parti che Cisco vende in bundle con CVM.

La tecnologia CVM esegue una serie di funzioni. Le due funzioni che utilizzeremo sono:

• Raccolta di Call Detail Records (CDR) dai gateway tramite SNMP.

• Ricezione di trap SNMP Quality of Voice (QoV) dai gateway.

Dopo aver raccolto queste informazioni, CVM formatta i dati e li trasmette a Telemate tramite semplice condivisione di file. Elabora quindi i dati e li memorizza in un database Microsoft SQL. Il risultato finale è un database con un elenco di chiamate con i rispettivi dettagli, incluso il valore Icpif. È quindi possibile eseguire diversi report sul database, inclusi i report QoV.

Il report QoV di Telemate che ci interessa è il report "Packet Voice Calling with Quality of Service Trap". Questo report elenca tutte le chiamate per cui il gateway ha generato una trap QoV. Non siamo interessati ai singoli inviti; siamo piuttosto interessati a identificare gli eventuali siti che presentano una percentuale di chiamate con qualità vocale superiore alla media. A tale scopo, è necessario che Telemate sia in grado di classificare le chiamate in base al sito. Questa operazione viene descritta nella sezione seguente.

Telematica directory

Inserendo nella directory Telemate informazioni sulle estensioni che risiedono in determinati siti, è possibile utilizzare Telemate per classificare le chiamate in base al sito.

La directory Telemate è una gerarchia a cinque livelli, con i seguenti livelli:

• Livello 1 - Società

• Livello 2 - Divisione

• Livello 3 - Reparto

• Livello 4 - Utente

• Livello 5 - Estensione

È possibile associare più estensioni a un utente.

In teoria, vorremmo che ogni chiamata nel report QoV fosse elencata con il nome del reparto. Potremmo quindi utilizzare il nome del reparto per rappresentare un determinato sito. In questo modo è possibile ordinare le chiamate per reparto/sito. Ma poiché le estensioni possono essere associate solo agli utenti, dobbiamo ottenere questo in modo leggermente imbarazzante. In pratica viene creato un utente fittizio per sito e il nome di tale utente viene impostato come nome del sito o codice del sito. A questo utente fittizio vengono quindi assegnate tutte le estensioni per quel particolare sito. È quindi possibile ordinare le chiamate in base all'utente, che diventa quindi l'equivalente di ordinarle in base al sito.

Ai fini del report QoV, non ci interessano i primi tre livelli della gerarchia di directory e a questi possono essere assegnati valori arbitrari.

Per questa implementazione, sono disponibili 200 siti con 45.000 estensioni assegnate, anche se non necessariamente tutte in uso. La directory contiene quindi 200 utenti fittizi e ogni utente fittizio è associato all'intervallo di estensioni per il proprio sito. Compilare la directory manualmente sarebbe un'operazione impossibile, quindi questa operazione viene eseguita in modo semi-automatico generando un file CSV con una riga per estensione e quindi si utilizza la funzione di importazione Telemate per importare il file nella directory. Ogni riga del file CSV ha il seguente formato:

Company,Division,Department,User,Extension

La generazione del file CSV viene inoltre eseguita in modo semi-automatico eseguendo uno script della shell Unix. Questo script accetta un file di inizializzazione come input. In questo file di origine sono elencati i siti e gli intervalli di estensione associati. Ogni riga nel file di origine ha il seguente formato:

site_name,extention_start,extension_end

Lo script shell è molto semplice e ha il seguente aspetto:

#--------------------------- Telemate script start ------------------------

#!/bin/ksh
 
 for i in `cat ./$1`
 do (
   echo $i | awk 'BEGIN{FS=","}{for (j=($2+0);j<($3+0);++j) printf "Company,Division,Dept,%s,%s\n", $1,j}'
) done
#--------------------------- Telemate script end ------------------------

Supponendo che lo script stesso sia denominato 'make_dir' e che il file di origine sia denominato 'seedfile.csv', il file telemate_dir.csv di importazione CSV viene creato eseguendo il comando seguente al prompt di Unix:

unix$ make_dir seedfile.csv > telemate_dir.csv

Il file di output telemate_dir.csv viene quindi importato in Telemate. Fare riferimento alla documentazione di Telemate per istruzioni dettagliate su come eseguire questa operazione.

Reporting

Quando si esegue un report di telematica, è possibile selezionare la destinazione di output. Per i report di grandi dimensioni, si consiglia di produrre il file in formato CSV. È quindi possibile modificare il report in Excel, nel modo seguente:

Durata	N. composizione	Posizione	Data	Ora	Sito	Est.
0:00:57	3-573-7783	10.200.16.33	10/05/2000	16:49:45	BLM	37569
0:00:57	3-573-7783	10.200.16.33	10/05/2000	16:49:45	BLM	37569
0:00:38	3-577-2958	10.200.16.33	10/05/2000	16:28:28	BLM	37576
0:00:38	3-577-2958	10.200.16.33	10/05/2000	16:28:28	BLM	37576
0:00:52	3-577-2985	10.200.16.33	10/05/2000	21:26:33	BLM	37593
0:01:19	3-577-1770	10.200.16.33	10/05/2000	19:26:05	BMC	34270
0:00:23	3-577-1770	10.200.16.33	10/05/2000	20:08:27	BMC	34270
0:00:23	3-577-1770	10.200.16.33	10/05/2000	20:08:27	BMC	34270
0:00:11	4-566-5302	10.132.16.33	10/05/2000	19:05:33	COR	42791
0:00:32	4-567-0417	10.132.16.33	10/05/2000	17:29:51	COR	42805
0:00:32	4-567-0417	10.132.16.33	10/05/2000	17:29:51	COR	42805
0:00:36	4-232-8545	10.132.16.33	10/05/2000	17:42:07	COR	42823
0:00:36	4-232-8545	10.132.16.33	10/05/2000	17:42:07	COR	42823
0:00:39	4-472-5011	10.132.16.33	10/05/2000	17:59:23	COR	46578
0:00:39	4-472-5011	10.132.16.33	10/05/2000	17:59:23	COR	46578
0:00:28	4-236-7687	10.132.16.33	10/05/2000	19:17:51	COR	46578
0:00:17	6-867-9766	10.132.16.35	10/05/2000	16:08:02	GIS	64197
0:00:17	6-867-9766	10.132.16.35	10/05/2000	16:08:02	GIS	64197
0:00:30	6-868-6889	10.132.16.35	10/05/2000	18:15:48	GIS	68549
0:00:30	6-868-6889	10.132.16.35	10/05/2000	18:15:48	GIS	68549
0:01:26	6-876-5223	10.132.16.35	10/05/2000	19:10:23	HAH	68369
0:01:26	6-876-5223	10.132.16.35	10/05/2000	19:10:23	HAH	68369
0:00:52	6-876-2223	10.132.16.35	10/05/2000	17:37:58	HAH	68397
0:01:05	4-477-5402	10.132.16.33	10/05/2000	16:23:20	JVL	47162
0:00:24	4-478-8848	10.132.16.33	10/05/2000	19:07:09	JVL	47168
0:00:24	4-478-8848	10.132.16.33	10/05/2000	19:07:09	JVL	47168
0:00:44	4-387-1333	10.132.16.33	10/05/2000	19:49:16	KIB	49252
0:00:44	4-387-1333	10.132.16.33	10/05/2000	19:49:16	KIB	49252
0:01:14	4-389-4299	10.132.16.33	10/05/2000	16:07:10	KIB	49254
0:01:14	4-389-4299	10.132.16.33	10/05/2000	16:07:10	KIB	49254
0:00:29	4-387-1337	10.132.16.33	10/05/2000	16:06:45	KIB	49256
0:00:29	4-387-1337	10.132.16.33	10/05/2000	16:06:45	KIB	49256
0:00:41	4-384-9269	10.132.16.33	10/05/2000	16:09:38	KIB	49261
0:00:41	4-384-9269	10.132.16.33	10/05/2000	16:09:38	KIB	49261
0:00:41	4-384-9269	10.132.16.33	10/05/2000	16:09:38	KIB	49261
0:00:17	4-387-1344	10.132.16.33	10/05/2000	16:33:04	KIB	49263
0:00:17	4-387-1344	10.132.16.33	10/05/2000	16:33:04	KIB	49263
0:00:31	6-367-5103	10.132.16.35	10/05/2000	20:44:46	LEV	64233
0:00:31	6-367-5103	10.132.16.35	10/05/2000	20:44:46	LEV	64233
0:00:30	6-368-9088	10.132.16.35	10/05/2000	16:11:06	LEV	64247
0:00:30	6-368-9088	10.132.16.35	10/05/2000	16:11:06	LEV	64247
0:00:38	4-570-2450	10.132.16.33	10/05/2000	16:08:26	LHT	43636
0:00:38	4-570-2450	10.132.16.33	10/05/2000	16:08:26	LHT	43636

Utilizzare la funzione "subtotali" di Excel per contare il numero di chiamate errate per utente/sito. Creare quindi una macro di Excel per automatizzare la creazione dei subtotali. Vedere l'esempio seguente:

Durata	N. composizione	Posizione	Data	Ora	Sito	Est.
				Conteggio BCM	5
				Conteggio BMC	3
				Conteggio COR	8
				Conteggio GIS	4
				Conteggio HAH	3
				Conteggio JVL	3
				Conteggio KIB	11
				Conteggio LEV	4
				Conteggio LHT	2
				Conteggio complessivo	43

La colonna Sito contiene ora il numero di chiamate errate da e verso il sito. La colonna Posizione nel report corrisponde all'indirizzo IP dell'altra estremità della gamba VoIP e proviene dal record CDR del gateway. In un ambiente CallManager (CCM), i punti terminali di segnalazione e media sono due indirizzi IP distinti. L'indirizzo IP elencato è l'endpoint della segnalazione (ad esempio, CallManager). È stato inviato un DTS (CSCds23283) per richiedere una manopola che consenta al record CDR di registrare l'indirizzo IP del supporto. In questo modo le chiamate non valide verranno ordinate in base alla subnet. In questo modo si ottiene una maggiore granularità, in quanto in genere sono presenti più subnet per sito. Se solo alcune di queste subnet presentano problemi di QoV, è possibile identificarle.

È consigliabile configurare l'utilità di pianificazione telematica per l'esecuzione automatica del rapporto "Chiamate vocali a pacchetti con registrazione QoS" una volta al giorno. I report completati possono quindi essere inviati via e-mail al personale operativo selezionato. Questi membri dello staff eseguono quindi un controllo QoV giornaliero nelle ultime 24 ore. I report devono essere archiviati per almeno un mese in modo che qualsiasi deterioramento di QoV possa essere correlato a qualsiasi modifica di rete eseguita in quel periodo.

Nota: per il corretto funzionamento dei report con i gateway che operano in un ambiente CallManager, è necessario utilizzare la versione 4.7 o successive di Telemate. Nelle versioni precedenti di Telemate si presume che le estensioni locali si trovino sempre sul lato POTS del gateway. In un ambiente CallManager, le estensioni locali (IPhone) si trovano sul lato VoIP del gateway. Di conseguenza, le versioni precedenti di Telemate vengono confuse e i report hanno un valore limitato.

Informazioni correlate

• Supporto dei prodotti Unified Communications
• Risoluzione dei problemi di Cisco IP Telephony
• Documentazione e supporto tecnico – Cisco Systems