Abgehackte Sprache in Teams: Jitter, Paketverlust und Roundtrip

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Seit Wochen „klingt komisch“-Tickets und keiner findet die Ursache? Wir grenzen mit dir anhand der Anrufdaten ein, wo es bricht. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die CQD, Anrufanalyse und Netzwerkwerte selbst lesen und Sprachprobleme sicher eingrenzen wollen. › Schulung Teams-Telefonie

 

„Du bist ganz abgehackt.“ Kaum ein Satz fällt in Teams-Anrufen häufiger, und kaum einer ist weniger hilfreich. Er sagt dir, dass etwas kaputt ist, aber nicht was, nicht wo und schon gar nicht, wer es reparieren soll. Die Antwort „Bei mir ist alles gut“ ist übrigens fast immer ehrlich gemeint und fast immer falsch, denn wer abgehackt sendet, hört sich selbst ja einwandfrei.

Hinter dem Symptom stecken drei Messwerte: Jitter, Paketverlust und Roundtrip. Sie entstehen irgendwo zwischen dem Mund des einen und dem Ohr des anderen: im Headset, im Rechner, im WLAN, im VPN, am Standort-Router oder auf der Internetleitung. Wer da ohne System sucht, tauscht nacheinander Headset, Laptop, Switch und schließlich den Internetanbieter und hat am Ende vier neue Geräte und dasselbe Problem.

Dieser Beitrag gehört zur Serie rund um die Teams-Telefonie und ist bewusst auf die schnelle Eingrenzung ausgelegt. Wie QoS, das Call Quality Dashboard (CQD) und die Netzwerkplanung grundsätzlich funktionieren, steht ausführlich in Sprachqualität in Teams: QoS, CQD und Troubleshooting. Hier geht es um die Frage, die im Helpdesk zuerst kommt: Ist es ein Benutzer, ein Standort oder alle? Und was machst du in den ersten dreißig Minuten, damit das Ticket nicht drei Wochen alt wird?

FAKTEN · Das Beispiel in diesem Beitrag Erfundener Tenant Contoso (contoso.com) mit Standorten in Frankfurt, Köln, Berlin, Hamburg und München. Direct Routing über sbc1.contoso.com (Frankfurt) und sbc2.contoso.com (Hamburg), Rufnummern im Muster +49 69 555 0100 für Frankfurt und +49 30 555 0100 für Berlin. Berlin hat das Subnetz 10.40.0.0/16, eine eigene Internetleitung und ein WLAN, das ein Dienstleister vor zwei Jahren „erst einmal provisorisch“ aufgebaut hat. Alle Namen, Adressen und Nummern sind erfunden.

 

Das Symptom: Roboterstimme, Wortfetzen, Funkstille

So klingt es im Helpdesk

Abgehackte Sprache kommt selten als sauber formuliertes Ticket. Sie kommt als Seufzer. Wenn du die typischen Sätze übersetzt, bekommst du aber erstaunlich gute Hinweise:

„Ich klinge wie ein Roboter.“ Klassischer Jitter oder Paketverlust, den der Codec mühsam überbrückt. Die Sprache ist da, aber zerhackt und metallisch.

„Es fehlen immer wieder halbe Wörter.“ Paketverlust. Kleine Lücken kaschiert Teams, größere Lücken hörst du als verschluckte Silben.

„Wir fallen uns ständig ins Wort.“ Hoher Roundtrip. Die Sprache ist sauber, kommt aber so spät an, dass beide gleichzeitig reden.

„Nur im Besprechungsraum“ oder „nur in der Kantine“. WLAN mit schwachem Signal, überfüllter Funkzelle oder Roaming zwischen Access Points.

„Seit ich im Homeoffice bin“ oder „nur mit VPN“. Der VPN-Tunnel trägt die Sprache, obwohl er das nicht sollte.

„Immer nachmittags“ oder „wenn das Backup läuft“. Volle Leitung, kein QoS. Sprache steht in derselben Warteschlange wie die Datensicherung.

„Die anderen hören mich schlecht, ich höre alle gut.“ Das Problem liegt auf deiner Senderseite: Headset, Mikrofon, Rechnerlast oder dein Upload.

„Nur bei Anrufen nach draußen, Teams intern ist alles gut.“ Die Strecke über den SBC ist verdächtig, nicht dein WLAN.

Die Admins erleben das Ganze von der anderen Seite: viele Tickets, wenig Muster, und jedes Mal, wenn du den Anruf nachstellst, klingt alles einwandfrei. Willkommen in der Welt der zeitabhängigen Netzprobleme. Sie haben die Angewohnheit, genau dann zu verschwinden, wenn jemand zuschaut.

Was die drei Messwerte im Ohr anrichten

Teams überträgt Sprache in kleinen Paketen, typischerweise je 20 Millisekunden Audio pro Paket. Der Empfänger braucht diese Pakete pünktlich, vollständig und ohne große Verzögerung. Jede der drei Bedingungen hat einen eigenen Messwert, und jeder Messwert klingt anders:

Messwert	Was er misst	Wie es klingt	Typische Quelle
Jitter	Schwankung der Ankunftszeit zwischen aufeinanderfolgenden Paketen	Roboterstimme, verzerrte oder gedehnte Silben	WLAN, überlastete Leitung ohne QoS, VPN
Paketverlust	Anteil der Pakete, die nie ankommen	Wortfetzen, Aussetzer, verschluckte Silben	WLAN, volle Leitung, fehlerhafte Kabel oder Ports
Roundtrip	Zeit für den Weg hin und zurück	Sauberer Ton, aber ständiges Ins-Wort-Fallen	Umwege über VPN, Proxy oder ferne Ausgänge
Kein Netzwert auffällig	Netz ist sauber, Ton trotzdem schlecht	Knacken, Aussetzer, Echo	Headset, Treiber, Rechnerlast

 

TIPP · Erst fragen, wer wen schlecht hört Die wichtigste Frage im ersten Gespräch kostet zehn Sekunden: Hörst du die anderen schlecht, oder hören die anderen dich schlecht? Wer schlecht gehört wird, hat das Problem meist auf seiner Senderseite. Wer schlecht hört, hat es auf seiner Empfangsseite oder beim Gegenüber. Allein diese Frage halbiert die Zahl der Verdächtigen.

 

Wie abgehackte Sprache technisch entsteht

Die Strecke vom Mund zum Ohr

Zwischen zwei Teams-Benutzern liegt eine Kette: Headset › Rechner › WLAN oder LAN › Standort-Router › gegebenenfalls VPN oder Proxy › Internetleitung › Microsoft-Netz › und spiegelbildlich dieselbe Kette auf der anderen Seite. Bei Anrufen ins Telefonnetz über Direct Routing kommt noch die Strecke Microsoft › SBC › SIP-Trunk dazu. Jede Station kann Jitter, Verlust oder Laufzeit beisteuern. Teams misst am Ende nur die Summe, und das Ohr hört nur das Ergebnis.

Zwei Dinge musst du dabei im Kopf behalten. Erstens: Headset und Rechner verursachen oft gar kein Netzproblem. Wenn das Mikrofon über Bluetooth aussetzt oder der Prozessor keine Zeit für die Audioverarbeitung hat, sind Jitter und Verlust im Netz unauffällig, der Ton ist trotzdem zerhackt. Zweitens: Die Medien nehmen nicht zwingend den Weg, den du vermutest. Ist UDP gesperrt, weicht Teams auf TCP aus, und das verschlechtert alle drei Messwerte. Diesem Spezialfall ist ein eigener Beitrag gewidmet: Teams-Telefonie über TCP statt UDP: warum das schlecht klingt.

Die Grenzwerte, die Microsoft ansetzt

Damit aus „klingt komisch“ ein messbarer Befund wird, brauchst du Grenzwerte. Microsoft dokumentiert zwei Sätze davon, und es lohnt sich, sie nicht zu verwechseln.

FAKTEN · Wann CQD einen Audiostream als schlecht einstuft Das Call Quality Dashboard markiert einen Audiostream als schlecht (Poor), wenn mindestens eine der folgenden Bedingungen erfüllt ist und der Stream mehr als 500 Pakete umfasst: durchschnittlicher Roundtrip über 500 ms, durchschnittliche Paketverlustrate über 0,1 (also 10 Prozent) oder durchschnittlicher Jitter über 30 ms. Mit den Dimensionen „Audio Poor Due To Jitter“, „Audio Poor Due To PacketLoss“ und „Audio Poor Due To RoundTrip“ siehst du, welcher Wert gerissen wurde. Die vollständige Definition steht in Streamklassifizierung im Anrufqualitätsdashboard.

 

Microsoft schreibt dazu ausdrücklich: Eine Einstufung als schlecht heißt nicht, dass der Stream tatsächlich schlecht klang oder dass jemand ein Problem bemerkt hat. Der Medienstack von Teams kann deutliche Verschlechterungen ausgleichen, bevor sie hörbar werden. Umgekehrt gilt leider auch: Ein Stream unterhalb dieser Schwellen kann trotzdem hörbar leiden, wenn die Störungen in Schüben kommen. Die CQD-Werte sind Durchschnitte über den ganzen Stream. Zehn Sekunden Totalausfall in einem Gespräch von dreißig Minuten verschwinden im Mittelwert.

Der zweite Satz Grenzwerte stammt aus dem Microsoft 365-Netzwerkkonnektivitätstest. Er misst in einem zehnsekündigen Testanruf per UDP zum Teams-Dienst und wertet als bestanden: Paketverlust unter 1 Prozent, Latenz unter 100 ms, Jitter unter 30 ms. Das sind Zielwerte für ein gesundes Netz, keine Alarmgrenzen.

Messwert	Ziel laut Konnektivitätstest	„Schlecht“ laut CQD	Was dazwischen liegt
Jitter	unter 30 ms	über 30 ms (Durchschnitt)	Keine Grauzone. Jitter um 30 ms ist schon grenzwertig.
Paketverlust	unter 1 %	über 10 % (Durchschnitt)	Breite Grauzone. 3 bis 5 Prozent hörst du oft schon, CQD meldet aber noch nichts.
Latenz bzw. Roundtrip	Latenz unter 100 ms	Roundtrip über 500 ms (Durchschnitt)	Hohe Werte stören das Gespräch, nicht den Klang.

 

WICHTIG · Grenzwerte nicht erfinden, sondern nachschlagen Im Netz kursieren viele Tabellen mit angeblichen Teams-Grenzwerten, oft aus alten Skype-for-Business-Zeiten oder aus Herstellerbroschüren. Für Teams verlässlich sind die Klassifizierung im CQD und die Bestehenskriterien des Konnektivitätstests aus der Microsoft-Dokumentation. Wenn dein Netzwerkteam mit anderen Zahlen argumentiert, frag nach der Quelle. Das spart erstaunlich viele Besprechungen.

 

Die sechs üblichen Verdächtigen

In der Praxis landet fast jeder Fall bei einer dieser sechs Ursachen. Die Spalte „Spur in den Daten“ nennt die CQD-Dimensionen, mit denen du den Verdacht erhärtest oder verwirfst.

Ursache	Typisches Muster	Spur in den Daten	Schnelle Gegenprobe
WLAN	Nur einzelne Räume, Etagen oder Geräte, oft beim Herumlaufen	Network Connection Detail = WiFi, WiFi Signal Strength, WiFi Band, WiFi Channel	Netzwerkkabel anstecken und denselben Anruf wiederholen
VPN	Nur im Homeoffice oder nur mit aktivem Tunnel	First VPN, VPN Estimated, oft zusammen mit hohem Roundtrip	Anruf mit getrenntem VPN wiederholen, falls die Sicherheitsrichtlinie es zulässt
Überlastete Leitung	Ganzer Standort, zu bestimmten Uhrzeiten	Schlechte Streams je Gebäude oder Subnetz, gehäuft zu Spitzenzeiten	Auslastung der Leitung zur selben Zeit prüfen
Fehlendes QoS	Wie überlastete Leitung, aber schon bei mittlerer Last	Jitter und Verlust steigen mit der Auslastung, nicht mit der Uhrzeit	Mitschnitt: Kommen Pakete mit DSCP 46 an, bleibt die Markierung erhalten?
Headset	Eine Person, egal wo, oft nur Senderichtung	Capture Dev Name, Device Glitches Event Ratio, Device Echo Event Ratio, Netzwerte unauffällig	Anderes Headset oder kabelgebundenes Modell testen
Rechnerlast	Eine Person, oft bei Bildschirmfreigabe oder vielen Programmen	CPU Insufficient Event Ratio, Is Call Throttled, Netzwerte unauffällig	Task-Manager während des Anrufs, Energiesparplan, ausstehende Updates

 

AUS DER PRAXIS · Ulis anynode-SBC und die nächtliche Datensicherung Mein eigener anynode-SBC läuft als virtuelle Maschine. Eine Zeit lang klangen ausgerechnet die abendlichen Anrufe ins Telefonnetz zerhackt, Teams-interne Anrufe zur selben Zeit dagegen sauber. Das WLAN war unschuldig, das Headset auch. Schuld war der Host, auf dem zur selben Zeit die Datensicherung lief und der virtuellen Maschine die Rechenzeit streitig machte. Seit der SBC eine feste CPU-Reservierung hat und die Sicherung zu einer anderen Uhrzeit läuft, ist Ruhe. Die Lehre: Wenn nur PSTN-Anrufe leiden, schau auf den SBC und seine Umgebung, nicht auf die Clients.

 

Schnelle Eingrenzung: ein Benutzer, ein Standort oder alle?

Die Diagnose ist bis zum Schluss rein lesend. Du brauchst Leserechte im Teams Admin Center und im Call Quality Dashboard, das PowerShell-Modul MicrosoftTeams und für die Netzseite jemanden, der Auslastung und Firewall-Protokolle lesen darf. Bevor du misst, bestimmst du den Kreis der Betroffenen. Das ist der Schritt, der die meiste Zeit spart, und der, der am häufigsten übersprungen wird.

Schritt 1: Fünf Fragen an das Ticket

Wer hört wen schlecht? Sender- oder Empfangsseite, siehe oben.

Wo? Standort, Gebäude, Raum, Homeoffice. Kabel oder WLAN?

Wann? Immer, zu bestimmten Uhrzeiten, nur bei bestimmten Tätigkeiten wie Bildschirmfreigabe?

Mit welchem Gerät? Headset-Modell, Bluetooth oder Kabel, Laptop oder Tischtelefon?

Welche Anrufe? Teams-intern, Besprechungen, Anrufe ins Telefonnetz über den SBC?

Sammle die Antworten für alle offenen Tickets in einer Tabelle. Nach zehn Tickets siehst du meistens schon, in welche Spalte der Skizze du gehörst. Nach zwanzig weißt du es.

Schritt 2: Einzelner Benutzer im Teams Admin Center

Für einen einzelnen Benutzer öffnest du im Teams Admin Center unter Benutzer › Benutzer verwalten den betroffenen Benutzer und dort die Registerkarte mit dem Besprechungs- und Anrufverlauf. Zu jedem Anruf zeigt die Anrufanalyse je Teilnehmer Angaben zu Gerät, System, Konnektivität und Netzwerk, darunter Jitter, Paketverlust und Roundtrip, den Verbindungstyp (verkabelt oder WLAN), Angaben zum WLAN, ob ein VPN erkannt wurde, sowie Mikrofon und Lautsprecher. Auffällige Werte hebt das Teams Admin Center hervor.

Die Lesart ist einfach: Sind die Netzwerkwerte gut und der Benutzer klagt trotzdem, schau auf Gerät und Rechner. Sind die Netzwerkwerte schlecht, schau auf Verbindungstyp und VPN. Und vergleiche mindestens drei Anrufe, nicht einen. Ein einzelner schlechter Anruf aus dem ICE eines Fernzugs ist kein Befund, sondern Alltag.

TIPP · Die Anrufintegrität im laufenden Gespräch Im Teams-Client kannst du während eines Anrufs über das Menü „Weitere Aktionen“ die Anzeige zur Anrufintegrität öffnen. Sie zeigt live unter anderem Roundtrip, Paketverlust und Jitter für die gesendeten und empfangenen Audiodaten. Lass Betroffene beim nächsten Aussetzer genau dort hinschauen und einen Screenshot machen. Das ist der beste Beweis, den ein Helpdesk je bekommt.

 

Schritt 3: Ganzer Standort im Call Quality Dashboard

Sobald mehr als eine Handvoll Benutzer betroffen ist, wechselst du ins CQD. Dort baust du einen Bericht für Audiostreams der letzten zwei bis vier Wochen. Messgröße ist „Audio Poor Percentage“, gruppiert nach Gebäude oder Subnetz, und als Filter nimmst du zunächst nur verkabelte Clients ohne VPN. Bleibt ein Standort dann auffällig, liegt es am Standort und nicht an WLAN oder Homeoffice. Danach nimmst du WLAN und VPN wieder hinzu und vergleichst.

Frage	CQD-Dimension oder Messgröße	Was du daraus liest
Welcher Standort leidet?	First Building Name, First Subnet, Audio Poor Percentage	Anteil schlechter Streams je Gebäude im Vergleich zu den anderen
Warum schlecht?	Audio Poor Due To Jitter, PacketLoss, RoundTrip	Welcher Grenzwert gerissen wurde
Kabel oder WLAN?	First Network Connection Detail, Network Connection Detail Pair	Ob WLAN-Streams deutlich schlechter sind als verkabelte
Spielt das VPN mit?	First VPN, First VPN Estimated	Ob VPN-Streams aus der Reihe fallen
Wann?	Datum und Stunde des Streams	Ob es Spitzenzeiten gibt, die auf eine volle Leitung deuten
Gerät oder Rechner?	First Capture Dev Name, First CPU Insufficient Event Ratio	Ob ein Headset-Modell oder überlastete Rechner auffallen

 

Bei Contoso war das Bild nach einer Viertelstunde klar: Berlin mit 18 Prozent schlechten Audiostreams, alle anderen Standorte zwischen ein und drei Prozent. Gefiltert auf verkabelte Clients blieb Berlin bei 14 Prozent, die Spitzen lagen werktags zwischen 13 und 16 Uhr, und als Grund stand fast immer Jitter oder Paketverlust. Also kein WLAN-Problem, sondern ein Leitungsproblem: Die Berliner Leitung wurde am Nachmittag von der Replikation der Dateiserver ausgelastet, und QoS gab es dort nicht.

WARNUNG · Ohne Gebäudedaten rät CQD nur CQD ordnet Streams nur dann Standorten zu, wenn du eine Gebäudedatei mit deinen Subnetzen hochgeladen hast. Fehlt ein Subnetz, landen dessen Streams unter „unbekannt“, und ein ganzer Standort kann unsichtbar werden. Ein Maschinenbauer mit zwölf Standorten hat so wochenlang das falsche Werk verdächtigt, weil ein Subnetz nach einem Umzug noch dem alten Gebäude zugeordnet war. Wie du Subnetze und Standorte konsistent hältst, steht in Netzwerkstandorte und Subnetze in Teams richtig pflegen.

 

Schritt 4: Nur Anrufe ins Telefonnetz

Klingen Teams-interne Anrufe gut und nur Anrufe über Direct Routing schlecht, verlagert sich die Suche. Ohne Media Bypass laufen die Medien vom Client zu Microsoft und von dort zum SBC. Mit Media Bypass spricht der Client direkt mit dem SBC, dann ist die Strecke zwischen Standort und SBC entscheidend. Und hinter dem SBC wartet noch die Strecke zum Provider. In CQD erkennst du die Strecke zum SBC daran, dass auf einer Seite der SBC als Server-Endpunkt auftaucht; die Dimension „Is Server Pair“ hilft beim Filtern. Für die Strecke zum Provider brauchst du die Statistiken des SBC selbst, die sieht Microsoft nicht.

Wie Media Bypass die Medienwege verändert, erklärt Teams Media Bypass und Local Media Optimization. Wenn die Medien dabei über einen anderen Standort laufen als erwartet, hilft Hairpinning in Teams: wenn Anrufe Umwege über andere Standorte nehmen weiter.

Schritt 5: Lesende PowerShell-Befehle

Im Tenant suchst du nicht nach dem Fehler, sondern nach den Rahmenbedingungen: Ist QoS-Markierung eingeschaltet, welche Quellports nutzen die Clients, sind die Subnetze den Standorten zugeordnet, und arbeiten die SBCs mit Media Bypass? Alle Befehle verändern nichts.

# Verbindung mit dem MicrosoftTeams-Modul Connect-MicrosoftTeams   # QoS-Markierung und Quellports der Clients Get-CsTeamsMeetingConfiguration | Select-Object EnableQoS, ClientMediaPortRangeEnabled, ClientAudioPort, ClientAudioPortRange, ClientVideoPort, ClientVideoPortRange, ClientAppSharingPort, ClientAppSharingPortRange   # Standorte und Subnetze: Ist 10.40.0.0/16 Berlin zugeordnet? Get-CsTenantNetworkSite | Select-Object NetworkSiteID, NetworkRegionID, Description Get-CsTenantNetworkSubnet | Sort-Object NetworkSiteID | Select-Object SubnetID, MaskBits, NetworkSiteID   # SBCs: aktiv und mit Media Bypass? Get-CsOnlinePSTNGateway | Select-Object Identity, Enabled, MediaBypass

 

Auf dem betroffenen Windows-Rechner kommen drei weitere lesende Befehle dazu. Sie zeigen Verbindungstyp und Geschwindigkeit, die WLAN-Werte und die per Gruppenrichtlinie verteilten QoS-Richtlinien:

# Netzwerkadapter: Kabel oder WLAN, Verbindungsgeschwindigkeit Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name, InterfaceDescription, LinkSpeed   # WLAN: Signal, Funkstandard, Kanal, Access Point netsh wlan show interfaces   # Aktive QoS-Richtlinien auf dem Rechner (z. B. aus der Gruppenrichtlinie) Get-NetQosPolicy -PolicyStore ActiveStore

 

Schritt 6: Vom Standort aus messen

Für die Netzseite eines Standorts ist der Microsoft 365-Netzwerkkonnektivitätstest das schnellste Werkzeug. Du rufst ihn im Browser auf, lädst den kleinen Testclient und bekommst unter anderem Paketverlust, Latenz und Jitter per UDP zum Teams-Dienst, den Internetausgang, einen eventuell konfigurierten Proxy, die VPN-Erkennung und einen Wert für Buffer Bloat, also wie stark die Latenz unter Last steigt. Microsoft meldet Buffer Bloat ab 100 ms als Auffälligkeit, und genau dieser Wert ist bei überlasteten Leitungen oft der verräterischste. Lass den Test einmal morgens und einmal zur Spitzenzeit laufen, von einem verkabelten Rechner. Zwei Ergebnisse nebeneinander sagen mehr als jede Diskussion.

Befund	Wahrscheinliche Ursache	Nächster Schritt
Netzwerte gut, nur eine Person klagt	Headset oder Rechner	Headset tauschen, CPU-Last im Anruf prüfen
Schlecht nur im WLAN, verkabelt gut	WLAN	Signal, Band und Kanal prüfen, WLAN-Team einbinden
Schlecht nur mit VPN	VPN ohne Split Tunneling	Split Tunneling für die Teams-Medien prüfen
Ganzer Standort, zu Spitzenzeiten	Leitung voll, kein QoS	Auslastung und QoS am Standort prüfen
Ganzer Standort, immer	Medienweg, TCP statt UDP, Umweg	Transport und Ausgang im CQD prüfen
Nur PSTN-Anrufe	SBC-Strecke oder Provider	SBC-Statistiken, Last und Media Bypass prüfen

 

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Der Teams-Telefonie Diagnostiker wertet in der Ansicht Anrufqualität die Audiostreams des gewählten Zeitraums je Standort aus. Ein Balkendiagramm zeigt für jeden Standort den Anteil schlechter Audiostreams und den Anteil der Medien über TCP statt UDP, mit Schwellen für mittlere und kritische Werte. Die Tabelle darunter nennt je Standort Subnetze, Streams, Paketverlust, Jitter, Roundtrip und die öffentliche Adresse. Damit siehst du auf einen Blick, ob ein Standort aus der Reihe fällt oder ob es um Einzelfälle geht. Auffällige Standorte erscheinen zusätzlich als Befund im Bereich Netz der Ampel. Für den Einzelfall zeigt der Benutzer-Steckbrief, an welchem Standort ein Benutzer geführt wird, wie die Medien an diesem Standort laufen und welche Befunde ihn betreffen. So trennst du schnell, ob das Problem an der Person oder am Ort hängt. Mehr dazu auf der Seite Teams-Telefonie Diagnostiker. Du kannst ihn 15 Tage kostenlos testen.

 

Behebung: je Ursache die passende Stellschraube

Die gute Nachricht: Fast keine dieser Behebungen findet im Teams-Tenant statt. Die schlechte: Fast alle finden in Systemen statt, die jemand anderem gehören. Plane also Abstimmung ein und halte für jede Änderung fest, wie du sie zurücknimmst.

WLAN

Microsoft empfiehlt für Teams im WLAN unter anderem QoS beziehungsweise WMM, damit Medienverkehr bevorzugt wird, die Nutzung des 5-GHz-Bands, gegebenenfalls Band Steering, und Access Points auf nicht überlappenden Kanälen. Praktisch heißt das: Funkausleuchtung prüfen, Besprechungsräume und Großraumbüros mit ausreichend Access Points versorgen und Clients nicht im 2,4-GHz-Band festhalten. Bis das erledigt ist, hilft der älteste Trick der IT: ein Netzwerkkabel für die Vieltelefonierer.

Rollback: Änderungen an Kanalplan oder Band Steering macht dein WLAN-Team über das Controller-Profil. Lass dir vor der Änderung den aktuellen Stand sichern, damit er sich zurückspielen lässt.

VPN

Microsoft empfiehlt, Teams-Medien am VPN vorbeizuführen. VPNs sind laut Microsoft typischerweise nicht für Echtzeitmedien ausgelegt, unterstützen manchmal kein UDP, verschlüsseln bereits verschlüsselte Medien ein zweites Mal und führen den Verkehr oft über Umwege. Die Lösung heißt Split Tunneling für die Teams-Medienendpunkte. Wie du das sauber und mit den richtigen Adressen einrichtest, steht in Teams-Telefonie über VPN: Split Tunneling richtig einrichten.

Rollback: Die Split-Tunnel-Konfiguration ist eine Profiländerung am VPN-Gateway oder im VPN-Client. Rolle sie zuerst für eine Pilotgruppe aus; zurück geht es über das vorherige Profil.

Überlastete Leitung und fehlendes QoS

Eine volle Leitung ist erst dann ein Sprachproblem, wenn Sprache in derselben Warteschlange steht wie alles andere. Dagegen hilft QoS. Microsoft empfiehlt dafür Quellportbereiche je Medienart und eine DSCP-Markierung: Audio mit den Ports 50000 bis 50019 und DSCP 46 (EF), Video mit 50020 bis 50039 und DSCP 34 (AF41), Bildschirmfreigabe mit 50040 bis 50059 und DSCP 18 (AF21). Auf Windows-Rechnern setzt du die Markierung per Gruppenrichtlinie, im Teams Admin Center schaltest du unter Besprechungen › Besprechungseinstellungen im Bereich Netzwerk die Einstellung für QoS-Markierungen ein. Entscheidend ist aber das Netz: Die Markierung nützt nur, wenn Switches, Router und WAN sie auf jedem verwalteten Abschnitt auch beachten.

Die Grundlagen dazu stehen in Sprachqualität in Teams: QoS, CQD und Troubleshooting und bei Microsoft in Implementieren von Quality of Service (QoS) in Microsoft Teams. Wenn QoS steht, die Leitung aber schlicht zu klein ist, hilft nur mehr Bandbreite oder weniger Datenverkehr zur falschen Zeit. Bei Contoso reichte es, die Replikation der Dateiserver in die Nacht zu verlegen und QoS am Berliner Router einzurichten: Der Anteil schlechter Streams fiel innerhalb einer Woche von 18 auf unter 3 Prozent.

WARNUNG · QoS ohne Rücksicherung ist ein Glücksspiel QoS-Änderungen an Routern und Firewalls wirken auf allen Verkehr, nicht nur auf Teams. Lass sie im Wartungsfenster einspielen, sichere vorher die Konfiguration und teste danach nicht nur Teams, sondern auch die geschäftskritischen Anwendungen. Ein Rollback besteht aus dem Zurückspielen der gesicherten Konfiguration; die Gruppenrichtlinie für die Markierung auf den Rechnern nimmst du durch Deaktivieren oder Entfernen der Verknüpfung zurück.

 

Headset und Rechner

Wenn die Netzwerkwerte unauffällig sind und es trotzdem zerhackt klingt, ist die Lösung erfreulich billig. Teste ein anderes Headset, idealerweise ein für Teams zertifiziertes Modell, und bei Bluetooth zum Vergleich ein kabelgebundenes oder eines mit eigenem USB-Empfänger. Prüfe Treiber und Firmware. Auf der Rechnerseite schaust du während eines Anrufs in den Task-Manager: Läuft gerade ein vollständiger Virenscan, ein Update oder eine Synchronisation, die den Prozessor auslastet? Steht der Energiesparplan auf maximaler Akkulaufzeit? Ein Laptop, der im Anruf die Taktfrequenz drosselt, klingt nicht besser, nur weil er länger durchhält.

Rollback: Gerätetausch ist trivial umkehrbar. Bei Treibern und Energieeinstellungen notierst du den Ausgangsstand, bevor du etwas änderst.

SBC-Strecke

Leiden nur Anrufe ins Telefonnetz, prüfst du Last und Ressourcen des SBC, die Netzanbindung zwischen SBC und Microsoft und die Strecke zum Provider. Grundlagen zum SBC findest du in Teams SBC Grundlagen: der Session Border Controller. Kommt das Problem eindeutig vom Provider, gehört es in dessen Ticketsystem; was du bei der Trunk-Auswahl beachten solltest, beschreibt SIP-Trunk-Auswahl für Teams Direct Routing.

Vorbeugung: damit „abgehackt“ kein Dauerzustand wird

Gebäudedaten im CQD aktuell halten. Jedes neue Subnetz gehört sofort in die Gebäudedatei, sonst ist dein wichtigstes Werkzeug blind.

Monatlich auf den Anteil schlechter Streams je Standort schauen. Ein Standort, der von zwei auf sechs Prozent steigt, kündigt die Tickets der nächsten Wochen an.

QoS nicht nur konfigurieren, sondern prüfen. Nach jedem Tausch von Router, Firewall oder WAN-Anbieter einen Mitschnitt machen: Kommt DSCP 46 an?

Split Tunneling für Teams-Medien festschreiben. Und bei jedem VPN-Update kontrollieren, ob es noch greift.

Headsets standardisieren. Wenige, für Teams zertifizierte Modelle reduzieren die Variablen im Helpdesk erheblich.

Große Datenübertragungen zeitlich planen. Backup, Replikation und Softwareverteilung gehören nicht in die Telefonie-Spitzenzeit.

Den Konnektivitätstest als Abnahme nutzen. Bei jedem neuen Standort und nach jeder größeren Netzänderung einmal laufen lassen und ablegen.

Viele dieser Punkte sind keine Technik-, sondern Organisationsfragen: Wer pflegt die Gebäudedaten, wer meldet Netzänderungen, wer schaut monatlich auf die Werte? Das gehört in jede ordentliche Betriebsdokumentation; einen Überblick über die übrigen Dauerbrenner gibt Teams-Telefonie Probleme: die zehn häufigsten Ursachen. Wenn ihr dafür einen Fahrplan oder eine zweite Meinung zum Netz braucht, hilft die Beratung zur Teams-Telefonie.

WEITERLESEN · Passend zu diesem Thema › Sprachqualität in Teams: QoS, CQD und Troubleshooting › Teams-Telefonie über TCP statt UDP: warum das schlecht klingt › Teams-Telefonie über VPN: Split Tunneling richtig einrichten › Netzwerkstandorte und Subnetze in Teams richtig pflegen › Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl › Einseitiges Audio oder kein Ton bei Teams Direct Routing › Teams-Anruf bricht nach einigen Minuten ab

 

FAQ: Abgehackte Sprache in Teams

Ab welchem Jitter wird Sprache in Teams abgehackt?

Eine feste Hörschwelle gibt es nicht, weil der Jitter-Puffer von Teams Schwankungen ausgleicht. Microsoft stuft einen Audiostream im CQD als schlecht ein, wenn der durchschnittliche Jitter über 30 ms liegt; der Konnektivitätstest erwartet für ein gesundes Netz Werte unter 30 ms. Kurze Spitzen können auch bei unauffälligem Durchschnitt hörbar sein.

Wie viel Paketverlust verträgt Teams?

Kleine Verluste verdeckt der Audio-Codec. Der Konnektivitätstest wertet unter 1 Prozent als bestanden, im CQD gilt ein Stream ab einer durchschnittlichen Verlustrate über 10 Prozent als schlecht. Dazwischen liegt eine Grauzone, in der es hörbar werden kann, ohne dass CQD Alarm schlägt.

Warum klingt es bei mir abgehackt, obwohl der Speedtest gut ist?

Ein Speedtest misst Bandbreite, nicht die Gleichmäßigkeit der Pakete. Teams-Audio braucht wenig Bandbreite, aber pünktliche Pakete. Jitter, Paketverlust und Latenz unter Last zeigt dir der Microsoft 365-Netzwerkkonnektivitätstest deutlich besser.

Wie erkenne ich, ob es am Headset liegt?

Wenn die Netzwerkwerte des Anrufs unauffällig sind, die Person aber überall und mit jedem Netz schlecht klingt, ist das Headset ein heißer Kandidat. Ein Test mit einem anderen, möglichst kabelgebundenen Modell bringt in wenigen Minuten Klarheit.

Ist ein einzelner schlechter Anruf schon ein Problem?

Nein. Mobilfunk im Zug, Hotel-WLAN oder ein überlastetes Netz beim Gegenüber erzeugen immer wieder einzelne schlechte Anrufe. Ein Problem ist es, wenn sich schlechte Streams bei einer Person, an einem Standort oder zu bestimmten Zeiten häufen.

Hilft es, das Video auszuschalten?

Manchmal, als Notlösung. Teams priorisiert Audio bei knapper Bandbreite ohnehin vor Video, aber auf einer überfüllten Leitung oder einem schwachen WLAN entlastet weniger Datenverkehr spürbar. Die Ursache behebt es nicht.

Kann ich die Ursache im Teams Admin Center allein finden?

Für einzelne Anrufe ja, die Anrufanalyse zeigt Netzwerte, Verbindungstyp, VPN und Geräte je Teilnehmer. Für Muster über Standorte und Zeiten brauchst du das CQD oder eine eigene Auswertung der Anrufdaten, wie sie Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl beschreibt.

Fazit: Erst eingrenzen, dann reparieren

Abgehackte Sprache ist kein Rätsel, sondern eine Rechenaufgabe mit drei Variablen. Jitter, Paketverlust und Roundtrip sagen dir, was kaputt ist; die Frage nach dem Kreis der Betroffenen sagt dir, wo. Eine Person: Headset, Rechner, WLAN, VPN. Ein Standort: Leitung, QoS, Medienweg. Nur Anrufe ins Telefonnetz: SBC und Provider. Wer diese Reihenfolge einhält, braucht für die meisten Fälle eine halbe Stunde und keine vier neuen Geräte.

Und wenn die Werte wieder grün sind, schau trotzdem einmal im Monat hin. Netze werden nicht von allein schlechter, aber irgendwer tauscht immer gerade einen Router, verlegt eine Datensicherung oder baut „provisorisch“ ein WLAN auf. Die Tickets kommen dann von ganz allein, meist mit dem Satz: „Du bist ganz abgehackt.“