In den vergangenen zwei Wochen haben wir unser interne IT um ein äußerst spannendes Feature erweitert: Wir haben die Telefonie-Funktionen in Microsoft Teams aktiviert.
Warum? Ganz einfach: Microsoft Teams ist der Mittelpunkt unserer internen Kommunikation geworden. Die Zusammenarbeit in und zwischen den „Teams“ in unserem Hause basiert auf „Teams“ aus dem Hause Microsoft. Täglich werden Dateien in gemeinsamer Arbeit erstellt, und zahlreiche Kanalnachrichten geteilt. Besprechungen über die Standorte hinweg werden in Teams gehalten, Bildschirme geteilt, und Aufgaben delegiert. Innerhalb dieser Zusammenarbeit haben sich die Telefonie- und Besprechungsfunktionen als ideales Werkzeug erwiesen, auch durch die „mobile“ Verfügbarkeit mittel Smartphone-Client. Bedingt durch die Nutzung von Softphone-Clients mit unserer Swyx-Telefonanlage sind die technischen Voraussetzungen für eine Nutzung der Voice- und Konferenzfunktionen innerhalb von Teams ideal.
Ein tatsächliches Ärgernis ist es allerdings, wenn man gerade intern via Teams telefoniert, und parallel dann „das echte“ Telefon klingelt. Eigentlich sollte besetzt sein, aber unsere Swyx tauscht den Besetzt-Status nicht mit Teams aus. Zudem zeigen die Busylights (kleine Lampen auf dem Bildschirm, die je nach Gesprächsstatus die Farbe ändern, z.B. rot für „besetzt“ und grün für „frei“) nur den Status einer Anwendung an. Ist man also in Teams „frei“, weil man extern mittels Swyx telefoniert, so ist für die Kollegen nicht zu erkennen, dass man gerade nicht angesprochen werden kann/sollte.
Innerhalb einer Bereitstellung der Telefonie mit Teams gibt es zwei Möglichkeiten, Rufnummern anzuschalten:
Variante 1: Buchung von Rufnummern und Gesprächsguthaben bei Microsoft, sogenannte „Anrufpläne“
Variante 2: Nutzung eines SessionBorderControllers (SBC) und Anschaltung vorhandener Rufnummern und SIP-Kanäle an Teams
Wir haben uns für Variante 2 entschieden, denn
Parallel stellte sich zudem die Frage, in welchem Rahmen wir die Telefonie testen, zeitlich und personell. Für eine Erprobung die gesamte Telefonie des Unternehmens zu gefährden stand nicht zur Debatte. Das Wunsch-Szenario wäre eine Einführung „parallel“, wenn Teams nicht funktioniert, sollte die Swyx weiterlaufen. Zudem ist unsere Swyx in elementare Geschäftsprozesse integriert, Rufverteilung, Gesprächsdatenerfassung und zuweisung, Routing-Funktionen, einige Dinge, die sich in Teams nicht abbilden lassen. Aus diesem Grunde überlegten wir uns ein Einführungs-Szenario, in dem beide Systeme Hand in Hand zusammenarbeiten: Teams wird als Telefonie-Client genutzt, die Anrufsteuerung erfolgt dabei jedoch über die bestehende Swyx-TK.
Nein. Teams ist nicht als SIP-Client konzipiert, sodern möchte eine eigenständige Telefonanlage sein. Technisch ist es uns dennoch gelungen, dies umzusetzen; die entsprechenden Funktionen haben wir im SBC konfiguriert. Somit konnten wir tatsächlich pro Mitarbeiter von Swyx auf Teams wechseln, wobei jederzeit die Option vorhanden bleibt, auf die Swyx „zurückzuwechseln“, durch einfaches öffnen des Softphone-Clients. Diese Funktion ist tatsächlich auch notwendig, da Teams z.B. nicht mehrere Absender-Kennungen verwalten kann, keine Funktion für anonyme Anrufe hat, und speziell im Bereich Ad-Hoc-Konferenzen und Makeln noch etwas Nachholbedarf hat.
Aufgrund des Umfangs dieses Artikel wird die technische Einrichtung in einem separatem Blog-Beitrag erscheinen. (https://www.skysystems.it/microsoft-teams-direct-routing-technik-tutorial/)
Konzeptionell haben wir nach Microsoft-Idee das nachfolgende Konzept umgesetzt:
Unser Telefonie-Trunk wird aktuell von der Swyx-Telefonanlage verwendet, somit sieht das Szenario adaptiert wie folgt aus:
Der Session Border Controller registriert sich dabei als SIP-Client im Anwender-Kontext. Dies erfordert zwar diverse Übersetzungen in der Rufnummern-Anzeige (Ein- wie Ausgehend), da Teams keine internen Rufnummern kennt, resultierend erhalten wir aber die gewünschte Funktionalität.
Innerhalb von Teams stellt sich schnell der gewünschte Effekt ein, Swyx verhält sich als Telefonie-Client. Leider fehlen CTI- und ERP-Integration. Da die Sprachdaten einen unegewöhnlich „langen“ Weg nehmen, vom Provider zur Swyx im Rechenzentrum, über den SBC in die Microsoft Cloud zu Teams, und von dort zum Endgerät (und den gleichen Weg wieder zurück) hatten wir initial mit Latenzen gerechnet; bis auf rund eine Sekunde Verzögerung beim Gesprächsaufbau ist hiervon jedoch im laufenden Gespräch nichts zu bemerken.
Die Mobilgeräte-Integration ist optimal umgesetzt, selbst im CarPlay-Modus lassen sich Teams-Gespräche problemlos führen. Die Integration des Telefonbuch funktioniert für ein- und ausgehende Anrufe einwandfrei. Die Bandbreiten-Anforderungen sind relativ gering; unterhalb von 3G ist jedoch kaum ein Telefonat möglich.
Die Telefonie-Funktion in Teams ist einfach und schlicht integriert, und wir werden diese auch langfristig nutzen. Bedingt durch die weiter vorhandene Swyx Telefonanlage können wir alle vorhandenen Enterprise-Funktionen weiter nutzen. Ob wir dies jedoch auf Kunden empfehlen können hängt stark vom jeweiligen Szenario ab. Tatsächlich dürften jedoch die aktuellen Kosten pro Anwender und Monat für die meisten Anwendungsszearien ein KO-Kriterium sein. Im Vergleich zur Swyx Telefonanlage (Lizenzmodell Swyx Flex) liegen die Lizenzkosten tatsächlich 3-8fach höher, wobei die Swyx dann durchaus mehr und ausgereiftere Funktionen hat.
Einzig die Transkriptions-Funktion der Teams-Voicemailbox hat Swyx nicht; nachdem eine Nachricht auf der Mailbox hinterlassen wurde, erhält man nicht nur die Audio-Datei, sondern auch eine Sprache-zu-Text Konvertierung, so dass man z.B. innerhalb einer Besprechung die eigenen VoiceMails lesen kann. (Fakt ist allerdings, wir haben uns bereits während der initalen Swyx-Konfiguration gegen VoiceMailboxen entschieden; die Transkriptions-Funktion ist für uns daher ohne Bedeutung, abgesehen von internen Nutzungsszearien.