Teams-Telefonie Probleme: die zehn häufigsten Ursachen

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Notruf, Sprachqualität und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Deine Teams-Telefonie läuft, aber keiner ist zufrieden? Wir gehen Rufweg, SBC und Netz gemeinsam mit dir durch. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die Wählplan, Voice Routing und SBC selbst sicher betreiben und Fehler eigenständig finden wollen. › Schulung Teams-Telefonie

 

Die Einführung ist gelaufen, das Projekt ist abgerechnet, die alte Telefonanlage steht im Keller und wartet auf den Wertstoffhof. Und trotzdem klingelt beim Helpdesk ständig das Telefon. Ironischerweise meist über Teams. „Ich kann nicht raus telefonieren.“ „Der Kunde sagt, ich klinge wie ein Roboter.“ „Bei uns in Köln geht’s, in Berlin nicht.“ „Die Zentrale legt einfach auf.“ Und der Klassiker: „Gestern ging’s noch.“

Wenn du an diesem Punkt bist, hast du keine Lust auf eine weitere Einführung in Teams Phone. Du willst wissen, warum es hakt. Die gute Nachricht: Teams-Telefonie Probleme sind selten originell. Nach vielen Projekten und noch mehr Nachsorge-Einsätzen landen fast alle Beschwerden bei denselben zehn Ursachen. Die schlechte Nachricht: Diese zehn Ursachen verteilen sich auf vier völlig unterschiedliche Bereiche, und wer im falschen Bereich sucht, kann tagelang Wählpläne umbauen, während eigentlich die Firewall UDP verschluckt.

Dieser Beitrag ist der Einstieg in eine ganze Reihe von Problemartikeln. Er sortiert die zehn häufigsten Ursachen in die vier Bereiche Netz, SBC/Routing, Konfiguration und Organisation, erklärt jede knapp, nennt den ersten Prüfschritt und verlinkt auf den Detailartikel, in dem du Diagnose und Behebung Schritt für Schritt findest. Grundlagen wiederholen wir hier nicht; wie Direct Routing aufgebaut ist, steht in Teams Direct Routing einrichten, was der Session Border Controller dabei leistet, in Teams SBC: Grundlagen des Session Border Controllers.

FAKTEN · Worum es hier geht Im Fokus steht Teams Phone mit Direct Routing, also mit eigenem Session Border Controller (SBC). Viele Ursachen, vor allem aus den Bereichen Netz, Konfiguration und Organisation, gelten genauso für Calling Plan und Operator Connect. Alle Beispiele nutzen den erfundenen Tenant Contoso mit Standorten in Frankfurt, Köln, Berlin, Hamburg und München, Rufnummern im Muster +49 69 555 0100 und SBCs wie sbc1.contoso.com. Alle PowerShell-Befehle in diesem Beitrag sind lesend. Sie stammen aus dem Modul MicrosoftTeams und ändern nichts an deinem Tenant.

 

Die Ampel: vier Bereiche, zehn Verdächtige

Bevor du irgendeine Einstellung anfasst, ordne das Symptom einem Bereich zu. Das klingt banal, ist aber der wichtigste Schritt überhaupt. Ein Anruf, der nicht rausgeht, hat eine völlig andere Fehlerklasse als ein Anruf, der zwar rausgeht, aber wie aus dem Bergwerk klingt. Und eine Warteschlange, die auflegt, ist meist überhaupt kein technischer Defekt, sondern eine Einstellung, die jemand mit besten Absichten so gewählt hat.

Die vier Bereiche im Überblick:

Netz: alles zwischen Endgerät und Microsoft-Cloud sowie zwischen SBC und Cloud. Paketverlust, Jitter, Medien über TCP statt UDP, VPN ohne Split Tunneling, schlecht gepflegte Netzwerkstandorte. Symptom: Es klingt schlecht oder bricht ab.

SBC/Routing: die Kette von der Voice Routing Policy bis zum Provider. Fehlende oder überdeckte Routen, inaktive SBCs, Zertifikatsprobleme, Medienports. Symptom: Der Anruf kommt gar nicht zustande, meist für viele Benutzer gleichzeitig.

Konfiguration: das Benutzerobjekt und seine Richtlinien. Wählplan, Normalisierungsregeln, Lizenz, Rufnummer, Caller ID. Symptom: Einzelne Benutzer oder einzelne Nummernmuster sind betroffen.

Organisation: Anrufflüsse, Zuständigkeiten, Pflege. Warteschlangen, Auto Attendants, Notrufadressen, Rufnummernverwaltung, Änderungen ohne Dokumentation. Symptom: Anrufer landen im Nichts, und niemand weiß, wer das eingestellt hat.

Symptom, Ursache, erster Prüfschritt

Die folgende Tabelle ist die Kurzfassung des ganzen Beitrags. Druck sie aus und häng sie neben den Helpdesk-Bildschirm. Sie ersetzt keine Diagnose, aber sie verhindert, dass du bei „Kunde hört mich nicht“ als Erstes den Wählplan umbaust.

Symptom	Wahrscheinliche Ursache	Erster Prüfschritt
„Ich klinge wie ein Roboter“, abgehackte Sprache	Nr. 1: Paketverlust und Jitter, oft WLAN oder fehlendes QoS	Anrufanalyse des Benutzers im Teams Admin Center, Netzwerkwerte des betroffenen Anrufs
Schlechte Qualität nur im Homeoffice oder unterwegs	Nr. 2: Medien über TCP oder durch den VPN-Tunnel	Transportprotokoll in der Anrufanalyse, Split-Tunnel-Konfiguration des VPN-Clients
Nur ein Standort ist auffällig, Notruf zeigt falsche Adresse	Nr. 3: Netzwerkstandorte und Subnetze fehlen oder sind falsch	Get-CsTenantNetworkSubnet gegen die tatsächlichen Subnetze abgleichen
„Anruf geht nicht raus“, bestimmte Ziele unerreichbar	Nr. 4: Rufweg-Kette bricht bei Usage oder Voice Route	Normalisierte Nummer gegen die Muster der Voice Routes der effektiven Policy prüfen
Niemand kann raus telefonieren, SIP 408 oder 504	Nr. 5: SBC inaktiv, OPTIONS fehlen, Zertifikat oder Root-CA	Status des SBC im Teams Admin Center, Get-CsOnlinePSTNGateway, SBC-Protokoll
Verbindung steht, aber eine Seite hört nichts	Nr. 6: Medienports, NAT oder Codec am SBC	Firewall-Regeln für die Medienports, öffentliche IP im SDP des SBC
Bestimmte Nummern landen falsch, 112 geht nicht an die Leitstelle	Nr. 7: Normalisierungsregeln in falscher Reihenfolge, Amtsholung	Test-CsEffectiveTenantDialPlan mit der gewählten Nummer
Einzelner Benutzer kann nicht telefonieren, Wählfeld fehlt	Nr. 8: Lizenz, Rufnummer, Richtlinie fehlt, Rückfall auf Global	Get-CsOnlineUser und Get-CsUserPolicyAssignment für diesen Benutzer
„Die Zentrale legt einfach auf“, Anrufer landen im Nichts	Nr. 9: Überlauf, Timeout oder Ziele in Warteschlange und Auto Attendant	Get-CsCallQueue: Schwellen und Aktionen für Überlauf und Timeout
Notrufadresse fehlt, Nummer doppelt, „gestern ging’s noch“	Nr. 10: Fehlende Pflege, Drift, keine Zuständigkeit	Letzte Änderungen nachvollziehen, Notrufadressen und Nummernzuweisungen prüfen

 

Bereich Netz: wenn es klingt wie ein Anruf aus dem Bergwerk

Netzprobleme haben eine gemeine Eigenschaft: Der Anruf funktioniert. Er klingt nur furchtbar, bricht ab oder hat Aussetzer, die genau dann kommen, wenn der Kunde die Auftragsnummer diktiert. Deshalb landen Netzprobleme oft erst spät beim richtigen Team, weil zuerst alle Beteiligten über das Headset diskutieren.

Ursache 1: Paketverlust, Jitter und Roundtrip

Symptom

„Ich verstehe nur jedes dritte Wort.“ „Der Kunde sagt, ich klinge blechern.“ Meist betrifft es bestimmte Benutzer, bestimmte Etagen oder bestimmte Tageszeiten, gern die Mittagspause, wenn im selben WLAN zwanzig Leute Videos streamen.

Wie es technisch entsteht

Sprache ist Echtzeit. Ein verlorenes Paket kommt nicht wieder, ein zu spät angekommenes ist so nützlich wie ein verlorenes. Teams gleicht viel aus, aber nicht alles. Typische Auslöser sind überlastete WLAN-Zellen im 2,4-GHz-Band, fehlendes QoS auf Engpassstrecken, ausgelastete Internetanschlüsse an kleinen Standorten und Sicherheitsgeräte, die jedes UDP-Paket einzeln inspizieren. Das Call Quality Dashboard (CQD) bewertet einen Audiostream unter anderem dann als schlecht, wenn der Jitter 30 Millisekunden oder die Paketverlustrate 10 Prozent überschreitet. Das sind keine Zielwerte, sondern die Grenze, ab der es auch Microsoft offiziell schlecht nennt.

Erster Prüfschritt

Im Teams Admin Center unter Benutzer den betroffenen Benutzer öffnen und im Anrufverlauf den konkreten Anruf mit der Anrufanalyse ansehen. Dort siehst du je Teilstrecke Paketverlust, Jitter und Roundtrip sowie Netzwerktyp (WLAN oder Kabel). Häufen sich schlechte Anrufe an einem Standort, ist das CQD mit Auswertung nach Subnetz das bessere Werkzeug.

WEITERLESEN · Diagnose und Behebung im Detail › Abgehackte Sprache in Teams: Jitter, Paketverlust und Roundtrip › Sprachqualität in Teams: QoS, CQD und Troubleshooting

 

Ursache 2: Medien über TCP statt UDP, VPN ohne Split Tunneling

Symptom

„Im Büro geht’s, im Homeoffice nicht.“ „Seit wir die neue Firewall haben, ist es schlechter.“ Gesprochen wird zeitversetzt, Gesprächspartner fallen sich ständig ins Wort.

Wie es technisch entsteht

Teams überträgt Medien bevorzugt per UDP. Ist UDP blockiert, weicht der Client auf TCP oder einen Relay-Pfad aus. Das funktioniert, aber TCP wiederholt verlorene Pakete und wartet auf deren Bestätigung, was bei Echtzeitsprache Verzögerung und Aussetzer erzeugt. Noch beliebter ist der VPN-Tunnel: Alle Medien laufen erst ins Rechenzentrum, dann ins Internet und zurück. Microsoft empfiehlt ausdrücklich, Teams-Verkehr per Split Tunneling am VPN vorbeizuführen, weil VPNs in der Regel nicht für Echtzeitmedien ausgelegt sind, manche UDP gar nicht unterstützen und eine zusätzliche Verschlüsselung über ohnehin verschlüsselte Medien legen.

Erster Prüfschritt

In der Anrufanalyse des betroffenen Anrufs das Transportprotokoll prüfen. Steht dort TCP, ist die Ursache fast immer eine Firewall- oder Proxy-Regel, die die UDP-Ports 3478 bis 3481 Richtung Microsoft nicht durchlässt, oder ein VPN-Profil ohne Ausnahmen für die Teams-Medienadressen.

WEITERLESEN · Diagnose und Behebung im Detail › Teams-Telefonie über TCP statt UDP: warum das schlecht klingt › Teams-Telefonie über VPN: Split Tunneling richtig einrichten

 

Ursache 3: Netzwerkstandorte und Subnetze nicht gepflegt

Symptom

„In Berlin klingt es schlechter als überall sonst.“ „Beim Notruf-Test kam die Adresse aus Frankfurt, obwohl ich in Hamburg sitze.“ Oder: Media Bypass ist eingerichtet, aber die Medien laufen trotzdem über Umwege.

Wie es technisch entsteht

Teams erkennt den Standort eines Clients anhand der Netzwerktopologie, die du im Teams Admin Center pflegst: Netzwerkregionen, Netzwerkstandorte, Subnetze und vertrauenswürdige öffentliche IP-Adressen. Davon hängen dynamischer Notruf, standortbasiertes Routing und Local Media Optimization ab. Kommt ein neues Subnetz hinzu, etwa weil die Netzwerkabteilung in Berlin das WLAN neu aufgeteilt hat, und niemand pflegt es in Teams nach, fällt der Client ins Ungewisse: falsche oder keine Notrufadresse, Medien über einen anderen Standort (Hairpinning), unnötige Umwege.

Erster Prüfschritt

Get-CsTenantNetworkSite | Format-Table Identity, NetworkRegionID, EnableLocationBasedRouting Get-CsTenantNetworkSubnet | Format-Table SubnetID, MaskBits, NetworkSiteID Get-CsTenantTrustedIPAddress | Format-Table IPAddress, MaskBits

 

Die Ausgabe gleichst du mit der Subnetzliste der Netzwerkabteilung ab. Jedes Subnetz, in dem Telefonie-Clients unterwegs sind, gehört genau einem Netzwerkstandort zugeordnet. Für Grundlagen zu Media Bypass und Local Media Optimization lies Teams Media Bypass und Local Media Optimization.

WEITERLESEN · Diagnose und Behebung im Detail › Netzwerkstandorte und Subnetze in Teams richtig pflegen › Hairpinning in Teams: wenn Anrufe Umwege über andere Standorte nehmen › Dynamischer Notruf in Teams funktioniert nicht

 

Bereich SBC/Routing: wenn der Anruf gar nicht erst rausgeht

Hier wird es binär. Entweder der Anruf kommt zustande oder nicht. Das macht die Diagnose einerseits leichter, andererseits nervöser, denn ein Fehler auf dieser Ebene trifft selten nur einen Benutzer. Wenn ein SBC ausfällt, telefoniert ein ganzer Standort plötzlich nur noch intern, und das Management erinnert sich lebhaft an die alte Anlage, die „nie Probleme gemacht hat“. Die alte Anlage, die im Keller wartet.

Um zu verstehen, wo ein abgehender Anruf hängenbleibt, musst du die Kette kennen, die Teams für jeden Anruf abarbeitet: Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC › Provider. Jede Station kann den Anruf beenden, und jede Station hat ihre Lieblingsfehler.

Ursache 4: Die Rufweg-Kette bricht bei Usage oder Voice Route

Symptom

„Ich komme nicht ins Ausland.“ „Handynummern gehen, Festnetz in München nicht.“ „Bei meinem Kollegen geht’s, bei mir nicht.“ Teams zeigt typischerweise an, dass der Anruf nicht durchgestellt werden konnte, und das Gespräch endet, bevor es klingelt.

Wie es technisch entsteht

Die Voice Routing Policy des Benutzers enthält eine geordnete Liste von PSTN Usages. Teams geht diese Liste in der festgelegten Reihenfolge durch und sucht in den Voice Routes, die zur jeweiligen Usage gehören, nach einer Route, deren Zahlenmuster auf die normalisierte Nummer passt. Innerhalb einer Usage entscheidet die Priorität der Routen. Die erste passende Route gewinnt, und die SBCs dieser Route werden versucht. Typische Bruchstellen:

Die Usage, die die passende Route enthält, fehlt in der Policy des Benutzers.

Das Regex-Muster der Route ist zu eng, zum Beispiel ^\+49(69|221)\d+$ für Frankfurt und Köln, und München mit +4989 bleibt draußen.

Eine Route mit höherer Priorität überdeckt die eigentlich gewünschte, etwa eine alte Testroute auf einen abgeschalteten SBC.

Die Route verweist auf einen SBC, der deaktiviert oder gelöscht ist.

Erster Prüfschritt

Get-CsOnlineVoiceRoutingPolicy -Identity "VRP-Frankfurt" | Select-Object -ExpandProperty OnlinePstnUsages Get-CsOnlineVoiceRoute | Sort-Object Priority | Format-Table Identity, Priority, NumberPattern, OnlinePstnUsages, OnlinePstnGatewayList

 

Nimm die normalisierte Nummer aus Ursache 7 und prüfe sie gegen jedes Muster in genau der Reihenfolge, in der Teams sie prüfen würde. Ein sauberes, nicht zu enges Muster für deutsche Ziele ist etwa ^\+49[1-9]\d+$, also +49 gefolgt von einer Vorwahl ohne führende Null.

WEITERLESEN · Diagnose und Behebung im Detail › Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen › Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen › Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen

 

Ursache 5: SBC inaktiv, Zertifikat oder Root-CA veraltet

Symptom

„Seit heute früh kann keiner mehr raus telefonieren.“ Im Teams Admin Center ist der SBC als nicht verbunden oder mit Warnungen markiert, in den Protokollen des SBC tauchen TLS-Fehler auf, die Anrufanalyse zeigt SIP 408 oder 504. Gern am Montag nach einem Wochenende, an dem irgendwo ein Zertifikat getauscht wurde.

Wie es technisch entsteht

Direct Routing überwacht die SBCs über SIP-OPTIONS-Nachrichten, die der SBC zu den Microsoft-Endpunkten sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com und sip3.pstnhub.microsoft.com schickt. Laut Microsoft gilt ein SBC als gesund, wenn er in den letzten drei Minuten OPTIONS gesendet hat; das reguläre Intervall ist eine Minute. Fehlen sie, wird der SBC herabgestuft und bei der Routenauswahl nicht mehr zuerst versucht. Die Verbindung selbst ist gegenseitig per TLS abgesichert (mTLS), und dabei muss der SBC dem Zertifikat von Microsoft vertrauen.

Genau hier hat Microsoft in den letzten Jahren mehrfach umgestellt. Die aktuelle Liste der Stammzertifizierungsstellen, denen der SBC vertrauen muss, umfasst sieben Einträge: DigiCert Global Root CA, DigiCert Global Root G2, DigiCert Global Root G3, DigiCert TLS ECC P384 Root G5, DigiCert TLS RSA 4096 Root G5, Microsoft ECC Root Certificate Authority 2017 und Microsoft RSA Root Certificate Authority 2017. Die Zertifikate der neuen Zertifizierungsstelle sind laut Microsoft seit Ende Juli 2026 produktiv. Ein SBC, dem einer dieser Einträge fehlt, kann je nach Verbindung mal funktionieren und mal nicht. Das ist die unangenehmste Variante, weil sie wie ein Zufall aussieht.

AUS DER PRAXIS · Mein eigener SBC Auch in meinem eigenen Netz läuft ein anynode-SBC gegen Teams. Seit den Root-CA-Umstellungen gehört der Blick in die Liste der vertrauenswürdigen Zertifizierungsstellen bei mir zu jedem Firmware-Update dazu, zusammen mit einem kurzen Testanruf über jeden Microsoft-Endpunkt. Das kostet zehn Minuten. Ein Montagmorgen ohne Amtsleitung kostet deutlich mehr Nerven.

 

Erster Prüfschritt

Get-CsOnlinePSTNGateway | Format-Table Identity, Enabled, SipSignalingPort, MediaBypass, MaxConcurrentSessions

 

Dazu im Teams Admin Center unter Sprache den Bereich Direct Routing öffnen: Dort steht je SBC der Verbindungsstatus samt Hinweisen zu TLS-Verbindung und OPTIONS. Den eigentlichen Grund liefert fast immer das Protokoll des SBC selbst, denn Fehler bei TLS-Aufbau oder abgelehnten INVITEs sieht die Anrufanalyse von Microsoft gar nicht erst.

WARNUNG · Herabgestuft ist nicht abgeschaltet Ein herabgestufter SBC wird nicht sofort aus dem Routing genommen. Microsoft beschreibt, dass der herabgestufte SBC zuletzt erneut versucht wird, bevor der Anruf mit einem Fehler endet. Wenn ein SBC halb tot ist, werden Anrufe deshalb nicht sauber abgewiesen, sondern laufen erst einmal in Zeitüberschreitungen. Für Anwender sieht das aus wie „Teams hängt“.

 

WEITERLESEN · Diagnose und Behebung im Detail › Teams SBC inaktiv: OPTIONS-Ping und Verbindungsstatus prüfen › SIP 504 nach dem Zertifikatswechsel: Root-CAs am SBC aktualisieren › SBC-Failover in Teams funktioniert nicht › SIP-Fehlercodes in Teams Direct Routing verstehen

 

Ursache 6: Einseitiges Audio und Abbrüche nach einigen Minuten

Symptom

„Ich höre den Kunden, er mich nicht.“ „Nach genau ein paar Minuten ist das Gespräch weg.“ Signalisierung funktioniert, der Anruf baut sich auf, aber der Ton bleibt einseitig oder die Verbindung reißt nach einer festen Zeit ab.

Wie es technisch entsteht

Signalisierung und Medien laufen getrennt. Für Medien zwischen SBC und Microsoft-Medienprozessoren nennt Microsoft UDP/SRTP auf den Ports 3478 bis 3481 und 49152 bis 53247, in beide Richtungen und für die vollständigen Microsoft-Adressbereiche. Fehlt eine Richtung in der Firewall oder trägt der SBC hinter NAT seine interne statt seiner öffentlichen Adresse in die Medienbeschreibung ein, kommt Ton nur in eine Richtung an. Abbrüche nach fester Zeit deuten eher auf die Signalisierung: Sitzungsaktualisierungen, die unterwegs verloren gehen, oder Firewalls, die Zustände zu früh vergessen. Microsoft weist ausdrücklich darauf hin, dass die Firewall NAT-Zuordnungen für UDP nicht während einer Sitzung ändern sollte.

Erster Prüfschritt

Im SBC-Protokoll einen betroffenen Anruf öffnen und die Medienadressen im SDP prüfen. Danach die Firewall-Regeln Richtung 52.112.0.0/14 und 52.120.0.0/14 mit der Liste aus der Microsoft-Dokumentation abgleichen. Bei Abbrüchen den Zeitpunkt messen: Ein exakt wiederkehrendes Intervall ist fast nie Zufall.

WEITERLESEN · Diagnose und Behebung im Detail › Einseitiges Audio oder kein Ton bei Teams Direct Routing › Teams-Anruf bricht nach einigen Minuten ab

 

Bereich Konfiguration: Wählplan, Normalisierung und Benutzerobjekt

Konfigurationsfehler erkennst du daran, dass sie selektiv sind. Ein Benutzer ja, der andere nicht. Eine Nummer ja, die andere nicht. Das ist eigentlich eine gute Nachricht, denn selektive Fehler lassen sich vergleichen: Was hat der Benutzer, bei dem es geht, was der andere nicht hat?

Ursache 7: Wählplan und Normalisierungsregeln in falscher Reihenfolge

Symptom

„Wenn ich mit der Null vorne wähle, geht’s nicht.“ „Die Kurzwahl 100 klingelt beim Empfang, aber die 112 auch.“ Der zweite Satz ist kein Witz, sondern der Grund, warum dieser Abschnitt den Notruf so ernst nimmt.

Wie es technisch entsteht

Der Wählplan übersetzt, was der Benutzer tippt, in eine E.164-Nummer, bevor das Routing überhaupt beginnt. Er besteht aus Normalisierungsregeln, also Paaren aus Regex-Muster und Übersetzung, die von oben nach unten geprüft werden. Die erste passende Regel gewinnt. Wer dreistellige Durchwahlen auf +49 69 5550 abbildet, erwischt mit ^(\d{3})$ auch 110 und 112, wenn die Notrufregel darunter steht. Dasselbe Spiel mit Amtsholung: Gewöhnte Anwender tippen 0 vor jede externe Nummer, also 00 89 555 98 76 für München oder 0112 für den Notruf. Eine Regel wie ^0([1-9]\d+)$ übersetzt dann aus 0112 brav +4969112, eine Ortsnummer in Frankfurt, die es so nicht gibt.

Ein Wählplan mit Amtsholung 0 für Frankfurt braucht deshalb eine Notrufregel ganz oben, die beide Varianten abfängt und unverändert lässt, und erst darunter die übrigen Regeln:

Reihenfolge	Name	Muster (.NET-Regex)	Übersetzung	Beispiel
1	Notruf	^0?(110|112)$	$1	0112 wird 112
2	Durchwahl	^(\d{3})$	+49695550$1	100 wird +49695550100
3	Amt-0 international	^000([1-9]\d+)$	+$1	000 33 1 … wird +331…
4	Amt-0 national	^00([1-9]\d+)$	+49$1	00895559876 wird +49895559876
5	Amt-0 Ortsnetz	^0([1-9]\d+)$	+4969$1	05559876 wird +49695559876

 

Die Reihenfolge ist hier kein Detail, sondern die halbe Logik: Regel 3 muss vor Regel 4 stehen, Regel 4 vor Regel 5, sonst schnappt sich die allgemeinere Regel die speziellere Nummer. Leerzeichen tippt in Teams niemand, sie stehen hier nur zur Lesbarkeit.

Erster Prüfschritt

Get-CsEffectiveTenantDialPlan -Identity sabine.hoffmann@contoso.com | Test-CsEffectiveTenantDialPlan -DialedNumber "0112" Get-CsEffectiveTenantDialPlan -Identity sabine.hoffmann@contoso.com | Test-CsEffectiveTenantDialPlan -DialedNumber "00895559876"

 

Die Ausgabe zeigt die übersetzte Nummer und die Regel, die gegriffen hat. Teste immer mindestens 110, 112, 0110, 0112, eine Durchwahl, eine Ortsnummer, eine nationale Nummer, eine Mobilnummer und eine internationale Nummer. Wie der Notruf danach geroutet wird, steht in Notruf in Microsoft Teams konfigurieren.

WARNUNG · Notruf nie in Produktion „mal eben“ testen Ein Testanruf an 112 landet bei einer echten Leitstelle. Prüfe Normalisierung und Routing zuerst lesend mit Test-CsEffectiveTenantDialPlan und gegen die Muster deiner Routen. Wenn du einen echten Test brauchst, stimme ihn vorher mit der zuständigen Leitstelle ab. › Notruf in Teams testen, ohne die Leitstelle zu verärgern

 

WEITERLESEN · Diagnose und Behebung im Detail › Normalisierungsregeln in Teams: typische Fehler und wie du sie findest › Wählplan mit Amtsholung 0 in Teams richtig bauen

 

Ursache 8: Benutzerobjekt unvollständig, Rückfall auf die globale Richtlinie

Symptom

„Bei mir fehlt die Wähltastatur.“ „Ich kann intern telefonieren, aber nicht raus.“ „Beim Angerufenen erscheint die Zentrale statt meiner Durchwahl.“ Fast immer ein einzelner Benutzer, oft einer, der neu ist oder gerade den Standort gewechselt hat.

Wie es technisch entsteht

Damit ein Benutzer über Direct Routing telefonieren kann, braucht er eine Teams-Phone-Lizenz, eine zugewiesene Rufnummer vom Typ Direct Routing, aktiviertes Enterprise Voice und eine Voice Routing Policy mit passenden Usages. Fehlt eine dieser Zutaten, fehlt die Wähltastatur oder der Anruf scheitert. Besonders tückisch ist die Richtlinienvererbung: Ist einem Benutzer weder direkt noch über eine Gruppe eine Richtlinie zugewiesen, gilt die globale Richtlinie der Organisation. Steht dort nichts Sinnvolles, etwa eine leere Voice Routing Policy, telefoniert der Benutzer intern weiter und wundert sich über den Rest. Direkte Zuweisung schlägt Gruppenzuweisung, und bei mehreren Gruppen entscheidet der Rang der Gruppenzuweisung. Dasselbe gilt für die Caller ID Policy, die bestimmt, welche Nummer der Angerufene sieht, sofern der SBC sie nicht nachträglich überschreibt.

Erster Prüfschritt

Get-CsOnlineUser -Identity julia.wagner@contoso.com | Select-Object DisplayName, LineUri, EnterpriseVoiceEnabled, FeatureTypes, OnlineVoiceRoutingPolicy, TenantDialPlan, CallingLineIdentity Get-CsUserPolicyAssignment -Identity julia.wagner@contoso.com -PolicyType OnlineVoiceRoutingPolicy | Select-Object -ExpandProperty PolicySource Get-CsPhoneNumberAssignment -TelephoneNumber "+496955500142"

 

Ein leeres Feld bei OnlineVoiceRoutingPolicy bedeutet nicht „keine Richtlinie“, sondern „globale Richtlinie“. Der Unterschied ist genau das, was dir im Helpdesk-Ticket später niemand glaubt. Get-CsPhoneNumberAssignment zeigt zusätzlich, ob eine Nummer womöglich an einem anderen Objekt hängt, etwa an einem Ressourcenkonto.

WEITERLESEN · Diagnose und Behebung im Detail › Teams-Benutzer fällt auf die globale Richtlinie zurück › Kein Wählfeld in Teams: Lizenz, Rufnummer und Enterprise Voice prüfen › Rufnummernanzeige in Teams falsch: CLIP, Caller ID Policy und SBC › Rufnummer in Teams doppelt vergeben

 

Bereich Organisation: Warteschlangen, Notruf und niemand ist zuständig

Der vierte Bereich ist der, den Projektpläne am liebsten übersehen. Technisch ist alles korrekt, die Ampel für Netz und Routing ist grün, und trotzdem sind die Anrufer unzufrieden. Weil die Warteschlange nach zwei Minuten auflegt. Weil der Auto Attendant nach 18 Uhr auf eine Gruppe verweist, die es nicht mehr gibt. Weil der Notruf am neuen Standort ohne Adresse rausgeht. Und weil niemand weiß, wer das eigentlich pflegt.

Ursache 9: Warteschlange und Auto Attendant schicken Anrufer ins Nichts

Symptom

„Ich habe zehn Minuten Musik gehört und dann war die Leitung tot.“ „Wenn ich die Zentrale anrufe, klingelt es kurz und dann tutet es.“ Interne Anwender merken davon nichts, sie rufen ja nicht die eigene Zentrale an. Es melden sich Kunden, und zwar über andere Kanäle.

Wie es technisch entsteht

Eine Anrufwarteschleife in Teams hat zwei Schwellen: die maximale Anzahl wartender Anrufe (Überlauf) und die maximale Wartezeit (Timeout). Laut Microsoft liegt der Standard für die maximale Anzahl bei 50, einstellbar von 0 bis 200; die maximale Wartezeit lässt sich von 0 Sekunden bis 45 Minuten einstellen. Für beide Fälle gibt es als Aktion Trennen oder Umleiten, etwa an eine Person, ein anderes Sprachanwendungsziel, eine externe Nummer oder eine gemeinsame Voicemail. Wer hier Trennen stehen lässt, baut eine Warteschlange, die nach Ablauf der Zeit höflich auflegt. Beim Auto Attendant kommen veraltete Ziele, falsche Feiertags- und Geschäftszeiten sowie Weiterleitungsschleifen zwischen Auto Attendant und Warteschlange hinzu.

Einstellung	Laut Microsoft	Typischer Fehler
Maximale Anrufe in der Warteschlange	Standard 50, Bereich 0 bis 200	Auf 0 gesetzt: Laut Doku kann dann nicht einmal die Begrüßung abgespielt werden
Aktion bei Überlauf	Trennen oder Umleiten	Trennen ohne Ansage, Anrufer hören nur noch Besetzt oder Stille
Maximale Wartezeit	0 Sekunden bis 45 Minuten	Kürzer als die Wartemusik, Rückruf-Funktion greift nie
Aktion bei Timeout	Trennen oder Umleiten	Umleiten auf ein Ziel, das es nicht mehr gibt, oder zurück in den Auto Attendant

 

Erster Prüfschritt

Get-CsCallQueue -NameFilter "Zentrale" | Select-Object Name, OverflowThreshold, OverflowAction, TimeoutThreshold, TimeoutAction Get-CsAutoAttendant -NameFilter "Empfang" | Select-Object Name, DefaultCallFlow, CallHandlingAssociations

 

WEITERLESEN · Diagnose und Behebung im Detail › Teams-Warteschlange legt auf: Überlauf und Timeout richtig einstellen › Teams Auto Attendant: wenn Anrufer im Nirwana landen › Eingehende Anrufe kommen in Teams nicht an

 

Ursache 10: Notrufadressen, Nummernpflege und Drift ohne Zuständigkeit

Symptom

„Gestern ging’s noch.“ Dieser Satz ist das Leitmotiv von Ursache 10. Dazu kommen Funde, die erst bei einer Prüfung auffallen: ein Standort ohne Notrufadresse, eine Rufnummer an zwei Objekten, eine Voice Route mit dem Namen „Test-alt-nicht-löschen“.

Wie es technisch entsteht

Nach der Einführung ändert sich die Organisation weiter, die Telefonie-Konfiguration aber nur, wenn jemand daran denkt. Neue Standorte bekommen Subnetze, aber keine Notrufadresse. Ein Admin legt kurz eine Testroute an und vergisst sie. Ein anderer ändert eine Richtlinie im Teams Admin Center, ein dritter überschreibt sie per Skript. Jede einzelne Änderung ist harmlos. In Summe entsteht Drift: Der Tenant entfernt sich still vom dokumentierten Soll, bis eines Tages ein Anruf genau durch die Lücke fällt. Beim Notruf ist das kein Komfortproblem. Fehlt die Notrufadresse oder wird der Standort nicht erkannt, kann die Leitstelle den Anrufer im Zweifel nicht ohne Nachfrage lokalisieren.

Erster Prüfschritt

Get-CsOnlineLisLocation | Format-Table City, StreetName, HouseNumber, Description, LocationId Get-CsTeamsEmergencyCallRoutingPolicy | Format-Table Identity, AllowEnhancedEmergencyServices Get-CsOnlineVoiceRoute | Where-Object { $_.Identity -match 'test|alt|old' }

 

Wichtiger als jeder Befehl ist hier die Frage, wer verantwortlich ist. Ohne benannte Zuständigkeit für Wählpläne, Routen, Notrufadressen und Anrufflüsse kommt Ursache 10 zuverlässig wieder. Wie du das organisatorisch festzurrst, beschreibt Microsoft Teams Telefonie-Governance.

WEITERLESEN · Diagnose und Behebung im Detail › Notrufadresse fehlt in Teams: was bei 112 wirklich passiert › Konfigurationsdrift in der Teams-Telefonie erkennen › Rufnummer in Teams doppelt vergeben

 

Diagnose, Behebung und Vorbeugung in der richtigen Reihenfolge

Zehn Ursachen sind zehn Möglichkeiten, an der falschen Stelle anzufangen. Deshalb lohnt eine feste Reihenfolge, auch wenn der Druck vom Vorstand groß ist. Gerade dann.

Schritt für Schritt eingrenzen

Fakten sammeln. Wer ist betroffen, seit wann, von welchem Standort und Netz, welche Nummer wurde gewählt, welches Gerät. Ein konkreter Anruf mit Uhrzeit ist mehr wert als zehn Beschwerden der Sorte „geht immer schlecht“. Wie du aus den Anrufprotokollen belastbare Muster statt Einzelfälle gewinnst, zeigt der Weiterlesen-Kasten am Ende dieser Liste.

Bereich bestimmen. Kommt der Anruf nicht zustande, geht es um SBC/Routing oder Konfiguration. Klingt er schlecht, um das Netz. Sind Anrufer statt Benutzer betroffen, um die Organisation.

Lesend prüfen. Erst mit den Get- und Test-Cmdlets aus diesem Beitrag und den Ansichten im Teams Admin Center: Anrufanalyse, Direct-Routing-Status des SBC, Bericht zur PSTN-Nutzung bei Direct Routing. Nichts ändern, bevor die Ursache feststeht.

SBC-Protokoll einbeziehen. Bei allem, was SIP, TLS oder Medien betrifft. Microsoft weist selbst darauf hin, dass die Anrufanalyse nur Fehler zeigt, die die Direct-Routing-Komponenten in der Cloud erreicht haben.

Eine Änderung, ein Test. Nie drei Dinge gleichzeitig umbauen. Sonst weißt du hinterher nicht, welches geholfen hat, und vor allem nicht, welches das nächste Problem verursacht.

WEITERLESEN · Muster statt Einzelfälle › Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl › SIP-Fehlercodes in Teams Direct Routing verstehen

 

Behebung mit Rückweg

Jede Korrektur an Wählplan, Route oder Richtlinie verändert den Rufweg für alle, die daran hängen. Sichere deshalb vor jeder Änderung den Ist-Zustand des betroffenen Objekts. Das geht lesend und kostet eine Zeile:

Get-CsTenantDialPlan -Identity "DP-Frankfurt" | Export-Clixml .\DP-Frankfurt_vorher.xml Get-CsOnlineVoiceRoute | Export-Clixml .\VoiceRoutes_vorher.xml Get-CsCallQueue -NameFilter "Zentrale" | Export-Clixml .\CQ-Zentrale_vorher.xml

 

WICHTIG · Rollback heißt: Du weißt vorher, wie du zurückkommst Exportiere den Ist-Zustand, notiere die geplante Änderung mit Uhrzeit und teste direkt danach mit denselben Nummern wie vorher, insbesondere 110 und 112. Geht etwas schief, stellst du anhand des Exports den alten Zustand wieder her, statt aus dem Gedächtnis zu rekonstruieren. Plane Änderungen an Routing und Normalisierung außerhalb der Hauptgeschäftszeit und informiere den Helpdesk vorher.

 

Die Ampel als Werkzeug

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Die Ampel aus diesem Beitrag ist kein Zufall: Der Teams-Telefonie Diagnostiker bildet genau diese vier Bereiche ab. Auf der Übersicht steht je Bereich Netz, SBC/Routing, Konfiguration und Organisation eine Ampel mit der Zahl der kritischen, mittleren und niedrigen Befunde. Darunter folgen die wichtigsten Befunde mit Prüffall-Kennung und Zahl der betroffenen Benutzer. Von dort gehst du in die Tiefe: Jeder Befund hat einen Prüffall mit Beschreibung, Empfehlung und den betroffenen Objekten. Der Rufweg-Simulator zeigt für einen Benutzer und eine gewählte Nummer die Kette vom Wählplan über die Normalisierung bis zur Voice Route und zum Gateway und markiert die Station, an der ein Anruf scheitert. Die Routing-Landkarte stellt Policies, PSTN Usages, Voice Routes und Gateways nebeneinander. Für den Bereich Netz gibt es die Ansicht Anrufqualität mit Standortauswertung und die SIP-Fehlercodes je Gateway. Der Benutzer-Steckbrief zeigt die effektiven Richtlinien eines Benutzers, einschließlich der Frage, ob er auf die globale Richtlinie zurückfällt. Für den Betrieb danach erzeugst du einen Bericht als Word- und Excel-Datei, die Drift-Erkennung meldet Abweichungen gegenüber einem früheren Stand, und die Assistenten für Wählpläne und Routing helfen beim sauberen Neuaufbau einzelner Standorte. Der Teams-Telefonie Diagnostiker lässt sich 15 Tage kostenlos testen. › Teams-Telefonie Diagnostiker

 

Die folgenden zwei Ansichten zeigen dieselbe Übersicht vor und nach einer Sanierung, jeweils mit erfundenen Daten des Demo-Tenants Contoso.

Vorbeugung: damit „gestern ging’s noch“ seltener wird

Testkatalog festlegen. Eine feste Liste von Testnummern je Standort, inklusive 110 und 112 im lesenden Test, Durchwahl, Ortsnetz, national, mobil, international. Nach jeder Änderung einmal durchlaufen lassen.

SBC-Wartung planen. Firmware, Zertifikat und Liste der vertrauenswürdigen Stammzertifizierungsstellen gehören in denselben Wartungsplan. Die Microsoft-Seite zu Neuerungen bei Direct Routing regelmäßig lesen.

Netztopologie pflegen. Neue Subnetze werden nicht nur im Netzwerk, sondern auch in Teams angelegt. Am besten als Pflichtschritt im Change-Prozess der Netzwerkabteilung.

Richtlinien explizit zuweisen. Verlasse dich nicht auf die globale Richtlinie, sondern gestalte sie so, dass ein Rückfall harmlos ist, und weise produktive Richtlinien gezielt zu.

Anrufflüsse regelmäßig anrufen. Einmal im Monat die Hauptnummer jedes Standorts von außen anrufen, auch außerhalb der Geschäftszeit. Klingt banal. Findet aber zuverlässig Warteschlangen, die ins Leere führen.

Zuständigkeit benennen. Pro Bereich eine verantwortliche Person mit Vertretung. Telefonie ohne Eigentümer verwahrlost schneller, als du „Konfigurationsdrift“ sagen kannst.

Wenn du merkst, dass die Liste der offenen Punkte länger ist als die Geduld der Anwender, hilft ein strukturierter Neustart. Den beschreibt Teams-Telefonie nach der Einführung retten: ein Plan in fünf Schritten. Wer die Grundsatzfragen noch einmal sauber aufsetzen will, findet im Festpreispaket Grobkonzept Teams-Telefonie einen festen Rahmen. Und wenn du lieber mit jemandem auf deinen Tenant schaust, statt allein zu suchen, sprich uns über die Beratung zur Teams-Telefonie an.

FAQ zu Teams-Telefonie Problemen

Warum funktioniert Teams-Telefonie bei einem Kollegen, bei mir aber nicht?

Weil Teams jeden Anruf mit den effektiven Einstellungen des jeweiligen Benutzers verarbeitet. Unterscheiden sich Wählplan, Voice Routing Policy, Lizenz oder Rufnummer, unterscheidet sich auch das Ergebnis. Vergleiche beide Benutzer mit Get-CsOnlineUser und Get-CsUserPolicyAssignment. Häufig hat einer eine direkt zugewiesene Richtlinie und der andere fällt auf die globale zurück.

Was bedeutet SIP 504 bei Teams Direct Routing?

SIP 504 steht für eine Zeitüberschreitung an einem Server unterwegs. In der Praxis mit Direct Routing deutet er oft darauf hin, dass die Verbindung zwischen Microsoft und dem SBC nicht zustande kommt, zum Beispiel wegen Firewall, DNS oder einer TLS-Vertrauenskette, der eine Stammzertifizierungsstelle fehlt. Die Details stehen in SIP 504 nach dem Zertifikatswechsel: Root-CAs am SBC aktualisieren.

Wie erkenne ich, ob mein SBC von Teams als gesund betrachtet wird?

Im Teams Admin Center zeigt der Bereich Direct Routing unter Sprache den Status je SBC. Technisch gilt ein SBC laut Microsoft als gesund, wenn er in den letzten drei Minuten SIP-OPTIONS geschickt hat. Fehlen sie, wird er herabgestuft und bei der Routenauswahl nicht mehr zuerst versucht.

Warum klingt Teams im Homeoffice schlechter als im Büro?

Häufig, weil die Medien durch den VPN-Tunnel laufen oder per TCP statt UDP übertragen werden. Microsoft empfiehlt, Teams-Verkehr per Split Tunneling am VPN vorbeizuführen. Prüfe in der Anrufanalyse das Transportprotokoll und den Netzwerkpfad des betroffenen Anrufs.

Darf ich zum Testen 112 aus Teams anrufen?

Nur nach Absprache mit der zuständigen Leitstelle. Normalisierung und Routing lassen sich vorher vollständig lesend prüfen, etwa mit Test-CsEffectiveTenantDialPlan und dem Abgleich gegen die Muster deiner Voice Routes. Wie du einen echten Test sauber organisierst, steht in Notruf in Teams testen, ohne die Leitstelle zu verärgern.

Warum legt meine Teams-Warteschlange einfach auf?

Meist ist für Überlauf oder Timeout die Aktion Trennen eingestellt, oder ein Umleitungsziel existiert nicht mehr. Prüfe mit Get-CsCallQueue die Werte OverflowThreshold, OverflowAction, TimeoutThreshold und TimeoutAction. Die maximale Wartezeit lässt sich laut Microsoft auf höchstens 45 Minuten einstellen.

Mit welchem der zehn Punkte sollte ich anfangen?

Mit dem, der zum Symptom passt, und bei mehreren gleichzeitig mit allem, was den Notruf betrifft. Danach SBC/Routing, weil dort Ausfälle viele Benutzer gleichzeitig treffen, dann Konfiguration, Netz und Organisation. Die Tabelle oben im Beitrag hilft beim Zuordnen.

Fazit: Erst den Bereich, dann die Ursache

Teams-Telefonie Probleme wirken nach der Einführung oft wie ein diffuses Grundrauschen aus Beschwerden. In Wahrheit stecken fast immer dieselben zehn Ursachen dahinter, verteilt auf vier Bereiche: Netz, SBC/Routing, Konfiguration und Organisation. Wer zuerst den Bereich bestimmt und dann lesend prüft, findet die Ursache meist in Stunden statt in Wochen.

Die wichtigsten Regeln passen auf einen Bierdeckel: Notruf zuerst. Eine Änderung, ein Test. Vorher exportieren. SBC-Protokoll ernst nehmen. Und jemandem die Verantwortung geben, bevor die Konfiguration sich selbstständig macht. Dann wird aus „Gestern ging’s noch“ irgendwann wieder „Ach, das Telefon. Läuft.“ Und die alte Anlage im Keller darf endlich zum Wertstoffhof.

Für jede der zehn Ursachen findest du in dieser Reihe einen eigenen Beitrag mit Diagnose, Behebung und Vorbeugung. Wenn du dein Team gezielt fit machen willst, ist die Schulung Teams-Telefonie der passende nächste Schritt.