Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Notruf, Sprachqualität und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Der Rufweg ist verknotet und keiner weiß mehr, warum? Wir entwirren Wählpläne, Routing und SBC gemeinsam mit dir. › 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

 

Montag, 8:12 Uhr. Das erste Ticket des Tages: „Ich kann nicht raus telefonieren.“ Um 8:19 Uhr das zweite: „Teams sagt, der Anruf konnte nicht abgeschlossen werden.“ Um 8:31 Uhr ruft der Vertriebsleiter persönlich an, natürlich vom Handy, weil Teams ja nicht geht, und fragt, ob man „die alte Anlage nicht einfach wieder einstecken“ könne. Kann man nicht. Die steht seit drei Monaten beim Wertstoffhof, und das ist auch gut so.

Wenn ein Teams-Anruf nicht rausgeht, ist das selten ein Mysterium. Zwischen dem Klick auf „Anrufen“ und dem Klingeln beim Gegenüber liegen genau sieben Stationen, und an jeder davon kann der Anruf sterben: Benutzer, Wählplan, Normalisierung, Voice Routing Policy, PSTN Usage, Voice Route und SBC. Wer diese Kette der Reihe nach prüft, findet den Fehler in der Regel in einer halben Stunde. Wer wild herumklickt, findet ihn auch, aber erst nachdem er drei neue eingebaut hat.

Dieser Beitrag ist die Prüfanleitung für genau diese Kette. Er setzt voraus, dass deine Teams-Telefonie grundsätzlich mit Direct Routing läuft. Wie du das aufbaust, steht in Teams Direct Routing einrichten; die Gesamtübersicht über das Thema findest du auf der Seite Teams-Telefonie. Hier geht es ausschließlich um das Symptom „teams anruf geht nicht raus“ und den kürzesten Weg zur Ursache.

FAKTEN · Worum es hier geht Betrachtet wird Teams Phone mit Direct Routing, also mit eigenem Session Border Controller. 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 der Diagnose sind lesend (Get- und Test-Cmdlets aus dem Modul MicrosoftTeams). Sie ändern nichts an deinem Tenant. Geschrieben wird erst im Abschnitt Behebung, und dort jeweils mit Rückweg.

 

Das Symptom: wie „geht nicht raus“ im Alltag klingt

„Geht nicht raus“ ist für Anwender eine Sammelbeschreibung für alles, was nach dem Wählen nicht zu einem Gespräch führt. Für dich als Admin ist die genaue Formulierung Gold wert, denn sie verrät oft schon, an welchem Glied der Kette es hakt. Frag also nach, bevor du suchst: Wer genau, welche Nummer genau, seit wann genau und was steht auf dem Bildschirm?

Was der Helpdesk hört	Was dahinterstecken kann	Erster Verdacht
„Bei mir gibt es gar kein Wählfeld.“	Benutzer ist nicht für Telefonie freigeschaltet, Lizenz oder Nummer fehlt	Station 1: Benutzer
„Ich kann intern telefonieren, aber nicht nach draußen.“	Keine passende Voice Routing Policy, Rückfall auf die globale Richtlinie	Stationen 1 und 4
„Handynummern gehen, Festnetz nicht.“ oder umgekehrt	Ein Routenmuster deckt nur einen Teil der Nummern ab	Station 6: Voice Route
„Mit 0 davor geht es nicht, mit +49 schon.“	Normalisierung fehlt oder setzt das Ergebnis falsch zusammen	Stationen 2 und 3
„Seit heute Morgen geht bei keinem mehr was.“	SBC deaktiviert, Zertifikat abgelaufen, OPTIONS fehlen	Station 7: SBC
„In Hamburg geht es, in München nicht.“	Standortspezifische Policy, Usage oder Route fehlt oder zeigt auf den falschen SBC	Stationen 4 bis 6
„Es klingelt kurz, dann ist die Leitung tot.“	Anruf erreicht den SBC, scheitert dahinter beim Provider	Station 7 und dahinter

 

Merke dir den Unterschied zwischen „der Anruf geht nicht raus“ und „der Anruf geht raus, aber man hört nichts“. Das zweite ist ein Medienproblem und gehört zu einer ganz anderen Fehlerklasse. Eine Einordnung aller typischen Fehlerbilder findest du in Teams-Telefonie Probleme: die zehn häufigsten Ursachen.

Wie der Fehler entsteht: sieben Stationen bis zum Amt

Ein abgehender Anruf bei Direct Routing durchläuft eine feste Kette. Teams wertet sie in dieser Reihenfolge aus, und genau in dieser Reihenfolge solltest du auch prüfen:

Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC

Kurz zu den Gliedern, nur so weit, wie es für die Fehlersuche nötig ist:

Benutzer: Er braucht eine Lizenz mit Teams Phone, muss für Enterprise Voice aktiviert sein und eine Rufnummer vom Typ Direct Routing haben. Fehlt etwas davon, kommt der Anruf gar nicht erst in die Routing-Logik.

Wählplan: Jeder Benutzer hat einen effektiven Wählplan. Er setzt sich laut Microsoft immer aus dem Dienst-Wählplan des Landes (abgeleitet aus der Usage Location) und entweder dem globalen Tenant-Wählplan oder einem zugewiesenen Benutzer-Wählplan zusammen. Die Regeln des Tenants haben Vorrang vor denen des Dienstes.

Normalisierung: Die Regeln im Wählplan übersetzen das, was jemand eintippt, in ein einheitliches Format, typischerweise E.164 mit +. Teams geht die Liste von oben nach unten durch und nimmt die erste passende Regel.

Voice Routing Policy: Ein Container mit einer geordneten Liste von PSTN Usages. Hat ein Benutzer keine eigene Policy, gilt die globale.

PSTN Usage: Ein Etikett, das Policies und Voice Routes miteinander verbindet. Die Reihenfolge der Usages in der Policy entscheidet: Passt in einer Usage eine Route, werden die folgenden nicht mehr ausgewertet.

Voice Route: Ein regulärer Ausdruck (Number Pattern), eine Priorität und eine Liste von Gateways. Die normalisierte Nummer muss auf das Muster passen.

SBC: Das Online-PSTN-Gateway. Es muss im Tenant angelegt, aktiviert und aus Sicht von Microsoft gesund sein: TLS-Verbindung steht, SIP OPTIONS kommen an, Zertifikat ist gültig.

FAKTEN · Was laut Microsoft-Dokumentation gilt Normalisierungsregeln werden von oben nach unten durchlaufen, die erste passende Regel gewinnt. Microsoft empfiehlt, dass alle Regeln ein Ergebnis mit führendem + liefern, weil ein Ergebnis ohne + erneut durch die Tenant- und Länderregeln normalisiert wird. Ein Tenant kann bis zu 1.000 Tenant-Wählpläne haben. Clients erhalten ihren Wählplan über die Bereitstellung bei der Anmeldung. Die PSTN Usages einer Voice Routing Policy werden in ihrer Reihenfolge ausgewertet. Die Gateways innerhalb einer Voice Route werden in zufälliger Reihenfolge versucht. Passt keine Route und hat der Benutzer keinen Calling Plan, wird der Anruf verworfen. Enthält die gewählte Nummer eine Durchwahl mit ;ext=, wird das Routenmuster nur auf den Teil ohne Durchwahl angewendet.

 

Das Gemeine an dieser Kette: Sie scheitert fast immer still. Teams zeigt dem Anwender eine freundlich-nichtssagende Meldung, und im Admin Center leuchtet nichts rot, solange der SBC selbst gesund ist. Ein Anruf ohne passende Route ist aus Sicht von Teams kein Defekt, sondern korrekt angewendete Konfiguration. Die Konfiguration ist halt nur falsch.

Diagnose: die Kette Glied für Glied prüfen

Vorher: eingrenzen, wer betroffen ist

Bevor du das erste Cmdlet tippst, beantworte eine Frage: Wie viele sind betroffen? Die Antwort sagt dir, ob du die Kette von vorn oder von hinten aufrollst. Ein ausgefallener SBC trifft alle gleichzeitig, ein falscher Wählplan meist nur einen Standort oder einzelne Benutzer.

Für die folgenden Schritte nehmen wir einen konkreten Fall: Lena Koch (lena.koch@contoso.com) sitzt in Frankfurt und kann den Kunden in Köln unter 0221 5550123 nicht erreichen. Verbinde dich zuerst mit dem Tenant:

Import-Module MicrosoftTeams Connect-MicrosoftTeams $upn = "lena.koch@contoso.com"

 

Station 1: Benutzer

Was schiefgehen kann: Die Lizenz mit Teams Phone fehlt oder ist erst seit Minuten zugewiesen, Enterprise Voice ist aus, die Rufnummer fehlt oder ist nicht vom Typ Direct Routing, die Usage Location steht auf dem falschen Land.

Get-CsOnlineUser -Identity $upn | Select-Object DisplayName, UsageLocation, EnterpriseVoiceEnabled, LineUri, FeatureTypes, OnlineVoiceRoutingPolicy, TenantDialPlan   Get-CsPhoneNumberAssignment -AssignedPstnTargetId $upn | Select-Object TelephoneNumber, NumberType, ActivationState

 

Erwartet wird: EnterpriseVoiceEnabled ist True, LineUri enthält die Nummer im E.164-Format (etwa tel:+49695550142), unter FeatureTypes taucht der Telefonie-Eintrag auf (in der Regel PhoneSystem), und NumberType ist DirectRouting. Die Usage Location sollte DE sein, denn sie bestimmt den Dienst-Wählplan, der im effektiven Wählplan steckt. Merk dir außerdem die Werte von OnlineVoiceRoutingPolicy und TenantDialPlan, du brauchst sie gleich. Ist eines der Felder leer, gilt die globale Variante.

Im Teams Admin Center siehst du dasselbe unter Benutzer › Benutzer verwalten › Lena Koch, Registerkarten Konto und Richtlinien. Fehlt das Wählfeld im Client komplett, lies weiter in Kein Wählfeld in Teams: Lizenz, Rufnummer und Enterprise Voice prüfen.

Station 2: Wählplan

Was schiefgehen kann: Der Benutzer hat keinen Benutzer-Wählplan und landet beim globalen, der für Frankfurt nicht passt. Oder er hat den Wählplan eines anderen Standorts, weil er über eine Gruppenzuweisung kommt, an die niemand mehr gedacht hat.

Get-CsEffectiveTenantDialPlan -Identity $upn | Select-Object -ExpandProperty NormalizationRules | Format-Table Name, Pattern, Translation -AutoSize   Get-CsUserPolicyAssignment -Identity $upn -PolicyType TenantDialPlan

 

Die erste Abfrage zeigt dir den effektiven Wählplan, also die Regeln, die tatsächlich gelten, in der Reihenfolge, in der Teams sie prüft. Die zweite zeigt, ob der Wählplan direkt oder über eine Gruppe zugewiesen ist. Gibt es keine Zuweisung, gilt der globale Tenant-Wählplan, ergänzt um den deutschen Dienst-Wählplan.

Im Teams Admin Center findest du die Wählpläne unter Sprache › Wählpläne. Dort steht beim Bearbeiten eines Wählplans auch der Bereich Wählplan testen, in den du eine Nummer eingeben kannst.

Station 3: Normalisierung

Was schiefgehen kann: Keine Regel passt, und die Nummer geht unverändert weiter. Eine Regel passt, liefert aber ein Ergebnis ohne +. Eine zu großzügige Regel steht oben und frisst Nummern, die für eine spätere Regel gedacht waren. Der Klassiker unter den Klassikern: eine dreistellige Durchwahlregel, die 110 und 112 gleich mit erledigt.

Test-CsEffectiveTenantDialPlan -Identity $upn -DialedNumber "02215550123" Test-CsEffectiveTenantDialPlan -Identity $upn -DialedNumber "112" Test-CsEffectiveTenantDialPlan -Identity $upn -DialedNumber "015123456789"

 

Die Ausgabe enthält die übersetzte Nummer (TranslatedNumber) und die Regel, die gegriffen hat (MatchingRule). Für unseren Fall erwartest du +492215550123 und eine Regel für nationale Rufnummern. Prüfe immer mindestens vier Klassen: Ortsnetz, national, Mobilfunk und Notruf. Für Ausland eine fünfte.

Zum Vergleich ein Satz fachlich sauberer Regeln für den Wählplan DP-Frankfurt ohne Amtsholung. Die Reihenfolge ist Absicht:

Nr.	Zweck	Muster	Ersetzung	Beispiel
1	Notruf unverändert	^(11[02])$	$1	112 › 112
2	Durchwahl dreistellig	^(1\d{2})$	+49695550$1	142 › +49695550142
3	Ortsnetz Frankfurt	^([2-9]\d{4,7})$	+4969$1	5550199 › +49695550199
4	National und Mobil	^0([1-9]\d{5,13})$	+49$1	02215550123 › +492215550123
5	International	^00([1-9]\d{6,14})$	+$1	0043155501 › +43155501

 

Regel 1 steht vor Regel 2, damit 110 und 112 nie zur Durchwahl werden. Wer Regel 2 lieber selbst absichert, schreibt sie als ^(1(?!1[02])\d{2})$: Der negative Lookahead schließt 110 und 112 aus, 111 oder 142 passen weiterhin. Regel 4 verlangt nach der 0 eine Ziffer von 1 bis 9, deshalb kann sie internationale Nummern mit 00 nicht versehentlich erwischen. Arbeitet ihr mit Amtsholung 0, sieht der Wählplan anders aus; das steht in Wählplan mit Amtsholung 0 in Teams richtig bauen. Weitere typische Regelfehler sammelt Normalisierungsregeln in Teams: typische Fehler und wie du sie findest.

WARNUNG · Notruf niemals umbiegen Prüfe 110 und 112 bei jeder Änderung am Wählplan mit Test-CsEffectiveTenantDialPlan. Ein Notruf, der als +49695550112 bei einer Durchwahl in Frankfurt landet, ist kein Schönheitsfehler. Wähle die Notrufnummern zum Testen nicht einfach im Live-Betrieb, sondern prüfe Normalisierung und Routing lesend. Wie ein echter Test sauber organisiert wird, steht in Notruf in Teams testen, ohne die Leitstelle zu verärgern; die Grundlagen findest du in Notruf in Microsoft Teams konfigurieren.

 

Station 4: Voice Routing Policy

Was schiefgehen kann: Der Benutzer hat keine eigene Policy und fällt auf die globale zurück, die keine oder die falschen Usages enthält. Oder er hat eine Policy, die für einen anderen Standort gebaut wurde. Oder die Policy existiert, aber ihre Usage-Liste ist leer.

$vrp = (Get-CsOnlineUser -Identity $upn).OnlineVoiceRoutingPolicy if ([string]::IsNullOrEmpty("$vrp")) { $id = "Global" } else { $id = "Tag:$vrp" } $policy = Get-CsOnlineVoiceRoutingPolicy -Identity $id $policy | Select-Object Identity, OnlinePstnUsages   Get-CsUserPolicyAssignment -Identity $upn -PolicyType OnlineVoiceRoutingPolicy

 

Steht bei Identity Global, obwohl Lena eigentlich die Policy VRP-DE-National haben sollte, hast du deinen Täter. Dieses Muster ist so häufig, dass es einen eigenen Beitrag hat: Teams-Benutzer fällt auf die globale Richtlinie zurück. Microsoft warnt in der Dokumentation übrigens ausdrücklich davor, die globale Policy unbedacht zu befüllen, weil dann alle sprachfähigen Benutzer sie erben, auch solche mit Calling Plan oder Operator Connect.

Im Teams Admin Center: Sprache › Richtlinien für das Sprachrouting. Die Reihenfolge der PSTN Usages in der Policy siehst du dort ebenfalls, und sie ist kein Kosmetikdetail.

Station 5: PSTN Usage

Was schiefgehen kann: Eine Usage steht in der Policy, aber keine Voice Route ist ihr zugeordnet. Eine Usage wurde angelegt, aber nie in eine Policy aufgenommen. Oder die Reihenfolge stimmt nicht: Eine Usage mit einer Route .* steht vorn und schluckt alles, bevor die eigentlich gemeinte Usage drankommt.

(Get-CsOnlinePstnUsage).Usage   $routes = Get-CsOnlineVoiceRoute foreach ($u in $policy.OnlinePstnUsages) { $n = @($routes | Where-Object { $_.OnlinePstnUsages -contains $u }).Count [pscustomobject]@{ Usage = $u; Routen = $n } }

 

PSTN Usages sind eine tenantweite Liste unter der Identity Global. Die Schleife zählt für jede Usage aus Lenas Policy, wie viele Voice Routes daran hängen. Eine Null ist ein Befund: Diese Usage führt ins Leere. Das allein bricht den Anruf noch nicht ab, weil Teams zur nächsten Usage weitergeht. Steht aber nur diese eine Usage in der Policy, ist hier Schluss.

Im Teams Admin Center: Sprache › Direct Routing, oben rechts PSTN-Nutzungsdatensätze verwalten.

Station 6: Voice Route

Was schiefgehen kann: Das Muster passt nicht auf die normalisierte Nummer, etwa weil es ein + erwartet, das die Normalisierung nicht liefert, oder umgekehrt. Ein Tippfehler im Regex. Eine Route mit .* und besserer Priorität überdeckt die spezifische Route. Oder die Route hat keine Gateways eingetragen.

Die folgende Abfrage spielt den Rufweg für eine Nummer nach. Sie nutzt den -match-Operator von PowerShell, der wie Teams mit .NET-Regex arbeitet. Damit siehst du für jede Usage der Policy in Prioritätsreihenfolge, welche Route trifft:

$nummer = "+492215550123" # TranslatedNumber aus Station 3 foreach ($u in $policy.OnlinePstnUsages) { $routes | Where-Object { $_.OnlinePstnUsages -contains $u } | Sort-Object Priority | ForEach-Object { [pscustomobject]@{ Usage = $u Route = $_.Identity Prio = $_.Priority Muster = $_.NumberPattern Treffer = ($nummer -match $_.NumberPattern) Gateways = $_.OnlinePstnGatewayList -join ", " } } } | Format-Table -AutoSize

 

Die erste Zeile mit Treffer gleich True in der obersten Usage, die überhaupt einen Treffer hat, ist die Route, die Teams nimmt. Gibt es nirgends ein True, hast du die Ursache: Für diese Nummer existiert in Lenas Policy keine Route. Typische Muster für Contoso sehen so aus:

Route	Muster	Deckt ab
DE-Notruf	^(110|112)$	Notruf, sofern die Normalisierung 110 und 112 unverändert lässt
DE-National	^\+49(?!900|137|180)[1-9]\d{4,13}$	Festnetz und Mobilfunk in Deutschland, ohne 0900, 0137 und 0180
DE-Mobil (falls getrennt)	^\+491[5-7]\d{8,9}$	Deutsche Mobilfunknummern 015x, 016x, 017x
International	^\+(?!49)[1-9]\d{6,14}$	Alle Ziele außerhalb Deutschlands

 

Zwei Fehler sehe ich in Projekten besonders oft. Erstens: ^\+490\d+ als Muster für nationale Nummern. In E.164 steht nach +49 nie eine 0, die Route trifft also nie. Zweitens: ein Muster ohne ^ und $, das plötzlich auch Nummern trifft, die es nicht treffen sollte, und so eine spezifischere Route mit schlechterer Priorität überdeckt. Mehr zu Regex, Priorität und überdeckten Routen steht in Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen, die Reihenfolge-Logik im Detail in Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen.

TIPP · Gleiche Gegenprobe für den Notruf Lass dieselbe Abfrage mit $nummer = "112" laufen, beziehungsweise mit dem, was Test-CsEffectiveTenantDialPlan aus 112 macht. Trifft die Notrufroute nicht oder trifft zuerst eine allgemeine Route, gehört das an den Anfang deiner Liste, nicht ans Ende.

 

Station 7: SBC

Was schiefgehen kann: Das Gateway in der Route ist deaktiviert oder gar nicht angelegt, etwa wegen eines Tippfehlers im FQDN. Der SBC sendet keine SIP OPTIONS mehr, die TLS-Verbindung steht nicht, das Zertifikat ist abgelaufen oder die Root-CA auf dem SBC passt nicht mehr zu den Zertifikaten von Microsoft.

Get-CsOnlinePSTNGateway | Select-Object Identity, Enabled, SipSignalingPort, SendSipOptions, MaxConcurrentSessions   $gw = (Get-CsOnlinePSTNGateway).Identity foreach ($r in $routes) { foreach ($g in $r.OnlinePstnGatewayList) { if ($g -notin $gw) { "Route $($r.Identity): Gateway $g ist nicht angelegt" } } }

 

Get-CsOnlinePSTNGateway zeigt die Konfiguration, aber nicht den Zustand. Den siehst du im Teams Admin Center unter Sprache › Direct Routing: Dort stehen je SBC der TLS-Verbindungsstatus, der Status der SIP OPTIONS und der Gesamtstatus. Laut Microsoft warnt das Dashboard auch, wenn ein Zertifikat innerhalb von 30 Tagen abläuft. Steht dort bei SIP OPTIONS eine Warnung oder ist der SBC inaktiv, schau in Teams SBC inaktiv: OPTIONS-Ping und Verbindungsstatus prüfen. Kam der Fehler direkt nach einem Zertifikatswechsel, lies SIP 504 nach dem Zertifikatswechsel: Root-CAs am SBC aktualisieren.

Hängen mehrere Gateways in einer Route, probiert Teams sie in zufälliger Reihenfolge. Ein einzelner kranker SBC fällt deshalb oft nur als „jeder zweite Anruf geht nicht“ auf. Warum die Ausweichroute dann manchmal trotzdem nicht greift, erklärt SBC-Failover in Teams funktioniert nicht.

AUS DER PRAXIS · Die Grenzlinie am eigenen SBC Für meine eigene Telefonie betreibe ich einen anynode-SBC, und dort habe ich mir eine Regel angewöhnt, die bei jeder Fehlersuche Zeit spart: Zuerst ins Protokoll des SBC schauen, ob das INVITE von Teams überhaupt ankommt. Kommt keins an, liegt der Fehler auf der Teams-Seite, also irgendwo in den Stationen 1 bis 6 oder in der Verbindung zwischen Microsoft und dem SBC. Kommt es an, ist die Teams-Konfiguration erledigt, und der Rest spielt sich im SBC und beim Provider ab: Nummernformat Richtung Trunk, gesperrte Ziele, Kanalanzahl. Diese eine Frage teilt den Suchraum in zwei Hälften. Mehr Effizienz bekommt man in der Fehlersuche selten für so wenig Aufwand.

 

Hinter dem SBC: wenn Teams alles richtig gemacht hat

Erreicht der Anruf den SBC und scheitert dahinter, liefert dir der SIP-Antwortcode den nächsten Hinweis. Im Teams Admin Center findest du unter Analysen und Berichte den Nutzungsbericht für PSTN mit einer Registerkarte für Direct Routing, der je Anruf den finalen SIP-Code ausweist. Was die einzelnen Codes bedeuten, steht in SIP-Fehlercodes in Teams Direct Routing verstehen. Wer mehr als einzelne Anrufe auswerten will, landet bei Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl. Und wenn der Anruf zwar rausgeht, beim Gegenüber aber die falsche Nummer erscheint und deshalb abgelehnt wird, hilft Rufnummernanzeige in Teams falsch: CLIP, Caller ID Policy und SBC.

Die ganze Kette auf einen Blick

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Der Rufweg-Simulator spielt genau die Kette dieses Beitrags nach: Du wählst einen Benutzer und gibst eine Nummer ein, und der Simulator zeigt Station für Station den effektiven Wählplan, die greifende Normalisierungsregel mit dem Ergebnis, die Voice Routing Policy, die PSTN Usages in ihrer Reihenfolge, die passende Voice Route und das Gateway. Die Station, an der der Anruf scheitert, ist markiert, zum Beispiel eine Usage ohne Route oder ein deaktiviertes Gateway. Für den Blick auf den gesamten Bestand gibt es die Routing-Landkarte, die Policies, Usages, Routen und Gateways nebeneinanderstellt und auffällige Elemente hervorhebt. Gefundene Probleme erscheinen als Befunde mit Prüffall, sodass du nachvollziehen kannst, warum etwas als Fehler gilt. Der Teams-Telefonie Diagnostiker lässt sich 15 Tage kostenlos testen. › Teams-Telefonie Diagnostiker

 

Behebung: reparieren, aber mit Rückweg

Jetzt wird geschrieben. Und damit beginnt der Teil, in dem man aus einem Fehler zwei machen kann. Die wichtigste Regel deshalb vorab: Erst sichern, dann ändern, dann mit denselben Nummern testen wie vorher.

WICHTIG · Vor jeder Änderung sichern Exportiere den aktuellen Stand, bevor du irgendetwas anfasst, zum Beispiel mit Get-CsOnlineVoiceRoute | Export-Clixml, Get-CsOnlineVoiceRoutingPolicy | Export-Clixml, Get-CsTenantDialPlan | Export-Clixml und (Get-CsOnlinePstnUsage).Usage | Export-Clixml in einen Ordner mit Datum. Notiere bei Benutzeränderungen die bisher zugewiesenen Richtlinien. Damit ist der Rollback eine Abschrift und keine Gedächtnisübung.

 

Befund	Behebung	Rollback
Benutzer ohne Enterprise Voice oder Nummer	Set-CsPhoneNumberAssignment -Identity <UPN> -PhoneNumber +49695550142 -PhoneNumberType DirectRouting	Remove-CsPhoneNumberAssignment für diese Nummer
Falscher oder fehlender Benutzer-Wählplan	Grant-CsTenantDialPlan -Identity <UPN> -PolicyName DP-Frankfurt	Grant-CsTenantDialPlan mit dem vorherigen Namen oder $null
Regel in falscher Reihenfolge oder zu großzügig	Regel im Teams Admin Center verschieben oder per Set-CsTenantDialPlan anpassen, danach Test-CsEffectiveTenantDialPlan mit allen Nummernklassen	Regelsatz aus dem Export zurückschreiben
Rückfall auf die globale Voice Routing Policy	Grant-CsOnlineVoiceRoutingPolicy -Identity <UPN> -PolicyName VRP-DE-National	Grant-CsOnlineVoiceRoutingPolicy mit vorherigem Namen oder $null
Usage fehlt in der Policy oder steht falsch	Set-CsOnlineVoiceRoutingPolicy -Identity VRP-DE-National -OnlinePstnUsages @{Replace="DE-Notruf","DE-National","International"}	Dieselbe Zeile mit der alten Liste aus dem Export
Route passt nicht oder hat kein Gateway	Set-CsOnlineVoiceRoute -Identity DE-National -NumberPattern <korrigiertes Muster> oder -OnlinePstnGatewayList sbc1.contoso.com, sbc2.contoso.com	Altes Muster und alte Gateway-Liste aus dem Export setzen
Gateway deaktiviert	Ursache klären, dann Set-CsOnlinePSTNGateway -Identity sbc1.contoso.com -Enabled $true	-Enabled $false

 

Ändere immer nur eine Sache auf einmal und teste danach. Wer gleichzeitig Wählplan, Route und Policy umbaut, weiß hinterher nicht, welche der drei Änderungen das Problem gelöst hat, und welche zwei neue verursacht haben. Bei Änderungen am Wählplan rechne damit, dass Clients die neuen Regeln erst nach erneuter Bereitstellung erhalten; ein Ab- und Anmelden im Teams-Client beschleunigt das beim Testen.

WARNUNG · Kein .* als schnelle Lösung Die Versuchung ist groß, eine Route mit dem Muster .* an alle Gateways zu hängen und in jede Policy zu packen. Dann geht der Anruf zwar raus, aber auch jeder andere: Sonderrufnummern, Auslandsziele, Premium-Dienste. Microsoft nennt .* in der Dokumentation als Möglichkeit, alle Anrufe an denselben SBC zu schicken. Als Pflaster für eine kaputte Routingstruktur taugt es nicht, und die Rechnung des Providers für 0900-Nummern ist nicht schwarzhumorig, sondern einfach schwarz.

 

Wenn du einen Standort ohnehin neu aufbaust, lohnt sich ein Blick auf Konflikte mit dem Bestand, bevor du anlegst: Zeigt eine neue Route auf ein deaktiviertes Gateway oder hat sie dasselbe Muster wie eine bestehende Route, ist das besser vorher bekannt als nach dem ersten Helpdesk-Anruf.

Vorbeugung: damit die Kette nicht wieder reißt

Die meisten Rufwegfehler entstehen nicht beim Aufbau, sondern danach: ein neuer Standort, eine schnell angelegte Route, ein Kollege, der „nur mal kurz“ die Reihenfolge der Usages geändert hat. Ein paar Gewohnheiten verhindern das:

Testnummernliste: Pflege je Standort eine kurze Liste mit Ortsnetz, national, Mobil, Ausland, 110 und 112. Nach jeder Änderung läuft sie durch Test-CsEffectiveTenantDialPlan und die Routenabfrage aus Station 6.

Benutzer nie ohne Policy: Weise Wählplan und Voice Routing Policy bei der Einrichtung explizit zu, direkt oder über Gruppen mit klarer Rangfolge. Ein Benutzer, der auf Global fällt, ist ein Befund, kein Zufall.

Ergebnis immer mit +: Jede Normalisierungsregel liefert E.164 mit +. So gilt die Empfehlung von Microsoft, und jedes Routenmuster kann auf ^\+ aufbauen.

Muster immer verankert: Jedes Routenmuster beginnt mit ^ und endet mit $. Ausnahmen werden dokumentiert.

Namenskonvention: Policies, Usages, Routen und Wählpläne folgen einem Schema wie VRP-DE-National, DE-National, DP-Frankfurt. Wer im Teams Admin Center auf „Test2-neu-final“ stößt, weiß, dass hier etwas schiefgehen wird.

SBC-Zustand beobachten: Schau regelmäßig in die Direct-Routing-Übersicht und reagiere auf Zertifikatswarnungen, bevor sie zum Ausfall werden.

Änderungen festhalten: Exportiere den Stand regelmäßig und vergleiche ihn mit dem vorherigen. Was sich unbemerkt verändert hat, ist bei der nächsten Störung der erste Verdächtige.

Wie man Abweichungen zwischen zwei Ständen systematisch findet, beschreibt Konfigurationsdrift in der Teams-Telefonie erkennen. Wenn du dein Team gezielt darauf vorbereiten willst, die Kette selbst zu prüfen und sauber zu ändern, ist die Schulung Teams-Telefonie der passende Rahmen. Ist der Bestand über die Jahre so verwachsen, dass niemand mehr durchblickt, hilft eine Beratung zur Teams-Telefonie, die Struktur einmal geordnet neu aufzusetzen.

FAQ: häufige Fragen zum Teams-Anruf, der nicht rausgeht

Warum geht mein Teams-Anruf nicht raus, obwohl intern alles funktioniert?

Interne Anrufe zwischen Teams-Benutzern brauchen weder Voice Routing Policy noch Voice Route. Für externe Anrufe über Direct Routing muss die Kette bis zum SBC vollständig sein. Am häufigsten fehlt eine passende Policy, weil der Benutzer auf die globale zurückfällt, oder kein Routenmuster passt auf die normalisierte Nummer.

Wie finde ich heraus, welche Normalisierungsregel bei einer Nummer greift?

Mit Test-CsEffectiveTenantDialPlan -Identity <UPN> -DialedNumber <Nummer>. Die Ausgabe zeigt die übersetzte Nummer und die Regel, die gegriffen hat. Im Teams Admin Center gibt es beim Bearbeiten eines Wählplans zusätzlich den Bereich zum Testen.

Was passiert, wenn keine Voice Route auf die Nummer passt?

Hat der Benutzer nur Teams Phone mit Direct Routing, wird der Anruf laut Microsoft verworfen. Hat er zusätzlich einen Calling Plan, geht der Anruf über den Calling Plan raus. Das kann einen Routingfehler verschleiern, weil der Anruf scheinbar funktioniert, nur eben über den falschen Weg.

Warum geht nur jeder zweite Anruf raus?

Ein typisches Zeichen dafür, dass in einer Voice Route mehrere Gateways hängen und eines davon nicht sauber arbeitet. Teams versucht die Gateways einer Route in zufälliger Reihenfolge. Prüfe den Zustand jedes SBC im Teams Admin Center unter Sprache › Direct Routing.

Muss ich die Muster meiner Voice Routes mit + schreiben?

Das Muster muss auf die Nummer passen, die nach der Normalisierung herauskommt. Liefern alle Regeln E.164 mit +, wie Microsoft es empfiehlt, beginnen die Routenmuster mit ^\+. Prüfe das konkret, indem du die TranslatedNumber aus Test-CsEffectiveTenantDialPlan gegen das Muster testest.

Ich habe den Wählplan korrigiert, aber der Anwender hat immer noch das alte Verhalten. Warum?

Clients erhalten ihren Wählplan über die Bereitstellung bei der Anmeldung. Gib der Änderung etwas Zeit und lass den Anwender sich im Teams-Client ab- und wieder anmelden, bevor du weitersuchst.

Fazit: sieben Stationen, eine Reihenfolge

Ein Teams-Anruf, der nicht rausgeht, ist fast nie Pech und fast nie ein Fehler bei Microsoft. Er ist das logische Ergebnis einer Kette aus sieben Gliedern, von denen eines nicht so konfiguriert ist, wie alle glauben. Benutzer, Wählplan, Normalisierung, Voice Routing Policy, PSTN Usage, Voice Route, SBC: In dieser Reihenfolge prüfst du, lesend, mit einer konkreten Nummer und einem konkreten Benutzer.

Grenz vorher ein, wer betroffen ist, sichere vor jeder Änderung den Bestand, ändere eine Sache auf einmal und teste immer auch 110 und 112. Dann wird aus dem Montagmorgen-Ticket ein Zehn-Minuten-Fall, und der Vertriebsleiter muss die alte Anlage nicht vom Wertstoffhof zurückholen lassen. Die hätte ohnehin keiner mehr angeschlossen bekommen.