SIP/RTP-Analyse in heterogenen Netzwerken

Fehlerquellen auf der Spur

18. September 2018, 7:00 Uhr | Klaus Degner

SIP/RTP sind aktuell die meistverbreiteten Protokolle zur Sprach- und Videoübertragung und stellen damit zwei der am häufigsten genutzten Protokolle im LAN/WAN-Umfeld dar. Die VoIP-Telefonie bedeutet für den Administrator jedoch neue Anforderungen bezüglich der Qualitätssicherung im Netzwerk.

Die beiden Protokolle SIP und RTP sind Grundelemente der heutigen VoIP-Kommunikation. Während das Session-Protokoll SIP (Session Initiation Protocol) für den Aufbau von Kommunikationssitzungen zuständig ist, läuft die Übertragung der eigentlichen Sprachdaten über das Datenprotokoll RTP (Real-Time Transport Protocol). Das Wettrennen als Nachfolger von leitungsvermittelnden Netzwerken haben die beiden Protokolle gewonnen und sich dabei gegen H.323 und SCCP durchgesetzt. Im Umkehrschluss stellen SIP/RTP somit neben HTTP(S) und DNS zwei der kritischen Protokolle in Netzwerken dar.

SIP-Cloud-Telefonanlagen bieten den großen Vorteil, dass man damit auch außerhalb des Büros oder der Firma ohne komplizierte Weiterleitung telefonieren kann. Gab es früher noch dedizierte Telefone und Telefonleitungen, werden diese heute durch PC-Software beziehungsweise Smartphone-Apps nach und nach abgelöst, sodass die Telefondaten sich ihre Leitung mit dem gesamten anderen Netzwerkverkehr teilen. Entsprechend bedeutet dies für IT-Abteilungen, vollkommen neue Maßstäbe hinsichtlich der Qualität von WLAN-, LAN- und WAN-Verbindungen in Unternehmen anzusetzen.

SIP, aber insbesondere RTP, erben alle Eigenschaften von paketvermittelnden Netzwerken, die es im klassischen Telefonnetz nicht gab. Probleme wie Paketverlust oder Jitter existierten in exklusiven Leitungen schlicht nicht. Im Gegensatz dazu ist Ethernet ein Best-Effort-Netzwerk, das so viel wie möglich in kleinen Paketen überträgt. Dabei treten unterschiedliche Latenzen und Paketverluste auf. Die Netzwerkschichten darüber müssen dies selbstständig korrigieren.

In der Praxis konfrontiert die SIP-Telefonie die IT-Abteilungen mit häufigen Fehlermeldungen: Die Qualität sei schlecht gewesen, es habe ein Echo gegeben, ein Knacken, Rauschen, eine Latenz oder ein Aussetzer in der Verbindung. Viele Nutzer vermuten ein Netzwerkproblem hinter der schlechten Verbindung. Oft treten diese Fehler auch nur sporadisch auf, sodass sie sich schlecht reproduzieren lassen. Wie kann ein IT-Mitarbeiter nun dem Unmut seiner Kollegen begegnen und den Fehler schnell beheben?

Fehlerquellen in der Übersicht

Grundlegend existieren bei jeder VoIP-Anwendung vier verschiedene Fehlerquellen: der VoIP-Client, der VoIP-Server, das Netzwerk zwischen Client und Server sowie die Verbindung beziehungsweise das Netzwerk zwischen VoIP-Server und dem zweiten Teilnehmer.

Die möglichen Fehlerquellen "Client" und "Server" lassen sich im Vergleich zum Netzwerk relativ leicht testen. Systematische Fehler, wie etwa ein schlechtes Mikrofon, lassen sich durch Kreuzvergleiche ausloten. Alternativ bieten aktuelle Netzwerkanalyse-Tools hier die Möglichkeit, rückwirkend den RTP-Strom als Audio abzuspielen. Fehler, die Server- oder Client-seitig vor dem Netzwerk auftreten - sei es ein Knacken oder Rauschen oder ein leises Mikrofon etc. - kommen an dieser Stelle oft schon zum Vorschein.

Komplizierter gestaltet sich das Auffinden von Fehlern innerhalb des Netzwerks. Hierbei ist es zunächst wichtig, zu verstehen, wie ein Audio-Codec über RTP funktioniert. Die meisten Audio-Codecs zerlegen die Audiodaten in Blöcke von 20 oder 30 ms und verpacken dies in RTP. Auf diese Art wird eine konstante RTP-Paketrate von und zum Client gewährleistet. Der Client beziehungsweise Server empfängt die Daten jedoch nicht konstant alle 20 ms, sondern mit einer Abweichung, dem sogenannten Jitter.

LL09F02_Bild1
Tools helfen dem Administrator dabei, VoIP-Traffic im Netzwerk zu analysieren. Bild: Allegro Packets

Der Endpunkt ermittelt nun den größten Jitter und passt daraufhin den Audiopuffer an, um die Wartezeit so kurz wie möglich zu halten. Steigt oder fällt dieser Jitter über längere Zeit, versucht sich der Codec daran anzupassen. Entweder entsteht dann im Audiopuffer eine Pause oder ein Teil des Puffers wird entfernt. Im reellen Gespräch hört sich das so an, als ob der Gesprächspartner die Worte nicht komplett ausspricht. Kommt es also sporadisch zu Lastspitzen im Netzwerk, führt dies zu einem schwankenden Jitter und zu Qualitätseinbußen bei RTP. Diese Art von Netzwerkfehlern lässt sich mithilfe von Netzwerkanalysatoren untersuchen. Eine Burst-Analyse zeigt etwa in Echtzeit alle Lastspitzen und deren Verursacher.

Ein weiterer Grund für schlechte Qualität stellt die Latenz zwischen den beiden Endpunkten dar. Je größer die Latenz ist, desto länger muss der Gesprächspartner auf die Antwort warten. Die Latenz kann insbesondere im WLAN sehr hoch sein, wodurch die Verbindung als schlecht empfunden wird. Paketverlust wiederum führt direkt zu Aussetzern in der Sprache. Diese Faktoren lassen sich ebenfalls mit Netzwerkanalyse-Tools messen.

Einflüsse auf den Sprachverkehr

Die technischen Hintergründe und Typen der verschiedenen Fehlerquellen, denen die VoIP-Telefonie ausgesetzt ist, sowie deren Analysemöglichkeiten sind nun erläutert. Offen ist nunmehr die Frage, was die Netzwerkprobleme bei SIP/RTP eigentlich verursacht. Die Erfahrung zeigt, dass die Ursache dabei häufig nicht bei SIP/RTP als solchem, sondern vielmehr bei dem anderen, parallel laufenden Netzwerkverkehr zu suchen ist.

Ein Beispiel aus der Praxis soll dies verdeutlichen: Eine Vertriebsabteilung hatte öfter Qualitätsschwierigkeiten mit dem VoIP über deren Cloud-SIP-Anbieter. Nach einigen Nachforschungen kam zutage, dass die Probleme immer gegen elf Uhr auftraten, sowohl auf den Windows-PCs als auch auf Smartphones über WLAN. Die IT konnte allerdings keine Störung feststellen. Weder die Telefonie noch der Uplink zum Internet wiesen Probleme auf.

Die Analyse des Netzwerkverkehrs mit einem Troubleshooting-Tool brachte die Lösung: Ursache war die falsche Konfiguration der WSUS (Windows Server Update Services), die um elf Uhr morgens statt abends liefen. Die Updates verursachten so viel Traffic und Last, dass sowohl das LAN als auch das WLAN einen Jitter von bis zu 500 Millisekunden und Paketverluste von etwa fünf Prozent erzeugten. Nachdem die Administratoren den WSUS-Server auf elf Uhr abends gestellt hatten, war die Last nicht mehr vorhanden.

VoIP-Qualitätseinbußen eingrenzen

Neben dieser kurzfristigen Problemlösung ist es mitunter ratsam, eine virtuelle oder physische Trennung des VoIP-Netzes gegenüber dem Rest des Netzwerks vorzunehmen. So wird der VoIP-Leitung nicht von anderem Verkehr tangiert. Sobald die VoIP-Telefonie allerdings über Handys und Client-PCs durchgeführt werden soll, ist eine Segmentierung schwieriger, weil man nicht zwischen VoIP- und Nicht-VoIP-Gerät trennen kann. Ein Beispiel hierfür sind automatische Updates auf Android- oder iOS-Geräten. Diese laden zum Teil vollkommen ungeplant mehrere GBytes mit hoher Bandbreite über ein WLAN herunter, wodurch die Qualität eines laufenden Telefonates auf diesem oder einem anderen Telefon leidet.

Oft werden auch Backups als Lastquelle unterschätzt. PCs und insbesondere Notebooks können durch eine eingebaute SSD-Festplatte Backups mit weit über 100 MBit/s ausliefern. Dies sorgt dafür, dass die Leitung zum Backup-Server mit voller Gigabit-Bandbreite ausgelastet wird. Dadurch verursachen gerade Notebooks mit SSD und 802.11ac-WLAN oft hohe Lastspitzen, die einen kompletten 80-MHz-Kanal auslasten und damit andere Teilnehmer stören.

Klaus Degner ist Managing Director bei Allegro Packets, www.allegro-packets.com.


Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu demig Prozessautomatisierung GmbH

Weitere Artikel zu Toshiba Mobile Communications Division

Weitere Artikel zu Fortinet

Matchmaker+