Direct Routing einrichten: Schritt für Schritt zum ersten Anruf

Direct Routing hat den Ruf, das komplizierte Kind unter den Teams-Anbindungswegen zu sein — dabei ist die Einrichtung überschaubar, wenn man die Schritte in der richtigen Reihenfolge geht und die zwei, drei berüchtigten Stolperfallen kennt. Dieser Artikel führt dich von null bis zum ersten erfolgreichen Anruf: FQDN, Zertifikat, Firewall, das PowerShell-Grundgerüst und der strukturierte Test am Ende. Keine Theorie-Schleifen, sondern die Reihenfolge, die in Projekten funktioniert.

Bevor du loslegst: Die Voraussetzungen

Dieser Artikel setzt voraus, dass die Architekturentscheidung gefallen ist — falls nicht, hilft der Entscheider-Vergleich zwischen Direct Routing und Operator Connect weiter, und was ein Session Border Controller überhaupt tut, klären die SBC-Grundlagen. Den Gesamtüberblick über die Teams-Telefonie findest du im Kompetenzbereich Teams-Telefonie. Hier geht es ums Machen — und Machen beginnt mit einer vollständigen Einkaufsliste. Die häufigste Ursache für zähe Direct-Routing-Projekte ist nicht die Technik, sondern eine Konfiguration, die gestartet wird, bevor alle Zutaten da sind: Dann wartet man mitten im Projekt auf ein Zertifikat, eine Firewall-Freigabe oder den Trunk-Vertrag, und aus einem Arbeitstag werden drei Wochen Kalenderzeit.

Skizze 1: Die fünf Schritte der Direct-Routing-Einrichtung — Reihenfolge ist Absicht.

Alt-Text-Vorschlag: Prozessdiagramm mit fünf nummerierten Schritten zur Einrichtung von Direct Routing: FQDN festlegen, TLS-Zertifikat beschaffen, Firewall mit beiden Microsoft-Bereichen freischalten, PowerShell-Konfiguration und Testanruf. Darunter die Voraussetzungen zertifizierter SBC, SIP-Trunk, Lizenzen und Admin-Rechte sowie der Hinweis, dass die Schritte eins bis drei vor der PowerShell-Konfiguration abgeschlossen sein müssen.

Schritt 1: FQDN und Domäne — der Name deines SBC

Dein SBC braucht einen vollqualifizierten, öffentlich auflösbaren Namen — etwa sbc.firma.de. Zwei Regeln entscheiden hier über Erfolg oder kryptische Fehlermeldungen: Erstens muss die Domäne des FQDN im Microsoft-365-Tenant als verifizierte Domäne hinterlegt sein; die Standard-Adresse firma.onmicrosoft.com funktioniert dafür nicht. Zweitens muss der Name im öffentlichen DNS auf die Adresse zeigen, unter der dein SBC von außen erreichbar ist. Am unkompliziertesten fährst du mit einer Subdomäne deiner ohnehin verifizierten Hauptdomäne — dann ist die Tenant-Seite bereits erledigt und es bleibt ein simpler DNS-Eintrag.

Schritt 2: Das TLS-Zertifikat — kein Platz für Bastellösungen

Microsoft akzeptiert für die Verbindung ausschließlich Zertifikate öffentlicher Zertifizierungsstellen — selbstsignierte oder interne CA-Zertifikate werden abgelehnt, Diskussion zwecklos. Das Zertifikat muss auf den FQDN des SBC ausgestellt sein; ein SAN- oder Wildcard-Zertifikat der Hauptdomäne funktioniert ebenfalls, solange der SBC-Name abgedeckt ist. Achte bei der Installation auf die vollständige Zertifikatskette inklusive Zwischenzertifikaten: Ein SBC, der nur das eigene Zertifikat ohne Kette präsentiert, produziert genau die Sorte Verbindungsfehler, bei der man alles andere zuerst verdächtigt.

Und plane die Erneuerung von Anfang an mit: Zertifikate laufen ab, gern sonntagnachts. Automatisierte Erneuerung oder mindestens ein Monitoring-Alarm 30 Tage vor Ablauf gehört zur Einrichtung dazu — warum das keine theoretische Sorge ist, beschreibt die Zertifikats-Zeitbombe in den SBC-Grundlagen mit einem sehr realen Montagmorgen.

Schritt 3: Die Firewall — und die Falle mit den zwei Bereichen

Jetzt kommt der Schritt, an dem mehr Direct-Routing-Installationen kranken als an allem anderen. Die SIP-Signalisierung läuft über TLS auf Port 5061 zwischen deinem SBC und den Microsoft-Proxys — und Microsoft nutzt dafür zwei große Adressbereiche. Beide. Nicht einen. Wer nur einen freischaltet, bekommt kein sauberes „geht nicht“, sondern das Schlimmste, was ein Telefoniesystem produzieren kann: Es geht meistens.

Schritt 4: PowerShell — das Grundgerüst in sechs Befehlen

Die eigentliche Teams-Konfiguration läuft über das Microsoft-Teams-PowerShell-Modul. Bevor die Befehle kommen, lohnt ein Blick auf das Objektmodell dahinter — denn wer es einmal verstanden hat, kann jede noch so verschachtelte Routing-Anforderung darauf abbilden. Die Kette lautet: Ein Benutzer bekommt eine Voice Routing Policy. Die Policy enthält eine oder mehrere PSTN Usages — reine Etiketten ohne eigene Logik. Jede Usage kennt Voice Routes, und jede Route besteht aus einem Nummernmuster (regulärer Ausdruck) und dem Gateway, an das passende Anrufe gehen: deinem SBC. Vier Objekte, eine Richtung — mehr ist es nicht.

Skizze 2: Das Voice-Routing-Objektmodell — vom Benutzer über Policy, Usage und Route zum SBC.

Alt-Text-Vorschlag: Diagramm des Teams-Voice-Routing-Objektmodells: Ein Benutzer erhält per Grant eine Voice Routing Policy, die eine PSTN Usage als Bindeglied enthält. Die Usage wählt Voice Routes aus, deren Nummernmuster geprüft werden; die passende Route zeigt auf das PSTN Gateway, also den eigenen SBC, der den Anruf an den SIP-Trunk weiterreicht. Ein Hinweis warnt, dass bei einem fehlenden Glied der Kette der Anrufer nur ein Besetztzeichen hört.

Verbinden und den SBC als PSTN-Gateway anlegen — der FQDN muss exakt dem Zertifikat entsprechen:

Dann das Routing-Gerüst: eine PSTN Usage als Etikett, eine Voice Route mit Nummernmuster und Gateway, eine Voice Routing Policy, die die Usage enthält:

Zum Schluss der Benutzer: Policy zuweisen, Rufnummer setzen, Telefonie aktivieren. Die Nummer kommt im E.164-Format mit Ländervorwahl — für eine Dortmunder Nummer also +49231 statt 0231:

Das Muster „.*“ in der Voice Route ist der Alles-Fänger für den Einstieg: Jede gewählte Nummer geht an den SBC, der Rest ist Sache von SBC und Trunk. In gewachsenen Umgebungen wird genau hier verfeinert — separate Routes für Sonderrufnummern, internationale Ziele oder mehrere Standorte mit eigenen Gateways, jeweils über Prioritäten geordnet. Das Objektmodell bleibt dasselbe; es bekommt nur mehr Glieder. Und noch ein Verwaltungshinweis: Nach Konfigurationsänderungen braucht die Teams-Cloud gelegentlich etwas Geduld, bis alles überall angekommen ist — von Minuten bis zu einigen Stunden. Wer fünf Minuten nach dem Grant-Befehl panisch alles zurückbaut, macht es sich unnötig spannend.

Die Gegenseite: Was am SBC selbst zu tun ist

PowerShell konfiguriert nur die Microsoft-Seite — der SBC braucht sein Spiegelbild. Wie die Oberfläche dafür aussieht, unterscheidet sich je Hersteller, die Aufgabenliste ist überall dieselbe: den Teams-Trunk zu den Microsoft-Proxys anlegen (die gängigen Produkte bringen dafür fertige Teams-Profile mit, die TLS, SRTP und die OPTIONS-Anfragen gleich richtig einstellen), den Trunk zum SIP-Provider mit dessen Zugangsdaten konfigurieren und dazwischen die Routing- und Übersetzungsregeln bauen. Der Klassiker unter den Übersetzungen: Teams spricht konsequent E.164 mit Ländervorwahl (+49231…), während mancher Provider nationale Formate (0231…) erwartet — diese Nummernmanipulation ist Standardhandwerk am SBC, in beide Richtungen. Dazu kommen die Codec-Einstellungen; hier gilt die langweilige Empfehlung: bei den Standardvorgaben des Teams-Profils bleiben, solange es keinen konkreten Grund für Abweichungen gibt. Kreativität in den Codec-Listen ist eine der zuverlässigsten Quellen für Einweg-Audio.

Schritt 5: Der erste Anruf — testen mit System

Bevor du zum Hörer greifst, lohnt der Blick ins Teams Admin Center: Unter Voice erscheint dein SBC mit einem Verbindungsstatus. Der speist sich aus zwei Dauerprüfungen — dem TLS-Verbindungsaufbau (hier fliegt ein kaputtes Zertifikat auf) und den zyklischen SIP-OPTIONS-Anfragen, mit denen sich SBC und Microsoft-Cloud gegenseitig Lebenszeichen schicken. Erst wenn beides grün ist, hat ein Testanruf überhaupt eine Chance. Wichtig: Die OPTIONS-Anfragen müssen am SBC aktiv konfiguriert sein — ein SBC, der stumm bleibt, wird von Microsoft als tot einsortiert, selbst wenn er technisch läuft.

Skizze 3: TLS-Aufbau und SIP-OPTIONS — das Dauer-Lebenszeichen zwischen SBC und Microsoft.

Alt-Text-Vorschlag: Sequenzdiagramm der Verbindungsprüfung zwischen dem eigenen SBC und den Microsoft-Proxys: Zuerst der TLS-Verbindungsaufbau mit Zertifikatsprüfung, dann zyklische SIP-OPTIONS-Anfragen mit 200-OK-Antworten in beide Richtungen. Als Ergebnis zeigt das Teams Admin Center den SBC-Status aktiv; bei inaktivem Status lautet die Prüfreihenfolge Zertifikat, Firewall, OPTIONS-Konfiguration.

Dann der strukturierte Test — und zwar mehr als ein einzelner Jubel-Anruf: abgehend ins Festnetz und Mobilfunk, ankommend aus beiden Richtungen, Halten und Weiterleiten, Voicemail, ein längeres Gespräch von einigen Minuten (manche NAT- und Timer-Probleme zeigen sich erst nach 15 bis 30 Sekunden oder beim Wiederaufnehmen aus der Halteposition). Erst wenn diese Liste grün ist, kommt die Pilotgruppe — eine Handvoll freiwilliger Alltagstelefonierer, bevor die Rufnummernportierung den großen Schalter umlegt. Falls dabei etwas hakt, hilft die folgende Tabelle mit den Klassikern:

Ein letzter, undankbarer, aber goldwerter Punkt: Dokumentiere den Endzustand, solange er frisch ist. FQDN, Zertifikatsquelle und Ablaufdatum, die Firewall-Regeln mit beiden Bereichen, jede Voice Route samt Muster und Zweck, die Nummernübersetzungen am SBC. Nicht für die Galerie, sondern für den Moment in 18 Monaten, in dem irgendetwas hakt und niemand mehr weiß, warum die Route „DE-Sonderfall-Prio2“ existiert. Eine Seite reicht — aber diese eine Seite trennt bei der Fehlersuche die Stunde von der Woche.

FAQ: Häufige Fragen zur Direct-Routing-Einrichtung

Wie lange dauert die Einrichtung von Direct Routing?

Die reine Konfiguration — Gateway anlegen, Routing bauen, Nummern zuweisen — ist an einem Arbeitstag machbar, wenn alle Voraussetzungen erfüllt sind. Die Kalenderzeit bestimmen die Beschaffungen drumherum: SIP-Trunk-Vertrag, Zertifikat, Firewall-Changes und vor allem die Rufnummernportierung, die ihre eigenen Fristen hat. Realistisch für ein Mittelstandsprojekt: einige Wochen von der Entscheidung bis zum Produktivbetrieb.

Welche Ports braucht Direct Routing?

Für die Signalisierung SIP über TLS auf Port 5061 zu beiden Microsoft-Bereichen 52.112.0.0/14 und 52.120.0.0/14. Für die Medien SRTP über UDP, üblicherweise auf den Ports 3478–3481 und 49152–53247 (Stand Mitte 2026). Die tagesaktuellen Listen stehen in Microsofts offizieller Endpunktdokumentation — prüfe sie vor dem Firewall-Antrag, dann musst du nur einmal durch den Change-Prozess.

Warum steht mein SBC im Teams Admin Center auf inaktiv?

In neun von zehn Fällen: Zertifikat, Firewall oder fehlende SIP-OPTIONS — in genau dieser Prüfreihenfolge. Häufigster Einzelfehler ist eine unvollständige Zertifikatskette am SBC; danach kommen blockierte Verbindungen auf Port 5061 und ein SBC, der keine OPTIONS-Anfragen sendet und deshalb von Microsoft als offline geführt wird.

Kann ich mehrere SBCs anbinden?

Ja — jeder SBC wird als eigenes PSTN-Gateway angelegt, und Voice Routes können mehrere Gateways mit Prioritäten enthalten. So baust du Redundanz (fällt ein SBC aus, greift der nächste) oder Standort-Routing (Dortmunder Nummern über den Dortmunder SBC). Das Objektmodell bleibt identisch, nur die Gateway-Liste wird länger.

Funktioniert Direct Routing mit einem selbstsignierten Zertifikat?

Nein. Microsoft akzeptiert ausschließlich Zertifikate öffentlicher Zertifizierungsstellen — selbstsignierte und interne CA-Zertifikate werden beim Verbindungsaufbau abgelehnt. Das ist keine Empfehlung, sondern eine harte Bedingung.

Mein Benutzer hat eine Rufnummer, kann aber nicht telefonieren — warum?

Die drei üblichen Verdächtigen: Erstens fehlt die Voice Routing Policy (Grant-Befehl), zweitens ist EnterpriseVoiceEnabled nicht gesetzt, drittens ist schlicht die Replikation noch nicht durch — Konfigurationsänderungen brauchen in der Teams-Cloud manchmal Stunden. Prüfe in dieser Reihenfolge, und wenn alles korrekt aussieht: Geduld vor Rückbau.

Kann ich Direct Routing risikolos parallel zur Altanlage testen?

Ja — und genau so solltest du es machen. Lass dir vom SIP-Trunk-Provider einen kleinen neuen Nummernblock geben und baue die komplette Strecke damit auf, während die Altanlage mit den Bestandsnummern ungestört weiterläuft. So testest du Konfiguration, Firewall und Sprachqualität im echten Betrieb, ohne dass ein einziger Kunde etwas merkt. Die produktiven Nummern folgen erst mit der Portierung — wenn die Teststrecke längst bewiesen hat, dass sie trägt.

Fazit: Reihenfolge schlägt Heldentum

Direct Routing einzurichten ist kein Hexenwerk — es ist eine Checkliste mit fünf Schritten, zwei berüchtigten Fallen (beide Firewall-Bereiche, vollständige Zertifikatskette) und einem Objektmodell, das man in zehn Minuten verstanden hat. Wer die Reihenfolge einhält und strukturiert testet, telefoniert am Ende des Tages. Wenn du bei deinem Setup an einer Stelle hängst oder das Konzept vor dem Produktivstart gegenprüfen lassen willst: Melde dich kurz — die meisten Direct-Routing-Knoten lösen sich in einer Stunde gemeinsamer Fehlersuche.