02. 09. 2015 Andrea di Lernia NetEye

Monitoraggio delle comunicazioni VoIP tramite IP SLA

VoIP Image

Nell’era della comunicazione digitale, il Voice over IP (VoIP) è da anni una realtà che ha portato da un lato dei considerevoli risparmi  economici e una grande flessibilità nelle infrastrutture ( chi se li ricorda più i cablaggi dedicati alla telefonia …).

L’altro lato della medaglia è la complessità nelle architetture che si è venuta a creare e la difficoltà nel capire, quando ci sono dei problemi  la loro effettiva causa.

Uno dei problemi ricorrenti nell’ utilizzo del Voice Over IP è la scarsa qualità delle conversazioni, casistica che si presenta di norma in presenza di reti geografiche dove le linee possono essere sottodimensionate o semplicemente male utilizzate.

Cosa possiamo fare quando siamo tempestati di telefonate dal nostri utenti che chiamano per lamentarsi della qualità delle conversazioni ma che purtroppo non riusciamo a capire perché’ durante la telefonata …..la voce va e viene … 😉 ?

Un monitoraggio puntuale di tutti i sistemi coinvolti centralino, flusso primario, infrastruttura di rete locale e geografica è sicuramente un buon punto di partenza ma spesso non è sufficiente.

Andiamo un po’ più in dettaglio e vediamo come funziona una comunicazione VoIP.

Per semplicità ci dedicheremo solo alla parte che riguarda il problema descritto precedentemente bypassando le tematiche riguardanti il protocollo SIP che coordina la gestione delle sessioni telefoniche e focalizzandoci solamente su quello che avviene dopo che la connessione telefonica è stata stabilita e due persone stanno comunicando.

I dati della conversazione vengono compressi tramite un codec ,  di norma il g729 che ha un buon rapporto di qualità ed utilizzo della banda (24.8Kbps),   in modo da ottimizzare l’utilizzo delle linee.

La comunicazione per essere più veloce avviene via UDP, il che significa che non c’è controllo della consegna dei pacchetti per cui se c’è saturazione della rete i pacchetti scartati semplicemente non arriveranno a destinazione e questo causerà quei fastidiosi “buchi di silenzio” nella conversazione.

La comunicazione tra due telefoni, ipotizziamo che siano chiamate interne tra due sedi distinte, possono avvenire in due modalità:

peer to peer: i due telefoni comunicano direttamente

non peer to peer: I due telefoni comunicano tramite il centralino telefonico

Ovviamente le due modalità possono convivere a seconda delle configurazioni e delle raggiungibilità tra di loro delle sedi remote il che complica ulteriormente le cose, tra l’altro la modalita’ “non peer to peer” duplica la banda utilizzata perché’ i dati passano due volte sulla linea.

A questo punto è evidente che con un monitoraggio tradizionale effettuato centralmente è difficile raccogliere tutte le informazioni necessarie per riuscire a fare un buon troubleshooting di eventuali problemi.

Che si può fare?

A questo proposito ci viene in aiuto l’ IP SLA che ha elaborato Cisco per misurare le performance di servizi IP sulle reti di comunicazione con apparecchiature Cisco, in sostanza IP SLA permette di generare del traffico tra le apparecchiature (switches, routers) in modo continuo, affidabile e prevedibile in modo da calcolare degli indicatori che ci danno visibilità sulla qualità delle comunicazioni anche in reti magliate, così potremmo sapere come si comporta il VoIP tra le sede A e B, la sede A e C e tra la sede B e C ed adottare in caso di problemi le necessarie contromisure.

I due indicatori che ci danno le informazioni sulla qualità della conversazione sono il MOS ( Mean Opinion Score) e l’ ICPIF (Impairment Calculated Planning Impairment Factor).

Il MOS è un valore da 1 a 5 dove 5 rappresenta una qualità audio eccellente, a seconda del tipo di codec ( e quindi dei compromessi tra banda e qualità audio) utilizzato ci si può avvicinare o meno allo score di 5

ICPIF è la risultante di cinque valori diversi che va da 5 ( ottimo ) a 55 ( scarso), di norma nelle buone conversazioni di attesta su 10.

Vediamo un esempio concreto di come possiamo utilizzare queste informazioni:

  • l’ utente Rossi nella sede di Milano ha lamentato un problema su telefonate che ha fatto con l’ utente Verdi nella sede di Catanzaro alle 08:00, 08:40, 09:20
  • noi abbiamo da tempo attivato gli IP SLA sulla nostra infrastruttura e ne monitoriamo le informazioni storicizzandole per poterle analizzare a posteri.
  • L’ operatore di service desk verifica le tratte in questione e scopre quanto segue:

Gli indicatori sotto controllo indicano che durante i periodi in questione si è effettivamente verificato un degrado del MOS ed un peggioramento dell’ ICPIF, nello stesso lasso di tempo è stata notata una saturazione della rete nella tratta Milano-Catanzaro. ( vedi immagini)

Degrado del MOS durante la conversazione

Degrado del MOS durante la conversazione

Degrado del ICPIF durante la conversazione

Degrado del ICPIF durante la conversazione

Saturazione della rete nella tratta Milano-Catanzaro

Saturazione della rete nella tratta Milano-Catanzaro

Ora che abbiamo capito quale è stato il problema possiamo decidere di stabilire un QoS (Quality of Services) per le comunicazioni VoIP tra le due sedi (stimando un nr. di comunicazioni contemporanee) e tenendo la situazione monitorata in modo da capire se la banda che abbiamo definito e’ sufficiente)

Il nostro sistema di monitoraggio ci informerà proattivamente se ci sono variazioni dei nostri indicatori in modo da poter reagire prontamente evitando il più possibile disagi ai nostri utenti

Di seguito alcuni esempi dei controlli che verificano la qualità del MOS, IPCIF ed il Jitter.

IP-SLA img5

IP-SLA img6

Andrea di Lernia

Andrea di Lernia

Profit Center Manager at Würth Phoenix
Hi everybody, I’m Andrea and my contribution to this blog is to give hints of the monitoring issue from an IT manager point of view. I was born in Bolzano in 1965 and my professional path started 25 years ago operating on the technical field as programmer, system/database administrator, network engineer, consultancy and so on. I’ve been living in Milan for 10 years working for multinational IT companies and I decided to return to Bolzano after my marriage and the birth of my daughter. I love sailing and diving in the summer, skiing in the winter and travelling off-road with my Landcruiser anytime

Author

Andrea di Lernia

Hi everybody, I’m Andrea and my contribution to this blog is to give hints of the monitoring issue from an IT manager point of view. I was born in Bolzano in 1965 and my professional path started 25 years ago operating on the technical field as programmer, system/database administrator, network engineer, consultancy and so on. I’ve been living in Milan for 10 years working for multinational IT companies and I decided to return to Bolzano after my marriage and the birth of my daughter. I love sailing and diving in the summer, skiing in the winter and travelling off-road with my Landcruiser anytime

2 Replies to “Monitoraggio delle comunicazioni VoIP tramite IP SLA”

  1. Luigi says:

    Ciao Andrea,
    trovo questo blog molto utile per far capire al neofita VoIP la possibilità di avere uno strumento di monitoraggio e diagnostica per risolvere questo tipo di problematiche. Mi permetto evidenziare la possibilità di spiegare meglio le connessioni tra telefoni in modalità non diretta. Sia perché i casi possono essere diversi, oltre al Vs. esempio ci possono essere 2 telefoni IP che parlano attraverso 2 centralini distinti che incanalano a loro volta il traffico su protocolli che possono essere diversi (es. SIP o IAX), sia perché non è molto chiaro il punto dove scrivi che i dati passano 2 volte sulla linea?
    A disposizione per eventuale confronto
    Luigi P.

    1. Andrea di Lernia says:

      Ciao Luigi,

      concordo con te che gli scenari in gioco e le problematiche possono essere molteplici, mio obiettivo era proprio di dare un paio di indicazioni ai “non addetti ai lavori” per cui era volutamente una versione semplificata ( non un compito facile 🙂 ). Quando dico che il traffico passa due volte sulla linea mi riferisco alla modalita “non peer to peer” ovvero quando i telefoni sono forzati a comunicare tramite il centralino.
      per cui se il centralino e’ nella sede A, e la telefonata intercorre tra un utente della sede B ed uno della C , i flussi di traffico dovranno passare sempre per la sede A sia in entrata da C che in uscita verso B e viceversa.
      … a rileggerla non sembra cosi’chiara …. spero di essermi spiegato 🙂
      Ciao
      Andrea

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive