02. 09. 2015 Andrea di Lernia NetEye

VoIP-Monitoring mit IP SLA

VoIP Image

Die heutige Welt ist geprägt von digitaler Kommunikation. Voice over IP (kurz VoIP) wurde zu einem wichtigen Instrument, das einerseits erhebliche Einsparungen und einen hohen Grad an Flexibilität mit sich bringt, andererseits aber auch das Maß an Komplexität steigert. Leider ist die Erkennung des Ursprungs eventuell auftretender Probleme mit dem Aufkommen der neuen Technologie nicht einfacher geworden.

Oft leiden VoIP-Kommunikationen unter schlechter Gesprächsqualität, vor allem in Gebieten mit schlechter oder schlecht genutzter Internetverbindung.

Was können wir also tun, wenn uns Anwender mit Anrufen bombardieren und sich ständig beschweren, dass die Qualität der Verbindung schlecht sei, wir aber einfach nicht verstehen warum die Verbindung ständig unterbrochen wird…?

Die gezielte Überwachung aller betroffenen Systeme, Telefonzentrale, Linie, Infrastruktur des lokalen Netzwerks und die geografische Verbindung zweier Niederlassungen, ist bestimmt ein sehr guter Ausgangspunkt, reicht aber meistens nicht um die Ursache der lästigen Unterbrechungen aufzudecken.

Gehen wir etwas mehr ins Detail und betrachten wir die Funktionsweise einer VoIP-Kommunikation etwas genauer.

Der Einfachheit halber, betrachten wir nur jene Bereiche, welche das oben beschriebene Problem betreffen ohne auf den Bereich SIP-Protokoll, welches die Verwaltung der Telefon-Sessions koordiniert, einzugehen. Konzentrieren wir uns darauf, was passiert sobald zwei Gesprächspartner miteinander verbunden sind und „versuchen“ zu kommunizieren.

Um die Nutzung der Linien zu optimieren, werden die Daten der Konversation durch ein Codec kodiert und komprimiert (normalerweise das g729, welches eine gute Qualität und eine adäquate Bandbreitennutzung (24.8Kbps) vorweist).

Zur Beschleunigung der Kommunikation, erfolgt diese über UDP. Dies bedeutet jedoch, dass es keine Kontrolle über die Zustellung der Pakete gibt. Im Falle einer Überbelastung, erreichen die verlorenen Pakete ihren Bestimmungsort nicht und werden auch nicht erneut versendet, dies wiederum verursacht die lästigen Unterbrechungen.

Die Kommunikation zwischen zwei Telefonen, nehmen wir an es handelt sich um einen internen Anruf zwischen zwei Geschäftsniederlassungen, kann auf zwei Arten erfolgen:

  • Peer to Peer: Die beiden Telefone kommunizieren direkt miteinander
  • Non Peer to Perr: Die beiden Telefone kommunizieren über die Telefonanlage

Diese beiden Kommunikationsarten können selbstverständlich auch nebeneinander bestehen, dies hängt ganz von der Konfiguration und der Erreichbarkeit zwischen den Geschäftsstellen selbst, ab. Non Peer to Peer-Kommunikationen benötigen die doppelte Bandbreite, da die Daten zwei Mal über die Linie laufen müssen.

Nun liegt es auf der Hand, dass es mithilfe eines traditionellen Monitoring-Ansatzes eher schwierig wird alle nötigen Informationen zu sammeln, um ein Troubleshooting auftretender Probleme vornehmen zu können.

Was können wir dagegen tun?

Hier kommt uns das von Cisco erarbeitete IP SLA zu Hilfe. Dieses misst die Performance von IP-Diensten auf dem Kommunikationsnetz mit Cisco-Geräten. IP SLA erlaubt es kontinuierlich, zuverlässig und vorhersehbar Traffik zwischen Geräten (Switche, Router) zu generieren, um Qualitätsindikatoren der Kommunikation zu berechnen. So können wir ermitteln, wie sich das VoIP zwischen Geschäftssitz A und B, zwischen A und C und zwischen B und C verhält, um falls notwendig, entsprechende Maßnahmen einzuleiten.

Die beiden Indikatoren, welche uns Informationen zur Qualität der Konversation liefern sind MOS (Mean Opinion Score) und ICPIF (Impairment Calculated Planning Imprairment Factor).

MOS ist ein Wert zwischen 1 und 5, wobei 5 eine exzellente Audio-Qualität bedeutet. Je nach Codec kann ein Wert nahe 5 erreicht werden.

ICPIF ist das Ergebnis fünf verschiedener Werte, welches sich zwischen 5 (ausgezeichnet) und 55 (schlecht) bewegen kann. Normalerweise weisen gute Konversationen einen Wert um 10 vor.

Betrachten wir nun ein konkretes Beispiel, wie diese Informationen eingesetzt werden können:

  • Anwender Rossi, in der Geschäftsstelle Mailand, beschwert sich über ein Problem während Konversationen (um 08:00, 08:40, 09:20 Uhr) mit Anwender Verdi, welcher sich in Catanzaro befindet.
  • IP SLA ist bereits seit einiger Zeit auf unserer Infrastruktur aktiv, wir überwachen VoIP-Kommunikationen bereits seit einiger Zeit und archivieren die erhaltenen Daten für eine spätere Analyse
  • Der Service Desk Mitarbeiter nimmt die Beschwerde entgegen, überprüft die betroffenen Abschnitte und stellt folgendes fest:

Die Indikatoren der betroffenen Zeiträume zeigen, dass sich in der Zeit der Gespräche eine Verschlechterung des MOS und ebenso des ICPIF ereignet haben. In denselben Zeiträumen, wurden Überlastungen des Netzes im Abschnitt Mailand-Catanzaro festgestellt. (siehe unten stehende Abbildungen)

Verschlechterung des MOS während des Gesprächzeitraums

Verschlechterung des MOS während des Gesprächzeitraums

Verschlechterung des ICPIF während des Gesprächzeitraums

Verschlechterung des ICPIF während des Gesprächzeitraums

Überlastung des Netzes im Abschnitt Mailand-Catanzaro

Überlastung des Netzes im Abschnitt Mailand-Catanzaro

Da wir nun das Problem erkannt haben, können wir eine QoS (Quality of Services) für Kommunikationen zwischen den beiden Geschäftsstellen festlegen. Dazu müssen wir eine Anzahl von gleichzeitig geführten Kommunikationen festlegen/schätzen, diese überwachen und dadurch verstehen ob die vorgesehene Bandbreite ausreichend ist.

Das Monitoring-System wird uns proaktiv informieren, falls es zu Abweichungen von den definierten Indikatoren, welche als Schwellenwerte dienen, kommt. So können wir zeitnah reagieren und Unannehmlichkeiten vermeiden.

Unten sehen Sie einige Beispiele von Kontrollen, welche die Qualität des MOS, IPCIF und Jitter prüfen.

IP-SLA img4

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

Leave a Reply

Your email address will not be published.

Archive