Als Netzwerkadministrator hat man zwar nur einen Teil der Kommunikationsstrecke unter Kontrolle. Aber schon auf den ersten Stationen – vom Endgerät zum Router in das externe Netz - sollte man die Voraussetzungen für eine gute VoIP-Qualität schaffen. Denn jeder Aussetzer auf den ersten paar Stationen macht sich auch beim Empfänger bemerkbar. Der weitere Weg über diverse Internet-Stationen verbessert die Qualität sicherlich nicht - ganz im Gegenteil.
Spezielle, teure Test-Tools können genau analysieren, ob und mit welchen Qualitätseinbußen zu rechnen ist, oder an welchen Schrauben man noch drehen kann, um die Qualität zu verbessern. Mehr dazu finden Sie in unserem Beitrag VoIP-Performance-Analyse - messtechnische Konzepte und Vorgehensweise. Aber man kann auch mit den Bordmitteln von Windows oder Linux und etwas Wissen über IP und VoIP grob evaluieren, ob dem Einsatz von VoIP etwas entgegensteht.
Delay/Jitter
Die Verzögerungszeit zwischen Sprechen des Senders und Hören beim Empfänger (Mund zu Ohr) ist ein entscheidendes Kriterium für die empfundene Qualität des VoIP-Gesprächs. Im Allgemeinen gilt, dass 250 bis 300 ms noch tolerabel sind. Die Verzögerung besteht aus folgenden Bestandteilen:
Kodierung und Paketierung
Zunächst muss die analoge Sprache digitalisiert und quantisiert werden. Je nach verwendetem Codec und Rechenleistung variiert die entstehende Verzögerung. Danach muss der kontinuierliche Datenstrom in einzelne Pakete verpackt werden. Ein solches lässt sich erst nach Fertigstellung versenden. Hier kann man nur durch die Auswahl des Codecs die Verzögerungen minimieren. Da dieser Block jedoch nur den geringsten Anteil an der Gesamtverzögerung hat, bringen Optimierungen nur wenig.
Transport
Hier entstehen die größten Verzögerungen. Neben der reinen Ausbreitungsgeschwindigkeit im Medium muss das Datenpaket ja auch serialisiert werden. Beispielsweise dauert das reine Übertragen eines 126 Byte großen Pakets über eine Leitung mit 1,5 Mbit/s 0,7 ms. Zusätzlich treten in Switches, Routern oder Firewalls und Proxies Latenzen auf, denn diese verarbeiten das Paket und senden es dann weiter. Gerade beim Routing fällt dies besonders ins Gewicht, denn hier findet oft ein Medienwechsel statt. Aus dem LAN kommen die Pakete beispielsweise mit 100 Mbit/s an, müssen dann jedoch durch eine „enge“ Röhre ins Internet, die etwa nur eine Bandbreite von 10 Mbit/s bietet. Je nach Arbeitsweise des Routers kommt hier eine erhebliche Verzögerung zustande.
Jitter und Dekodierung
Auch wenn der Absender absolut regelmäßig alle x Millisekunden ein Datenpaket schickt, heißt das noch lange nicht, dass auch alle x Millisekunden ein Datenpaket beim Empfänger ankommt. Jitter ist die Bezeichnung für die Abweichung vom „normalen“ Paketabstand. Ein Jitter-Buffer beim Empfänger soll dafür sorgen, dass Unregelmäßigkeiten bis zu einem gewissen Grad ausgeglichen werden können. Die Faustregel ist: Je toleranter ein System gegenüber Jitter ist (etwa durch größere Buffer), desto mehr Latenz addiert sich. Zu guter Letzt müssen die Pakete noch dekodiert werden. Auch das dauert eine gewisse Zeit. Da diese Schritte aber beim Empfänger ablaufen, hat man darauf keinen Einfluss. Man kann lediglich versuchen, den im eigenen Netzwerk - etwa durch Router - verursachten Jitter zu minimieren.
Paketverlust
Zusätzlich kommt noch ein weiterer Faktor ins Spiel - der Packet Loss. Ist der Traffic so groß, dass irgendeine Station ihn nicht mehr verarbeiten kann, gehen Pakete verloren. Bei einer normalen TCP-Verbindung ist das kein Problem, denn die internen Mechanismen sorgen dafür, dass das entsprechende Paket neu übertragen wird, sobald die Bestätigung für das Paket ausbleibt.
UDP, wie es bei VoIP verwendet wird, stellt dagegen die Übertragung nicht sicher, es würde ja auch keinen Sinn machen. Ein Sprachpaket enthält im Allgemeinen zwischen 20 und 30 ms Sprachdaten, also knapp eine Silbe. Eine fehlende Silbe irgendwann später nachzuliefern, wäre reichlich sinnlos. Zudem würde eine Nachlieferung den Jitter deutlich erhöhen.
Bei Paketverlusten gilt es, zwei verschiedene Szenarien zu unterscheiden: unregelmäßig verstreute Paketverluste und den Verlust mehrerer aufeinander folgender Pakete. Ersteres ist erheblich besser tolerierbar, da sehr kurze Aussetzer die Sprachqualität nicht so sehr beeinflussen wie eine Serie von verlorenen Paketen. Das kann dazu führen, dass ganze Wörter nicht übertragen werden.
Messungen
Um die Verzögerungen auf dem Weg zu messen, bietet sich ein Ping für eine grobe Annäherung an. Dabei sind zwei Faktoren zu beachten: Zum einen misst Ping die Gesamtverzögerung von Hin- und Rückweg (RTT). Da die Sprachdaten aber nur in eine Richtung fließen, muss der Wert halbiert werden. Zum anderen sollten die Testpakete ungefähr so groß sein wie ein Standard-VoIP-Paket.
Geht man von einer Kodierung nach G.711 und 20 ms Sprachdaten pro Paket aus, erhält man eine Nutzlast von 160 Byte (64 Kbit/s * 0,02 s). Dazu kommen noch 40 Byte für die IP/UDP/RTP-Header. Also sollten beim Ping 200 Byte große Pakete verschickt werden.
Unter Windows lautet das Kommando dann
ping -l 200 -t <Hostname>
Das -t weist ping an, solange Pings zu senden, bis Sie Strg-C drücken. Unter Linux verwenden Sie den Befehl
ping -s 200 <Hostname>
Zum einen erhalten Sie aus dieser Messung einen Anhaltspunkt für die Paketlaufzeit, und zum anderen können Sie damit die Paketverlustrate ermitteln.
Mehr Infos mit pathping
Zusätzliche Informationen können Sie unter Windows mit dem Programm pathping erhalten. Dieses ermittelt auf einer Wegstrecke, ob dort RSVP (Parameter -R) oder eine Layer-2-Prioritätskennung nach 802.1p (Parameter -R) unterstützt wird.
Um den Jitter zu ermitteln, können Sie unter Linux beispielsweise das Tool mtr nutzen. Dazu müssen Sie nach dem Start lediglich auf die Taste <j> drücken, um sich die Jitter-Statistiken anzeigen zu lassen.
RTP-Messungen
Zu guter Letzt sollten Sie noch einige Messungen mit RTP-Streaming durchführen, um einen zusätzlichen Eindruck von der zu erwartenden Qualität zu erhalten. Dazu können Sie beispielsweise die frei verfügbaren Tools RTPMonitor von der Columbia University und das Robust Audio Tool (RAT) vom University College London verwenden. Ersteres ist ein für Windows verfügbarer Treiberfilter für Netzwerkkarten, der RTP- und RTCP-Pakete abfängt und an eine grafische Oberfläche schickt, die detaillierte Statistiken über den RTP-Traffic sowie die entsprechenden Rückmeldungen von der Gegenstelle ausgibt. Das Robust Audio Tool ist eine Open-Source-Applikation für Audio-Konferenzen und Streaming, die unter den Betriebssystemen FreeBSD, HP-UX, IRIX, Linux, NetBSD, Solaris, SunOS und Windows läuft.
Installieren Sie den Treiber für RTPMonitor, indem Sie im Eigenschaften-Dialog der Netzwerkkarte auf „Installieren“ klicken, den Eintrag „Dienst“ auswählen und auf „Hinzufügen“ klicken. Im folgenden Dialog verwenden Sie die Schaltfläche „Datenträger“ und geben dann das Verzeichnis an, in das Sie den Quality Monitor Driver von RTPMonitor entpackt haben. Die Warnmeldungen von Windows, dass ein unsignierter Treiber hochgefährlich ist, können Sie getrost ignorieren. Danach starten Sie das GUI RTPMonitor.exe.
Im nächsten Schritt installieren Sie das Paket von RAT. Der Installer erzeugt keinen Eintrag im Startmenü, da Sie das Tool von der Kommandozeile aus starten müssen. Dazu öffnen Sie eine CMD-Shell und wechseln in das Verzeichnis Mbone unterhalb des Programme-Ordners. Zuvor benötigen Sie natürlich eine Gegenstelle, bei der Sie RAT ebenfalls einrichten.
Messungen mit RAT
RAT verfügt über eine Vielzahl von Kommandozeilen-Optionen und kann auch an Multicast-Konferenzen teilnehmen, für unseren Test reicht aber die einfachste Variante, bei der zwei Stationen direkt per Unicast miteinander kommunizieren. Dazu geben Sie lediglich den Namen oder die IP der Gegenstelle und eine gerade Portnummer ab 1024 getrennt durch einen Slash an:
rat <Rechner2>/10000
Der Port ist gegebenenfalls an einer dazwischen liegenden Firewall freizugeben. Auf dem anderen Rechner starten Sie äquivalent mit:
rat <Rechner1>/10000
Nun startet die grafische Benutzerschnittstelle von RAT, und hier können Sie ein paar zusätzliche Optionen einstellen. Klicken Sie dazu auf die Schaltfläche „Options“, und danach wählen Sie unter Category den Punkt „Audio“ an. Hier sollte die richtige Sound-Karte schon ausgewählt sein. Je nachdem welche Sample-Rate und wie viele Channels (Mono oder Stereo) Sie selektieren, können Sie später in der Kategorie „Transmission“ verschiedene Codecs auswählen. Es geht um IP-Telefonie, daher sollten Sie Mono und eine Abtastrate von 16 KHz verwenden.
Danach können Sie zur Kategorie „Transmission“ wechseln und dort einstellen, wie RAT die ausgehenden Daten kodieren soll. Die beiden Einträge µ-Law und a-Law beziehen sich auf G.711. Einen dieser beiden sollten Sie für den ersten Test verwenden. Später können Sie dann noch mit den diversen Subvarianten von G.726 experimentieren.
Analyse mit dem RTP Monitor
Hiermit sind zunächst die Einstellungen abgeschlossen, und Sie können die Konfiguration bestätigen. Damit Sie sich beim Test nicht den Mund fusselig reden müssen, können Sie RAT anweisen, eine WAV-Datei als Eingabemedium zu verwenden. Klicken Sie auf das Diskettensymbol im Programmfenster und dann wieder auf die Diskette bei Playback. Nun wählen Sie eine WAV-Datei aus. Musikstücke sind allerdings weniger geeignet. Im Verzeichnis C:\WINDOWS\Help\SBSI\Training\WXPPro\Content\Wave finden Sie beispielsweise die Datei U4L3DR.WAV. Diese enthält einen längeren gesprochenen Text, der sich relativ gut eignet.
Um die RTP-Ströme zu überwachen, starten Sie nun im RTPMonitor die Protokollierung. Wechseln Sie zurück zum RAT File Control und klicken auf das Dreieck. RAT startet die Übertragung, und Sie müssten nun bei der Gegenstelle den Text hören. Gleichzeitig können Sie dort auch eine Übertragung starten und den RTPMonitor beobachten.
Meldet eine der Stationen per RTCP Probleme, etwa weil Pakete zu spät oder gar nicht eintreffen, sehen Sie das nun direkt am RTPMonitor.
Ausblick
Mit den vorgestellten Tools können Sie schon im Vorfeld grob austesten, ob Ihr Netzwerk den Anforderungen von VoIP gewachsen ist. Die Kombination von RAT und RTPMonitor lädt geradezu zum Experimentieren ein. Mehrere Streams, parallel laufende Übertragungen von Dateien, Spielereien mit Multicast für Inhouse-Konferenzen oder ähnliche Tests sind ohne großen Aufwand möglich.
Die Auswahl des Codecs und seine Auswirkungen auf die Sprachqualität bei verschiedenen Netzwerkbelastungen lassen sich ebenfalls so ermitteln, denn RAT ermöglicht auch das Aufzeichnen der eingegangenen Sprachdaten. Ein Vergleich mit dem gesendeten Original ist somit sehr gut möglich. (ala)