This website is available in German language. Please use Google Translate to view this website in your preferred language.
abonnieren verfolgen

Die Übertragung von Sprache über das IP-Protokoll birgt sowohl in Unternehmensnetzen als auch im Providerumfeld diverse Herausforderungen. So gibt es zunächst eine sehr hohe Verfügbarkeitsanforderung. Als Echtzeitdienst bemerken die Nutzenden aber auch sofort Probleme in der Dienstgüte. Gerade die Netzwerkqualitätsparameter Paketverlust, Jitter und Delay haben einen großen Einfluss auf die resultierende Sprachqualität. 
Grundsätzlich ist im VoIP-Umfeld zu beachten, dass man zwischen drei Datenströmen differenziert, wobei nur zwei einen bemerkbaren Einfluss für die Nutzenden hat.

 

  • Den ersten Datenstrom stellt die Signalisierung dar. Als Signalisierung bezeichnet man die Kommunikation zum Auf- und Abbau, sowie Änderungen. Dabei werden auch schützenswerte Metadaten, wie Quell- und Zielrufnummer übertragen. Es gibt unterschiedliche Protokolle zur Signalisierung, wie SIP (Session Initiation Protocol), H.323 oder MGCP (Media Gateway Control Protocol). Im öffentlichen Netz und aktuellen Unternehmensnetzen kommt primär das SIP-Protokoll zum Einsatz. Es gibt jedoch eine Vielzahl von unterschiedlichen SIP-Implementierungen. Dies führt in der Praxis zu vielfältigen Fehlerquellen durch Inkompatibilitäten. Im Payload der Signalisierung, genauer gesagt im Session Description Protocol (SDP) werden aber auch einige Parameter, wie zu verwendende Codecs und die UDP-Ports, sowie die zugehörigen IP-Adressen für die Sprachdatenübertragung ausgehandelt.
     
  • Den zweiten Datenstrom stellt die Übertragung der Sprache über das Real-Time Transport Protocol (RTP) dar. Dieses Protokoll basiert auf einer UDP-Übertragung und es ist als Echtzeitübertragung besonders sensitiv gegenüber Latenz, Jitter und Paketverlusten. Es können Hierbei unterschiedliche Codecs mit unterschiedlichen Paketierungszeiten, Größe und Qualität zum Einsatz kommen.
     
  • Den dritten Datenstrom stellt das Real-Time Transport Control Protocol (RTCP) dar. Er liefert statistische Daten mit Qualitätsindikatoren für VoIP. Dieser Datenstrom fließt auf gleichem Transportweg wie RTP, jedoch eine Portnummer höher.

 

Eine große Herausforderung beim Troubleshooting in VoIP-Umgebungen stellt die Differenzierung der Fehlerursache zwischen Signalisierung und Sprachdaten oder auch dem zugrunde liegenden Netzwerk dar. Die unterschiedlichen Medienströme müssen in vielen Fällen auch NAT-Übergänge oder auch Sicherheitskomponenten, wie Firewalls passieren. Dies führt in der Praxis dazu, dass sich die zuständigen Teams für VoIP, Netzwerk und Sicherheit bei Fehlern die zugehörigen Tickets hin- und herschieben. Das Profitap IOTA hat es sich zur Aufgabe gemacht, die VoIP-Analyse effektiv und effizient zu machen. Das „Blame Game“ zwischen den unterschiedlichen Teams soll durch grafisch aufbereitete Dashboards in Kombination mit vielfältigen Filteroptionen für SIP und RTP ein Ende haben und für den Endanwender die Mean-Time-to-Recover (MTTR) durch eine schnelle Fehleranalyse verkürzen. Dienstanbieter können somit auch Ihre SLAs besser einhalten.

 

SIP Trapezoid mit Differenzierung zwischen Signalisierung über SIP und Sprache über RTP.

 


Root Cause Analyse
Die Root Cause Analyse in VoIP Netzen gleicht häufig der Suche nach der Nadel im Heuhaufen. Von den Anwendern kommen meist recht unstrukturierte Fehlermeldung, wie „Mein Telefon funktioniert seit gestern nicht mehr. Ich erhalte immer ein Besetzt-Zeichen.“ oder „Ich habe zeitweise Verständigungsprobleme mitten im Gespräch.“. Ob dies am Netzwerk, einer Firewall, einem Signalisierungsfehler auf einem SIP-Proxy oder einem Fehler der Endgeräte liegt, kann zunächst nur schwierig differenziert werden. Aber auch einseitige oder gar keine Verständigung (One Way Audio oder Dead Air Effekt), sowie zeitweise abbrechende Anrufe stellen eine Herausforderung im Troubleshooting Prozess dar.

Es gilt also die grundsätzliche Ursache des Problems (Root Cause) zu ermitteln. Wenn die Key Performance Indikatoren Paketverlust, Jitter und Delay bidirektional ohne Auffälligkeiten sind, kann ein Sicherheits- und Netzwerkproblem ausgeschlossen werden. Die Ursache kann dann direkt im VoIP-Umfeld gesucht werden. Jedoch ist nicht jede VoIP-Verbindung direkt Ende-zu-Ende messbar. Sogenannte Session Border Controller (SBC) können an Sicherheitsübergängen den SIP-Dialog und den RTP-Datenstrom je Kommunikationsseite terminieren und manipulieren. Es kann also geschehen, dass trotz gemessenen Paketverlusten von 0% bis zum Provider hinter dessen SBC ein Paketverlust zu einem anderen Provider besteht. Somit sind VoIP Analysen auch häufig an multiplen Punkten im Netzwerk durchzuführen.

Im VoIP-Umfeld selbst muss zunächst definiert werden, ob es sich um ein Problem in der Signalisierung oder im Sprachdatenstrom handelt. Kommt es beim Verbindungsauf- oder Abbau oder einer Veränderung, wie einem Halten des Gesprächs oder einem Codecwechsel zu Problemen, liegt dies an einem Signalisierungsproblem und es kann gezielt in den SIP-Daten über Filter eine Eingrenzung
geschehen.

Schwieriger in der Analyse sind die bereits erwähnten Fehlerbilder, wie Dead Air und One Way Audio. Diese können sowohl aus dem Netzwerk kommen, aber auch durch Firewalls und IPS-Systeme oder Probleme in Baugruppen des VoIP-Systems. Beispiel für einen Netzwerkfehler wäre ein fehlerhaftes Routing oder ein NAT-Übergang. Problem bei NAT im Zusammenhang mit VoIP ist, dass lediglich die IP-Informationen im Header ersetzt werden, jedoch nicht im Payload. SIP überträgt jedoch im Session Description Protocol (SDP) IP- und Portinformationen für den RTP-Stream. Wenn nun ein NAT-Übergang die IP-Header manipuliert, aber im Payload keine Anpassung vollzogen wird, führt dies zu einseitiger oder keiner Verständigung, da der RTP-Datenstrom zum falschen Ziel geführt wird. Gleichzeitig besteht aber auch die Möglichkeit, dass eine Firewall die Ports für die Signalisierung zulässt, aber den RTP-Datenstrom blockt. Aber auch Intrusion Prevention System bieten eine mögliche Fehlerquelle für geblockte RTP-Datenströme. Gleichzeitig könnte dies jedoch auch im VoIP-Umfeld an einer nur einseitigen Verschlüsselung mit SRTP oder einem fehlerhaften Codecwechsel oder defekten VoIP-Baugruppen, wie DSPs liegen. Es braucht also für die Root Cause Analyse ein Werkzeug, dass flexibel an unterschiedlichen Stellen im Netzwerk zum Einsatz kommen kann und mit einfachen Mitteln einen „Drill Down“ auf die benötigten Informationen ermöglicht.

 

Wie kann Profitap IOTA unterstützen?
Das  Profitap IOTA bietet eine portable Lösung zur VoIP Analyse. Damit eignet es sich, um an unterschiedlichen Stellen im Netzwerk aufzuzeichnen und zu analysieren. Sowohl der Betrieb im Inline-, als auch im SPAN-Modus sind möglich. Somit ist es in der VoIP Analyse flexibel einsetzbar, da es sowohl zwischen Telefon und Switch im Inline Betrieb geschaltet werden kann, aber auch direkt an einem SPAN-Port des Switches, wenn beispielsweise ganze VLANs oder ein Switchport zu einem Session Border Controller oder einer IP-PBX analysiert werden müssen.

Neben der reinen Aufzeichnung bietet das IOTA jedoch auch applikationsseitige Analysefunktionen für VoIP. Somit kann dem Fingerpointing zwischen Netzwerk- und Voice-Team schnell ein Ende gesetzt werden. Netzwerkadministratoren können für definierte Zeiträume oder sogar einen spezifischen Anruf Paketverluste und Jitter erkennen. Dies kann über eine Filterung auf die Quell- oder Ziel-URI des Anrufers geschehen. Abbildung 2 bietet ein Beispiel eines Filters auf die Ziel-URI. Übergibt der VoIP-Administrator sogar die Call-ID des Anrufs, kann direkt eine Filterung auf den Anruf stattfinden. So kann der Fehler soweit vorqualifiziert werden, dass im Nachgang gezielt auf einzelnen Netzwerkkomponenten, wie Switches und Routern auf Link-Fehler und Quality of Service Probleme gesucht werden kann.

VoIP Dashboard mit Filter auf die Ziel-URI. Über diesen Filter erhält man eine Liste der Anrufe auf diese Ziel-URI.

Für Qualitätsprobleme in der Übertragung der Sprachdaten im RTP-Datenstrom bietet das IOTA vielfältige Möglichkeiten. So gibt es ein vorbereitetes Call Detail Dashboard, dass jeweils von Anrufendem und Angerufenen separiert den Jitter und Paketverluste angibt. Die Anzeige von Paketverlusten gibt die Werte sowohl prozentual zu der Gesamtanzahl an Paketen an, als auch in der reinen Menge an Paketen, die verloren wurden. Neben den übersichtlichen Grafiken bieten sich auch Filter mit „>=“ an. So können Anrufe mit Paketverlusten und Jitter über bestimmten Schwellwerten, wie beispielsweise Jitter >= 20ms herausgefiltert werden.

RTP Qualitätsparameter Jitter und Paketverlust in Grafiken. Paketverluste werden sowohl prozentual, als auch in der Anzahl an Paketen angegeben


Aber auch das „Click-and-Drag“ in den Grafiken bietet die Möglichkeit, bei festgestellten Auffälligkeiten, gezielt in einen Zeitbereich zu springen. Ein Einfaches „Click-and-Drag“ mit der Maus genügt dabei, um den Zeitbereich einzuschränken. Erkennt der Netzwerkanalyst einen hohen prozentualen Anteil des Paketverlusts im Vergleich zu den übertragenen Paketen im Call Detail Dashboard, kann er die Call-IDs erkennen und diese in Filtern nutzen, um problematische Kommunikationsbeziehungen zu erkennen. Führt die Analyse eines Dead Air Effekts beispielsweise immer wieder zu einem bestimmten Portbereich könnte eine fehlende oder nicht ausreichende Firewallfreigabe ursächlich sein.

Dies bietet die Möglichkeit Tickets zu Verständigungsproblemen in der VoIP-Umgebung schnell vorqualifizieren zu können. Das IOTA ermöglicht es durch vielfältige Filtermöglichkeit, den Fehler immer näher einzugrenzen, um zum „Root Cause“ des Problems zu kommen.

Aber auch im Bereich von Signalisierungsfehlern kann das IOTA einiges bieten. Um Muster von Signalisierungsfehlern erkennen zu können, bietet sich die in Abbildung 4 dargestellte Grafik „SIP Methods and Responses“ aus dem VoIP Dashboard an. Falls vermehrt „488 Not acceptable here“ sichtbar wären, würde dies beispielsweise auf eine Inkompatibilität der Codecs hindeuten. Bei „403“ Fehlercodes hingegen, dass der SIP-Proxy die Anfrage ablehnt.
Bei vermehrten „404 Not found“ Meldungen kann man gezielt einen Blick auf die Callee URIs im VoIP Dashboard werfen, um die fehlerhaften Zielrufnummern oder Zieldomains zu erkennen. Im Beispiel in Abbildung 4 sind einige 403 Responses sichtbar. Diese sind in der eingesetzten SIP-Authentifizierung begründet und somit vollkommen in Ordnung.

Grafische Darstellung des prozentualen Anteils von SIP Request Methoden und zugehöriger Antworten


Bei einem verzögerten Gesprächsaufbau könnten auch die Latenzdaten der Signalisierung einen Aufschluss bringen. Bei SIP über TCP bietet die Round-Trip-Time einen ersten Ansatzpunkt. Diese kann das IOTA ebenfalls analysieren.


Für komplexere Fälle können auch gezielt PCAP-Daten heruntergeladen werden, um diese näher in Wireshark zu analysieren. So können bei unverschlüsseltem RTP und unterstütztem Codec auch die aufgezeichneten Audioinhalte im RTP-Player angehört werden, um sich unabhängig vom Telefon einen Eindruck von der Sprachqualität zu verschaffen. Sogar ein automatisierter Export von PCAP-Dateien auf eine externe Datenquelle ist möglich.