Managed SBC mit Teams

Auf dieser Seite beschreibe ich, wie Net at Work einen "Managed SBC" für Kunden betreibt, die die Flexibilität von Direct Routing benötigen, aber den eigenen Betrieb eines SBC vermeiden wollen. Bei Operator Connect müssen Sie ja ihre Rufnummernböcke umziehen, und das nimmt Flexibilität.

Hinweis
Diese Seite beschreibt verschiedene Anbindungen von Teams ans Telefonnet um dann die Möglichkeiten und Abgrenzungen eines "Managed SBC" zu Operator Connect oder selbst betriebenen SBCs zu erläutern. Net at Work bietet z.B.: den Betrieb eines Managed-SBC (https://www.netatwork.de/managed-sbc/) an.

Kurzübersicht PSTN-Anbindungen

Wenn Sie mit Teams telefonieren wollen, müssen Dienstleister die Rufnummern, die "Leitungen" und die Vermittlungsleistung bereitstellen. Dazu gibt es es mehrere Varianten, die ich ganz kurz aufführe.

Variante Beschreibung Rufnummern Telefon-Leitung SBC Managed

Microsoft Dialplan

Das ist die einfachste aber nicht in allen Ländern verfügbare und nicht immer günstige Anbindung

Microsoft

Microsoft

Microsoft

Nein

Operator Connect

Beim klassischen Operator Connect stellt ihr TK-Provider alles bereit. Sie brauchen bei sich nichts

ProviderA

ProviderA

ProviderA

Nein

Operator Connect + Mobile

Dies ist eine Erweiterung von Operator Connect, bei der auch Mobilfunk-Geräte eng eingebunden werden. Meines Wissens bietet in Deutschland nur die Telekom diese Funktion aktuell an (Sep 2023)

ProviderB

ProviderB

ProviderB

Nein

Direct Routing - Teams Provider

Es gibt TK-Provider, die nicht am Operator Connect Programm teilnehmen aber einen direkten SIP-Trunk zu Microsoft anbieten. Sie brauchen hier keinen eigenen SBC aber können Rufnummern nicht wie bei Operator Connect im Portal verwalten

ProviderC

ProviderC

ProviderC

Nein

Direct Routing - SIP-Provider

Andere Provider bieten zwar SIP-Trunks an aber können kein Teams. Oft sind das Stadtwerke oder City-Provider, die einfach Teams noch nicht auf ihrem Radar haben. Hier können Sie mit ihrem eigenen SBC die Verbindung herstellen

ProviderD

ProviderD

Selbst

Möglich

Direct Routing - HostedSBC

Wenn Sie lokal wenig Bedarf haben, dann bietet sich ein SBC "in der Cloud" an, z.B. nahe Microsoft oder beim Provideri

ProviderE

ProviderE

HostedSBC

Möglich

Direct Routing - selbst

Zuletzt können Sie natürlich ihre bestehende TK-Anlage weiterführen und bestimmte Rufnummern über einen lokalen SBC mit Teams verbinden

ProviderF

ProviderF

Selbst

Nein

Ein "Managed-SBC" kommt ist immer dann möglich, wenn die Vermittlungsleistung nicht direkt vom Telefonieanbieter kommt oder Sie lokal noch besondere Konstellationen abzudecken haben und sie einen eigenen SBC einsetzen müssen.

Kurzübersicht SBC Betriebsarten

Einen SBC zur Verbindung benötigen Sie immer dann, wenn ihr Telekom Provider keine direkte Verbindung zu Microsoft Teams bereitstellen kann oder will oder eine direkte Verbindung ihre Anforderungen nicht erfüllen kann. Erst dann lohnt sich eine Überlegung, wo der SBC im Netzwerk steht, wer ihn kauft/besitzt und wer ihn betreibt.

Kriterium Beschreibung Managed SBC

Besitz

Als Kunde können sie einen SBC natürlich selbst kaufen oder der Anbieter der Dienstleistung stellt auch die Funktion bereit. Wenn der Anbieter die SBC-Funktion bereitstellt, kann er durch den Betrieb mehrerer Kunden auf dem gleichen SBC natürlich Kosten sparen und es ist auch einfacher eine hochverfügbare und geografisch verteilte Plattform bereitzustellen. Ein eigener SBC garantiert natürlich ihren exklusiven Zugriff und erlaubt individuellere Konfigurationen, die ein Provider vielleicht nicht unterstützt.

Net at Work

Betrieb

Wenn Sie einen eigenen SBC kaufen und installieren, dann können Sie den Betrieb dennoch auch an einen Dienstleister wie Net at Work abgeben. Hier gibt es sogar mehrere Abstufungen, z.B.: dass der Anbieter für größere Updates und Änderungen als auch das laufende Monitoring zuständig ist, während Sie selbst z.B. einfache Fehleranalysen weiter selbst machen und der Anbieter nur 2nd/3rd Level ist. Allerdings sollten sie vorab die Produktauswahl mit dem Anbieter absprechen.

Net at Work

Standort

Zuletzt stellt sich die Frage, wo der SBC platziert wird. Steht er z.B.: in Azure oder einer anderen Cloud, um flexibel die SIP-Trunks zu verbinden oder wird er vor Ort installiert, um z.B. eine lokale TK-Anlage und analoge Geräte besser anzuschließen. Kosten aber auch Sicherheit, Funktionsumfang und Management sind hier entscheidende Faktoren. Vor Ort kann der SBC natürlich auch nicht für mehrere Kunden genutzt werden.

Azure

Bei all dem geht es nicht nur um den reinen SBC selbst sondern auch der Betrieb ist schon etwas mehr als nur Platz, Strom, VM, Lizenz und Netzwerk bereitzustellen. Konfigurationsänderungen müssen geplant, getestet, umgesetzt und dokumentiert werden, Zertifikate sind regelmäßig zu tauschen und auch Updates der Software, Monitoring der Erreichbarkeit und Protokollierung der Aktivitäten gehören dazu.

Ob sie eine individuelle SBC-Konfiguration benötigen ist primäre von der geforderten Funktion abhängig. Rufnummern von Microsoft sind nur in wenigen Ländern verfügbar und nicht immer günstig. Die Zahl der Operator Connect Anbieter und Länder nimmt ständig zu aber das klar definierte Angebot funktioniert mit Teams Endstellen wunderbar. Wenn Sie aber im gleichen Rufnummernblock auch andere Endpunkte betreiben wollen, z.B. Fax, Callcenter, TK-Anlagen, DECT, Türstationen etc., dann scheiden die meisten Angebote aus. Für Operator Connect Anbieter ist es erst einmal attraktiver, die "TeamsOnly"-Kunden zu bedienen.

Übersicht

Wie anfangs schon geschrieben: Wenn alle Nebenstellen bei Microsoft Teams sind und der Provider einen SIP-Trunk zu teams al "Operator Connect" oder über Direct Routing unterstützt, dann erscheint diese direkte Verbindung optimal. Einige Anbieter können sogar einzelne Rufnummern weiter über eine eigene Cloud-PBX oder zu einem separaten SBC routen. Die meisten SIP-Provider machen dies aber nicht pro Nummer sondern pro Nummerngruppe oder nur für alle Rufnummern. Und natürlich kann auch der Preis diese direkte Verbindung unattraktiv machen. Viele Anbieter verdienen ja ihr Geld durch die eigene "Hosted PBX" und da ist eine Abwanderung zu Teams natürlich nicht gerne gesehen. Schauen wir uns mal die verschiedenen Möglichkeiten an und wie ein SBC dabei helfen kann.

Szenario Beschreibung

Klassische Anbindung

Viele Firmen haben auch heute noch eine lokale Telefonanlage. Teilweise ist sie schon per SIP direkt mit dem Provider verbunden, der die Rufnummern und die Verbindung zur Welt bereitstellt. Vielleicht ist ihre TK-Anlage noch so alt, dass Sie sogar noch ISDN nutzt oder ihr Provider nutzt noch ISDN und sie schon SIP. Dann steht bei ihnen vor Ort meist ein SBC oder ein "Gateway", welches zwischen ISDN und SIP übersetzt oder zwischen zwei SIP-Dialekten und zur Netztrennung (Voice-Firewall) die Verbindungen umsetzt.

Es gibt auch Anbindungen, in denen kein SBC "sichtbar" ist, weil er in der TK-Anlage enthalten ist oder der Provider ihnen einen "Netzabschlussgerät" kostenfrei montiert, weil er z.B.: den ISDN-Anschluss loswerden will aber ihre TK-Anlage halt noch ISDN erwartet. Die Telekom hat hier z.B. gerne einen Audiocodes Median 800 verbaut und sie sehen weiterhin ISDN-Anschlüsse um keine Änderung an der alten TK-Anlage vornehmen zu müssen.

Cloud PBX

Ganz moderne Firmen haben gar keine lokale Vermittlungsstelle, sondern nutzen eine TK-Anlage in der Cloud ihres PSTN-Providers. Beispiels dazu sind z.B. NFON, Sipgate aber auch das DeutschlandLAN-Angebot der Telekom. Auf ihrem Tisch steht dann ein SIP-Telefon oder ein PC mit SIP-Software, die sich aber an der Cloud-PBX registriert.

Teams Direct Routing

Wenn ihr Provider direkt einen SIP-Trunk zu Teams legen kann, dann ist das die einfachste Lösung ihre Rufnummern komplett zu Teams zu routen. Sie können bei ihre Provider bleiben aber bei dem Bild gibt es keine fremden Geräte mehr. Fax, Türsprechstellen etc. sind so erst einmal nicht möglich. Einige Provider sind bei Microsoft offiziell als "Operator Connect" registriert und können ihnen auch die Rufnummern bereitstellen. Andere Provider richten mit ihnen einfach Direkt Routing ein.

Direct Routing mit Sonderweg

Wenn Sie aber noch andere Geräte nutzen wollen, dann gibt es wohl Anbieter, die sowohl einen SIP-Trunk zu Teams legen können als auch einzelne Rufnummern oder Rufnummernblöcke weiter über ihre Cloud-PBX routen und damit auch kompatible SIP-Endgeräte bedienen können.

Auch Microsoft Teams kann mittlerweile ausgewählte SIP-Geräte direkt bedienen aber Türstationen, Fax u.a. geht nur an Teams vorbei.

SBC als Vermittlung

Die maximale Flexibilität haben Sie natürlich mit einem SBC, der zwischen dem TK-Provider und ihren verschiedenen TK-Systemen steht. Der TK-Provider schaltet einen SIP-Trunk zu dem SBC und der SBC kann nun individuell je nach Rufnummer die Verbindungen zu Teams einer lokalen TK-Anlage oder anderen Systemen herstellen.

Mit einem eigenen SBC können Sie sogar SIP-Trunks mehrerer Telefonprovider z.B. aus unterschiedlichen Standorten einbinden. Neben dem Teams Trunk bleiben ihnen weiterhin alle Optionen zur Anbindung von TK-Anlagen, DECT-Systemen, Fax-Servern, Telefone auf Baustellen, Bergwerken, lauten Fabriken etc. Je nach Leistungsumfang des SBC können Sie Rufe umleiten oder zu mehreren Endgeräten (Call Fork) senden, die Anrufernamen anhand Datenbanken setzen u.a.

Der Weg über einen SBC ist natürlich Pflicht, wenn der PSTN-Provider keine Teams-Unterstützung hat. Sie können diesen Weg natürlich auch nutzen, wenn ihre lokale TK-Anlage zwar SIP aber nicht Teams-Kompatibel ist, um einen SIP-Trunk zu Teams aufzbauen.

Alle Varianten haben ihre individuellen Vorteile und Einschränkungen.

Managed SBC als Brücke

Alle bislang vorgestellten Lösungen funktionieren ohne einen eigenen SBC, weil diese Funktion entweder der Provider übernimmt. Es gibt aber Fälle, in denen dies nicht funktioniert. Und immer dann kommt ein SBC zum Einsatz. Der Betrieb eines SBC ist aber nicht einfach

Hier ein paar Beispiele:

Beispiel Beschreibung

PSTN-Provider nicht Teams Kompatible

 

Das ist klassische und einfache Fall. Sie haben einen Telefonanbieter, der schon SIP zu ihrer TK-Anlage macht aber kein Teams unterstützt. Sie wollen aus verschiedenen Gründen aber den Provider nicht wechseln.

Lokale PBX nicht Teams-Kompatibel

Sollte ihre eigene TK-Anlage zwar SIP sprechen aber nicht mit Microsoft Teams zertifiziert sein, können Sie problemlos einen SBC zwischen beide Welten klemmen. Die TK-Anlage sendet dann ihren spezifischen "INVITE" zum SBC, der die Einladung umformatiert und auch die Audio-Verbindung transcodiert.

Faxserver, DECT u.a.

Microsoft Teams stellt zwar auch einen SIP-Zugang für Endgeräte bereit, aber die Auswahl der zertifizierten Geräte ist überschaubar. Die meisten SBCs erlauben aber auch eine Anmeldung durch Endgeräte (Audiocodes "Far-end User License") oder sie installieren ein SIP-Gateway zur Anbindung von Türstellen, analogen Geräten etc.

Konsolidierung

Sie können einen SBC auch als "Sternmittelpunkt" aufbauen, der alle Telefonie-Verbindungen zwischen den verschiedenen TK-Anlagen, Microsoft-Teams, SIP-Trunk-Providern etc. vermittelt und idealerweise per Verzeichnisdienst (LDAP; WebService) dynamisch und flexibel agieren kann.

 Der eigene SBC ist natürlich am flexibelsten aber sie müssen Sie natürlich über den Kauf/Miete, Standort und Betrieb Gedanken machen. Hier kommt dann der "Managed SBC" in den Fokus, dass Sie die Leistungsfähigkeit einer SBC-Lösung mit einem Dienstleister kombiniert, der ihnen des kompletten SBC-Betrieb abnimmt.

Wenn Sie Fragen zum Thema "Managed SBC" haben oder sogar ein Angebot wünschen, dann sprechen Sie z.B. meine Kollegen bei Net at Work an.

Multi Tenant SIP-Trunk

Zuerst möchte ich die Herausforderung eines "Managed-SBC"- Anbieters beschreiben Es gibt mehrere Optionen, wie ein Provider seine SBCs beim Kunden in den Teams-Tenant registriert.Bei Microsoft gibt es nur globale Gegenstellen, d.h. anders als bei SharePoint, OneDrive oder dem MX-Record gibt es keine individuellen IP-Adressen oder DNS-Namen für die Terminierung des SIP-Trunks in Teams, die von allen Tenants genutzt werden. Das bringt zwei Herausforderungen mit:

  • PST zu Microsoft eingehend
    Microsoft muss bei einem eigenenden SIP-INVITE des PSTN-Providers oder SBC-Betreibers den richtigen "Kunden" zuordnen, d.h. ein Provider sendet einen eingehenden Ruf zu Microsoft und Microsoft muss den korrekten Tenant zuordnen. Microsoft kann dies nicht an der IP-Adresse oder dem Zertifikat festmachen. Microsoft nutzt dazu die Domain im Contact-header des INVITE, ehe es dann die Rufnummer sucht.

Bei Direct Routing pflegen Sie die Rufnummern ihrer Anwender in ihrem Tenant komplett alleine. Nur bei Operator Connect oder Mirosoft Nummern bekommen Sie Rufnummern vorgegegeben. Sie könnten ihrem Anwender durchaus eine Rufnummer zuweisen, die nicht ihnen sondern einer anderen Firman gehört. Daher kann Microsoft eingehende Anrufe nicht anhand der gerufenen Nummer zu einem Tenant routen.

  • Microsoft zu PSTN ausgehend
    Mehrere Tenants können über den gleichen Provider ins Telefonnetz anrufen. Der Provider sieht dabei dann auch nur "Teams Only" mit den für alle Tenants gemeinsam genutzten IP-Adressen und Zertifikat. Hier muss der SBC des Providers quasi sicherstellen, dass nur legitimierte Rufnummern und Tenants anrufen dürfen.

Auch bei ausgehenden Anrufen darf der Provider die Legitimität nicht an der "rufenden Nummer" festmachen. Sonst könnte ich bei mir ja auch eine Rufnummer einer anderen Firma und ein Routing hinterlegen und damit auf Kosten der anderen Firma telefonieren oder Spoofing betreiben. Der Provider muss auch hier einen Header im SIP INVITE prüfen.

Konfiguration

In der Anfangszeit von Direct Routing war es erforderlich, dass ich in dem jeweiligen Tenant einen "SIP Trunk" konfiguriere. Der Name des SBCs musste zudem aus meinen DNS-Domains im Tenant sein. Da ein TK-Provider zum einen sicher kein Zertifikat für "<sbcname>.<kundename>.<tld>" bekommt und der Provider aus seinem SBC auch nicht für jeden Kunden ein Zertifikat installieren und alle 365 Tage erneuern will, war damals ein Wildcard-Zertifikat das Mittel der Wahl. Der Provider hat z.B. auf seinem SBC ein Zertifikat mit dem Namen "*.sbc.<provider>.<tld>" hinterlegt und alle Kunden haben dann ihrerseits eine DNS-Domain im Tenant in der Form "<kunde>.sbc.<provider>.<tld>" hinterlegt. Details dazu habe ich schon auf Direct Routing für Provider beschrieben.

Mittlerweile geht es aber auch ohne SBC einfach nur mit einer Voice Route. Der Provider konfiguriert einen SIP-Trunk zu seinem eigenen Tenant, der dann aber auch von anderen Tenants mit genutzt werden kann.

Im eigenen Tenant ist der SBC ganz normal mit einem FQDN definiert und hat auch ein entsprechendes Zertifikat. In den jeweils anderen "Kunden-"Tenants hingegen ist kein SBC konfiguriert. Hier am Beispiel eines Kunden-Tenants:

Es gibt zwar keine SBC-Konfiguration aber sehr wohl eine Voice-Router:

Sie können das mit einem "Outbound Connector" in Exchange Online oder einem SendConnector in Exchange On-Prem vergleichen. Jeder Administrator kann problemlos so eine Konfiguration anlegen und damit Mails an einen komplett anderen Host senden. Ob dieser die Verbindung aber annimmt, muss das Zielsystem absichern. Jeder, der ein System im Internet betreibt, darf sich nicht drauf verlassen, dass es vielleicht nicht "gefunden" wird. "Security by Obscurity" ist kein Konzept und wenn Sie ihren SBC nicht abgesichert habe, dann wird irgendwann jemand eine teure "Mehrwertnummer" anrufen und damit hohe Kosten verursachen.

Was ist mit RTP?

Die Konfiguration der Signalisierung ist nur ein Teil der Miele. Bei der Telefonie gibt es natürlich keine Video-Übertragung oder Desktop-Sharing aber Audio ist hinsichtlich der Netzwerkanforderungen kritischer zu sehen, auch wenn die erforderliche Bandbreite deutlich niedriger ist. Dennoch dürfte in den meisten Fällen die Audio-Übertragung auch immer über den SBC laufen, der teilweise auch die Töne umcodieren muss (SILK, G.711, G.722, G.729.

Auch wenn Audio mit ca. 100kBit/Sek pro Verbindung heute keine Herausforderung mehr scheint, ist Latenzzeit und Stabilität immer noch ein Knackpunkt. Daher werden viele SBCs z.B. in Azure platziert, weil damit die Verbindung zu Teams sehr sicher möglich ist, das Peering der Azure-Cloud zu anderen Providern in der Regel sehr gut ist und kein Umweg für Teams-Verbindungen zu erwarten ist. Nachteilig ist der Standort natürlich, wenn der Anruf vom PSTN-Provider über das Internet zum SBC in Azure geht, der dann die Verbindung aber zu einer lokalen On-Premises Vermittlungsstelle weiterreicht. Das funktioniert innerhalb einen Kontinents aber dennoch meist reibungslos. Ein Vorteil hat hier natürlich ein PSTN-Provider, der selbst anhand der Rufnummer die Verbindung direkt zum Ziel aufbauen kann und vielleicht zugleich auch der Internet Provider des Kunden ist und die Pakete nie den Provider über ein Peering verlassen.

Einschätzung

Wo wir in 10 Jahren sein werden, kann ich heute noch nicht abschätzen. Wer dem Marketing von Microsoft glaubt, dann werden mehr und mehr Firmen mit Teams telefonieren und immer mehr Provider mit Operator Connector oder Direct Routing ihre Kunden mit Rufnummern versorgen. Aber eine nicht kleine Zahl von Firmen wird weder mit Microsoft Rufnummern noch mit Operator Connect nicht arbeiten können, weil es eben Konstellationen gibt, die damit nicht oder noch nicht abzudecken sind. Auch das SIP-Gateway von Microsoft ist ja nicht "offen" für beliebige Clients sondern erlaubt nur Verbindungen von ausgewählten Endgeräten.

Ob sie dann aber groß genug sind, um selbst einen SBC in Eigenverantwortung zu betreiben, müssen Sie sich überlegen. Genau das ist die Lücke zwischen privat betriebenen SBCs auf der einen Seite und Operator Connect auf der anderen Seiten, in der ein Managed SBC zu vertretbaren Kosten ihre Kommunikationsanforderungen bedienen kann.

Sie sollten dies auf jeden Fall mit in ihre Überlegungen einfließen lassen und zumindest ein Gespräch hierzu mit einem Anbieter führen.

Ob für sie eine Teams-Telefonie über Operator Connect, Direct Routing, eigenen SBC oder Managed SBC die beste Lösung ist, lässt sich am einfachsten im direkten Kontakt klären. Sprechen Sie meine Kollegen oder mich einfach an. https://www.netatwork.de/managed-sbc/

Weitere Links