SBC für Teams: Was der Session Border Controller wirklich tut

Wer sich für Direct Routing entscheidet, bekommt ein neues Gerät in sein Leben: den Session Border Controller. Für die einen ist er eine Blackbox mit gruseligem Namen, für die anderen das Schweizer Taschenmesser der Teams-Telefonie. Dieser Artikel erklärt, was ein SBC tatsächlich tut, welche Hersteller Microsoft zertifiziert hat, wie du die richtige Größe findest — und ob die Kiste bei dir im Serverraum, in Azure oder beim Dienstleister stehen sollte.

Brauchst du überhaupt einen eigenen SBC?

Kurze Vorbemerkung, bevor wir die Kiste aufschrauben: Einen eigenen SBC brauchst du nur beim Anbindungsweg Direct Routing. Bei Operator Connect und beim Microsoft Calling Plan betreibt der Carrier beziehungsweise Microsoft die SBCs — du siehst davon nichts. Ob Direct Routing für dich der richtige Weg ist, klärt der Entscheider-Vergleich zwischen Direct Routing und Operator Connect; den Gesamtüberblick über alle Anbindungswege findest du im Kompetenzbereich Teams-Telefonie. Die Kurzfassung: Sobald Fax, analoge Geräte, eine Übergangsphase mit der Altanlage oder besondere Routing-Wünsche im Spiel sind, führt am eigenen SBC kaum ein Weg vorbei. Und dann lohnt es sich, das Gerät zu verstehen, statt es nur zu ertragen.

Dolmetscher, Türsteher, Notnagel: Die drei Rollen des SBC

Ein SBC ist kein Router mit Telefonie-Aufkleber, sondern ein Spezialist mit drei klar getrennten Jobs. Wer die drei Rollen verstanden hat, versteht auch, warum das Gerät in fast jedem Direct-Routing-Projekt die zentrale Komponente ist — und warum man an ihm nicht sparen sollte.

Rolle 1: Der Dolmetscher

SIP ist ein Standard — theoretisch. Praktisch spricht jeder Provider seinen eigenen Dialekt: andere Header, andere Erwartungen an die Rufnummernformate, andere Vorstellungen davon, wie ein Anruf höflich beendet wird. Und die Teams-Cloud hat noch einmal ganz eigene Ansprüche. Der SBC sitzt dazwischen und übersetzt in beide Richtungen: Er normalisiert Rufnummern, biegt SIP-Header zurecht und wandelt bei Bedarf Sprachcodecs um (Transcoding), damit beide Seiten sich verstehen. Ohne diesen Dolmetscher reden Teams und dein SIP-Trunk aneinander vorbei — im wörtlichen Sinn: Der Anruf kommt an, aber keiner hört den anderen. Solche Einweg-Audio-Fälle gehören zu den Klassikern der Voice-Fehlersuche.

Rolle 2: Der Türsteher

Dein SBC steht mit einem Bein im Internet — und Telefonie-Infrastruktur im Internet ist ein Dauerziel. Gebührenbetrug (Toll Fraud) ist ein Milliardengeschäft: Angreifer kapern schlecht gesicherte Systeme und telefonieren auf deine Rechnung im Minutentakt zu Premium-Nummern in Übersee. Der SBC ist die Instanz, die das verhindert: Er verschleiert deine interne Netztopologie nach außen, akzeptiert Signalisierung nur von bekannten Gegenstellen, erzwingt Verschlüsselung (TLS für die Signalisierung, SRTP für die Medien) und kann auffällige Anrufmuster blocken. Kurz: Er entscheidet, wer überhaupt mit deiner Telefonie reden darf — und wirft alle anderen raus, bevor sie an der Bar stehen.

Rolle 3: Der Notnagel

Die dritte Rolle ist die, die in Projekten am häufigsten den Ausschlag gibt: Der SBC ist der Andockpunkt für alles, was die Teams-Cloud nicht kann. Fax over IP über die Teams-Cloud wird offiziell nicht unterstützt — also hängt das Fax per ATA und T.38 am SBC, an der Cloud vorbei. Türsprechstelle, Aufzugsnotruf, Alarmanlage: gleiche Adresse. Die Altanlage soll während der Migration monatelang parallel weiterlaufen: Der SBC routet zwischen beiden Welten. Und wenn Internet oder Cloud ausfallen, kann der SBC lokal ein Notfall-Routing übernehmen, damit wenigstens der Amtskopf noch funktioniert. Diese Rolle erklärt die Faustregel aus dem Entscheider-Vergleich: Altlasten führen zu Direct Routing — weil nur der eigene SBC sie mitnimmt.

Skizze 1: Der SBC als Drehkreuz — zwischen Teams-Cloud, SIP-Trunk, Altanlage und Analog-Welt.

Alt-Text-Vorschlag: Architekturdiagramm mit dem Session Border Controller in der Mitte: Links die Microsoft Teams Cloud mit Verbindung über SIP und TLS, rechts der frei wählbare SIP-Trunk mit dem Telefonnetz, unten die alte TK-Anlage für die Koexistenz während der Migration sowie ein ATA für Fax, Türsprechstelle und Alarmanlage. Eine Beschriftung nennt die drei Rollen des SBC: Dolmetscher, Türsteher und Notnagel.

Warum Microsoft nur zertifizierte SBCs zulässt

Für Direct Routing akzeptiert Microsoft ausschließlich SBCs, die ein Zertifizierungsprogramm durchlaufen haben. Das ist keine Schikane, sondern Selbstschutz auf beiden Seiten: Microsoft testet Interoperabilität, Fehlerverhalten und Update-Fähigkeit — und du bekommst im Störungsfall Support, statt zu hören, deine Bastellösung sei das Problem. Ein generischer SBC oder eine Open-Source-Vermittlung mag technisch sogar funktionieren, ist aber nicht supportet — und bei der Telefonie, dem Nervensystem deiner Firma, ist „funktioniert meistens“ kein Betriebskonzept.

Neben der Zertifizierung stellt Microsoft handfeste technische Anforderungen, die du bei der Planung auf dem Zettel haben musst — sie entscheiden über Projektlaufzeit und Betriebsstabilität mehr als jedes Datenblatt-Feature.

Skizze 2: Was Microsoft vom SBC verlangt — FQDN, öffentliches TLS-Zertifikat und beide Firewall-Bereiche.

Alt-Text-Vorschlag: Schaubild der Verbindung zwischen dem eigenen SBC und den Microsoft-Proxys: Der SBC benötigt einen öffentlichen FQDN und ein TLS-Zertifikat einer öffentlichen Zertifizierungsstelle. Die Signalisierung läuft über SIP mit TLS auf Port 5061 durch zwei Firewall-Öffnungen zu den beiden Microsoft-Signalisierungsbereichen 52.112.0.0/14 und 52.120.0.0/14. Ein Warnhinweis betont, dass beide Bereiche freigeschaltet sein müssen, da sonst sporadische Anrufausfälle auftreten.

Die zertifizierten Hersteller im Überblick

Die Liste der zertifizierten SBCs pflegt Microsoft laufend; die relevanten Namen für den deutschen Markt sind seit Jahren stabil (Stand Mitte 2026). Die folgende Übersicht ist bewusst charakterisierend statt wertend — welcher Hersteller passt, entscheidet dein Szenario, nicht die Markenfarbe. Vollständigkeit findest du in Microsofts offizieller Kompatibilitätsliste; hier stehen die Namen, die dir in deutschen Projekten tatsächlich begegnen.

Woran du die Auswahl festmachen solltest, wenn die Kandidatenliste steht: Erstens am Formfaktor — brauchst du Hardware mit Analog-Ports vor Ort, oder reicht reine Software? Zweitens am Lizenzmodell — wächst die Session-Lizenz mit, oder kaufst du Kapazitätsstufen? Drittens am Support-Weg — gibt es deutschsprachigen Herstellersupport und einen Dienstleister in deiner Nähe, der das Produkt wirklich kennt? Und viertens, gern unterschätzt: an der Frage, womit dein Team oder dein Dienstleister bereits Erfahrung hat. Ein technisch brillanter SBC, den bei dir niemand bedienen kann, ist im Störungsfall der schlechteste im Feld.

Dimensionierung: Wie groß muss der SBC sein?

Die wichtigste Erkenntnis zuerst: SBCs werden nicht nach Benutzern dimensioniert, sondern nach gleichzeitigen Gesprächen — bei Software-SBCs heißt das Lizenzmodell entsprechend meist „Sessions“ oder „Kanäle“. Und gleichzeitige Gespräche sind deutlich weniger, als das Bauchgefühl vermutet: Im normalen Büroumfeld telefoniert nie die ganze Firma auf einmal. Als Erfahrungswert hat sich ein Verhältnis von etwa einem Sprachkanal je fünf bis acht Benutzer bewährt — mit deutlichen Ausschlägen nach oben bei Vertriebsteams, Hotlines und allem, was nach Contact Center riecht.

Zwei Feinheiten, die in Angeboten gern untergehen: Erstens kostet Transcoding Rechenleistung — wenn der SBC häufig zwischen Codecs umrechnen muss, sinkt die nutzbare Kanalzahl unter den Katalogwert. Zweitens ist die Kanalzahl deines SIP-Trunks eine eigene Baustelle: Ein SBC mit 100 Sessions nützt nichts, wenn der Trunk bei 30 Kanälen dichtmacht — und umgekehrt. Beide Werte gehören gemeinsam geplant. Und denk bei der Bedarfsermittlung an alles, was ohne menschlichen Benutzer telefoniert: Warteschleifen und automatische Vermittlungen belegen Kanäle, während Anrufer warten; Fax und Alarmwählgeräte kommen obendrauf. Wer nur die Kopfzahl der Belegschaft zählt, dimensioniert an der Realität vorbei.

Betriebsmodelle: Serverraum, Azure oder Dienstleister?

Wo der SBC läuft, ist eine eigene Architekturentscheidung — und sie hat mehr mit deinen Sonderfällen und deinem Team zu tun als mit Technikvorlieben. Drei Modelle haben sich etabliert.

On-premises — als Hardware oder VM im eigenen Haus — ist Pflicht, wenn die Analog-Welt physisch angebunden werden muss: Der ATA für Fax und Türsprechstelle braucht nun einmal Kupfer in Reichweite. On-prem glänzt außerdem bei der Survivability: Fällt Internet oder Cloud aus, kann der lokale SBC ein Notfall-Routing übernehmen. Dafür liegen Hardware, Patching, Monitoring und Redundanz komplett bei dir.

Als Azure-VM entfällt die eigene Hardware, der Software-SBC skaliert flexibel und sitzt nah an der Microsoft-Cloud. Der Haken: Analoge Sonderfälle brauchen trotzdem lokale Komponenten am Standort, und gegen einen Internet-Ausfall vor Ort hilft auch die schönste Azure-Region nichts. Das Modell passt zu Cloud-first-Umgebungen ohne nennenswerte Analog-Reste.

Gehostet beim Dienstleister heißt: Direct-Routing-Flexibilität ohne eigenen Betrieb — der Dienstleister kümmert sich um Patching, Zertifikate und Redundanz, du behältst die freie Trunk-Wahl und die Routing-Kontrolle. Betrieblich nähert sich das dem Komfort von Operator Connect an, mit mehr Freiheitsgraden und laufenden Servicekosten. In der Praxis sind übrigens Mischformen üblich: ein zentraler Software-SBC plus kleine lokale Einheiten an den Standorten, die Analog-Anschlüsse oder ein Notfall-Routing brauchen.

Redundanz: Ein SBC ist keiner

Egal welches Betriebsmodell: Der SBC ist nach der Migration dein Amtskopf — fällt er aus, telefoniert niemand mehr mit der Außenwelt. Ein einzelner SBC ist damit ein klassischer Single Point of Failure, und die Frage ist nicht ob, sondern wie du das absicherst. Die gängigen Antworten: ein zweiter SBC im Aktiv/Passiv- oder Aktiv/Aktiv-Verbund (in Teams lassen sich mehrere SBCs mit Prioritäten in den Voice Routes hinterlegen, sodass der Ausfall eines Geräts automatisch abgefangen wird), verteilte SBCs an mehreren Standorten — oder, ganz bewusst und dokumentiert, der Verzicht auf Redundanz mit Mobilfunk als definiertem Fallback. Auch das ist eine legitime Strategie, solange sie eine Entscheidung ist und keine Überraschung. Was nicht geht: das Thema auf „machen wir später“ zu vertagen und es dann beim ersten Ausfall im Krisenmodus zu klären.

Skizze 3: Drei Betriebsmodelle im Vergleich — on-premises, Azure-VM und gehostet.

Alt-Text-Vorschlag: Vergleichsübersicht der drei SBC-Betriebsmodelle in drei Spalten: On-Premises mit direkter Analog-Anbindung, lokalem Notfall-Routing und eigenem Betriebsaufwand; Azure-VM ohne eigene Hardware, aber mit weiterhin nötigen lokalen Komponenten für analoge Geräte; gehostet beim Dienstleister ohne eigenen Betrieb, mit Redundanz und laufenden Servicekosten. Darunter der Hinweis, dass Mischformen mit zentralem Software-SBC und kleinen lokalen Einheiten üblich sind.

FAQ: Häufige Fragen zum SBC für Teams

Was macht ein Session Border Controller?

Ein SBC verbindet Microsoft Teams Phone mit dem öffentlichen Telefonnetz und erfüllt dabei drei Rollen: Er übersetzt zwischen der Teams-Cloud und deinem SIP-Trunk (Rufnummernformate, SIP-Dialekte, Codecs), sichert den Übergang ab (Verschlüsselung, Schutz vor Gebührenbetrug) und bindet alles an, was die Cloud nicht kann — Fax, analoge Geräte, die Altanlage und lokales Notfall-Routing.

Welche SBCs sind für Microsoft Teams zertifiziert?

Zu den zertifizierten Herstellern gehören u. a. TE-SYSTEMS (anynode), AudioCodes, Ribbon und Oracle (Stand Mitte 2026). Die vollständige, laufend aktualisierte Liste veröffentlicht Microsoft in seiner offiziellen Dokumentation — vor einer Kaufentscheidung lohnt der Blick dorthin, auch wegen der freigegebenen Firmware-Stände.

Funktioniert Direct Routing auch ohne zertifizierten SBC?

Technisch mag mancher unzertifizierte SBC eine Verbindung aufbauen — supportet ist das nicht, und im Störungsfall stehst du allein da. Für ein System, an dem Notruf und Erreichbarkeit deiner Firma hängen, ist das kein tragfähiges Konzept. Kurz: nein, nimm einen zertifizierten.

Wie viele SBC-Kanäle brauche ich?

Dimensioniert wird nach gleichzeitigen Gesprächen, nicht nach Benutzern. Im Büroumfeld liegt der Erfahrungswert bei einem Kanal je fünf bis acht Benutzer; Hotlines und Contact Center brauchen eine eigene Rechnung. Am verlässlichsten ist die Amtsbelegungs-Statistik deiner bisherigen Anlage: Spitzenwert plus rund 30 Prozent Reserve.

Kann der SBC in Azure laufen?

Ja — Software-SBCs wie anynode oder die virtuellen AudioCodes-Varianten laufen problemlos als Azure-VM. Beachte aber: Analoge Geräte brauchen weiterhin lokale Komponenten am Standort, und gegen einen Internet-Ausfall vor Ort hilft der Cloud-SBC nicht. Für Standorte mit Survivability-Anforderungen gehört zusätzlich lokale Intelligenz ins Konzept.

Brauche ich für Operator Connect einen eigenen SBC?

Nein. Bei Operator Connect betreibt der Carrier die SBCs — genau das ist der Kern des Modells. Der eigene SBC ist ein reines Direct-Routing-Thema. Welcher der beiden Wege zu dir passt, klärt der Entscheider-Vergleich.

Was kostet ein SBC für Teams?

Das hängt an Bauform und Kanalzahl: Software-SBCs werden typischerweise nach gleichzeitigen Sessions lizenziert und wachsen mit, Hardware-Geräte kommen als Einmalinvestition plus Wartung. Dazu kommen Betriebskosten — egal ob als eigene Arbeitszeit, Azure-Ressourcen oder Dienstleister-Pauschale. Konkrete Zahlen ändern sich laufend und gehören in eine aktuelle Gesamtrechnung deines Szenarios, nicht in einen Grundlagenartikel.

Was ist der Unterschied zwischen SBC und ATA?

Der SBC ist die zentrale Vermittlungsinstanz zwischen Teams und der Telefoniewelt. Ein ATA (Analog Telephone Adapter) ist ein kleines Zusatzgerät, das analoge Endgeräte — Fax, Türsprechstelle, das letzte Wandtelefon im Lager — in die IP-Welt übersetzt und dafür am SBC andockt. Merksatz: Der SBC ist der Bahnhof, der ATA ist der Zubringerbus für die Analog-Dörfer.

Fazit: Kein Grund zur Ehrfurcht — aber zur Sorgfalt

Der Session Border Controller ist keine Blackbox, sondern ein Werkzeug mit drei klaren Jobs — und die Herstellerauswahl ist überschaubarer, als die Abkürzung vermuten lässt. Entscheidend sind saubere Planung bei Zertifikat, Firewall und Dimensionierung sowie ein Betriebsmodell, das zu deinem Team passt. Wenn du bei Dimensionierung oder Betriebsmodell eine zweite Meinung zu deinem Szenario willst: Melde dich kurz für eine Standortbestimmung — die Frage nach der richtigen SBC-Größe ist meist in einem Gespräch geklärt.