Direct Routing für Provider
Diese Seite beschreibt die Möglichkeiten, wie ein Telefonprovider einen SIP-Trunk zu Tenants von Kunden bereitstellen können. Microsoft stellt nur in ganz wenigen Länden Rufnummern in Form eines "Dialplans" bereit. Alle anderen Länder müssen ihre Rufnummer über Direct Routing selbst mitbringen. Aber auch Länder mit Dialplan nutzen Direct Routing, wenn ihnen die Preise von Microsoft zu hoch sind oder 3rd Party Lösungen wie DECT, Call Center oder TK-Anlage angebunden werden müssen. Wer aber neben Exchange, SharePoint, OneDrive auch die Telefonie aus der Cloud nutzt, wird zurecht fragen, wie er vielleicht auch die Telefonanbindung als "Trunk as a Service" einkaufen kann.
Beachten Sie auch die Seite Operator Connect. Vielleicht ist ihr Carrier dabei?
Provider als Anbieter
Die Funktion "Direct Routing" eignet sich natürlich für SIP-Trunk-Provider, um ihre Kunden weiterhin per Telefonie zu versorgen aber nun die Signalisierung über Teams abzuwickeln. Hierbei gibt es auch wieder die beiden Möglichkeiten der Umsetzung:
| Topologie | Vorteil | Nachteil |
|---|---|---|
SBC beim KundenDer Provider stelle einen SBC beim Kunden auf, und baut den SIP-Trunk vom Provider zum Kunden-SBC auf. Ein zweiter SIP-Trunk wird dann vom Kunden-SBC zu Teams eingerichtet. |
|
|
Trunk durch ProviderSpeziell, wenn der Kunde gar keine lokale Infrastruktur möchte oder braucht, ist ein SIP-Trunk vom Provider zu Teams interessant |
|
|
Speziell für kleinere oder "digitale" Firmen ist natürlich die zweite Option ohne lokale Geräte interessant. Wobei hier auch die Option "Rufnummer von Microsoft" zu überlegen ist. Das ist dann eine Kostenrechnung. Aktuell kenne ich aber noch keine Anbieter in Deutschland, die so einen Weg aktiv anbieten. Technisch ist es einfach, da der Anbieter ja dann einfach bei sich ein Gateway von Audiocodes oder Ribbon aufbauen müsste, um für den Kunden den Link anzubieten. Es gibt schon die ersten Anbieter, die SIP-Trunks für Office 365 Tenants anbieten.
Unterstützung durch
Net at Work:
Sie können natürlich auch Net at Work oder andere
qualifizierte Firmen beauftragen, einen SIP-Trunk zwischen
ihre vorhandenen oder neu einzurichtenden TK-Anbieter und
Teams einzurichten.
| Provider | Land/Region | Typ | Beschreibung und Links |
|---|---|---|---|
Deutsche Telekom |
Deutschland |
AllIP-Gateway vor Ort macht SIP-Trunk |
Von der Telekom gibt es zwei unterschiedliche Angebote.
2.4 Teams Telefonie
|
Pfalzcloud |
Deutschland |
Hosted Trunk |
|
deHOSTED/NetTask |
Deutschland |
Hosted trunk |
|
TopLink |
Deutschland |
Hosted Trunk |
|
easybell |
Deutschland |
Hosted Trunk |
|
PeopleFone |
Deutschland |
Hosted Trunk |
Microsoft TEAMS powered by
peoplefone |
byon GmbH |
Deutschland Europa |
Hosted Trunk |
https://www.byon.de/ip-sprachanschluss/byon-sip-for-teams Preisliste |
Infotech EDV Systeme GmbH |
Österreich |
Hosted Trunk |
Hosted-PBX Anbieter in Österreich, der auch Teams Direct Routing anbietet.
https://www.infotech.at/portfolio/internet-network-security-service/telefon/microsoft-teams-direct-routing.html |
GTT GmbH |
Welt |
Hosted Trunk |
Der Anbieter GTT hat mittlerweile auch auf der deutschen Seite einen Hinweis auf einen direkten SIP-Trunk zu Teams Gerade
durch das direkte Peering
von GTT mit Microsoft können
wir dedizierte SIP-Trunks
für den Microsoft Teams
Service eines Kunden
bereitstellen (Teams Direct
Routing). Kunden profitieren
von der Konnektivität mit
den geringsten Laufzeiten
zwischen dem Netzwerk von
GTT und Microsoft Office 365 Auf der US-Seite gab des den Hinweise schon etwas früher.
“Interoperable with key UC
platforms and legacy
infrastructure. Supports
direct routing to Microsoft
Teams.” |
Verizon |
Welt |
Hosted Trunk |
Verizon Enterprise Solutions to provide integrated connectivity for Microsoft
Teams users https://enterprise.verizon.com/de-de/products/business-communications/ Service soll in Deutschland wohl Sommer 2020 starten |
Arkadin |
Welt |
Hosted Trunk |
Arkadin’s Global Direct Routing as a
Service https://www.arkadin.com/de-de/services/unified-communications/office-365-enhanced-arkadin |
PureIP |
38 Länder |
Hosted Trunk |
Direct Routing for
Microsoft Teams |
Telestra |
Australien |
Hosted Trunk |
Telestra Calling (Australia) integrated
calling using Teams Phone System |
ThinkTel |
Kanada |
Hosted Trunk |
ThinkTel Direct Routing
for Microsoft Teams |
BroadConnect |
Kanada |
Hosted Trunk |
Direct Routing for
Microsoft Teams |
Altigen |
Kanada |
Hosted Trunk |
Intelligent Direct
Routing for Microsoft Teams
Phone System |
Swisscom |
Schweiz |
Hosted Trunk |
Make phone calls with Microsoft Teams? |
TwinCap First AG |
Schweiz |
Hosted Trunk |
|
Loopup |
Deutschland |
Hosted Trunk |
https://loopup.com/de/microsoft-teams-direct-routing-partner/ |
NFon |
Deutschland |
PBX + Hosted Trunk |
Wenn ich das Angebot richtig verstehe, dann haben die Kunden erst einmal eine NFON-SoftPBX mit allen Funktionen, die aber per SIP-Trunk und vermutlich CallForking die Anrufe auch zu Teams sendet und von Teams annimmt. |
sipdate |
Deutschland |
Hosted Trunk |
Laut sipgate gibt es die ersten Kunden, die direkt an den SBC von sipgate mit Teams angebunden sind. Eine Integration in "sipgate teams" wird vermutlich noch entwickelt. Updates folgen. |
Call2Teams |
Welt (?) |
PBX-Kopplung |
Eine reine CloudLösung ist Call2Teams, welche sich per SIP mit ihrer lokalen TK-Anlage verbindet und die Brücke zu Teams schlägt. Im Grunde ist es ein "Hosted SBC" mit Verwaltung per Browser und Pay per Use Ein Beispiel liefert z.B. die Firma Yeastar.
|
Ich möchte im folgenden etwas die Probleme und Herausforderungen von Providern beschreiben, die sehr viele Kunden über einen gemeinsam genutzten SBC beim Provider betreiben wollen und wie die Konfiguration dennoch gelingen kann.
Die Liste ist vermutlich nicht vollständig, da natürlich nicht alle Firmen in der Welt die MSXFAQ kennen und sich bei mir melden.
Herausforderung TLS
Was bei der Einrichtung von Direct Routing mit einer Firma noch einfach erscheint, kann für einen Provider knifflig sein. Damit Direct Routing funktioniert, sind einige Voraussetzungen zu schaffen, die für einen Provider erst mal eine harte Nuss sind.
- SBC Einrichtung im Tenant
Bei der Einrichtung von Direct Routing werden im Tenant des Kunden entsprechende Session Border Controller eingerichtet - DNS-Name
Erschwerend kommt dazu, dass der SBC nicht über einen IP-Adresse oder einen beliebigen DNS-Namen angesprochen werden kann, sondern der Domain-Anteil im DNS zu einer in Office 365 registrierten Domäne gehören muss. die Microsoft Domäne ihres Tenant (<tenantname.onmicrosoft.com>) können sie nicht für ihren SBC nutzen, da Sie hier keine DNS-Einträge addieren können und sicher kein öffentliches Zertifikat bekommen. - TLS mit Zertifikat
Zusetzt erwartet Microsoft eine TLS-Verbindung, bei der sich der SBC auch mit dem Namen meldet. Über den damit verifizierten Namen des SBC kann Office 365 überhaupt erst erkennen, welcher SBC da eine Verbindung zum PSTNHub aufbaut und zu welchem Tenant der Anruf zu leiten ist.
Für einen Provider sind das natürlich erst einmal ein paar Stolperfallen, denn er möchte natürlich nicht pro Kunde einen SBC oder Virtual-SBC samt Zertifikat des Kunden aufstellen. Der Kunde müsste dann auch noch DNS-Einträge machen und Zertifikate anfordern.
Der Provider selbst will natürlich Kosten und Aufwand sparen und idealerweise wenige SBC's mit wenigen öffentlichen IP-Adresse und noch weniger Zertifikaten betreiben. Ein normaler SBC kann natürlich verschiedene TLS-Profile mit Zertifikaten verwalten aber Provider denken ja in anderen Dimensionen. Da wäre ich nicht sicher, welche SBC hier früher oder später an interne Grenzen stoßen oder z.B. SNI nicht unterstützen.
Basiskonfiguration
Schon sehr früh haben Provider wie Thinktel aber eine Lösung gefunden, wie die diese Vorgaben erfüllen können. Folgende Konfiguration könnte eine Lösung darstellen:
- Provider baut SBC mit Public-IP auf
Der Provider installiert einen zertifizierten SBC und bindet ihn an seine TK-Backends an. Zusätzlich kauf der Provider ein Wildcard-Zertifikat für z.B. "*.sbc.provider.tld" - Kunde unterschreibt Vertrag
Damit läuft dann ein Prozess beim Provider, bei dem der Provider einen DNS-Namen mit z.B. einer Kundennummer anlegt. Der A-Eintrag verweist auf den SBC des Providers auf dem zufällig auch ein Zertifikat "*.sbc.provider.tld" vorliegt.
z.B. "Kunde.sbc.provider.tld" Aus Sicherheitsgründen sollten Sie den Namen irgendwie verändern, z.B. GUID oder Hashwert o.ä.
- Provider nennt Kunde den DNS-Name
Der Namen ist kundenspezifisch und muss vom Office 365 bei der weiteren Konfiguration verwendet werden - Kunde richtet eine Office 365-Domäne ein
Das ist erforderlich, da ansonsten im weiteren Prozess kein SBC mit den Namen "Kunde4711.sbc.provider.tld" angelegt werden kann. Zur Verifikation muss der Kunde den von Office 365 geforderten DNS-Eintrag an den Provider übermitteln, damit dieser den Eintrag vornehmen kann - Provider trägt DNS-TXT-Record ein
Erst dann kann der Kunde die Verifikation der Domäne abschließen. - Provider richtet Trunk zu Office 365 ein
Auch wenn es dort noch keine passende Gegenstelle gibt, kann der Provider schon mal den Trunk mit den "OPTIONS"-Requests einstellen und im "Contact-Feld" den Namen "Kunde4711.sbc.provider.tld" verwenden. - Kunde richtet SBC ein
Im Office 365 Tenant wird nun durch den Kunden oder mit Hilfe des Providers ein SBC anlegt, der als Zieladresse wieder "Kunde4711.sbc.provider.tld" hat. Wenn soweit alles richtig ist, sollten die beiden Systeme nun erfolgreich miteinander kommunizieren können. - Konfiguration von Rufnummern, Voice
Routen, PSTNUsage etc.
Nun kommt wieder die ganz normale weitere Arbeit der Einrichtung für Telefonie im Tenant. Sie müssen PSTN-Usages definieren, die sie mit entsprechenden Voicerouten zum SBC verknüpfen. Wenn Sie den Anwender die Rufnummerneingabe vereinfachen wollen, können Sie mit Dialpläne anlegen.
So werden alle Anforderungen erfüllt und der Provider muss nicht für jeden Tenant einen virtuellen SBC oder zumindest ein SIP-Profil einrichten. Vor allem muss er durch den Trick mit der Subdomain pro Kunde kein Zertifikat der Kundendomäne in seinem SBC einspielen sondern nutzt sein Wildcard-Zertifikat.
- Configure a Session Border Controller
for multiple tenants
https://docs.microsoft.com/en-us/MicrosoftTeams/direct-routing-sbc-multiple-tenants
SuperTrunk
Die oben genannte Konfiguration funktioniert, aber ist durchaus fehleranfällig. So kann der Kunde z.B.: die Anzahl der gleichzeitigen Anrufe verändern oder andere Einstellungen an der SBC-Konfiguration auf Teams-Seite verdrehen. Telefonie muss aber einfach funktionieren. Daher hat Microsoft eine Variante entwickelt, bei der kein SBC im Kunden-Tenant mehr eingerichtet werden muss. Die Schritte sind mittlerweile auch gut dokumentiert:
- Configure a Session Border Controller
for multiple tenants
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants
Die wesentliche Veränderung ist der Verzicht auf ein im Tenant angelegtes SBC-Gateway. Damit der Tenant aber weiß, wohin er die ausgehenden Rufe geroutet werden, muss eine VoiceRoutingPolicy zu einem SBC im Tenant des Trunk-Providers konfiguriert werden.
| Wo/Wer | Schritt | Erledigt |
|---|---|---|
|
Provider |
Tenant anlegenDer Trunk-Provider muss natürlich selbst einen Tenant haben. Er muss ja seinen SBC entsprechend konfigurieren. Der Tenant "kann" theoretisch auch ihr produktiver Office-Tenant sein. Besser ist es aber einen eigenen Tenant vorzusehen, um z.B. die Verbindungsdaten von Kunde nicht mit den eigenen Daten zu vermischen. Die Microsoftdomain könnte "trunkprovider.onmicrosoft.com" o.ä. sein |
 |
|
Provider |
Domains registrierenMit der onmicrosoft.com-Domain kommen Sie nicht weiter, da sie dort ja keine DNS-Einträge machen können. Sie müssen daher eine eigene Domain im Tenant registrieren und verifizieren. Für die weitere Beschreibung nutze ich "msxfaq.de". |
|
|
Provider |
SBC-Domain trunkkunden.msxfaq.de registrierenSpäter muss jeder Kunden eine eigene DNS-Domain im Namensraum des Providers bekommen. Microsoft sieht daher eine eigene Sub-Domäne im Tenant vor. z.B. "trunkkunden.msxfaq.de". Da es eine Subdomain von "msxfaq.de" ist, müssen Sie diese nicht mehr gesondert aktivieren. Hinweis: Wenn sie als Provider nicht mit einem Loadbalancer oder SBC-Cluster für HA arbeiten, sollten Sie mehrere DNS-Namen vorsehen, z.B. "trunkkunden1.msxfaq.de" und "trunkkunden2.msxfaq.de" In der weiteren Checkliste nutze ich nur trunkkunden.msxfaq.de. Bei Hochverfügbarkeit mit DNS-Round Robin müssen Sie alles doppelt mit den unterschiedlichen Namen einrichten. |
|
|
Provider |
Ein Benutzer mit Phone System LizenzDamit Microsoft für den Tenant die grundlegenden Voice-Features freischaltet, müssen Sie mindestens einen Benutzer anlegen
Ich weiß nicht, ob Sie den Benutzer und die Lizenz nach der Aktivierung wieder löschen können. Ich würde ihn als "Testbenutzer" bestehen lassen. |
|
Provider |
SIP-Trunk einrichtenNun müssen Sie in ihrem Tenant natürlich einen SIP-Trunk einrichten. Dazu sind mehrere Schritte erforderlich, z.B.
New-CSOnlinePSTNGateway ` -FQDN trunkkunden.msxfaq.de ` -SIPSignalingport 5068 ` -ForwardPAI $true Achtung: |
|
Kunde |
Kunden-SBC Domain eintragenTeams erlaubt nur Voice-Routen auf einen SBC, der einen Domainnamen des eigenen Tenants trägt. Als Kunde mit der Domain "uclabor.de" kann ich also kein Gateway mit dem FQDN "sbc.msxfaq.de" eintragen. Daher nutzt Microsoft den Trick, eine Subdomain von der SBC-Domain "trunkkunden.msxfaq.de" im Kundentenant anzulegen.
|
|
Provider |
Verifizieren der uclabor.trunkkunden.msxfaq.deDer Kunde selbst kann natürlich nicht einen DNS-Eintrag in der Tone "msxfaq.de" des Providers machen. Als Provider müssen Sie den vom Kunden gelieferten TXT-Record in ihrem DNS machen.
Das ist übrigens ein Grund, warum Sie vielleicht nicht nur einen eigenen Tenant sondern auch eine eigene Domain nutzen sollten. Ansonsten müsste ein Trunk-Einrichter auf ihre Firmen-DNS-Zone berechtigt sein. |
|
Kunde |
Domain abschließenMit dem TXT-Eintrag des Providers können Sie als Kunde nun die Domaineinrichtung abschließen. |
|
Kunde |
Benutzer in Domain uclabor.trunkkunden.msxfaq.de anlegenWie schon beim Provider muss auch der Kunde einen Benutzer vorweisen, der in dieser Domain ist. Da Sie als Kunde später sicher nicht einen echten Mitarbeiter mit dieser funktionalen Domain arbeiten lassen wollen, legen Sie besser einen Dummy-Benutzer an.
Angeblich können Sie nach der einmaligen Aktivierung diesem Benutzer danach die Lizenz wieder entziehen. Aber auch hier würde ich den Benutzer als "Testbenutzer" bestehen lassen. |
|
Kunde |
Voice KonfigurationIm Kundentenant ist nun natürlich etwas Arbeit erforderlich, damit Voice auch für die Benutzer wie gewünscht möglich ist. Hier unterscheidet sich die Anbindung nicht von einem eigenen SIP-Trunk. Als Kunde sparen Sie einfach Aufbau und Betrieb eines SBCs aber nicht die Konfiguration. Als guter Provider geben Sie ihren Kunden natürlich entweder eine Anleitung oder PowerShell-Script zu Hand oder lassen Sich die Berechtigungen zur Verwaltung geben.
New-CsOnlineVoiceRoute ` -Identity "AllCalls" ` -NumberPattern "^\+?\d+$" ` -OnlinePstnGatewayList uclabor.trunkkunden.msxfaq.de ` -Priority 1 ` -OnlinePstnUsages "AllCalls" |
|
Das ist natürlich nur eine Kurzfassung der Schritte und viele Nebentätigkeiten habe ich bislang verschwiegen, da Sie je Kunde und Provider unterschiedlich sind. Ich denke da an:
- Gebührenerfassung und Abrechnung
Als Provider kommen Sie erst einmal nicht an die CDR-Daten des Kunden-Tenants und müssen ihren SBC dazu abfragen - Managed Services
Einige Provider werden vielleicht für ihre Kunden die komplette Verwaltung übernehmen. Dann gewährt der Kunde dem Provider z.B. administrative Rechte, so dass dieser als "vertrauenswürdige Instanz" für den Kunden auch die Konfiguration und Betrieb übernehmen kann. - Lizenzmanagement
Wenn der Provider auch als "Reseller" auftritt, kann er dem Kunden auch die Lizenzen vermitteln, konfigurieren und in Rechnung stellen. - Monitoring
Der Ausfall einer Telefonie-Funktion ist ist für viele Kunden undenkbar. Es kann aber passieren und neben einer geplanten Hochverfügbarkeit gehört auch ein Monitoring dazu.
So gibt es noch viele weitere Punkte. Es ist eine Aufgabe des Providers ein passendes "Produkt" für seine Kunden zu schnüren.
Offen
Sowohl der erste Weg als auch die neue Version funktionieren und letztlich wird ein kleiner Kunde entweder nach der Schritt für Schritt-Anleitung mit Unterstützung des Hosters vorgehen oder sich von einem Dienstleister helfen lassen. Denn aktuell gibt es z.B. keine eigene Admin-Rolle für einen Trunk-Provider, damit er genau und nur die erforderlichen Einstellungen für den Kunden vornehmen und ggfls. auch später einmal anpassen kann. Auch könnte ich mir als Provider durchaus vorstellen, dass ich für den Kunden auch die Rufnummern, die ich ihm gegeben habe, provisioniere und konfiguriere. Aber kaum ein Kunde wird den PSTN-Provider dazu zum "Teams Admin" machen oder gar "Delegated Admin" machen.
Hier würde ich mir noch ein paar Möglichkeiten seitens Office 365 wünschen, die dem dem Hoster einen Zugriff auf die erforderlichen Einstellungen gewähren könnte ohne gleich zu viele administrative Berechtigungen zu erhalten.
Unterstützung durch
Net at Work:
Sie wollen keinen SBC selbst betreiben
aber nicht auf
Operator
Connect setzen?. Dann lassen sie doch die SBC-Funktion
betreiben.
https://www.netatwork.de/managed-sbc/
Weitere Links
- Direct Routing Konfiguration
- Direct Routing - Telefonie mit eigener SIP-Anbindung
- Plan Direct Routing
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan - Microsoft Teams Direct Routing explained
https://msunified.net/2018/05/27/microsoft-teams-direct-routing-explained/ - Configure a Session Border Controller
for multiple tenants
https://docs.microsoft.com/en-us/MicrosoftTeams/direct-routing-sbc-multiple-tenants - Direct Routing Carrier Hosting Model
Explained
https://www.msteamsswe.se/direct-routing-carrier-hosting-model-explained/ - DRaaS – a Better Way to Enable Telephony
in Microsoft Teams?
https://www.uctoday.com/collaboration/team-collaboration/draas-a-better-way-to-enable-telephony-in-microsoft-teams/
