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.
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.
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.
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)
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.
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.
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