SIP-Fehlercodes in Teams Direct Routing verstehen

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Deine Erfolgsquote sinkt, und keiner weiß, ob Tenant, SBC oder Provider schuld ist? Wir sortieren das mit dir. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die SIP-Codes, Rufweg und SBC-Logs selbst lesen wollen, statt auf den nächsten Störfall zu warten. › Schulung Teams-Telefonie

 

SIP-Fehlercodes sind die Abschiedsbriefe der Telefonie: kurz, förmlich und in der Regel erst verständlich, wenn es zu spät ist. „403 Forbidden“, „504 Server Time-out“, „488 Not Acceptable Here“ klingen wie Absagen einer schlecht gelaunten Behörde, und genau so fühlen sie sich für deine Anwender an. Der Unterschied: Hinter jeder dieser Absagen steckt eine konkrete Stelle in deiner Konfiguration, und die lässt sich finden.

Dieser Beitrag ist für den Moment gedacht, in dem du mit einem konkreten Code vor dem Teams Admin Center sitzt oder ein Kollege „SIP 504“ in das Ticket geschrieben hat. Du erfährst, wie du die teams direct routing sip fehlercodes liest, wer sie erzeugt hat, wo du sie siehst und mit welchen lesenden PowerShell-Befehlen du die Ursache eingrenzt. Die Grundlagen zu Direct Routing, Session Border Controller und Routing wiederholen wir hier nicht; die 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 hängen gemeinsam in den Voice Routes, Rufnummern im Muster +49 69 555 0100 (Frankfurt) und +49 221 555 0100 (Köln). Die Testbenutzerin heißt Anna Berger (anna.berger@contoso.com), Durchwahl +49 69 555 0142. Alle Codes, Bedeutungen und Standardwerte stammen aus der Microsoft-Dokumentation zu Direct Routing, Stand November 2026. Microsoft ergänzt die Liste der Subcodes laufend; wenn du einen Code findest, der hier fehlt, gilt die Logik trotzdem.

 

Das Symptom: wie SIP-Fehler im Alltag aussehen

Was Anwender sagen

Anwender sehen keine SIP-Codes. Sie sehen ein Teams-Fenster, das kurz „Wird angerufen …“ zeigt und dann ohne Ton wieder verschwindet. Was im Helpdesk ankommt, klingt deshalb ungefähr so:

„Anrufe nach draußen gehen nicht, intern geht alles.“ Klassiker für 403 aus dem Tenant: Policy, Lizenz oder keine passende Voice Route.

„Bei mir klingelt es einmal, dann ist Schluss.“ Oft 504 oder 408: Microsoft erreicht den SBC nicht oder bekommt keine rechtzeitige Antwort.

„Kunden sagen, ich sei nicht erreichbar, aber mein Teams ist an.“ Eingehend 404 mit Subcode 511404: Die Nummer kommt in einem Format an, das keinem Benutzer zugeordnet ist.

„Der Anruf wird angenommen und bricht sofort ab.“ Häufig 488: Medien konnten nicht ausgehandelt werden, etwa wegen Codec oder SRTP.

„Seit heute Morgen geht in Köln gar nichts mehr.“ Wenn ein ganzer Standort ausfällt, ist es fast nie der Benutzer. Zertifikat, DNS, Firewall oder ein überlasteter SBC sind die üblichen Verdächtigen.

Was Admins sehen

Als Admin siehst du die gleiche Geschichte in Zahlen. Im Health Dashboard für Direct Routing sinkt die Netzwerkeffektivität eines SBC, im PSTN-Nutzungsbericht stehen Zeilen mit dem Ereignistyp „Attempt“ statt „Success“, und in den Spalten „Final SIP code“, „Final Microsoft subcode“ und „Final SIP phrase“ steht die eigentliche Begründung. Im SBC-Log wiederum liegen Absagen, die Microsoft nie zu Gesicht bekommen hat. Der häufigste Fehler in dieser Lage ist nicht technisch: Man liest nur den dreistelligen SIP-Code, sucht ihn im Internet und landet bei einer allgemeinen Erklärung, die mit Teams nichts zu tun hat. Der eigentliche Hinweis steckt im Microsoft-Subcode.

WICHTIG · Erst die Herkunft, dann die Ursache Ein 403 kann bedeuten, dass Teams den Benutzer nicht nach draußen telefonieren lässt, dass keine Voice Route passt oder dass dein SBC den Anruf abgelehnt hat. Das sind drei völlig verschiedene Baustellen. Welche es ist, entscheidet der Microsoft-Subcode, nicht der SIP-Code.

 

Wie ein SIP-Fehlercode in Direct Routing entsteht

Die Kette vom Wählen bis zum Netz

Ein abgehender Anruf läuft durch eine feste Kette: Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC › SIP-Provider › Ziel. An jeder Station kann der Anruf scheitern, und je nachdem, wo das passiert, entsteht ein anderer Code. Scheitert es im Tenant, etwa weil die Voice Routing Policy keine Usage mit passender Route enthält, erzeugt ein Microsoft-Dienst die Absage. Scheitert es am SBC oder dahinter beim Provider, schickt der SBC die Absage zurück, und Microsoft reicht sie mit einem eigenen Stempel weiter. Wie die einzelnen Glieder der Kette zusammenspielen, erklärt Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen ausführlich.

SIP-Code und Microsoft-Subcode

Microsoft meldet bei Direct Routing zwei Codes, die du immer zusammen lesen solltest. Der SIP-Antwortcode (in Anrufprotokollen als CallEndReason) ist der bekannte dreistellige Code nach RFC 3261 und sagt, was passiert ist. Der Microsoft-Antwortcode (CallEndSubReason) ist meist sechs Stellen lang, kann aber laut Microsoft auch kürzer oder länger sein, und sagt, warum es passiert ist. Im Teams Admin Center heißen die beiden „Final SIP code“ und „Final Microsoft subcode“.

560 heißt: Diesmal war es der SBC

Die wichtigste Regel des ganzen Beitrags passt in einen Satz: Beginnt der Microsoft-Subcode mit 560, hat dein SBC die endgültige SIP-Antwort erzeugt, und die letzten drei Ziffern sind der SIP-Code. 560403 ist also ein 403 vom SBC, 560503 ein 503 vom SBC. Alle anderen Subcodes stammen von einem Microsoft-Dienst. Microsoft empfiehlt bei 560er-Codes ausdrücklich, mit den SBC-Logs zu beginnen und gegebenenfalls den SBC-Hersteller einzubeziehen. Ob der SBC selbst ablehnt oder nur die Absage des Providers durchreicht, verrät dir erst sein Log.

WARNUNG · Was Microsoft nicht sieht, steht in keinem Bericht Call Analytics und die Berichte im Teams Admin Center helfen nur, wenn der Anruf die internen Komponenten von Direct Routing erreicht hat. Lehnt Microsoft ein INVITE vom SBC schon an der Tür ab, zum Beispiel weil der FQDN des Trunks falsch eingetragen ist, findest du die Begründung laut Microsoft nur im SBC-Log. Wer dann stundenlang im Admin Center sucht, sucht im falschen Gebäude.

 

Failover: Welche Codes einen zweiten SBC bekommen

Bei Direct Routing entscheidet der Code auch darüber, ob Microsoft es noch einmal über einen anderen SBC versucht. Laut Dokumentation von Set-CsOnlinePSTNGateway gilt ein abgehender Anruf bei jeder 4xx- oder 6xx-Antwort standardmäßig als abgeschlossen. Nur die Codes im Parameter FailoverResponseCodes lösen einen Versuch über den nächsten SBC aus; der Standard ist 408, 503, 504. Dazu kommt FailoverTimeSeconds mit dem Standard 10: Antwortet der SBC nicht innerhalb von zehn Sekunden, geht der Anruf zum nächsten Trunk, und gibt es keinen, wird er beendet. Microsoft dokumentiert diesen Fall als Subcode 500001 mit SIP 408.

Daraus folgt eine unangenehme Wahrheit: Ein 404 oder 403 vom Provider landet nie auf dem zweiten SBC, ganz gleich, wie redundant du gebaut hast. Wenn dein Failover trotz zweier SBCs nicht greift, lohnt der Blick in SBC-Failover in Teams funktioniert nicht.

Die wichtigsten SIP-Fehlercodes in Teams Direct Routing

Die folgende Tabelle fasst die Codes zusammen, die dir in Direct Routing am häufigsten begegnen. Die Subcodes und Empfehlungen stammen aus Microsofts Seiten „Microsoft and SIP response codes“ für Direct Routing. Für 487 gibt es dort keine eigene Seite; die Einordnung folgt der allgemeinen SIP-Bedeutung.

Code	Bedeutung	Typische Ursache in Direct Routing (Subcode)	Erster Prüfschritt
403 Forbidden	Anruf wird verweigert	510560: Benutzer nicht für Enterprise Voice aktiviert. 510562: keine abgehenden PSTN-Anrufe erlaubt. 510559: keine passende Voice Route (No viable path). 510532: Anruf kommt von einem SBC-FQDN, der nicht zum Tenant gehört. 510534: Anrufernummer eingehend blockiert.	Get-CsOnlineUser (EnterpriseVoiceEnabled, Policy), Routen gegen die Nummer testen, Get-CsOnlinePSTNGateway
404 Not Found	Ziel nicht gefunden	511404: eingehende Nummer bei der Rückwärtssuche keinem Benutzer oder Ressourcenkonto zugeordnet, meist Format statt E.164. 10202: Ersatzanruf bei Übergabe nicht gefunden. 560404: SBC oder Provider kennt das Ziel nicht.	Get-CsPhoneNumberAssignment mit der Nummer in E.164, Format am SBC prüfen
408 Request Timeout	Keine Antwort in der Zeit	500001: Failover-Timer abgelaufen, SBC hat nicht innerhalb von FailoverTimeSeconds geantwortet. 560408: SBC meldet, dass das Ziel nicht antwortet. 1106: SBC hat das 200 OK nicht bestätigt.	FailoverTimeSeconds am Gateway, SBC-Log, Häufung nach Zielland
480 Temporarily Unavailable	Vorübergehend nicht erreichbar	10037: Angerufener in keinem Teams-Client angemeldet. 10191: Weiterleitung an Voicemail per Richtlinie deaktiviert. 560480: Absage vom SBC oder Provider.	Anmeldung des Benutzers, Voicemail-Einstellungen, SBC-Log
486 Busy Here	Besetzt	Ziel besetzt, meist völlig normal. 10321: ein Bot (zum Beispiel Aufzeichnung) lehnt ab, weil ausgelastet.	Nur bei Häufung: Bot, Warteschlange oder Weiterleitung prüfen
487 Request Terminated	Anfrage abgebrochen	Anrufer hat vor der Annahme aufgelegt oder ein paralleler Zweig wurde beendet, etwa bei gleichzeitigem Klingeln oder Warteschlangen.	Normalfall. Nur prüfen, wenn Anrufer wiederholt vor der Annahme verlieren
488 Not Acceptable Here	Medien nicht akzeptiert	531000: kein akzeptabler Codec im SDP oder SRTP fehlt. 531027: keine ICE-Kandidaten bei Media Bypass (ICE Lite am SBC). 531052: SDP mit Adresse 0.0.0.0.	Codec-, SRTP- und ICE-Lite-Einstellung des Teams-Profils am SBC
500 Server Internal Error	Interner Fehler	510482: Schleife durch endlose Weiterleitung. 510544: keine Trunk-Konfiguration für abgehend gefunden, auch für Notrufbenutzer. 540500: doppelte INVITEs vom SBC bei Übergaben.	Weiterleitungen, Gateways in den Routen, Notruf-Routing-Richtlinie
503 Service Unavailable	Dienst nicht verfügbar	560503: SBC in Wartung oder überlastet, oft fehlende Sitzungslizenzen. 540998: Microsoft-Endpunkt in Wartung, bei Häufung DNS-Auflösung am SBC zu selten. 10320: Bot nicht erreichbar.	SBC-Log und Lizenzen, DNS-Cache des SBC, Häufung je Ziel
504 Server Time-out	Gegenstelle antwortet nicht	569002: TLS- oder TCP-Verbindung zum SBC scheitert, Firewall, Port. 569008: SBC-Zertifikat abgelaufen. 569009: nicht vertrauenswürdige Stammzertifizierungsstelle. 569015 und 569016: DNS findet keinen A- oder AAAA-Eintrag.	Health Dashboard (TLS), Zertifikat, DNS-Auflösung, Firewall
560xxx	Antwort stammt vom SBC	Die letzten drei Ziffern sind der SIP-Code, den der SBC geschickt hat, zum Beispiel 560403 oder 560503. Ursache liegt am SBC oder beim Provider dahinter.	SBC-Log, bei Provider-Absagen Ticket beim Provider

 

FAKTEN · Was im Health Dashboard als Erfolg zählt Die Netzwerkeffektivität (Network Effectiveness Ratio) im Health Dashboard berechnet Microsoft als 100 × (angenommene Anrufe + Besetzt + Klingeln ohne Annahme + Abweisung durch das Endgerät) / alle Anrufe. Besetzt und unbeantwortet gelten also als zugestellt. Ein 504 vom SBC dagegen senkt den Wert. Bei weniger als 100 ausgewerteten Anrufen kann der Wert laut Microsoft niedrig und trotzdem normal sein.

 

Tenant-Fehler: 403, 404 und 500 mit Microsoft-Subcode

Steht kein 560 vor dem Subcode, liegt der Fehler bei Microsoft im Tenant, also bei dir. Das ist die gute Nachricht, denn hier kannst du alles selbst prüfen. 510560 und 510562 sind Lizenz- und Aktivierungsthemen: Benutzer ohne Teams Phone, ohne Enterprise Voice oder ohne passende Zuweisung. 510559 ist der Klassiker „keine passende Route“: Die gewählte Nummer passt auf kein Rufnummernmuster einer Voice Route, die über die PSTN Usages in der Voice Routing Policy des Benutzers erreichbar ist. Das kann an der Route selbst liegen, siehe Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen, an einer Normalisierung, die eine falsche Nummer erzeugt, siehe Normalisierungsregeln in Teams: typische Fehler und wie du sie findest, oder schlicht daran, dass der Benutzer auf eine andere Policy fällt als gedacht, siehe Teams-Benutzer fällt auf die globale Richtlinie zurück.

Eingehend ist 511404 der häufigste Tenant-Code. Microsoft sucht zur angerufenen Nummer einen Benutzer oder ein Ressourcenkonto und findet keinen. Fast immer liefert der SBC oder Provider die Nummer in einem anderen Format als dem, das in Teams zugewiesen ist, etwa 069 555 0142 oder nur die Durchwahl statt +49695550142. Microsoft erwartet laut Dokumentation in der Regel E.164 mit Länder- und Ortskennzahl. Wie du eingehende Anrufe systematisch prüfst, beschreibt Eingehende Anrufe kommen in Teams nicht an.

WARNUNG · 500 mit 510544 beim Notruf ernst nehmen Die Kombination 500 mit dem Subcode 510544 und der Phrase „failed getting direct routing gateways for emergency user“ bedeutet laut Microsoft, dass für einen Notrufbenutzer kein Gateway gefunden wurde. Microsoft verweist dafür auf die Emergency Call Routing Policies. Das ist kein Schönheitsfehler, sondern ein Notruf, der nicht rausgeht. Prüfe Route, Usage und Notruf-Richtlinie für 110 und 112 sofort; wie das sauber aufgebaut wird, steht in Notruf in Microsoft Teams konfigurieren.

 

Verbindungsfehler: 504 und 408 zwischen Microsoft und SBC

504 ist der Code, der Admins nachts wach hält, und das aus gutem Grund: Er betrifft meist nicht einen Benutzer, sondern einen ganzen SBC. Die Phrase verrät die Ursache recht genau. „TLS negotiation failed“ mit SEC_E_CERT_EXPIRED (569008) heißt abgelaufenes SBC-Zertifikat, SEC_E_UNTRUSTED_ROOT (569009) eine Zertifizierungsstelle, der Direct Routing nicht vertraut, „No such host is known“ (569015) einen DNS-Namen, der sich nicht auflösen lässt, und „target machine actively refused it“ (569002) eine Firewall oder einen falschen Port. Der Fall, dass nach einem Zertifikatswechsel plötzlich nichts mehr geht, ist so häufig, dass er einen eigenen Beitrag hat: SIP 504 nach dem Zertifikatswechsel: Root-CAs am SBC aktualisieren.

408 mit 500001 sieht ähnlich aus, ist aber oft harmloser: Der SBC hat innerhalb der FailoverTimeSeconds nicht geantwortet. Microsoft nennt als typischen Grund lange Verbindungsaufbauzeiten im Telefonnetz mancher Regionen und schlägt vor, den Timer dort auf 20 Sekunden zu erhöhen. Bevor du das tust, prüfst du aber im SBC-Log, ob der SBC das INVITE überhaupt bekommen hat. Ein SBC, der keine SIP-OPTIONS mehr schickt, wird laut Microsoft nach drei ausbleibenden Intervallen von je einer Minute zurückgestuft; mehr dazu in Teams SBC inaktiv: OPTIONS-Ping und Verbindungsstatus prüfen.

SBC und Provider: 560xxx, 488 und 503

Alles mit 560 vorne gehört ins SBC-Log. Dort siehst du, ob der SBC selbst ablehnt, etwa weil eine Manipulationsregel die Nummer zerlegt hat, oder ob er nur die Antwort des Providers weitergibt. Ein 560404 bedeutet in der Praxis oft, dass der Provider die Nummer in dem Format, das dein SBC schickt, nicht kennt. Ein 560503 kann laut Microsoft auf einen überlasteten oder in Wartung befindlichen SBC hinweisen; Microsoft empfiehlt ausdrücklich, die Lizenzierung der gleichzeitigen Sitzungen zu prüfen und zu schauen, ob der Fehler nur bestimmte Zielländer betrifft.

488 ist das Codec-Missverständnis unter den Fehlercodes. Microsoft unterscheidet mehrere Fälle: Der SBC bietet keinen unterstützten Codec an, er bietet kein SRTP an, oder er liefert bei aktivem Media Bypass keine ICE-Kandidaten, weil ICE Lite am SBC nicht eingeschaltet ist. Gerade der letzte Fall taucht gern nach dem Einschalten von Media Bypass auf, siehe Teams Media Bypass und Local Media Optimization. Wenn der Anruf zwar zustande kommt, aber stumm bleibt, liegt das Problem dagegen meist nicht in der Aushandlung, sondern im Medienweg, siehe Einseitiges Audio oder kein Ton bei Teams Direct Routing.

AUS DER PRAXIS · Ulis eigener SBC und der Codec, den keiner bestellt hat In meinem eigenen Labor läuft ein anynode-SBC zwischen Teams und einem SIP-Trunk. Nach einem Umbau des Medienprofils auf der Teams-Seite kamen abgehende Anrufe für einige Ziele mit 488 zurück. Der Subcode begann nicht mit 560, die Absage kam also von Microsoft, und die Phrase sprach von „no media acceptable“. Ein Blick ins Log zeigte, dass das SDP an Teams nur noch einen Codec enthielt, den ich beim Aufräumen für den Provider-Trunk gedacht hatte. Profil zurückgesetzt, Fehler weg. Moral: Codec-Listen gehören je Seite getrennt gepflegt, und Aufräumen ohne Vorher-Export ist Mutprobe, nicht Wartung.

 

Normale Absagen: 480, 486 und 487

Nicht jeder Code ist ein Fehler. 486 heißt besetzt, 487 heißt, dass jemand vor der Annahme aufgelegt hat oder ein paralleler Klingelzweig beendet wurde. In Warteschlangen und beim gleichzeitigen Klingeln entstehen solche Abbrüche ganz regulär, weil nur einer abnehmen kann und die anderen Zweige abgeräumt werden. Auch 480 mit 10037 ist meist kein Konfigurationsfehler, sondern ein Benutzer, der in keinem Teams-Client angemeldet ist. Spannend werden diese Codes erst, wenn sie sich häufen. Legen Anrufer in einer Warteschlange reihenweise auf, ist das eher eine Frage von Timeout und Überlauf als von SIP: Teams-Warteschlange legt auf: Überlauf und Timeout richtig einstellen.

Diagnose Schritt für Schritt

Wo du die Codes siehst

SIP-Fehlercodes tauchen an drei Stellen auf, und jede zeigt einen anderen Ausschnitt. Microsoft nennt das Teams Admin Center und den Power-BI-Bericht „Quality of Experience Report (QER) for PSTN“ als Orte, an denen die Codes gemeldet werden. Für den Alltag reichen meist die folgenden drei.

Quelle	Wo	Was du dort siehst	Grenzen
Health Dashboard für Direct Routing	Teams Admin Center › Sprache (Voice) › Direct Routing	Je SBC: Netzwerkeffektivität, durchschnittliche Anrufdauer, TLS-Status mit Warnung 30 Tage vor Zertifikatsablauf, SIP-OPTIONS-Status, gleichzeitige Anrufe, Jitter, Paketverlust, Latenz	Zeigt Trends und Zustand, aber keinen einzelnen Anruf mit Begründung
PSTN-Nutzungsbericht, Reiter Direct Routing	Teams Admin Center › Analysen und Berichte › Nutzungsberichte	Je Anruf: Final SIP code, Final Microsoft subcode, Final SIP phrase, SBC FQDN, Ereignistyp; Klick auf den Code öffnet den SIP-Anruffluss als Leiterdiagramm	Bericht laut Microsoft meist mit 24 bis 48 Stunden Verzug; SIP-Anruffluss nur für Anrufe der letzten 30 Tage, Daten bis zu 30 Minuten verzögert
SBC-Log	Auf deinem SBC	Vollständige SIP-Nachrichten in beide Richtungen, auch zum Provider	Muss aktiv sein und lange genug aufbewahrt werden; Formate je Hersteller verschieden

 

TIPP · Export für Muster statt Einzelfälle Den Direct-Routing-Bericht kannst du als CSV exportieren. Laut Microsoft geht das bis zu 150 Tage zurück, für Deutschland beträgt die Aufbewahrung im Direct-Routing-Bericht ebenfalls 150 Tage. Im Export filterst du nach Final SIP code und Microsoft subcode und siehst sofort, ob ein Fehler einen SBC, einen Standort oder ein Zielland betrifft. Microsoft empfiehlt genau das etwa bei 560408: nach gehäuften Zielnummern oder Zielländern suchen. Wer das regelmäßig auswerten will, findet in Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl den Weg über Call Records.

 

Schritt 1: Herkunft und Umfang bestimmen

Öffne im PSTN-Nutzungsbericht den Reiter Direct Routing, filtere auf den betroffenen Benutzer oder Zeitraum und notiere für zwei, drei fehlgeschlagene Anrufe SIP-Code, Microsoft-Subcode, Phrase und SBC FQDN. Dann beantwortest du zwei Fragen: Beginnt der Subcode mit 560? Betrifft der Fehler einen Benutzer, einen SBC oder alle? Ein Benutzer deutet auf Policy oder Lizenz, ein SBC auf Verbindung oder SBC-Konfiguration, alle zusammen auf etwas Grundsätzliches wie eine geänderte Route.

Schritt 2: Zustand der SBCs prüfen

Im Health Dashboard schaust du dir den betroffenen SBC an: TLS-Status, SIP-OPTIONS-Status und den Zeitpunkt der letzten OPTIONS. Parallel liest du die Gateway-Konfiguration mit PowerShell aus. Alle Befehle in diesem Abschnitt sind rein lesend und benötigen das Modul MicrosoftTeams.

Connect-MicrosoftTeams   # Gateways mit den für Fehlercodes relevanten Eigenschaften Get-CsOnlinePSTNGateway | Select-Object Identity, Enabled, SipSignalingPort, SendSipOptions, FailoverResponseCodes, FailoverTimeSeconds, MaxConcurrentSessions, MediaBypass

 

Achte auf drei Dinge: Ist Enabled auf True? Ein neu angelegtes Gateway ist laut Microsoft standardmäßig deaktiviert. Stehen in FailoverResponseCodes noch 408, 503 und 504, oder hat jemand die Liste überschrieben? Und passt FailoverTimeSeconds zu deinem Provider?

Schritt 3: Rufweg des Benutzers nachvollziehen

Bei 403 und 500 ohne 560 prüfst du den Weg des Benutzers durch den Tenant. Das Beispiel nimmt Anna Berger, die eine Kölner Nummer nicht erreicht.

$upn = "anna.berger@contoso.com"   # Telefonie-Grunddaten des Benutzers Get-CsOnlineUser -Identity $upn | Select-Object DisplayName, LineUri, EnterpriseVoiceEnabled, OnlineVoiceRoutingPolicy, TenantDialPlan   # Wirksame Voice Routing Policy (auch bei Gruppenzuweisung) Get-CsUserPolicyAssignment -Identity $upn -PolicyType OnlineVoiceRoutingPolicy   # Was macht der Wählplan aus der gewählten Nummer? Test-CsEffectiveTenantDialPlan -Identity $upn -DialedNumber "02215550199"   # Welche Usages stehen in der Policy? Get-CsOnlineVoiceRoutingPolicy -Identity "DE-Frankfurt" | Select-Object -ExpandProperty OnlinePstnUsages   # Welche Voice Routes passen auf die normalisierte Nummer? $nummer = "+492215550199" Get-CsOnlineVoiceRoute | Where-Object { $nummer -match $_.NumberPattern } | Select-Object Identity, Priority, NumberPattern, OnlinePstnUsages, OnlinePstnGatewayList

 

Der Vergleich mit -match funktioniert, weil PowerShell wie Teams .NET-Regex verwendet. Passt eine Route, deren Usage nicht in der Policy des Benutzers steht, hast du die Ursache für 510559 gefunden. Ein Muster wie ^\+49221\d+$ würde zum Beispiel alle Kölner Nummern in E.164 erfassen. Steht die Nummer nach der Normalisierung nicht in E.164 da, liegt der Fehler eine Station früher im Wählplan.

Für eingehende 404 mit 511404 drehst du die Frage um und suchst, wem die Nummer gehört:

# Wem ist die Nummer zugewiesen? (Nummer in E.164) Get-CsPhoneNumberAssignment -TelephoneNumber "+49695550142" | Select-Object TelephoneNumber, AssignedPstnTargetId, NumberType, ActivationState   # Bei 403 mit 510534: Ist die Anrufernummer eingehend gesperrt? Get-CsInboundBlockedNumberPattern | Select-Object Identity, Pattern, Enabled

 

Findet der erste Befehl die Nummer, ist die Zuordnung in Teams in Ordnung, und das Problem liegt im Format, das der SBC schickt. Das siehst du im SIP-Anruffluss in der Request-URI des INVITE.

Schritt 4: SIP-Anruffluss und SBC-Log lesen

Im PSTN-Nutzungsbericht klickst du auf den Final SIP code eines Anrufs und bekommst den SIP-Anruffluss: ein Leiterdiagramm aller Nachrichten zwischen Microsoft SIP-Proxy und deinem SBC, jede Nachricht mit Details. Dafür brauchst du laut Microsoft die Rolle Teams-Administrator oder Teams-Telefonieadministrator. Dort siehst du, ob das INVITE die erwartete Nummer enthält, welcher Codec angeboten wurde und wer zuerst eine Fehlermeldung geschickt hat. Alles, was dahinter Richtung Provider passiert, findest du nur im SBC-Log. Bei 560er-Codes ist das Log deshalb nicht der dritte, sondern der erste Schritt.

TIPP · Microsofts eingebaute SBC-Tests Im Teams Admin Center unter Sprache › Direct Routing gibt es den Reiter „SBC test cases“. Dort legst du Testsuiten für einen SBC an, etwa Outbound-Inbound, gleichzeitiges Klingeln, Medieneskalation und Rückfrageübergabe, und bekommst Ergebnisse mit Hinweisen zu Tenant-, Benutzer- und Richtlinienkonfiguration. Für die Tests braucht es einen Testbenutzer mit eigenen Anmeldedaten; nimm dafür ein eigenes Testkonto, nicht das Konto der Geschäftsführung.

 

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Im Bereich Anrufqualität zeigt die Ansicht „SIP-Fehlercodes je Gateway“ für jeden SBC den Anteil der SIP-Ergebnisse, getrennt nach 200 OK und den Fehlercodes wie 404, 408, 480, 486, 487, 488 und 503, jeweils für die letzten sieben Tage und den Gesamtzeitraum. Eine Tabelle darunter fasst Anrufe, Erfolgsquote und technische Fehler je Gateway zusammen. So siehst du, ob ein Code an einem SBC gehäuft auftritt oder sich gleichmäßig verteilt, bevor du ins Log gehst. Bei Tenant-Fehlern wie 510559 hilft der Rufweg-Simulator, der den Weg einer gewählten Nummer durch Wählplan, Policy, Usage und Route nachstellt. Die Befunde mit Prüffall halten fest, welche Abweichung gefunden wurde und wie du sie nachprüfst. Mehr dazu auf der Seite Teams-Telefonie Diagnostiker. Du kannst ihn 15 Tage kostenlos testen.

 

Beheben, zurückrollen, vorbeugen

Behebung je Code mit Rollback

Die Diagnose war lesend, die Behebung ist es nicht. Deshalb gilt vor jeder Änderung: aktuellen Stand sichern, eine Sache ändern, testen, erst dann die nächste. Die Tabelle nennt die üblichen Maßnahmen und den Weg zurück.

Code und Subcode	Maßnahme	Rollback
403 / 510560, 510562	Teams-Phone-Lizenz prüfen, Enterprise Voice aktivieren, Voice Routing Policy zuweisen	Zuweisung mit dem vorher notierten Wert wiederherstellen
403 / 510559	Fehlende Usage in die Policy aufnehmen oder Route ergänzen; vorher mit -match testen	Usage-Liste aus dem Export vor der Änderung zurückschreiben
404 / 511404	Format am SBC auf E.164 bringen oder eingehende Übersetzungsregel am Gateway setzen; nur an einer Stelle	SBC-Konfiguration aus Sicherung, Übersetzungsregel vom Gateway entfernen
408 / 500001	FailoverTimeSeconds am Gateway erhöhen, laut Microsoft etwa auf 20 Sekunden	Vorherigen Wert, Standard 10, wieder setzen
488 / 531000, 531027	Codec- und SRTP-Einstellung des Teams-Profils am SBC korrigieren, bei Media Bypass ICE Lite aktivieren	SBC-Konfiguration aus Sicherung; Media Bypass am Gateway wieder ausschalten
503 / 560503	Sitzungslizenzen und Last am SBC prüfen, mit dem Hersteller klären	Keine Änderung im Tenant nötig
504 / 569008, 569009	Zertifikat erneuern, vollständige Kette einspielen, alte TLS-Verbindungen in einem Wartungsfenster neu aufbauen	Altes Zertifikat nur bis zum Ablaufdatum als Notlösung
504 / 569015, 569016	A- oder AAAA-Eintrag für den SBC-FQDN anlegen oder korrigieren	DNS-Eintrag auf den alten Wert zurück

 

Für Gateway-Änderungen sieht das so aus. Erst lesen und den Wert sichern, dann ändern:

# Vorher: aktuellen Stand sichern Get-CsOnlinePSTNGateway -Identity sbc1.contoso.com | Select-Object Identity, FailoverTimeSeconds, FailoverResponseCodes | Export-Csv .\sbc1-vorher.csv -NoTypeInformation -Encoding UTF8   # Ändern Set-CsOnlinePSTNGateway -Identity sbc1.contoso.com -FailoverTimeSeconds 20   # Rollback Set-CsOnlinePSTNGateway -Identity sbc1.contoso.com -FailoverTimeSeconds 10

 

WARNUNG · FailoverResponseCodes überschreibt, ergänzt nicht Wer im Parameter FailoverResponseCodes eigene Codes setzt, ersetzt laut Microsoft die Standardliste. Wer also nur 480 eintragen möchte, verliert damit stillschweigend den Failover bei 408, 503 und 504. Wenn du die Liste änderst, schreibst du die Standardcodes ausdrücklich mit hinein. Und überleg dir gut, ob ein zusätzlicher Code wirklich ein Infrastrukturproblem anzeigt. Einen 404 vom Provider über den zweiten SBC noch einmal zu probieren, macht die Nummer auch nicht existenter.

 

WICHTIG · Zertifikat erneuert und trotzdem Warnung? Microsoft weist darauf hin, dass nach der Erneuerung des SBC-Zertifikats die alten TLS-Verbindungen, die noch mit dem alten Zertifikat aufgebaut wurden, beendet werden müssen. Sonst bleiben die Ablaufwarnungen im Teams Admin Center bestehen. Microsoft empfiehlt dafür einen Neustart des SBC in einem verkehrsarmen Zeitfenster oder das Vorgehen nach Anleitung des Herstellers.

 

Vorbeugung: damit der Code gar nicht erst kommt

Health Dashboard regelmäßig ansehen. Die Warnung 30 Tage vor Zertifikatsablauf nützt nur, wenn sie jemand liest. Ein fester Termin im Betriebskalender ist billiger als ein 504 am Montagmorgen.

SIP-OPTIONS eingeschaltet lassen. SendSipOptions steht standardmäßig auf True. Ohne OPTIONS fällt der SBC laut Microsoft aus Überwachung und Alarmierung heraus.

MaxConcurrentSessions setzen. Ist der Wert gesetzt, alarmiert Microsoft ab 90 Prozent Auslastung. Das ist die Frühwarnung vor 560503.

DNS am SBC häufig auflösen. Microsoft empfiehlt, die SIP-Signalisierungs-FQDNs etwa alle 15 Minuten oder öfter aufzulösen. Das vermeidet 540998 bei Wartungsarbeiten auf Microsoft-Seite.

Nummernformat an einer Stelle festlegen. E.164 zwischen SBC und Teams, Umformungen entweder am SBC oder in den Übersetzungsregeln, nie an beiden. Das verhindert 404 und 511404.

Fehlerquote je SBC beobachten. Ein Export des Direct-Routing-Berichts pro Woche, gefiltert nach Final SIP code, zeigt Trends lange bevor der Helpdesk sie meldet.

Änderungen dokumentieren. Die meisten Fehlercodes nach einem ruhigen Wochenende haben eine Ursache, die jemand am Freitag „nur kurz“ geändert hat. Ein Änderungsprotokoll spart dir die Detektivarbeit.

Zum letzten Punkt gehören zwei Vertiefungen: Konfigurationsdrift in der Teams-Telefonie erkennen zeigt, wie du ungeplante Änderungen an Routen, Gateways und Policies erkennst, und Microsoft Teams Telefonie-Governance regelt, wer sie überhaupt vornehmen darf. Wenn deine Fehlerquote seit Monaten über dem liegt, was du für normal hältst, und Tenant, SBC und Provider sich gegenseitig die Schuld zuschieben, ist das ein gutes Thema für eine Beratung zur Teams-Telefonie. Wer SIP-Codes, SIP-Anruffluss und SBC-Logs lieber einmal in Ruhe üben möchte als nachts im Störfall, ist in der Schulung Teams-Telefonie richtig.

WEITERLESEN · Passend dazu › Teams-Telefonie Probleme: die zehn häufigsten Ursachen › Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen › SIP 504 nach dem Zertifikatswechsel: Root-CAs am SBC aktualisieren › SBC-Failover in Teams funktioniert nicht › Teams SBC inaktiv: OPTIONS-Ping und Verbindungsstatus prüfen › Teams SBC Grundlagen: der Session Border Controller

 

FAQ

Was bedeutet der Microsoft-Subcode 560 vor dem SIP-Code?

Beginnt der Microsoft-Subcode mit 560, hat dein SBC die endgültige SIP-Antwort erzeugt. Die letzten drei Ziffern sind der SIP-Code, 560403 ist also ein 403 vom SBC. Alle anderen Subcodes stammen von einem Microsoft-Dienst. Bei 560er-Codes beginnst du die Fehlersuche im SBC-Log.

Wo finde ich den SIP-Fehlercode eines bestimmten Anrufs?

Im Teams Admin Center unter Analysen und Berichte › Nutzungsberichte, Bericht PSTN-Nutzung, Reiter Direct Routing. Dort stehen je Anruf Final SIP code, Final Microsoft subcode und Final SIP phrase. Ein Klick auf den Code öffnet den SIP-Anruffluss. Dieser steht laut Microsoft für Anrufe der letzten 30 Tage zur Verfügung, die Daten können bis zu 30 Minuten verzögert sein.

Warum sehe ich im Teams Admin Center gar keinen Fehler, obwohl der Anruf scheitert?

Weil Microsoft den Anruf nicht kennt. Lehnt Direct Routing ein INVITE schon an der Tür ab, etwa wegen eines falschen FQDN, oder scheitert der Anruf zwischen SBC und Provider, taucht er in Call Analytics nicht auf. Dann hilft nur das SBC-Log.

Was ist der Unterschied zwischen SIP 503 und SIP 504?

503 heißt, dass die Gegenstelle erreichbar ist, den Anruf aber gerade nicht annehmen kann, etwa weil der SBC überlastet ist (560503) oder ein Microsoft-Endpunkt in Wartung ist (540998). 504 heißt, dass die Verbindung gar nicht zustande kam: TLS-Fehler, abgelaufenes Zertifikat, DNS oder Firewall. 504 ist deshalb meist dringender, weil er alle Anrufe über diesen SBC betrifft.

Welche SIP-Codes lösen ein Failover auf den zweiten SBC aus?

Standardmäßig 408, 503 und 504, festgelegt im Parameter FailoverResponseCodes des Gateways. Dazu kommt der Timer FailoverTimeSeconds mit dem Standard 10 Sekunden. Jede andere 4xx- oder 6xx-Antwort beendet den Versuch. Wenn du die Liste änderst, ersetzt du die Standardwerte und musst sie mit angeben.

Sind 486 und 487 Fehler, um die ich mich kümmern muss?

Meist nicht. 486 bedeutet besetzt, 487 einen vor der Annahme abgebrochenen Anruf. In Warteschlangen und beim gleichzeitigen Klingeln entstehen 487 regulär, weil nur ein Zweig angenommen wird. In der Netzwerkeffektivität des Health Dashboards zählt Microsoft Besetzt und unbeantwortete Anrufe sogar als erfolgreich zugestellt. Kümmern solltest du dich erst bei ungewöhnlicher Häufung.

Was bedeutet 404 mit 511404 bei eingehenden Anrufen?

Microsoft hat zur angerufenen Nummer keinen Benutzer und kein Ressourcenkonto gefunden. Meist liefert der SBC die Nummer in einem anderen Format als dem zugewiesenen, zum Beispiel ohne +49 oder nur als Durchwahl. Prüfe mit Get-CsPhoneNumberAssignment, ob die E.164-Nummer zugewiesen ist, und korrigiere dann das Format am SBC oder per Übersetzungsregel.

Hilft es, den Failover-Timer einfach hochzusetzen?

Nur bei 408 mit 500001 und wenn das SBC-Log zeigt, dass der SBC das INVITE bekommt, aber der Provider lange für den Verbindungsaufbau braucht. Microsoft nennt 20 Sekunden als möglichen Wert für Regionen mit langen Aufbauzeiten. Kommt das INVITE gar nicht an, verlängerst du nur die Wartezeit bis zum Fehler.

Fazit: Drei Ziffern sind kein Urteil, sondern eine Wegbeschreibung

SIP-Fehlercodes in Teams Direct Routing wirken wie Absagen ohne Begründung, sind aber erstaunlich gesprächig, wenn man sie richtig liest. Der SIP-Code sagt, was passiert ist, der Microsoft-Subcode sagt, warum, und die 560 davor sagt, wer es war. Mit dieser Reihenfolge landest du bei Tenant-Fehlern in PowerShell, bei Verbindungsfehlern im Health Dashboard und bei allem mit 560 im SBC-Log, statt in allen dreien gleichzeitig und nirgends richtig.

Dauerhaft ruhig wird es, wenn du Zertifikate, OPTIONS, Sitzungslimits und Nummernformate vorbeugend im Blick behältst und die Fehlerquote je SBC regelmäßig anschaust. Dann erfährst du von einem 504 aus dem Dashboard und nicht aus der Geschäftsführung. Und das ist, ganz ohne Galgenhumor, der angenehmere Weg.