Mit dem Thema „Interoperabilität“ muss ich mich an jedem Tag meines Berufslebens auseinandersetzen. In den vergangenen Wochen habe ich viel Zeit mit den im Markt angebotenen Session-Border-Controllern verbracht, denn einer meiner Kunden wollte seinen Session-Border-Controller mit einem Voice-Recorder zusammenarbeiten lassen. Auch wenn dieses Ansinnen nach einer ziemlich einfachen Aufgabe klingt, liegt der Teufel wie immer im Detail. Die Marketing-Broschüren oder Produktmerkblätter der Hersteller bieten selten die notwendige Detailtiefe um ein Problem lösen zu können. Um an das notwendige Wissen zu kommen, muss man telefonieren, E-Mails verschicken und oft auf die Gefälligkeiten der Supporter oder Systemingenieure hoffen. Jedoch verstehen unterschiedliche Hersteller unter dem Begriff „Interoperabilität“ immer Dinge, die meinem Verständnis nach nichts mit „Interoperabilität“ zu tun haben.
Die Interoperabilität ist ein Begriff mit vielen verschiedenen Ebenen. Auf der untersten Ebene bedeutet Interoperabilität (nach meiner Meinung), dass man beim Zusammenschalten zweier Komponenten nicht den Kommunikationspartner zum Absturz bringt. Technisch gesehen bedeutet „Interoperabilität“ auf dieser Ebene nur „Kompatibilität“. Mehr ist auch auf dieser Ebene nicht notwendig: Zwei Produkte arbeiten problemlos auf der technischen Ebene zusammen.
Weiter oben im Schichtenmodell sollte man in der Lage sein, die entsprechenden Informationen zwischen zwei Geräten oder Systemen problemlos auszutauschen. Man sollte erwarten, dass die übermittelten Informationen richtig interpretiert werden. Auch sollte eine adäquate Reaktion auf die übermittelten Informationen erfolgen. Beispiel: Ein Avaya-System unterstützt die SIP-Funktionen. Wird ein SIP-Telefon von Polycom an ein Avaya-System angeschaltet, dann bedeutet die Interoperabilität auf dieser Ebene, dass ein Polycom-SIP-Telefon an einem Avaya-System problemlos Anrufe tätigen und empfangen kann.
Wandert man noch höher in der Anforderungsliste, dann kommt man zwangsläufig an den Punkt der Produkt-Features. Zum Beispiel lässt sich ein Polycom-SIP-Telefon erfolgreich an eine Avaya-Anlage anschließen, aber es liefert nicht zwangsläufig die gleichen Features wie ein vergleichbares Avaya-Telefon. Dies hat die triviale Ursache, dass die Firmware eines Avaya-SIP-Telefons gewisse Dinge tut, die außerhalb des erwarteten Verhalten eines „Standard-SIP-Telefons“ liegen. Dies macht Avaya-Telefone weder besser noch schlechter als Polycom-Telefone, aber die Hersteller nutzen die zusätzlichen Featurs zur Abgrenzung gegenüber dem Wettbewerb.
Ich liebe es, die installierten Kommunikationskomponenten über ein zentrales Management-Interface zu Konfigurieren und zu Überwachen. Auch in diesem Bereich spielt die Interoperabilität eine zentrale Rolle. Einige Komponenten arbeiten problemlos zusammen und kommunizieren wie erwartet miteinander. Aber beim Management und der Konfiguration hört deren Gemeinsamkeit sehr schnell auf. Die fehlende Interoperabilität auf dieser Ebene verkompliziert die Konfiguration, führt zu Fehlern und Zeitverlusten und hinterlässt in der Regel unzufriedene Techniker.
Web-Services spielen eine große Rolle bei der Interoperabilität. In der Regel erfordert das Zusammenspiel zwischen zwei Produkten unterschiedlicher Hersteller eine kundenspezifische Konfiguration. Aus diesem Grund ist eine gute Web-Schnittstelle zur Anpassung zweier unterschiedlicher Produkte von Wichtigkeit.
Interoperabilität kann auch dadurch erreicht werden, dass ein System dem anderen System signalisiert, dass etwas nicht stimmt. Dieser Aspekt wird all zu oft bei Produktentscheidungen übersehen. Ich überprüfe bei einer Kaufentscheidung immer die SNMP- (Simple-Network-Management-Protocol-)Unterstützung der betreffenden Hersteller in deren Produkten. Die in der jeweiligen SNMP-MIB (Management-Information-Base) versteckten Parameter eines Produkts bleiben oft die einzigen Mechanismen, um Konfigurationsprobleme beheben zu können. Je vollständiger die MIB ist, desto besser (granularer) lassen sich die Informationen anpassen.
Neue Technologien bringen zwangsläufig eine Reihe von Interoperabilitätsproblemen mit sich. Die Herausforderung besteht darin, eine Brücke zwischen den neuen und alten Mechanismen zu finden. In letzter Zeit scheinen sich jedoch unterschiedliche Formen der „neuen Mechanismen“ zu etablieren.
WebRTC ist das Aushängeschild für den neuesten Umbruch in der Kommunikationsindustrie. Die Unternehmen arbeiten momentan an der Integration von WebRTC in ihre bestehenden VoIP-Systeme und -Prozesse. Bei der Integration einer WebRTC Lösung eines Anbieters mit einer WebRTC Lösung eines anderen Anbieters kommt es zu erheblichen Problemen. Dies hat sowohl mit der unbekannten (weil neuen) Technologie als auch mit dem Desinteresse der Hersteller an Standards zu tun.
Nur weil ein Hersteller behauptet, er unterstütze einen Standard, bedeutet dies nicht, dass seine Produkte alle die gleiche Variante des betreffenden Standards implementiert haben. Auch bedeutet diese Aussage nicht, dass seine Produkte mit Produkten anderer Hersteller kompatibel sind und dem gleichen Standard folgen. Das Avaya-SIP unterscheidet sich signifikant von Ciscos SIP, welches sich wiederum signifikant von Microsofts SIP unterscheidet. Manchmal sind die Unterschiede nur ärgerlich.
Die Interoperabilität erfordert manchmal einen „Vermittler“ zwischen den unterschiedlichen Welten, um die Dinge wieder in Ordnung zu bringen. Die Session-Border-Controller werden oft für diese Aufgabe eingesetzt. SBCs unterstützt eine Art Anpassungsschicht, die den SIP-Dialekt von einem Anbieter an den SIP-Dialekt eines anderen Herstellers anpasst.
Unterm Strich bleibt: da sich nicht alle Hersteller an Standards halten bzw. diesen oft anders interpretieren ist die Interoperabilität wichtiger denn je. Und diese muss leider immer wieder auf Neue getestet werden. (mh)
