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.

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 Kunden

Der 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.

  • Benutzer im LAN können per RTP direkt mit dem SBC telefonieren ohne Office 365 als Relay zu nutzen.
  • Am SBC können TK-Anlagen, DECT und analoge Endgeräte angebunden werden.

  • Eigener SBC beim Kunden, d.h. Hardware, Platz, Anbindung, Wartung, Bandbreite
  • Bandbreite zum Kunden und zum Internet
  • Längere Latenzzeit für Anwender, die nicht im LAN sind

Trunk durch Provider

Speziell, wenn der Kunde gar keine lokale Infrastruktur möchte oder braucht, ist ein SIP-Trunk vom Provider zu Teams interessant

  • Keine lokale Hardware

  • Keine eigenen lokalen TK-Fremdsysteme.
  • Sonderlösungen für z. B. FAX

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.

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

Telekom
https://cloud.telekom.de/en/blog/a-new-way-of-collaboration-with-microsoft-teams
https://cloud.telekom.de/de/software/office-365/microsoft-teams
https://cloud.telekom.de/de/software/office-365/microsoft-teams/teams-telefonie
Zielgruppe scheinen die Firmen mit "DeutschlandLAN" und Office 365 Business Premium zu sein. Technisch wird der Mediant 500 bei ihnen mit einem SIP-Trunk zu Microsoft Teams konfiguriert.

Arkadin

Welt

Hosted Trunk

Arkadin’s Global Direct Routing as a Service
https://www.arkadin.com/en-gb/about-us/news-media/arkadin-launches-global-direct-routing-service-microsoft-teams-deliver-greater

https://www.arkadin.com/de-de/services/unified-communications/office-365-enhanced-arkadin

Telestra

Australien

Hosted Trunk

Telestra Calling (Australia) integrated calling using Teams Phone System
https://www.telstra.com.au/business-enterprise/solutions/collaboration-conferencing/unified-communications/telstra-calling-365

ThinkTel

Kanada

Hosted Trunk

ThinkTel Direct Routing for Microsoft Teams
https://www.thinktel.ca/services/skype-teams/
https://realtimeuc.com/2018/05/thinktel-direct-routing/

BroadConnect

Kanada

Hosted Trunk

Direct Routing for Microsoft Teams
https://www.broadconnect.ca/microsoft-teams/direct-routing/

Altigen

Kanada

Hosted Trunk

Intelligent Direct Routing for Microsoft Teams Phone System
https://voiceforteams.com/direct-routing/

Swisscom

Schweiz

Hosted Trunk

Make phone calls with Microsoft Teams?
https://www.swisscom.ch/en/business/enterprise/offer/worksmart/et4t.html
https://ict.swisscom.ch/2018/06/pstnbreakoutmsteams/

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.

Problem: 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. "Kunde4711.sbc.provider.tld"
  1. Provider nennt Kunde den DNS-Name
    Der Namen ist kundenspezifisch und muss vom Office 365 bei der weiteren Konfiguration verwendet werden
  2. 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
  3. Provider trägt DNS-TXT-Record ein
    Erst dann kann der Kunde die Verifikation der Domäne abschließen.
  4. 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.
  5. 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.
  6. 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.

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 1-4 der Basiskonfiguration sind wohl weiterhin erforderlich aber der SBC selbst muss nicht mehr im Tenant eingerichtet werden. Stattdessen wird die Domäne, die nun ein Hostname ist, als Ziel konfiguriert.

Leider sind die Informationen dazu nicht so leicht zu finden. Bislang hat mir kein Carrier seine Anleitung dazu zur Verfügung gestellt.

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 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 icih 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.

Weitere Links