Einführung in das Troubleshooting
Vor Fehlern ist kein VoIP- bzw. Datennetz geschützt, deshalb muss der Administrator in der Lage sein, die VoIP- bzw. Netzprobleme auf dem Kabel lokalisieren zu können. Wenn die Bordmittel des Betriebssystems nicht mehr ausreichen, um Problemen im VoIP-Netzwerk auf die Spur zu kommen, müssen schwerere Geschütze aufgefahren werden, die einen Blick "in" bzw. "auf" das Kabel ermöglichen. Ein solches spezialisiertes Analysewerkzeug ist nicht Bestandteil der Rechner und muss deshalb speziell beschafft werden.
ie Ursachen für Netzwerkprobleme haben sich in den vergangenen
Jahren deutlich verändert. Lagen sie früher häufig bei den physischen
Komponenten wie Verkabelung, Netzwerkkarten, Switches oder Routern, so sind sie
heute zum überwiegenden Teil auf den höheren OSI-Schichten der Layer 4 bis 7 zu
suchen. VoIP erfordert jedoch das korrekte Zusammenspiel aller Schichten und
erhöht somit die Komplexität bei der Fehlersuche. Besonders wichtig ist die
Ende-zu-Ende-Beurteilung der Spracheigenschaften,
wie beispielsweise die Verzögerung, der Jitter und die Paketverluste. Darüber
hinaus hängt die Übertragungsqualität auch von der Netzverfügbarkeit und den individuellen
Eigenschaften der genutzten Telefone und Gateways ab.
Fallstricke der VoIP-Telefonie
Dieses Kapitel beschreibt die heute genutzten VoIP-Protokolle in der Übersicht. Voice over IP setzt auf dem Internet Protocol (IP) als Transportbasis auf. Die digitalisierten Sprachdaten werden mit Hilfe von IP-Paketen zwischen den Kommunikationsteilnehmern über die Netzwerke übermittelt.
Signalisierung
Signalisierungsprotokolle sind Verfahrensvorschriften mit denen Steuernachrichten zwischen VoIP-Komponenten codiert, decodiert und interpretiert werden. VoIP kennt eine Vielzahl unterschiedlicher Signalisierungsprotokolle, die zur Einrichtung, Durchführung der Anrufe und Übermittlung von Informationen genutzt werden. Das Session Initiation Protocol (SIP) und H.323 gehören zu den wichtigsten Signalisierungsmechanismen im VoIP-Markt.
Der früher dominierende H.323-Protokollmechanismus wurde inzwischen durch SIP weitgehend ersetzt und wird mittlerweile von allen VoIP-Anbietern unterstützt.
Eine SIP-Systemarchitektur besteht aus Terminals, Clients, Proxy und Location Servern. Der Proxy Server dient der Verwaltung der Anrufe, der SIP Accounts und der SIP Terminals bzw. SIP-Clients. Der Proxy Server besitzt eine Datenbank mit diversen SIP-Accounts. Diese Accounts bestehen aus Benutzerangaben, Passwörtern und den dazugehörigen Telefonnummern.
Ein SIP Terminal muss sich beim Proxy Server registrieren und anmelden, wenn das Terminal erreichbar sein soll. Nach der Anmeldung kann der Server die Rufnummer des Clients einer IP-Adresse zuordnen.
Möchte ein angemeldeter Client einen anderen Teilnehmer anrufen, wird eine so genannte SIP-Invite Nachricht generiert und an den SIP Proxy übermittelt. Der Proxy überprüft die in der SIP Message enthaltene Telefon/Teilnehmernummer. Ist der Empfänger am System angemeldet, leitet der SIP Server die SIP-Anfrage an das betreffende Endsystem weiter. Beim Gesprächsaufbau werden auf Basis des SIP-Protokolls die für die eigentliche Sprachkommunikation notwendigen IP-Adressen der beiden Clients ausgetauscht. Nach Abschluss der SIP-Signalisierung findet das eigentliche Gespräch in Form einer Peer-to-Peer-Verbindung (und der Nutzung des Real Time Protocols; RTP) zwischen den beiden Endgeräten statt. Befindet sich die gewählte Rufnummer bzw. der Teilnehmer außerhalb der lokalen SIP-Domäne, werden die SIP-Nachrichten an den SIP-Proxy der Ziel-SIP-Domäne oder an ein Telefon-Gateway (Übergang ins ISDN-Netz) weitergeleitet.
Bei der Signalisierung in Telefonanlagen treten zahlreiche potenzielle Probleme auf. Dies kann sich um so einfache Dinge, wie die Übergabe falscher IP-Adressen, die Signalisierung falscher SIP-Optionen, aber auch um komplexe Kompatibilitätsprobleme zwischen den beiden Endpunkten handeln.
Zur Analyse der zwischen den SIP-Elementen ausgetauschten Signalsierungsnachrichten ist ein VoIP-Analysator notwendig. Dieser erkennt die Probleme im Bereich der Signalisierung und stellt dem Administrator die notwendigen Informationen zur Behebung des betreffenden Problems zur Verfügung.
Streams
Nachdem die Merkmale der VoIP-Verbindung zwischen den beiden Endpunkten mit Hilfe des Signalisierungsprotokolls übermittelt wurden, werden die eigentlichen Sprachinformationen über so genannte RTP-Streams über das IP-Netzwerk in Echtzeit übertragen. Alle VoIP-Standards verwenden das Real Time Transport Protocol (RTP) für das Streaming von Echtzeitsprachpaketen.
RTP verpackt den Gesprächsdatenstrom in einzelne Pakete und verschickt diese Pakete auf Basis der UDP/IP-Mechanismen. In den RTP-Paketen werden neben den reinen Sprachinformationen auch zusätzliche Steuerinformationen übermittelt:
- Synchronization Source (SSRC): dient der Zuordnung der gesendeten Pakete zu einer Session.
- Sequenznummern: Auf Basis der Sequenznummer werden die empfangenen Pakete wieder in die richtige Reihenfolge gebracht und außerdem festgestellt, wenn Pakete verloren gegangen sind.
- Timestamp: Der Zeitstempel dient der Laufzeitenkontrolle der Pakete und dient als Grundlage zur Jitterberechnung.
- Payloadtype: Definiert die Art der Informationscodierung. Dadurch kann der Empfänger die im RTP-Strom enthaltenen Sprachdaten richtig dekodieren.
Der RTP-Standard legt keinen festen UDP-Port für die Kommunikation fest. Aus diesem Grund müssen die Endpunkte diese Ports beim Verbindungsaufbau kommunizieren. Bei der Kommunikation über Firewalls und Network Address Translation (NAT) Komponenten werden jedoch die ursprünglichen Port- und Adress-Kennungen verändert. Da die signalisierten und die real genutzten IP-Adressen/Portadressen nicht mehr übereinstimmen, kommt keine RTP-Verbindung und somit auch kein Telefongespräch zwischen den beiden Endsystemen zustande.
Firewalls und NATs im VoIP-Netz erfordern den Einsatz eines STUN/TURN-Servers. Hierzu müssen die VoIP-Endgeräte die notwendigen STUN/TURN-Funktionen implementiert haben und diese müssen vom Administrator auch aktiviert sein.
Werden die Sprachpakete durch die Firewall bzw. die NAT-Komponente blockiert, müssen die betreffenden RTP-Streams auf Basis eines VoIP-Messgeräts eingehend analysiert werden, um die Verbindungsfehler bzw. Falschkonfigurationen beseitigen zu können.
Die Sprachströme werden bei VoIP nicht mit dem sicheren TCP-Protokoll übermittelt. RTP nutzt stattdessen das ungesicherte User Datagram Protocol (UDP) für die Übertragung von Sprachpaketen. Der Grund hierfür liegt in dem hohen TCP-Overhead und durch TCP verbundenen hohen Paketverzögerungen. Durch die Nutzung von UDP werden auf der Transportebene keine auf dem Weg zum Empfänger verloren gegangenen Pakete wiederholt. VoIP kann zwar mit geringen Paketverlusten umgehen. Die sich dadurch verändernde Sprachqualität macht sich kaum beim Nutzer bemerkbar. Gehen jedoch größere Mengen an Datenpaketen verloren oder erhöht sich die Verzögerungszeit durch eine Überlast im Netzwerk, hat dies eine signifikante Verschlechterungen der Telefonströme zur Folge.
Auch hier gilt: Den Paketverlusten und Staus im Netzwerk muss auf die Spur gekommen werden. Auch hier hilft ein VoIP-Messgerät zur detaillierten Ursachenforschung.
Der VoIP-Analysator stellt die Aufzeichnung eines Datenverkehrs an einem Netzknotenpunkt in einem so genannten Trace dar. Die RTP-Ströme werden dabei in einer Liste dargestellt. Die RTP-Sessionliste verweist darüber hinaus auf die dzugehörigen SIP-Signalisierungen. Die Details der RTP-Sessionliste verdeutlichen die wichtigen VoIP-Parameter und QoS-Werte einer RTP-Session. Zu diesen Parametern gehören beispielsweise der Jitter, die Paketverlustrate und die genutzten Codecs. Für jede Session wird der individuelle R-Faktor berechnet und der MOS-Wert (Mean opinion Score) abgeleitet. Durch farbliche Codes (Grün, Gelb, Rot) werden Sessiondaten qualifiziert . Dies sorgt für einen schnellen Überblick alle Verbindungen in einem Trace.
Codecs
Bevor ein VoIP-Gespräch über ein IP-Netz geführt werden kann, muss das analoge Audiosignal in ein digitales Signal umgewandelt werden. Da oft nur eine geringe Bandbreite zur Verfügung steht, ist auch eine entsprechende Komprimierung des Signals notwendig. Dabei wird eine möglichst hohe Sprachqualität bei einer möglichst niedrigen Datenrate angestrebt.
Das Sprachsignal wird beim Sender quantisiert und kodiert. Danach wird es per IP über das Netzwerk übertragen und beim Empfänger dekodiert, also für die Wiedergabe in ein analoges Signal umgewandelt. Die wichtigste Forderung an das verwendete Kodierverfahren ist: das Signal muss in Echtzeit, das heißt mit minimaler Verzögerung, kodierbar und dekodierbar sein.
| CODEC | Name | Übertragungs-rate | Sprachqualität | Verzögerung |
| G.711 PCM | Pulse Code Modulation | 64kbps | sehr gut | Nominell |
| G.723 | Algebraic Code Excited Linear Prediction (ACELP) | MP-MLQ 6.4/5.3 kBit/s | Gut bis schlecht | Hoch |
| G.723.1 MP MLQ | Multiple Maximum Likelihood Quantization (MPMLQ) | 6.4/5.3 kBit/s | Gut bis schlecht | Hoch |
| G.726 ADPCM | Adaptive Differential Pulse Code | 40/32/24/ 16 kBit/s | gut-schlecht | sehr gering |
| G.728 LD CELP | Low Delay Code Excited Linear Prediction (LD-CELP) | 16 kBit/s | gut | Gering |
| G.729 ACELP | Algebraic Code Excited Linear Prediction | 8 kBit/s | gut | Gering |
| G.729A ACELP | Conjugate Structure Algebraic Code Excited Linear Prediction (CSACELP) | 8 kBit/s | befriedigend | Gering |
Tabelle: Übersicht der verschiedene Sprachkomprimierverfahren.
Codecs unterscheiden sich in deren Sound-Qualität, die zur Quantifizierung/Codierung notwendige Rechenleistung und den für die Übermittlung der Signale notwendigen Bandbreite. Nutzt der Sender einen bestimmten Sprachcodec zum Kodieren der Sprache, muss der Empfänger den selben Sprachcodec zur Dekodierung der Sprache benutzen. Bei der Signalisierung des Gesprächs wird festgelegt, welchen Sprachcodec die beiden Kommunikationspartner anwenden.
Der Codec G.711 ist der bekannteste Sprachcodec und muss von jedem VoIP-Endgerät unterstützt werden. Dieser bietet die beste Sprachqualität (ähnlich ISDN), benötigt aber auch die größte Bandbreite.
Da nicht immer die maximale Bandbreite zur Übermittlung der Sprachsignale zur Verfügung steht, sind die Endgeräte dazu gezwungen, einen schlechteren Sprachcodec zu nutzen, um die betreffende VoIP-Verbindung überhaupt aufbauen zu können. Dies bringt zwangsläufig eine Verschlechterung der Sprachqualität mit sich.
Sollen mehrere Standorte miteinander verbunden und sollen in allen Standorten VoIP-Geräte installiert werden, müssen zwischen den einzelnen Standorten von einem Service Provider die entsprechenden Verbindungen angemietet werden. Zur Reduzierung der notwendigen Bandbreite und damit selbstverständlich auch der Kosten, werden oftmals auf diesen Leitungen Codecs mit geringer Bandbreitenanforderungen genutzt. Hierfür werden spezielle Gateways installiert, welche die Telefonate von einen Codec in einen andern Codec umsetzen. Beispielsweise werden in einer Geschäftsstelle für die interne Kommunikation G.711 benutzt. sollen Verbindungen zwischen unterschiedlichen Unternehmensstandorten Verbindungen aufgebaut, übersetzen die Gateways die G.711 codierten Gespräche beispielsweise in G.729 codierte Datenströme. Dadurch wird eine nicht unerhebliche Menge an Bandbreite (pro Datenstrom bis zu 54 kBit/s) eingespart. Am anderen Ende der Verindung, im Empfangsstandort, werden die ankommenden G.729 Gespräche über ein Gateway wieder in G.711-Signale umkonvertiert und anschließend zum betreffenden Endgerät im internen Netz weitergeleitet. Die Umcodierung in den Gateways spart zwar Übertragungsbandbreite ein, hat jedoch den Nachteil, dass sich die Sprachqualität verringert. Dies bedeutet: Die Qualität eines solchen umcodierten Gesprächs wird nie besser sein als die vom G.729 Codec zur Verfügung gestellte Signalqualität. Dabei ist es vollig unerheblich, ob die Endteilnehmer einen besseren Codec (G.711) nutzen. Das Gateway bestimmt mit seinem Codec die Ende-zu-Ende-Sprachqualität.
An geeigneten Analysepunkte im Netzwerk (beispielsweise Eingang Ausgang der Mediagateways) lassen sich die Umcodierungen darstellen. Der eingehende G.711- und der ausgehende G.729–Verkehr wird hierbei aufgezeichnet und miteinander korrelliert.
In der Praxis lässt sich die Qualität der eigentlichen Umkodierung mit Hilfe einer passiven Messung nicht überprüfen. Hierfür muss man auf eine aktive VoIP-Simulation zurückgegriffen werden. (mat)