RCC Zukunft

Mit der Funktion RemoteCallControl konnte man seit OCS 2007 eine Kopplung von TK-Anlage und Communicator derart herstellen, dass über den Communicator das Tischtelefon gesteuert wurde. Dazu war es natürlich erforderlich, dass auf Seite von OCS bestimmte Einstellungen durchgeführt werden und natürlich auch seitens der TK-Anlage entsprechende Voraussetzungen geschaffen wurden.

Hinweis
Mit Skype für Business wird RCC nicht mehr unterstützt.

Quelle: "Plan für remote call control in Skype für Business 2015" https://technet.microsoft.com/en-us/library/gg558658.aspx
"... any Users homed on Skype für Business Server, remote call control is not supported..."

RCC in der Praxis

Ich weiß nicht, wie viele Implementierungen es mit RCC tatsächlich gibt. Vermutlich eher zu viele, weil viele Firmen und Mitarbeiter sich noch nicht wagen den Schritt zu OCS zu gehen. Man muss aber auch ein Stück weit sehen, welche Funktion RCC denn alle bereit stellt und welche davon genutzt werden:

  • Anzeige und Annahme eingehender Rufe
  • Ausgehende Rufe initiieren
  • Statusupdate (Am Telefon)

Viele Dinge waren und sind per RCC aber nicht möglich, z.B.: wenn ein Ruf herein kommt, kann ich diesen nicht per OC weiterleiten. Auch sind die seitens der TK-Anlage bereit gestellten Funktionen mit den Funktionen in OC nicht deckungsgleich. Ergo kann nur der kleinste gemeinsame Nenner umgesetzt werden.

Hinzu kommt, dass die Trennung von Audio von den sonstigen OCS-Funktionen wie Video, Desktopsharing etc. immer wieder einen Medienbruch bedeutet, den viele Mitarbeiter nicht verstehen können oder wollen

Die Rolle der TK-Firmen

Allerdings muss man natürlich auch offen sagen, dass die TK-Anbieter nicht ganz mit offenen Karten spielen bzw. die Kooperationsbereitschaft nur bedingt vorhanden ist. Anfänglich habe ich noch gedacht, dass die TK-Firmen das vielleicht nicht besser können, zumal RCC ihnen ja sogar den Kunden zuspielt und die bestehende TK-Anlage oft sogar erweitert oder aktualisiert werden muss. Faktisch zementieren Sie mit dem Einsatz von RCC sogar die bestehende TK-Anlagenstruktur und deren Endgeräte. Und der Vertrieb der TK-Anlage freut sich um so mehr, da er nicht nur die TK-Anlage, die Endgeräte und die Dienstleistung verkaufen kann, sondern zudem auch noch die Gateway-Anbindung zu OCS zusätzlich als Service, Server und Lizenz hinzukommt.

Und wenn der Kunden dann irgendwann merkt, dass die RCC-Funktion nicht so perfekt ist, dann kann die TK-Welt natürlich mit ihren eigenen Softclients aufwarten. Diese auf die TK-Anlage angepasste Software kann meist sehr viel besser das Tischtelefon virtuell abbilden und in vielen Fällen kann diese Software sogar als Softphone dienen.

Enterprise Voice statt RCC

Allerdings kann dies natürlich auch ins Gegenteil für die TK-Struktur umschlagen, z.B.: wenn ein paar Anwender komplett per OCS arbeiten und darüber auch telefonieren. Sicher wird es noch einige Zeit dauern, bis sich die Anwender "befreit" genug fühlen, den Platz für das Telefon auf dem Tisch anderweitig zu nutzen und komplett per PC zu kommunizieren. Dann merken die Anwende plötzlich, welches Potential im OCS-Server und Communicator steckt und nach kurzer Zeit wird man sich die Frage stellen, wie Kommunikation in der Prä-OCS-Zeit möglich war.

Es ist natürlich verständlich, dass dieses "AHA-Erlebnis" seitens der etablierten TK-Vertriebskanäle gerne herunter geredet oder torpediert wird. Das ist ja auch verständlich, da OCS deutlich günstiger sein kann und damit die fetten Margen so nicht mehr realisierbar sein. Aber das wird der Markt regeln.

Vision: Zukünftige Telefonie in Firmen

Mit den Erfahrungen aus RCC-Projekten sehe ich eigentlich zukünftig nur drei Szenarien, wie Mitarbeiter mit einem Telefon umgehen.

  • Klassisches Telefon ohne CTI/TAPI
    Dieses "System" können Sie schon viele Jahrzehnte und es wird sicher noch lange solche Nebenstellen ohne PC-Kopplung geben, z.B. Notfalltelefone, Aufzugstelefone, "Public Area"-Telefone in der Kantine, an Empfangscountern et. oder eben auch in Produktionsbüros, wo es "nur" auf telefonieren ankommt und keine Integration erforderlich ist.
  • OCS mit Enterprise Voice oder anderes Softphone
    Das andere Extrem sind die "Desktop Worker" die heute schon alles mit dem PC machen und die parallele Bereitstellung eines Tischtelefons neben dem Platz auf dem Schreibtisch auch zusätzliche Infrastruktur benötigen und Hardwarekosten verursachen. Wenn ich eh "ohne PC" nicht mehr arbeiten kann, weil im Einkauf oder der Bestellannahme ohne das passende PC-Programm es auch keinen Sinn macht, zu telefonieren, dann kann ich den PC auch als Telefon nutzen. Hier spielt natürlich OCS seine Stärken aus. Aber auch andere Softclients können zumindest die Telefonfunktionen bereit stellen.
  • Komforttelefon mit native PC-Kopplung (OCS oder TK-Software)
    Wer aber an einem PC arbeitet und dennoch das autarke Tischtelefon präferiert, der wird eine Telefonsteuerung wünschen, die per PC m������glichst umfangreich das Telefon bedient und vielleicht sogar programmiert. So wäre es ja pfiffig, wen eine PC-Anwendung ausgewählte Nummern aus Outlook o.ä. auf die Kurztasten des >Telefons herunter laden kann. So weit geht die OCS-Anbindung nicht. Per OCS können das Rufmanagement per PC ausführen aber nicht das Telefon programmieren. Einige Hersteller bilden ja das Tischtelefon sogar auf dem PC als "Bild" nach. Das mag sinnvoll sein, wenn der Monitor ein Touchscreen ist, aber ansonsten zeigt es eher, dass der Hersteller noch alten Ansichten nachhängt.

Meine Beobachtungen zeigen mir eher, dass der letzte Weg in eine Sackgasse führt, da OCS mit RCC als "Klebstoff" zwar schon mehr Funktion bieten kann als ein Telefon ganz ohne PC-Kopplung, aber die TK-Anbieter mit ihren auf die TK-Anlage zugeschnittenen TAPI-Clients natürlich mehr Funktionen zeigen können. Nur warum sollte eine Firma erst OCS-Server, Standard-CALs und Enterprise-CALs kaufen und dann noch eine klassische TK-Anlage bezahlen, installieren und pflegen und oben drauf noch zusätzliche Server, TK-Lizenzen und Komplexität durch eine RCC-Kopplung setzen ?-

Ich sage ja nicht, dass eine Firma "genau eine" dieser drei Lösungen umgesetzt soll. Es ist problemlos möglich in einer Firme mehrere Strukturen zu betreiben um damit für den jeweiligen Arbeitsplatz die passende Lösung bereit zu stellen. Ich kann mir sehr gut vorstellem, dass es einen Personenkreis gibt, der nur noch per OCS Telefoniert und andere Personen mit ihrem Tischtelefon und manche während der Migration sogar mit der TK-Kopplung des Herstellers arbeiten. Aber letztlich sehe ich in der Zukunft nur noch PC-gestützte Telefone oder "einfache Endgeräte ohne PC-Kopplung.

Diese Telefone können dann SIP-Telefone sein, die direkt mit OCS sprechen (z.B. SNOM Telefone oder andere) oder an einer kleinen TK-Anlage oder dem OCS-Gateway hängen. Größere Firmen müssen ihren OCS-Server einfach nur über "Enterprise Voice" mit der TK-Anlage koppeln und die Rufnummern entsprechend konfigurieren.

Koexistenz: SIP-Statusabgleich

Wenn nun aber in einer Umgebung beide Welten während einer Migration oder längere Zeit als Koexistenz bestehen und RCC nicht eingesetzt wird, dann ergibt sich die unschöne Konstellation, dass OCS-Anwender den "Am Telefon"-Status der TK-Benutzer nicht sehen und die TK-Anwender, die .z.B. mit der zu TK-Anlage mitgelieferten TAPI-Anwendung arbeiten, den Status der OCS-Anwender nicht sehen können. Die Lösung hierbei lautet SIP-Statusabgleich.

So erlaubt OCS es zentralen Programmen per UCMA den Status von Benutzern auf dem Server zu setzen und auch wieder auszulesen. Denkbar ist daher, dass eine zentrale Komponente den Status von OCS-Anwender, die noch mit der TK-Anlage telefonieren, entsprechend der TK-Funktion setzen und löschen und umgekehrt der Status der OCS-Benutzer in die TK-Anlage übertragen wird.

Einzige Frage bleibt hier, welches Programm dies zukünftig übernehmen wird und wie sowohl OCS also auch die TK-Anlage wissen, welchen Anwender zu welcher Rufnummer gehört.

Knifflig wird auch, dass es im Active Directory für jeden Benutzer natürlich ein Konto gibt, welches für OCS aktiviert sein kann. Wenn eine Software dann z.B.: erkennt, dass der Benutzer eine TEL-URI hat aber dennoch nicht für Enterprise Voice oder RCC aktiviert ist, dann kann die Software zu dem Benutzer passend den Status in der TK-Anlage abfragen und in OCS setzen.

Umgekehrt kann ich leider nichts beitragen. Es ist wohl sehr anlagenspezifisch, wie ein Anwender, der per OCS telefoniert und in der TK-Anlage nur als Rufnummerneintrag in der Routingtabelle aber nicht als "Teilnehmer mit Endgerät" erscheint, einen Status bekommen kann. Es gibt Anlagen, die sowas wie "Kontakte" verwalten. Aber hier bleibt noch einiges an Forschungsarbeit.

Alles in Allem kann dies aber zukünftig meine Überlegungen bestätigen, dass RCC, sei es nun per OCS oder per TK-Anlage immer unwichtiger wird und eine Vielzahl der Anwende mit PC auch mit dem PC telefonieren werden. Und das muss nicht, aber wird aus meiner Sicht sehr oft der Office Communicator sein

SWYX Client könnte z.B. den OCS-Status setzen.

SNOM und SIP-Status

Etwas vorgeprescht auf ihre Weise ist hier SNOM. Deren Telefone können zwar auch als Enterprise Voice-Teilnehmer mit OCS betrieben werden aber wenn eine Firma SNOM mit einer anderen SIP-Infrastruktur einsetzen, dann können Sie im Telefon auch die OCS-Identität addieren. Das Snom setzt beim Telefonieren per VoIP mit der TK-Anlage dann parallel auch den OCS-Status, obwohl der Benutzer weder OCS-Telefonie noch OCS-RCC nutzt.

Weitere Links