Latenz, Jitter, Paketverlust – was die Sprachqualität wirklich kaputt macht

„Die Leitung ist schlecht“ ist bei VoIP fast nie die ganze Wahrheit. Der Anschluss hat genug Bandbreite, der Speedtest ist grün, und trotzdem klingt das Gespräch abgehackt oder man redet ständig durcheinander. Bandbreite ist bei Telefonie selten das Problem; ein Gespräch braucht nur rund 100 kbit/s, wie im Beitrag über Codecs gemessen.

Was die Sprache wirklich kaputt macht, sind drei andere Werte: Latenz, Jitter und Paketverlust. Ich erkläre, was dahintersteckt, und habe die drei im Labor absichtlich erzeugt, um zu zeigen, wie sie in den Messwerten einer Telefonanlage auftauchen.

Kurz zur Erinnerung: Sprache in Paketen

Bei VoIP wird die Stimme in kleine Stücke geschnitten, üblicherweise 20 Millisekunden lang. Jedes Stück wird als eigenes Paket verschickt, 50 pro Sekunde und Richtung. Am anderen Ende werden die Pakete wieder zu Sprache zusammengesetzt. Damit das klappt, müssen sie rechtzeitig, gleichmäßig und vollständig ankommen. Genau dafür stehen die drei Werte.

Latenz: wie lange die Sprache unterwegs ist

Latenz ist die Verzögerung vom Mund des einen bis zum Ohr des anderen. Sie setzt sich aus vielen kleinen Teilen zusammen: das Zusammenstellen der Pakete, der Weg durchs Netz, Warteschlangen in Routern und der Puffer beim Empfänger.

Wie viel geht? Die ITU empfiehlt in ihrer Norm G.114 für Gespräche möglichst nicht mehr als 150 Millisekunden in eine Richtung. Bis dahin merkt man praktisch nichts. Darüber fängt es an zu stören: Man fällt sich ins Wort, weil man die Pause des anderen zu spät bemerkt, und es entstehen diese typischen „Hallo? – Ja? – Nein, du zuerst“-Momente. Ab etwa 400 Millisekunden ist ein normales Gespräch kaum noch möglich.

Eine Strecke durch Deutschland hat meist nur 10 bis 30 Millisekunden. Kritisch wird es mit Satellitenverbindungen, überlasteten Leitungen oder wenn ein Gespräch über mehrere Anlagen und Kontinente geführt wird.

Was hohe Latenz außerdem macht: Echos werden hörbar. Ein kleines Echo gibt es in fast jedem Telefonat, etwa von einem Freisprechtelefon oder einem analogen Anschluss. Kommt es schnell zurück, nimmt man es nicht wahr. Kommt es erst nach einer Viertelsekunde, hört man sich selbst.

Jitter: wie gleichmäßig die Pakete ankommen

Die Pakete werden schön regelmäßig verschickt, eins alle 20 Millisekunden. Unterwegs nehmen sie aber nicht alle genau gleich lang: Mal steht eins kurz in einer Warteschlange, mal ein anderes nicht. Diese Schwankung heißt Jitter.

Damit die Sprache trotzdem gleichmäßig klingt, hat jeder Empfänger einen Jitter-Puffer. Er sammelt die Pakete kurz und gibt sie dann im richtigen Takt wieder aus. Das funktioniert gut, kostet aber Zeit: Ein Puffer von 60 Millisekunden macht das Gespräch 60 Millisekunden langsamer. Kommt ein Paket später als der Puffer warten kann, ist es für die Sprache verloren, so als wäre es nie angekommen.

Faustregel: Jitter von ein paar Millisekunden ist normal. Ab etwa 30 Millisekunden wird es kritisch, weil der Puffer dann entweder groß und das Gespräch träge wird oder Pakete verwirft.

Paketverlust: was gar nicht ankommt

Manche Pakete kommen einfach nicht an. Ein überlasteter Router wirft sie weg, ein schlechtes WLAN verliert sie, ein Mobilfunkwechsel verschluckt ein paar. Bei Webseiten oder Downloads fällt das nicht auf, weil verlorene Daten einfach noch einmal geschickt werden. Bei Sprache geht das nicht: Wenn das Paket nach einer Sekunde nachkäme, wäre das Gespräch längst weiter.

Jedes verlorene Paket ist ein Loch von 20 Millisekunden in der Sprache. Moderne Telefone versuchen, kleine Lücken zu überdecken, indem sie den letzten Laut kurz verlängern. Das klappt bei einzelnen Verlusten. Bei mehr als 1 Prozent wird es hörbar: Silben fehlen, die Stimme klingt abgehackt oder blechern. Ab einigen Prozent ist das Gespräch anstrengend, ab 10 Prozent kaum noch zu verstehen.

Der Labortest

Im Labor ruft ein Softphone eine Asterisk-Anlage an, die alles zurückspielt, was sie bekommt (eine Echo-Nebenstelle). Auf der Netzwerkschnittstelle des Telefons stelle ich mit tc netem künstlich Störungen ein, zum Beispiel:

tc qdisc add dev eth0 root netem delay 80ms 30ms loss 3%

Das heißt: Jedes Paket wird um 80 Millisekunden verzögert, plus oder minus 30, und 3 Prozent gehen verloren. Nach 18 Sekunden Gespräch frage ich die Anlage, was sie selbst misst:

asterisk -rx "pjsip show channelstats"

So sieht das Ergebnis ohne Störung aus:

                                             ...........Receive......... .........Transmit..........
 BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
          1001-00000000      00:00:18 alaw      905       0    0   0.001    905       0    0   0.001   0.000

Die Spalten links („Receive“) zeigen, was die Anlage vom Telefon bekommt, die rechten („Transmit“), was beim Telefon ankommt; das meldet das Telefon per RTCP zurück. Jitter und RTT (die Zeit hin und zurück) stehen in Sekunden.

Und so mit verschiedenen Störungen:

Die Störung habe ich nur in eine Richtung eingestellt, vom Telefon zur Anlage. Deshalb entspricht die RTT ungefähr der eingestellten Verzögerung. Was man sieht:

• Reine Verzögerung macht die Messwerte nicht schlechter. Es geht nichts verloren, Jitter bleibt bei null. Man würde sie im Gespräch trotzdem merken, ab 150 Millisekunden deutlich.
• Schwankende Verzögerung taucht direkt als Jitter auf: ± 20 Millisekunden ergeben gemessene 19.
• Verlust wird sauber gezählt. Bei 10 Prozent eingestelltem Verlust kamen 9 Prozent nicht an; das ist Zufall in der kurzen Messzeit.

Diesen Befehl kann man übrigens auch im echten Betrieb nutzen. Wer eine Asterisk-Anlage hat und eine Beschwerde über schlechte Qualität bekommt, sieht mit pjsip show channelstats während des Gesprächs sofort, ob Pakete fehlen oder schwanken.

Selbst ausprobieren: Im Sprachlabor stellst du Verzögerung, Jitter und Verlust mit Reglern ein und siehst, was die Anlage messen würde und wie die Qualität nach dem E-Modell ausfällt. Mit Kopfhörern kannst du dort auch deine eigene Stimme mit der eingestellten Verzögerung hören.

Wo die Störungen herkommen

In der Praxis sind es fast immer dieselben Verdächtigen:

• Volle Upload-Leitung. Lädt jemand gleichzeitig große Dateien hoch oder läuft ein Backup, stehen die Sprachpakete im Router hinten in der Schlange. Ergebnis: Jitter und Verlust. Hier hilft Priorisierung im Router (oft „QoS“ oder „Priorisierung für Telefonie“ genannt).
• WLAN. Funk ist für Sprache das schwierigste Medium: Störungen, viele Geräte, Wechsel zwischen Zugangspunkten. Tischtelefone gehören ans Kabel.
• VPN und Umwege. Läuft die Telefonie durch einen VPN-Tunnel über die Zentrale, kommen Verzögerung und mögliche Engpässe dazu.
• Mobilfunk und Satellit. Wechselnde Latenz und kurze Aussetzer sind dort normal.
• Schlechte Leitung beim Provider. Seltener, als man denkt, aber es gibt sie. Dann helfen Messwerte über mehrere Tage, um es zu belegen.

Wie man so etwas systematisch eingrenzt, steht in „Telefon geht nicht“. Und wie ich im Support-Alltag Mitschnitte auswerte, steht in Voice-Diagnose.

Und der MOS-Wert?

In Messwerkzeugen taucht oft ein MOS auf, der „Mean Opinion Score“. Ursprünglich haben Menschen in Hörtests Gespräche mit 1 (schlecht) bis 5 (ausgezeichnet) bewertet. Heute rechnen Werkzeuge den Wert aus Latenz, Jitter, Verlust und Codec aus, meist nach dem sogenannten E-Modell der ITU (G.107). Als grobe Orientierung: über 4 ist gut, unter 3,6 merken viele einen Unterschied, unter 3 beschweren sich die Leute. G.711 ohne Störungen kommt auf etwa 4,4.

Fazit

• Latenz stört ab etwa 150 Millisekunden: Man fällt sich ins Wort, Echos werden hörbar.
• Jitter ab etwa 30 Millisekunden: Der Puffer wird träge oder verwirft Pakete.
• Paketverlust ab etwa 1 Prozent: Die Sprache wird abgehackt.

Und fast immer steckt eine volle Leitung, ein WLAN oder ein Umweg dahinter, nicht die Bandbreite.

Labor: Asterisk 20 und baresip 1.1 in Docker, Störungen mit Linux tc netem. Quellen: ITU-T G.114 (Übertragungszeit) · ITU-T G.107 (E-Modell) · RFC 3550 (RTP und RTCP)

Trace lesen lassen statt selbst grübeln: Lade deinen SIP-/VoIP-Mitschnitt bei der Pcap-Diagnose hoch und bekomme eine klare technische Einschätzung zurück — wo es hakt, auf welcher Seite, was der nächste Schritt ist. Die erste Analyse pro E-Mail-Adresse ist kostenlos.