SBC-Failover in Teams funktioniert nicht

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Zwei SBCs gekauft, aber nur einer arbeitet? Wir prüfen mit dir, ob dein Routing einen Ausfall wirklich übersteht. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die Routen, Prioritäten und SIP-Antwortcodes selbst lesen und Failover gefahrlos testen wollen. › Schulung Teams-Telefonie

 

Es gibt diesen einen Moment, in dem eine Redundanz beweisen muss, dass sie mehr ist als ein Posten im Budget. Bei Direct Routing kommt er meistens an einem Dienstagvormittag: sbc1 hängt, der Provider-Trunk dahinter ist weg oder jemand hat im Wartungsfenster den falschen Dienst neu gestartet. Der zweite SBC steht daneben, ist gesund, schickt fröhlich seine OPTIONS an Microsoft und bekommt trotzdem keinen einzigen Anruf. Die Telefonie liegt, und im Monitoring leuchten zwei grüne Lampen.

Dieser Beitrag ist für genau diesen Moment, oder besser: für die Woche davor. Du erfährst, warum ein SBC-Failover in Teams nur so gut ist wie die Routen, in denen der zweite SBC steht, welche Rolle Gateway-Status, Routenpriorität, FailoverResponseCodes und FailoverTimeSeconds spielen, wie du die Lücken mit lesenden PowerShell-Befehlen findest und wie du den Failover testest, ohne die halbe Firma vom Netz zu nehmen. Die Grundlagen zu Direct Routing, SBC und Routing findest du gesammelt auf der Seite Teams-Telefonie.

FAKTEN · Das Beispiel in diesem Beitrag Erfundener Tenant Contoso (contoso.com) mit Standorten in Frankfurt, Köln, Berlin, Hamburg und München. Zwei Session Border Controller sbc1.contoso.com und sbc2.contoso.com, beide im Teams Admin Center eingetragen. Rufnummern im Muster +49 69 555 0100 (Frankfurt) und +49 221 555 0100 (Köln). Die Benutzerin heißt Anna Berger (anna.berger@contoso.com) und hat die Voice Routing Policy VRP-DE-Standard. Verhalten, Standardwerte und Parameter stammen aus der Microsoft-Dokumentation auf Microsoft Learn, Stand November 2026.

 

Das Symptom: Zwei SBCs, und trotzdem steht alles

Was Anwender sagen

Ein fehlender Failover fällt nie im Normalbetrieb auf, sondern immer dann, wenn sbc1 gerade nicht kann. Und dann klingt der Helpdesk ungefähr so:

„Ins Festnetz komme ich durch, aufs Handy nicht.“ Der Klassiker für einen zweiten SBC, der nur in einer Route steht. Festnetz hat Failover, Mobilfunk nicht.

„Jeder zweite Anruf geht, der andere nicht.“ Typisch für eine Route mit zwei Gateways, von denen eines kaputt ist und vom Health-Check noch nicht als krank erkannt wird.

„Es tutet ewig, dann kommt eine Ansage, und dann klappt es doch.“ Failover funktioniert, aber erst nach der Failover-Zeit. Die Nutzer zählen mit, und zwar laut.

„Seit dem Wartungsfenster heute Nacht geht gar nichts.“ Jemand hat sbc1 zum Arbeiten deaktiviert, und sbc2 war seit seiner Einrichtung selbst nie aktiviert.

Was Admins sehen

Im Teams Admin Center unter Sprache › Direct Routing stehen beide SBCs in der Liste, oft beide mit grünem Status für TLS-Verbindung und SIP-OPTIONS. Genau das ist die Falle: Der Health-Check sagt nur, dass ein SBC erreichbar ist, nicht, dass er in irgendeiner Route eingeplant ist. Im PSTN-Nutzungsbericht auf dem Reiter Direct Routing tauchen gescheiterte Anrufe auf, alle mit demselben SBC, und sbc2 hat in der fraglichen Stunde schlicht keinen Verkehr. Je nachdem, wie sbc1 ausgefallen ist, steht dort ein 503, ein 504, ein 408 oder ein ganz anderer Code.

Was du dagegen nicht siehst: eine Meldung „Für Mobilfunk ist kein Ausweich-SBC eingeplant“. Das Teams Admin Center prüft keine Failover-Abdeckung. Diese Lücke musst du selbst finden, und das geht mit ein paar Zeilen PowerShell zum Glück schneller als die nächste Störung.

WICHTIG · Failover ist eine Eigenschaft deiner Routen, nicht deiner Hardware Microsoft entscheidet für jeden einzelnen Anruf anhand der Voice Routing Policy des Benutzers, welche Routen passen und welche Gateways darin stehen. Nur diese Gateways kommen für den Anruf in Frage. Ein SBC, der im Tenant existiert, aber in der passenden Route fehlt, ist für diesen Anruf nicht vorhanden, egal wie gesund er ist.

 

Wie der Fehler technisch zustande kommt

Wo der Failover in der Kette sitzt

Ein ausgehender Anruf durchläuft in Teams immer dieselbe Kette: Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC. Der Failover passiert ganz am Ende, aber er wird weiter vorne entschieden. Microsoft geht die PSTN Usages der Policy in ihrer Reihenfolge durch und nimmt die erste Usage, in der eine Route zur Nummer passt. Laut Dokumentation werden die übrigen Usages dann nicht mehr ausgewertet. Innerhalb dieser Usage zählen alle passenden Routen, sortiert nach Priorität, und in jeder Route alle eingetragenen Gateways. Das ist die gesamte Kandidatenliste für den Failover. Mehr gibt es nicht.

Wie die Kette in der richtigen Reihenfolge zusammenspielt, steht ausführlich in Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen. Für den Failover reichen drei Regeln aus der Microsoft-Dokumentation:

Mehrere Gateways in einer Route werden in zufälliger Reihenfolge versucht. Microsoft spricht von einem Fisher-Yates-Mischen zwischen gleich gesunden SBCs.

Mehrere passende Routen werden nach Priorität abgearbeitet. Erst wenn kein Gateway der Route mit der höheren Priorität den Anruf annehmen kann, kommt die nächste Route dran.

Ein SBC ohne OPTIONS in den letzten drei Minuten gilt als nicht gesund und wird herabgestuft. Er wird nicht entfernt, sondern nur zuletzt versucht, bevor der Anruf scheitert.

Aus diesen drei Regeln ergeben sich die fünf typischen Gründe, warum der Failover nicht funktioniert. Wir nehmen sie der Reihe nach auseinander.

Fehlerbild 1: Der zweite SBC steht nur in einer Route

Das häufigste Muster, und das mit dem größten Überraschungseffekt. Bei der Einführung hat jemand sbc2 in die Route für Festnetz eingetragen, weil das die Route war, mit der getestet wurde. Die Routen für Mobilfunk, Ausland, Sonderrufnummern und Notruf kamen später dazu, wurden aus der Vorlage für sbc1 kopiert und tragen deshalb nur sbc1. Im Normalbetrieb merkt das niemand. Am Tag X funktioniert Festnetz weiter, alles andere nicht.

Besonders unangenehm ist das beim Notruf. Wenn die Route für 110 und 112 nur einen SBC kennt, hat ausgerechnet der wichtigste Anruf im Unternehmen keine Ausweichstrecke. Verwendest du eine Emergency Call Routing Policy mit eigener PSTN Usage für Notrufnummern, gehören deren Routen ausdrücklich mit in die Prüfung. Grundlagen dazu findest du in Notruf in Microsoft Teams konfigurieren.

Fehlerbild 2: Die Reihenfolge stimmt nicht

Viele Admins tragen sbc1 und sbc2 in dieselbe Route ein und erwarten, dass Teams sich an die Reihenfolge der Liste hält: erst sbc1, dann sbc2. Tut es nicht. Microsoft schreibt ausdrücklich, dass die SBCs innerhalb einer Route in zufälliger Reihenfolge versucht werden, auch wenn die Routen selbst Prioritäten haben. Das ist Lastverteilung mit eingebautem Failover, aber kein Primär-Backup-Modell. Wenn sbc2 eigentlich nur ein Notnagel sein soll, etwa weil dahinter ein teurerer Trunk oder ein schmaleres Kontingent an Sprachkanälen hängt, bekommt er trotzdem ungefähr die Hälfte aller Anrufe.

Wer eine echte Rangfolge will, baut zwei Routen mit identischem Muster: Priorität 1 mit sbc1, Priorität 2 mit sbc2. Microsoft zeigt genau dieses Muster in der Dokumentation zum Anrufrouting. Dabei lauern zwei weitere Fehler:

Die Backup-Route steckt in einer anderen PSTN Usage. Weil Microsoft nach der ersten Usage mit Treffer aufhört, wird eine Usage weiter hinten in der Policy nicht als Ausweich ausgewertet. Primär- und Backup-Route gehören in dieselbe Usage. Steckt die Backup-Usage in gar keiner Policy, ist die Route ohnehin nur Dekoration.

Die Muster laufen auseinander. Jemand ändert die Primärroute auf ein neues Muster, die Backup-Route bleibt beim alten. Dann gibt es Nummern, für die nur noch eine Route passt.

Details zu überdeckten Mustern und Prioritäten findest du in Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen.

Fehlerbild 3: Das Gateway ist deaktiviert

Jedes Gateway hat in Teams den Schalter Enabled. Laut Microsoft ist er dafür gedacht, einen SBC für Wartung vorübergehend aus dem Betrieb zu nehmen: Bestehende Gespräche laufen weiter, neue Anrufe gehen an einen anderen SBC der Route, sofern es einen gibt. Zwei Details machen daraus eine Falle. Erstens legt New-CsOnlinePSTNGateway einen SBC deaktiviert an, wenn du den Parameter nicht ausdrücklich setzt; der Standardwert ist $false. Ein frisch angelegter sbc2, der nie aktiviert wurde, steht also brav in allen Routen und bekommt trotzdem nichts. Zweitens wird der Schalter gern im Wartungsfenster umgelegt und danach vergessen.

Der schlimmste Fall ist die Kombination: sbc2 war nie aktiv, und jemand deaktiviert sbc1 für ein Firmware-Update im Vertrauen darauf, dass sbc2 übernimmt. Ab diesem Moment gibt es für neue Anrufe kein einziges Gateway mehr.

WARNUNG · SendSipOptions ist kein harmloser Komfortschalter Mit SendSipOptions = $false nimmst du einen SBC laut Microsoft aus dem Monitoring und der Alarmierung heraus. Microsoft empfiehlt ausdrücklich, SIP-OPTIONS eingeschaltet zu lassen. Ohne OPTIONS fehlt dir die Gesundheitsinformation, auf der die Auswahl zwischen gesunden und herabgestuften SBCs beruht. Wie du OPTIONS und Verbindungsstatus prüfst, steht in Teams SBC inaktiv: OPTIONS-Ping und Verbindungsstatus prüfen.

 

Fehlerbild 4: Die Failover-Antwortcodes passen nicht

Jetzt wird es spannend, denn hier scheitert der Failover, obwohl beide SBCs aktiv sind und sauber in derselben Route stehen. Wenn Teams einen Anruf an sbc1 schickt und sbc1 mit einem Fehlercode antwortet, muss Teams entscheiden: Ist das eine endgültige Antwort, oder soll ich es woanders versuchen? Die Entscheidung trifft der Gateway-Parameter FailoverResponseCodes.

Der Standardwert lautet laut Microsoft „408, 503, 504“. Für alle anderen Codes aus den Klassen 4xx und 6xx gilt der Anruf ohne Eintrag in dieser Liste als abgeschlossen. Das ist auch richtig so, denn ein 486 Busy Here heißt, dass der Angerufene besetzt ist. Den Anruf über sbc2 noch einmal zuzustellen, würde nur ein zweites Besetztzeichen produzieren, oder schlimmer, beim Angerufenen ein zweites Klingeln.

Das Problem entsteht an zwei Stellen. Erstens beim Überschreiben: Wer den Parameter setzt, ersetzt laut Microsoft die Standardwerte vollständig. Ein gut gemeintes „FailoverResponseCodes 500“ wirft also 408, 503 und 504 hinaus. Zweitens beim SBC selbst: Viele SBCs antworten bei einem toten Provider-Trunk nicht mit 503, sondern mit dem, was der Trunk zuletzt geliefert hat, oder mit einem eigenen Code wie 480 oder 500. Steht dieser Code nicht in der Liste, gibt Teams auf, obwohl sbc2 den Anruf problemlos zustellen könnte.

Code	Bedeutung	Failover sinnvoll?	Begründung
408	Request Timeout	ja (Standard)	Der SBC oder der Weg dahinter hat nicht rechtzeitig reagiert.
503	Service Unavailable	ja (Standard)	Der SBC oder sein Trunk ist nicht verfügbar. Das ist das eigentliche Failover-Signal.
504	Server Time-out	ja (Standard)	Zeitüberschreitung beim nächsten Hop, oft auch TLS- oder Verbindungsprobleme zum SBC.
500	Server Internal Error	nur nach Prüfung	Kann ein SBC-Problem sein, aber auch eine Antwort des Providers auf eine bestimmte Nummer. Erst im Log ansehen.
480	Temporarily Unavailable	meist nein	Oft ein Zustand beim Angerufenen. Ein zweiter Weg ändert daran nichts.
404	Not Found	nein	Die Nummer gibt es nicht. Über sbc2 gibt es sie auch nicht.
486	Busy Here	nein	Besetzt. Ein Failover erzeugt bestenfalls ein zweites Besetztzeichen.
487	Request Terminated	nein	Der Anrufer hat aufgelegt.
603	Decline	nein	Der Angerufene hat abgelehnt. Ein erneuter Versuch wäre unhöflich und kann zu mehrfachen Anrufen führen.

 

Was ein Code im Einzelfall bedeutet und welche Microsoft-eigenen Subcodes dazugehören, steht in SIP-Fehlercodes in Teams Direct Routing verstehen.

Fehlerbild 5: Die Failover-Zeit ist zu kurz oder zu lang

Der zweite Gateway-Parameter heißt FailoverTimeSeconds und steht standardmäßig auf 10. Microsoft beschreibt das Verhalten so: Ausgehende Anrufe, die das Gateway nicht innerhalb dieser Zeit beantwortet, werden an den nächsten verfügbaren Trunk weitergeleitet. Gibt es keinen weiteren Trunk, wird der Anruf beendet. Microsoft weist selbst darauf hin, dass in Umgebungen mit langsamen Netzen und langsam antwortenden Gateways dadurch Anrufe unnötig abgebrochen werden können.

Daraus ergeben sich zwei entgegengesetzte Fehlerbilder. Ist der Wert zu kurz für deinen SBC und deinen Provider, springt Teams zu sbc2, obwohl sbc1 nur gemächlich war, und bei einem einzelnen SBC in der Route bricht der Anruf ab. Ist der Wert zu lang, funktioniert der Failover zwar, aber der Anrufer hört lange nichts. Im Helpdesk heißt das dann „Es dauert ewig, bis es klingelt“. Wie lange dein SBC bis zu seiner ersten Antwort auf ein INVITE braucht, siehst du im SBC-Log. Daran orientierst du den Wert, nicht an einem Bauchgefühl.

Die fünf Fehlerbilder im Überblick

Fehlerbild	Typisches Symptom	Wo du es siehst
sbc2 nur in einer Route	Festnetz geht, Mobil, Ausland oder Notruf nicht	Get-CsOnlineVoiceRoute, Spalte OnlinePstnGatewayList
Falsche Reihenfolge	sbc2 bekommt im Normalbetrieb die Hälfte der Anrufe, oder die Backup-Route greift nie	Routen mit gleichem Muster, Priorität, PSTN Usage
Deaktiviertes Gateway	Nach Wartung oder Neueinrichtung geht nichts über diesen SBC	Get-CsOnlinePSTNGateway, Eigenschaft Enabled
Failover-Antwortcodes	sbc1 lehnt ab, sbc2 wird nie gefragt	FailoverResponseCodes und SBC-Log von sbc1
Failover-Zeit	Lange Stille vor dem Klingeln oder Abbrüche bei langsamem Aufbau	FailoverTimeSeconds und Antwortzeiten im SBC-Log

 

AUS DER PRAXIS · Ein Maschinenbauer mit zwölf Standorten Zwei SBCs in zwei Rechenzentren, sauber dokumentiert, jährlich auditiert. Beim ersten echten Ausfall von sbc1 konnte die Zentrale ins Festnetz telefonieren, der Außendienst aber niemanden auf dem Handy erreichen. Die Mobilfunkroute war bei einer Tarifumstellung neu angelegt worden, aus einer alten Vorlage mit nur einem Gateway. Das Audit hatte die Zahl der SBCs geprüft, nicht die Zahl der Gateways je Route. Seitdem gibt es dort eine Prüfnummernliste, die monatlich läuft.

 

Diagnose Schritt für Schritt

Alle Befehle in diesem Abschnitt lesen nur. Du brauchst das PowerShell-Modul MicrosoftTeams und eine Anmeldung mit Connect-MicrosoftTeams, für die eine Rolle mit Leserechten auf die Telefoniekonfiguration genügt. Nichts davon ändert den Tenant.

Schritt 1: Die Gateways lesen

Zuerst der Blick auf die SBCs selbst. Uns interessieren Aktivierung, OPTIONS und die beiden Failover-Parameter.

Get-CsOnlinePSTNGateway | Select-Object Identity, Enabled, SendSipOptions, FailoverTimeSeconds, FailoverResponseCodes, MaxConcurrentSessions | Format-Table -AutoSize

 

Prüfe drei Dinge: Ist jedes Gateway, das in Routen steht, auf Enabled = True? Steht SendSipOptions überall auf True? Und sind FailoverResponseCodes und FailoverTimeSeconds auf allen SBCs gleich, oder hat jemand einen davon individuell angepasst? Unterschiede zwischen sbc1 und sbc2 sind nicht automatisch falsch, aber sie brauchen einen Grund, den du kennst.

Im Teams Admin Center findest du dieselben Werte unter Sprache › Direct Routing auf dem Reiter SBCs, wenn du einen SBC öffnest. Für einen schnellen Vergleich über mehrere SBCs ist PowerShell aber deutlich angenehmer.

Schritt 2: Policy und Normalisierung des betroffenen Benutzers

Failover wird pro Benutzer entschieden, also brauchst du zuerst dessen Policy und die Nummer in der Form, in der sie nach der Normalisierung beim Routing ankommt.

Get-CsOnlineUser -Identity anna.berger@contoso.com | Select-Object DisplayName, LineUri, OnlineVoiceRoutingPolicy, TenantDialPlan   Test-CsEffectiveTenantDialPlan -Identity anna.berger@contoso.com -DialedNumber "0170 5550100" | Select-Object TranslatedNumber, MatchingRule

 

Ist OnlineVoiceRoutingPolicy leer, gilt die globale Policy. Das ist ein eigenes Fehlerbild mit eigenen Überraschungen. Ergibt der Wählplan nicht die erwartete E.164-Nummer, hier +491705550100, liegt das Problem vor dem Routing, und der Rufweg-Check aus Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen ist der richtige Einstieg.

Schritt 3: Die Failover-Abdeckung je Nummernart prüfen

Jetzt kommt der eigentliche Test. Das folgende Skript bildet die Routing-Logik für eine Policy und eine Liste von Prüfnummern nach: erste PSTN Usage mit Treffer, alle passenden Routen dieser Usage nach Priorität, alle Gateways darin samt Aktivierung. Am Ende zählt es die aktiven Gateways. Steht dort eine 1, hat diese Nummernart keinen Failover.

$policy = Get-CsOnlineVoiceRoutingPolicy -Identity "Tag:VRP-DE-Standard" $routes = Get-CsOnlineVoiceRoute $gateway = @{} Get-CsOnlinePSTNGateway | ForEach-Object { $gateway[$_.Identity] = $_.Enabled }   $testnummern = "112", "+49695550100", "+492215550100", "+491705550100", "+442079460100"   foreach ($nummer in $testnummern) { $treffer = $null foreach ($usage in $policy.OnlinePstnUsages) { $treffer = $routes | Where-Object { $_.OnlinePstnUsages -contains $usage -and $nummer -match $_.NumberPattern } | Sort-Object Priority if ($treffer) { break } } $aktiv = @($treffer | ForEach-Object { $_.OnlinePstnGatewayList } | Sort-Object -Unique | Where-Object { $gateway[$_] }) [pscustomobject]@{ Nummer = $nummer Usage = $usage Routen = ($treffer | ForEach-Object { "$($_.Identity) ($($_.Priority))" }) -join ", " AktiveGateways = $aktiv -join ", " Anzahl = $aktiv.Count } }

 

Zwei Hinweise zum Skript. Erstens verwendet PowerShell mit -match denselben .NET-Regex-Dialekt wie Teams, deshalb sind die Ergebnisse für die Musterprüfung belastbar. Zweitens bildet das Skript keine Gesundheitsdaten nach, also weder OPTIONS noch Herabstufung. Es beantwortet nur die Frage, ob es überhaupt einen zweiten Kandidaten gibt. Findet das Skript für eine Nummer gar keine Route, zeigt die Spalte Usage die letzte geprüfte Usage und die Spalte Routen bleibt leer; dann hast du kein Failover-Problem, sondern ein Routing-Problem.

Die Prüfnummern wählst du so, dass jede Route deiner Policy mindestens einmal getroffen wird: Notruf, Ortsnetz, Fernnetz, Mobilfunk, Ausland, Sonderrufnummern und, falls vorhanden, Standortrouten. Als Muster für die Mobilfunkroute genügt zum Beispiel ^\+491[5-7]\d{8,9}$; es deckt die deutschen Mobilfunkvorwahlen 015, 016 und 017 in E.164-Form mit +49 ab.

TIPP · Gleich noch die Routen ohne zweiten Kandidaten auflisten Für einen schnellen Überblick über alle Routen mit nur einem Gateway reicht eine Zeile. Sie ersetzt nicht die Prüfnummern, weil eine Route mit einem Gateway durchaus eine Backup-Route mit gleichem Muster haben kann. Aber sie zeigt dir, wo du genauer hinsehen musst: Get-CsOnlineVoiceRoute | Where-Object { $_.OnlinePstnGatewayList.Count -lt 2 } | Select-Object Identity, Priority, NumberPattern, OnlinePstnUsages, OnlinePstnGatewayList

 

Schritt 4: Usages, die in keiner Policy stecken

Backup-Routen in verwaisten Usages findest du, indem du die Usages aller Routen mit den Usages aller Policies vergleichst.

$inPolicies = Get-CsOnlineVoiceRoutingPolicy | ForEach-Object { $_.OnlinePstnUsages } | Sort-Object -Unique Get-CsOnlineVoiceRoute | Where-Object { -not ($_.OnlinePstnUsages | Where-Object { $inPolicies -contains $_ }) } | Select-Object Identity, Priority, NumberPattern, OnlinePstnUsages, OnlinePstnGatewayList

 

Was hier auftaucht, wird von keinem Benutzer verwendet. Das kann Absicht sein, etwa bei einer vorbereiteten Route für einen neuen Standort. Eine Route namens „Backup“ in dieser Liste ist aber fast immer ein Fehler.

Schritt 5: Was beim letzten Ausfall wirklich passiert ist

Konfiguration ist die eine Hälfte, Beweis die andere. Im Teams Admin Center unter Analysen und Berichte › Nutzungsberichte findest du den PSTN-Nutzungsbericht mit dem Reiter Direct Routing. Filtere auf den Zeitraum des Ausfalls und sieh dir den finalen SIP-Code, die Microsoft-Antwortphrase und den SBC je Anruf an. Lauter 503 auf sbc1 und null Versuche auf sbc2 bei Mobilfunknummern ist das Fehlerbild 1 in Reinform. Ein Code außerhalb von 408, 503 und 504 bei aktivem sbc2 in derselben Route spricht für Fehlerbild 4. Für eine systematische Auswertung über Wochen hinweg lohnt der Blick in Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl.

Die zweite Quelle ist das SBC-Log. Bei Problemen, die Microsoft gar nicht erst als Anruf verbucht, etwa weil das INVITE den SBC nie erreicht hat, steht die Wahrheit nur dort. Microsoft selbst verweist in der Dokumentation zur Überwachung von Direct Routing für solche Fälle auf die SBC-Logs.

Prüfung	Wo	Erwartung
Gateways aktiv	Get-CsOnlinePSTNGateway, Teams Admin Center › Direct Routing › SBCs	Enabled = True für alle eingeplanten SBCs
OPTIONS	Health Dashboard in Direct Routing	beide SBCs mit aktuellem OPTIONS-Status
Abdeckung je Nummernart	Prüfnummern-Skript	mindestens zwei aktive Gateways je Nummer
Rangfolge	Routen mit gleichem Muster, Priorität, Usage	Primär und Backup in derselben Usage
Antwortcodes	FailoverResponseCodes, SBC-Log	Ausfallcode des SBC steht in der Liste
Failover-Zeit	FailoverTimeSeconds, SBC-Log	deutlich über der normalen Antwortzeit des SBC

 

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Die Routing-Landkarte zeigt Voice Routing Policies, PSTN Usages, Voice Routes und Gateways in vier Spalten mit ihren Verbindungen. Deaktivierte Gateways und Routen, die nur auf sie zeigen, sind rot markiert, Usages ohne Policy gelb. Damit siehst du ohne Skript, welche Route nur an einem SBC hängt. Der Rufweg-Simulator spielt für einen Benutzer und eine Nummer den Weg vom Wählplan bis zum Gateway durch. In den Befunden stehen die gefundenen Lücken jeweils mit einem Prüffall, den du nachvollziehen kannst. Die Ansicht SIP-Fehlercodes je Gateway zeigt, welcher SBC mit welchen Codes antwortet, und die Drift-Erkennung meldet, wenn sich Routen oder Gateways seit dem letzten Stand geändert haben. Der Assistent für Routing fragt primären SBC und Failover-SBC getrennt ab und weist vor dem Anlegen auf deaktivierte Gateways hin. Mehr zum Werkzeug: Teams-Telefonie Diagnostiker. Du kannst es 15 Tage kostenlos testen.

 

Behebung und Failover-Test ohne Produktionsschaden

Bevor du etwas änderst, sicherst du den Stand. Das kostet zehn Sekunden und erspart dir im Ernstfall eine Rekonstruktion aus dem Gedächtnis.

$stand = Get-Date -Format "yyyyMMdd-HHmm" Get-CsOnlineVoiceRoute | Export-Clixml ".\routes-$stand.xml" Get-CsOnlinePSTNGateway | Export-Clixml ".\gateways-$stand.xml" Get-CsOnlineVoiceRoutingPolicy | Export-Clixml ".\vrp-$stand.xml"

 

Den zweiten SBC in alle relevanten Routen eintragen

Für Routen, in denen beide SBCs gleichwertig arbeiten sollen, setzt du die vollständige Gateway-Liste. Den vollständigen Wert zu setzen statt einen Eintrag hinzuzufügen, hat einen Vorteil: Du siehst im Befehl genau, wie die Route danach aussieht.

Set-CsOnlineVoiceRoute -Identity "DE-Mobil" ` -OnlinePstnGatewayList "sbc1.contoso.com", "sbc2.contoso.com"   # Rollback Set-CsOnlineVoiceRoute -Identity "DE-Mobil" -OnlinePstnGatewayList "sbc1.contoso.com"

 

Wiederhole das für Ausland, Sonderrufnummern und Notruf. Achte beim Notruf darauf, dass beide SBCs die Notrufnummern an ihren Trunk korrekt weitergeben, etwa mit der nötigen Standortkennung deines Providers. Ein zweiter SBC, der 112 falsch umsetzt, ist kein Failover, sondern ein zweites Risiko.

Primär und Backup sauber bauen

Soll sbc2 nur im Fehlerfall arbeiten, legst du zu jeder Primärroute eine Backup-Route mit identischem Muster, niedrigerer Priorität und derselben PSTN Usage an.

New-CsOnlineVoiceRoute -Identity "DE-Mobil-Backup" ` -NumberPattern "^\+491[5-7]\d{8,9}$" ` -OnlinePstnUsages "DE-National" ` -OnlinePstnGatewayList "sbc2.contoso.com" ` -Priority 3   # Rollback Remove-CsOnlineVoiceRoute -Identity "DE-Mobil-Backup"

 

Die Priorität bestimmt die Position unter allen Routen, die zur selben Nummer passen. Prüfe nach dem Anlegen mit Get-CsOnlineVoiceRoute | Sort-Object Priority, ob die Backup-Route wirklich direkt hinter ihrer Primärroute steht und nicht hinter einer allgemeineren Route, die dieselben Nummern ebenfalls abdeckt. Liegt eine solche Sammelroute dazwischen, wird sie vor der Backup-Route versucht.

WARNUNG · Ein Muster für Primär und Backup, nicht zwei ähnliche Kopiere das Muster der Primärroute wörtlich. Eine Backup-Route mit ^\+4917\d+$ neben einer Primärroute mit ^\+491[5-7]\d{8,9}$ deckt die Vorwahlen 015 und 016 nicht ab. Genau diese Nummern fallen dann beim Ausfall von sbc1 durch, und der Test mit deiner eigenen 017-Nummer zeigt grün.

 

Deaktivierte Gateways aktivieren

Set-CsOnlinePSTNGateway -Identity "sbc2.contoso.com" -Enabled $true   # Rollback (nimmt sbc2 aus dem Betrieb, laufende Gespräche bleiben bestehen) Set-CsOnlinePSTNGateway -Identity "sbc2.contoso.com" -Enabled $false

 

Bevor du einen SBC aktivierst, der lange nicht gearbeitet hat, prüfe im Health Dashboard, ob OPTIONS und TLS-Verbindung grün sind. Sonst aktivierst du einen Kandidaten, der beim ersten Anruf selbst scheitert. Ein aktiver SBC mit abgelaufenem Zertifikat hilft niemandem.

FailoverResponseCodes und FailoverTimeSeconds bewusst setzen

Die eleganteste Lösung für Fehlerbild 4 liegt meist nicht in Teams, sondern am SBC: Konfiguriere ihn so, dass er bei einem ausgefallenen Provider-Trunk mit 503 antwortet. Dann greift der Standardwert, und du musst in Teams nichts anfassen. Geht das nicht, ergänzt du die Liste in Teams um genau den Code, den dein SBC im Ausfall liefert, und nimmst die Standardwerte ausdrücklich mit.

# Vorher den aktuellen Wert notieren Get-CsOnlinePSTNGateway -Identity "sbc1.contoso.com" | Select-Object FailoverResponseCodes, FailoverTimeSeconds   # Standardwerte plus 500, nur wenn das SBC-Log 500 als Ausfallcode belegt Set-CsOnlinePSTNGateway -Identity "sbc1.contoso.com" -FailoverResponseCodes "408, 503, 504, 500"   # Rollback auf den Standard Set-CsOnlinePSTNGateway -Identity "sbc1.contoso.com" -FailoverResponseCodes "408, 503, 504"

 

FailoverTimeSeconds änderst du nur mit Messwerten. Liegt die Antwortzeit deines SBC im Log regelmäßig deutlich unter zehn Sekunden, bleibt der Standard. Kommt sie gelegentlich in die Nähe, erhöhst du moderat und dokumentierst den Grund. Den Wert zu senken, um schneller umzuschalten, klingt verlockend, erhöht aber das Risiko unnötiger Abbrüche, vor dem Microsoft ausdrücklich warnt.

Den Failover testen, ohne die Firma abzuschalten

Der naheliegende Test ist, sbc1 im Wartungsfenster zu deaktivieren und zu schauen, was passiert. Das ist erlaubt, aber grob. Es testet nur das Fehlerbild „Gateway deaktiviert“, nicht die Antwortcodes, nicht die Failover-Zeit, und es trifft alle Nummernarten gleichzeitig. Eleganter ist ein isolierter Rufweg für eine einzige Testnummer, der parallel zur Produktion läuft.

Testnummer festlegen. Du brauchst ein externes Ziel, das du selbst kontrollierst, im Beispiel +49 69 555 0199, etwa ein Diensthandy oder ein analoger Testanschluss. Niemals 110 oder 112.

Isolierte Konfiguration anlegen. Eine PSTN Usage Test-Failover, zwei Routen mit dem Muster ^\+49695550199$, Priorität 1 mit sbc1 und Priorität 2 mit sbc2, und eine Voice Routing Policy VRP-Test-Failover mit der Usage DE-Notruf vorn und Test-Failover dahinter. Diese Policy bekommt nur ein Testkonto wie test.failover@contoso.com.

Basistest ohne Störung. Testanruf auf die Testnummer. Er muss über sbc1 laufen. Das bestätigt, dass die Testkonfiguration greift.

Ablehnung am SBC. Auf sbc1 eine Regel anlegen, die nur INVITEs an +49 69 555 0199 ablehnt, und zwar mit dem Code, den sbc1 im echten Ausfall liefern würde. Testanruf: Der Anruf muss über sbc2 beim Testanschluss ankommen.

Zeitüberschreitung. Die Regel so ändern, dass sbc1 das INVITE für diese Nummer nicht beantwortet. Testanruf mit Stoppuhr: sbc2 muss nach ungefähr FailoverTimeSeconds übernehmen.

Aufräumen. Regel auf sbc1 entfernen, Testpolicy vom Testkonto nehmen, Testrouten, Usage und Policy löschen oder bewusst für den nächsten Test aufheben.

Der Trick liegt in Schritt 4. Weil die SBC-Regel nur eine einzige Zielnummer betrifft, merkt die Produktion nichts davon. Bei meinem eigenen anynode-SBC lege ich dafür eine zusätzliche Regel für genau diese Zielnummer an, die vor allen anderen ausgewertet wird und den Anruf abweist. Welcher Code dabei wirklich zu Teams zurückgeht, prüfe ich vorher im Log. Ein Test, der mit 403 statt 503 ablehnt, beweist nämlich nur, dass Teams bei 403 aufgibt, und das wussten wir schon.

WICHTIG · Warum die Notruf-Usage in der Testpolicy steht Das Testkonto bleibt ein Telefoniekonto. Wählt jemand damit im Ernstfall 112, muss der Notruf funktionieren. Deshalb steht DE-Notruf in der Testpolicy vorn. Den Failover der Notrufroute selbst testest du nicht mit echten Notrufen, sondern über die Konfigurationsprüfung aus Schritt 3 und, wenn nötig, in Absprache mit der Leitstelle. Wie das gelingt, steht in Notruf in Teams testen, ohne die Leitstelle zu verärgern.

 

Änderung	Rollback
Gateway in Route ergänzt	Set-CsOnlineVoiceRoute mit der vorherigen Gateway-Liste
Backup-Route angelegt	Remove-CsOnlineVoiceRoute für die Backup-Route
Gateway aktiviert	Set-CsOnlinePSTNGateway -Enabled $false
FailoverResponseCodes geändert	Set-CsOnlinePSTNGateway mit dem notierten alten Wert
FailoverTimeSeconds geändert	Set-CsOnlinePSTNGateway -FailoverTimeSeconds mit dem alten Wert
Testkonfiguration	Policy entziehen, Testrouten, Usage und Policy löschen, SBC-Regel entfernen

 

Vorbeugung: Damit der zweite SBC nicht nur Deko bleibt

Prüfnummernliste pflegen. Eine Nummer je Route, im Prüfnummern-Skript hinterlegt. Jede neue Route bekommt eine neue Prüfnummer, sonst ist sie nicht fertig.

Regel für neue Routen. Keine Route ohne zweiten Kandidaten, entweder als zweites Gateway oder als Backup-Route in derselben Usage. Ausnahmen sind dokumentiert und begründet.

Wartungsfenster mit Checkliste. Vor dem Deaktivieren eines SBC: Ist der andere aktiv und gesund? Nach der Wartung: Ist der SBC wieder auf Enabled = True?

Failover-Test im Kalender. Der isolierte Test aus dem vorigen Abschnitt dauert eine halbe Stunde. Einmal im Quartal und nach jedem größeren Umbau am SBC ist realistisch.

Änderungen beobachten. Routen und Gateways ändern sich schleichend. Wer regelmäßig den Stand exportiert und vergleicht, sieht eine verlorene Backup-Route, bevor der Ausfall sie findet.

Zum Vergleichen des Stands über die Zeit lies Konfigurationsdrift in der Teams-Telefonie erkennen. Wer die Regeln für neue Routen, Wartungsfenster und Tests verbindlich festhalten will, findet das Gerüst dafür in Microsoft Teams Telefonie-Governance.

TIPP · Kapazität des Backup-SBC nicht vergessen Ein Failover funktioniert technisch, und trotzdem bricht die Telefonie ein, wenn sbc2 oder sein Trunk nur für einen Bruchteil der Gespräche ausgelegt ist. Setze MaxConcurrentSessions auf die tatsächliche Kapazität. Microsoft alarmiert dann laut Dokumentation, sobald 90 Prozent erreicht sind. Das ersetzt keine Kapazitätsplanung, aber es meldet sich wenigstens.

 

Wenn du Redundanz von Grund auf planst, also Standorte, Trunks und SBCs zusammen, ist der richtige Zeitpunkt vor dem Routing, nicht danach. Dabei hilft das Festpreispaket Grobkonzept Teams-Telefonie, und wenn es schon brennt, die Beratung zur Teams-Telefonie.

WEITERLESEN · Passend dazu › Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen › Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen › SIP-Fehlercodes in Teams Direct Routing verstehen › Teams SBC inaktiv: OPTIONS-Ping und Verbindungsstatus prüfen › Teams SBC Grundlagen: der Session Border Controller › Teams-Telefonie Probleme: die zehn häufigsten Ursachen

 

FAQ

Ist ein zweiter SBC in derselben Route ein Failover oder eine Lastverteilung?

Beides. Microsoft versucht die Gateways einer Route in zufälliger Reihenfolge und weicht auf das andere aus, wenn eines nicht kann. Eine feste Rangfolge bekommst du nur über zwei Routen mit gleichem Muster und unterschiedlicher Priorität in derselben PSTN Usage.

Warum versucht Teams bei 486 Busy Here nicht den anderen SBC?

Weil 486 eine gültige Antwort ist: Der Angerufene ist besetzt. Für 4xx- und 6xx-Codes gilt der Anruf laut Microsoft als abgeschlossen, sofern der Code nicht in FailoverResponseCodes steht. Und 486 gehört dort auch nicht hinein.

Ich habe FailoverResponseCodes auf 500 gesetzt. Jetzt geht gar kein Failover mehr. Warum?

Weil der Parameter die Standardwerte ersetzt. Mit „500“ allein sind 408, 503 und 504 nicht mehr enthalten. Setze die Liste vollständig, also „408, 503, 504, 500“.

Wird ein SBC ohne OPTIONS komplett aus dem Routing genommen?

Nein. Laut Microsoft wird ein SBC, der in den letzten drei Minuten keine OPTIONS geschickt hat, herabgestuft. Er wird dann nicht als Erster versucht, aber noch einmal, bevor der Anruf endgültig scheitert. Ein deaktiviertes Gateway bekommt dagegen gar keine neuen Anrufe.

Warum landet ein weitergeleiteter Anruf immer auf demselben SBC, obwohl die Route zwei hat?

Microsoft bevorzugt bei Weiterleitung oder Übergabe eines eingehenden PSTN-Anrufs den SBC, über den der Anruf hereingekommen ist, sofern er auch als Ausgang in Frage kommt. Dessen Priorität wird dann ignoriert. Das ist kein Fehler, sondern dokumentiertes Verhalten.

Kann ich den Failover einfach durch Deaktivieren von sbc1 testen?

Ja, im Wartungsfenster. Laufende Gespräche bleiben bestehen, neue Anrufe gehen an andere Gateways der Route. Du testest damit aber nur das Fehlerbild „deaktiviertes Gateway“ und triffst alle Benutzer. Antwortcodes und Failover-Zeit prüfst du besser mit dem isolierten Test über eine einzige Testnummer.

Hilft eine zweite PSTN Usage in der Policy als Backup?

Nicht zuverlässig. Microsoft dokumentiert, dass die Usages der Reihe nach geprüft werden und nach einem Treffer in der ersten Usage die weiteren nicht ausgewertet werden. Die Backup-Route gehört deshalb in dieselbe Usage wie die Primärroute.

Gilt das alles auch für Operator Connect?

Bei Operator Connect betreibt der Anbieter die SBCs, und du siehst weder deren Routen noch deren Failover-Parameter. Die Fragen aus diesem Beitrag stellst du dann deinem Anbieter, am besten mit den Fehlerbildern als Checkliste.

Fazit: Redundanz zählt man in Routen, nicht in Gehäusen

Ein zweiter SBC ist schnell gekauft und schnell im Teams Admin Center eingetragen. Ob er im Ernstfall einen einzigen Anruf übernimmt, entscheiden andere Dinge: ob er in jeder relevanten Route steht, ob die Reihenfolge über Priorität statt über Hoffnung geregelt ist, ob er aktiviert ist, ob der Ausfallcode von sbc1 in der Failover-Liste steht und ob die Failover-Zeit zu deinem SBC passt. Alles davon lässt sich mit lesenden Befehlen in einer Stunde prüfen und mit einer einzigen Testnummer gefahrlos beweisen.

Der schwarze Humor der Sache: Ein fehlender Failover ist der einzige Fehler in der Teams-Telefonie, der sich garantiert nie im Normalbetrieb zeigt. Er wartet geduldig auf den ungünstigsten Moment. Nimm ihm diesen Spaß und such ihn vorher.