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

Von der Telekom gibt es zwei unterschiedliche Angebote.

  • All-IP mit lokalem Mediant als SBC für die TK-Anlage und mit SIP-Trunk zu Teams
    Dies ist für Firmen interessant, die weiterhin eine lokale TK-Anlage nutzen und nur einen Teil der Rufnummern mit Teams bedienen.
  • vSBC in der Telekom-Clod zu Teans
    Das ist ein interessanter Weg für Firmen, die komplett zu Teams als Telefonie-Lösung umsteigen
    https://www.telekom.de/dlp/agb/pdf/46418.pdf

2.4 Teams Telefonie
Die Telekom überlässt dem Kunden für die Nutzung der Telefonieleistungen von Teamwork in Microsoft 365 (Microsoft Teams) mit Nutzern außerhalb von Microsoft 365 über SIP-Trunk Produkte der Telekom die entsprechenden Lizenzen inkl. der notwendigen technischen Infrastruktur.
Die Leistung von Teams Telefonie besteht dabei aus der Überlassung der "Microsoft 365 Business Voice (without calling plan)" Lizenz
von Microsoft. Zusätzlich stellt die Telekom im Rahmen von Teams Telefonie die notwendige technischen Infrastruktur (virtueller Session Border Controller/vSBC) bereit und betreibt diese.
Für die Nutzung von Teams Telefonie muss der Kunde ein Produkt mit Teamwork (z. B. Microsoft Teams) sowie ein SIP-Trunk Telefonieprodukt der Telekom nutzen. Diese Produkte müssen vom Kunden
separat bei der Telekom gebucht werden.
Quelle: https://www.telekom.de/dlp/agb/pdf/46418.pdf

 

Pfalzcloud

Deutschland

Hosted Trunk

deHOSTED/NetTask

Deutschland

Hosted trunk

TopLink

Deutschland

Hosted Trunk

easybell

Deutschland

Hosted Trunk

PeopleFone

Deutschland
Schweiz

Hosted Trunk

Microsoft TEAMS powered by peoplefone
https://www.youtube.com/watch?v=WTQ9rnxhPlI&feature=youtu.be
5€/Kanal

byon GmbH

Deutschland
Europa

Hosted Trunk

https://www.byon.de/ip-sprachanschluss/byon-sip-for-teams

Preisliste
https://www.byon.de/images/PDFs/byon_Preisliste_SIP_for_teams_Deutschland.pdf

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
https://www.infotech.at/portfolio/internet-network-security-service/telefon.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
Quelle: SIPTrunk https://www.gtt.net/de-de/services/unified-communications/sip-trunking/

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.”
Quelle: https://www.gtt.net/us-en/services/unified-communications/sip-trunking/

Verizon

Welt

Hosted Trunk

Verizon Enterprise Solutions to provide integrated connectivity for Microsoft Teams users
https://www.verizon.com/about/news/verizon-enterprise-solutions-provide-integrated-connectivity-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/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

PureIP

38 Länder

Hosted Trunk

Direct Routing for Microsoft Teams
https://pure-ip.com/nz/integrations/direct-routing-for-microsoft-teams/

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://www.thinktel.ca/services/skype-for-business-online-retirement-and-microsoft-teams-adoption/
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/

TwinCap First AG

Schweiz

Hosted Trunk

https://twincapfirst.ch/teams-telefonie/

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.ä.
  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 sind mittlerweile auch gut dokumentiert:

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 anlegen

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

Mit 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 registrieren

Spä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 Lizenz

Damit Microsoft für den Tenant die grundlegenden Voice-Features freischaltet, müssen Sie mindestens einen Benutzer anlegen

  • Benutzer in der SBC-Domain anlegen
    Da ohne ADSync die SIP-Adresse vom UPN abgeleitet wird, muss der Benutzer einen Anmeldenamen in der SBC-Domain haben
    z.B. testuser@trunkkunden.msxfaq.de
  • Für Voice aktivieren
    Er braucht daher eine Teams Lizenz und eine "Phone System Lizenz"
  • Geduld
    Dieser Benutzer mit der SIP-Domain in "@trunkkunden.msxfaq.de" triggert bei Microsoft ein Provisioning, dass diese SIP-Domain für Voice-Routing aktiviert wird. Das kann manchmal einige Minuten oder Stunden dauern.

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 einrichten

Nun müssen Sie in ihrem Tenant natürlich einen SIP-Trunk einrichten. Dazu sind mehrere Schritte erforderlich, z.B.

  • DNS-Name "trunkkunden.msxfaq.de
    Der SBC muss einen Namen bekommen, der per DNS auch auf eine öffentliche IP-Adresse des SBC verweist. Microsoft sieht dazu die SBC-Domain als Hostname vor. Das klingt erst mal komisch aber erklärt sich im nächsten Schritt
  • Wildcard-Zertifikat für "*.trunkkunden.msxfaq.de"
    Die Verbindung ist ja TLS-gesichert und über den Trick wird nun jeder Hostname darunter auch mit abgedeckt
  • SBC installieren
    Natürlich ist nun die Zeit gekommen, den SBC selbst mit der im DNS hinterlegten IP-Adresse und dem Zertifikat so einzurichten, dass er mit Teams kommunizieren kann.
    Siehe auch https://docs.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants#deploy-and-configure-the-sbc
  • SBC eintragen
    Dies hier ist nur die Eintragung im Tenant des Providers. Sie sehen den FQDN, für den auhc ein Wildcard-Zertifikat vorhanden ist.
New-CSOnlinePSTNGateway `
   -FQDN trunkkunden.msxfaq.de `
   -SIPSignalingport 5068 `
   -ForwardPAI $true

Achtung:
Später kommen "INVITE-Pakete von ihren Kunden über ihren SBC. Sie haben als Provider aber keine Steuerung im Kundentenant hinsichtlich Voice-Routen, PSTN-Usages etc. Wenn Sie gewisse Dinge verhindern wollen, müssen Sie dies im SBC umsetzen. Auch Daten für eine Gebührenabrechnung sollten Sie am SBC oder ihrem nachgelagerten Vermittlungssystem abgreifen.

Kunde

Kunden-SBC Domain eintragen

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

  • Anlegen der Domain "uclabor.trunkkunden.msxfaq.de"
  • Verifizieren der Domain
    Office 365 erwarte nun einen Beweis, dass Sie diese Domain nutzen dürfen. Übermitteln Sie dazu den TXT-Record an ihren Provider

Provider

Verifizieren der uclabor.trunkkunden.msxfaq.de

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

  • TXT-Record eintragen
    Damit der Kunde im nächsten Schritt die Domain verifizieren kann
  • Namensauflösung für "uclabor.trunkkunden.msxfaq.de" auf den Provider-SBC
    Der Name uclabor.trunkkunden.msxfaq.de wird später im Kundentenant in den Voice-Routen genutzt. Der Provider muss aber die DNS-Auflösung dafür sicherstellen, dassSie aufden SBC des Providers verweist., z.B. per A-Record oder CNAME

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ßen

Mit dem TXT-Eintrag des Providers können Sie als Kunde nun die Domaineinrichtung abschließen.

Kunde

Benutzer in Domain uclabor.trunkkunden.msxfaq.de anlegen

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

  • Anlegen eines Testbenutzer
    UPN = Testuser@uclabor.trunkkunden.msxfaq.de
  • Zuweisen einer Teams/Skype Lizenz
    Wir brauchen einen Voice-aktivierten Benutzer mit einer SIP-Adresse in der Domain uclabor.trunkkunden.msxfaq.de.

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 Konfiguration

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

  • Dialplan
    Damit aus "kurzen Nummern" die richtigen E.164-Nummern werden. Diese Einstellungen ist individuell pro Kunde
  • Anlegen der PSTN-Usages
    Einfachere Umgebungen können natürlich die eingebauten Policies einfach nutzen.
  • Konfiguration der Anwender
    z.B. Zuweisen der Rufnummern, Dialplan und PSTN-Usages
  • Einrichten der VoiceRoute
    Nachdem alle Vorarbeiten erledigt sind, können wie im Tenant nun eintragen, dass alle ausgehenden Anrufe zu dem DNS-Namen ihres SBCs gehen
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.

Weitere Links