Cisco Room Kits mit OpenTalk verbinden – SIP, Obelisk und LiveKit im Einsatz

Cisco Room Kits und Videotelefone wie das Cisco Webex DX80 waren einmal echte Statussymbole – teuer, hochwertig, für den professionellen Einsatz konzipiert. Heute fristen sie in vielen Behörden und Unternehmen ein Schattendasein. Seit Videokonferenzen mit jedem Laptop möglich sind, wirken die Geräte von damals oft wie überdimensionierte Altlasten.

Dabei steckt in dieser Hardware noch einiges an Potenzial. Viele dieser Geräte können nicht nur telefonieren, sondern auch Video über SIP übertragen – eine Funktion, die in modernen Open-Source-Setups bislang kaum genutzt wird.

Wir wollten wissen: Können wir diese Cisco-Geräte sinnvoll weiterverwenden? Können wir sie an OpenTalk anbinden, inklusive Bild und Ton, ganz ohne Webex-Zwang, ohne Cloud-Bindung – einfach im eigenen Netzwerk?

Die kurze Antwort: Ja, es geht. Die lange Antwort finden Sie in diesem Blogartikel.

Wir zeigen Ihnen, wie wir verschiedene Cisco-Telefone und Room Kits mit unserer Videokonferenzlösung OpenTalk verbunden haben – über SIP, mit einem eigens entwickelten Service namens Obelisk und einer komplett überarbeiteten Medienverarbeitung auf Basis von LiveKit und Rust. Der Weg dorthin war technisch anspruchsvoll, mit einigen Stolpersteinen – aber genau das hat es für uns so spannend gemacht.

Cisco Room Kits & Tischtelefone: Alte Technik, neue Chancen

Warum ausgerechnet Cisco? Ganz einfach: Weil die Geräte noch überall stehen. In Behörden, Unternehmen, Besprechungsräumen – oft auf jedem zweiten Schreibtisch. Und weil sie viel mehr können, als man auf den ersten Blick vermuten würde.

Geräte wie das Cisco Webex DX80 oder das 8945-Tischtelefon wirken zunächst wie klassische SIP-Telefone. Doch viele von ihnen beherrschen auch Videotelefonie – und genau das macht sie für moderne Konferenzlösungen interessant. Vor allem, wenn man sie mit einer Open-Source-Videoplattform wie OpenTalk verbinden möchte.

Ein echter Pluspunkt: Cisco-Geräte lassen sich zentral provisionieren. Beim Einschalten holen sie sich ihre Konfiguration automatisch per TFTP (Trivial File Transfer Protocol) – anhand der eigenen MAC-Adresse suchen sie gezielt nach einer passenden XML-Datei der Form SEP[MAC].cnf.xml. Dort sind zwar keine Infos zu den tatsächlich unterstützten Codecs hinterlegt (das ist von Modell zu Modell sehr unterschiedlich), aber alle wichtigen Dinge wie SIP-Accounts, Telefonbucheinträge und weitere Einstellungen. So lassen sich selbst große Flotten an Geräten unkompliziert einrichten und verwalten.

Noch interessanter wird es bei den Cisco Room Kits: Sie bestehen aus einer hochwertigen Kamera- und Mikrofoneinheit (meist als „Bar“ am Monitor montiert) und einem Tablet zur Steuerung. Diese Geräte sind für Konferenzräume gedacht, erkennen Sprecher*innen automatisch, zoomen dynamisch und liefern selbst in größeren Gruppen ein sauberes Audio- und Videobild. Im Test weiterhin: ein Cisco Webex DX80, das die gleiche Firmware wie die Room Kits verwendet. Unter der Haube läuft ein Android.

Über das integrierte Web-Dashboard und lassen sich die Geräte erstaunlich flexibel anpassen – wenn man weiß, wo man suchen muss. In unserem Fall war einer der ersten Schritte: den Webex-Button deaktivieren. Schließlich wollten wir die Hardware nicht an die Cloud binden, sondern in unser eigenes Open-Source-Videokonferenzsystem integrieren.

SIP kann mehr – wenn man’s richtig nutzt

Der Schlüssel zur Integration der Cisco-Geräte liegt im SIP-Protokoll (Session Initiation Protocol). Denn obwohl die Hardware ursprünglich für proprietäre Systeme wie Webex entwickelt wurde, lässt sie sich dank SIP auch in offene Infrastrukturen einbinden – zum Beispiel in OpenTalk.

Im Zentrum unserer Lösung stehen zwei Komponenten: Asterisk und Obelisk:

• Asterisk fungiert in unserem Setup als SIP-Registrar. Die Cisco-Telefone melden sich dort mit ihren SIP-Zugangsdaten an, genau wie bei einer klassischen IP-Telefonanlage. Jeder Teilnehmer bekommt eine eigene Durchwahl, etwa 1000, 1001 oder 1002 – ganz klassisch. Ruft ein Gerät eine andere Nummer an, wird der Anruf über Asterisk weitervermittelt.
• Obelisk ist unser eigenes Bindeglied zwischen der SIP-Welt und der browserbasierten WebRTC-Welt von OpenTalk. Der Dienst nimmt SIP-Anfragen entgegen, interpretiert SDP-Daten (Session Description Protocol) und entscheidet anhand der Codec-Angebote, ob eine Verbindung möglich ist – und wie.

Damit Cisco-Telefone und OpenTalk wirklich zusammenarbeiten können, braucht es eine Übersetzung zwischen den Formaten – genau das übernimmt Obelisk. In der SIP-Welt ist H.264 als Videocodec weit verbreitet, während wir in OpenTalk auf Basis von WebRTC aktuell VP8 für Video und Opus für Audio einsetzen. (Die Wahl der Codecs ist bei WebRTC nicht fest vorgegeben, aber VP8 und Opus bieten sich in vielen Setups als robuste Lösung an.)

Beim Aufbau einer Verbindung erkennt Obelisk automatisch, welche Codecs auf beiden Seiten zur Verfügung stehen, und wandelt die Medienströme entsprechend um. So wird zum Beispiel ein eingehender H.264-Videostream live in VP8 übersetzt – und umgekehrt, falls nötig auch von VP8 zurück nach H.264. Das Gleiche gilt für den Audiokanal, typischerweise von G.722 zu Opus.

Auf diese Weise können sich Cisco-Geräte und OpenTalk-Clients problemlos verständigen – unabhängig davon, welche Codecs sie ursprünglich sprechen.

So funktioniert ein SIP-Anruf mit OpenTalk im Detail

Wenn ein Cisco-Gerät wie das DX80 an einer OpenTalk-Videokonferenz teilnehmen soll, beginnt alles mit einem klassischen SIP-Anruf – genauer gesagt mit einer sogenannten INVITE-Nachricht. Diese enthält ein technisches Angebot zur Medienübertragung: das sogenannte SDP-Offer. SDP steht für Session Description Protocol und legt den Rahmen für die Verbindung fest. Die Cisco-Telefone verraten darin jedoch nicht explizit, welche Auflösungen oder Frameraten sie unterstützen. Stattdessen finden sich Angaben zu den verfügbaren Audio- und Video-Codecs (wie G.722 oder H.264) und zur maximalen Bitrate.

Die tatsächlich nutzbare Auflösung und Bildwiederholrate (Frames per Second, FPS) berechnen wir daher selbst: Anhand der Bitrate ermitteln wir das optimale Verhältnis von Auflösung und Framerate – mit dem Ziel, möglichst konstante 25 FPS zu erreichen, ohne die Bandbreite zu überschreiten. Manchmal bedeutet das: Lieber eine geringere Auflösung mit mehr Bildern pro Sekunde, manchmal umgekehrt – je nachdem, was das jeweilige Gerät und die Verbindung hergeben.

Obelisk prüft dieses Angebot, entscheidet, welche Optionen zu OpenTalk passen, und antwortet mit einem passenden SDP-Answer als Teil der 200-OK-Nachricht. Wird die Verbindung akzeptiert, startet der Medienfluss: Obelisk transkodiert dann in Echtzeit, zum Beispiel von H.264 nach VP8 oder von G.722 nach Opus – und umgekehrt. So wird aus einem klassischen SIP-Anruf ein moderner WebRTC-Stream in OpenTalk.

CUCM im Test: Zwischen VMware und Videobild

Obwohl unser Setup mit Asterisk und Obelisk bereits gut funktionierte, wollten wir noch einen Schritt weitergehen. Viele größere Organisationen setzen nicht auf Asterisk, sondern nutzen den Cisco Unified Communications Manager (CUCM) – auch bekannt als CallManager. Wer also bestehende Cisco-Infrastrukturen an OpenTalk anbinden möchte, wird früher oder später genau dort landen.

Unsere Idee: Wenn wir es schaffen, SIP-Videoanrufe aus dem CUCM in OpenTalk zu bringen, schaffen wir die Grundlage für eine wirklich breite Unterstützung von Cisco-Systemen – ohne dass bestehende Telefonie-Infrastrukturen umgebaut werden müssen. Die Praxis: deutlich komplexer als erwartet.

Die CUCM-Einrichtung ist nicht ganz trivial. Das beginnt bei der Installation – CUCM läuft nur auf VMware, braucht bestimmte Netzwerkeinstellungen, spezielle ISO-Images und einiges an Geduld. Auch die Weboberfläche ist funktional, aber verschachtelt – wer dort ein Videotelefon korrekt einbinden will, muss wissen, an welchen Stellschrauben zu drehen ist. Ein Blick in die Anleitung ist empfehlenswert! 

Letztendlich haben wir es geschafft, den CallManager erfolgreich eingerichtet, die Services aktiviert und erste Testgeräte registriert. Der erste Anruf? Lief. Doch dann traten kleine, aber entscheidende Probleme auf: Videobild fehlerhaft, Bitraten falsch interpretiert, Geräte reagierten unerwartet. Teilweise lag es an der Kodierung, teilweise an Protokolldetails, manchmal an Einstellungen, die nicht dokumentiert waren.

Besonders herausfordernd: Unterschiedliche Cisco-Geräte verhalten sich selbst bei identischer Firmware nicht immer gleich. Manche unterstützen Videostreaming nur einseitig, andere benötigen eine angepasste Bitrate, wieder andere bevorzugen das proprietäre SCCP-Protokoll (Skinny Client Control Protocol) statt SIP.

Kurz gesagt: Der CallManager funktioniert – aber er ist anspruchsvoll. Es braucht Erfahrung, Geduld und gutes Troubleshooting, um die Geräte mit OpenTalk zu verbinden. Wir haben dabei viel gelernt. Und genau das war unser Ziel.

Firmware, Bitrate, Eigenleben – ein Erfahrungsbericht

Im praktischen Einsatz mit verschiedenen Cisco-Geräten wurde schnell klar: Jedes Modell hat seine Eigenheiten – nicht nur bei der Bedienung, sondern auch in der technischen Umsetzung von Videoanrufen.

Ein Beispiel: Manche Geräte lieferten beim ersten Test mit dem Cisco CallManager ein fehlerhaftes Videobild. Ursache war eine fehlerhafte Berechnung der maximalen Bitrate – die Lösung war überraschend einfach: Die Bitrate musste schlicht durch zwei geteilt werden. Hintergrund: Einige Modelle erwarten die Angabe für den gesamten Datenfluss (hin und zurück), andere nur für eine Richtung. Ohne klare Kennzeichnung im Protokoll bleibt nur Ausprobieren – oder ein konservativer Standardwert für alle.

Ein weiteres Thema waren Geräte mit firmenspezifischer Konfiguration: Manche gebrauchten Cisco-Geräte, etwa aus früheren Unternehmensinstallationen, waren mit einer individuellen Firmware versehen. Diese versuchte beim Start, sich mit externen Servern zu verbinden, um Updates zu laden oder Richtlinien abzurufen – meist auf nicht erreichbaren IPs oder Ports. Ohne diese Verbindung verweigerten die Geräte ihren Dienst, unabhängig von der aktuellen Netzwerkkonfiguration.

Besonders problematisch: Solche Einstellungen lassen sich teilweise nur über den ursprünglichen Cisco CallManager entfernen. Ohne Zugriff darauf kann das Gerät dauerhaft in einem blockierten Zustand verbleiben – ein vollständiger Reset oder ein Firmware-Update ist dann nicht mehr möglich. Wer also gebrauchte Hardware einsetzt, sollte genau prüfen, ob sie sich vollständig neu provisionieren lässt.

Viele Probleme lassen sich jedoch mit Geduld und sorgfältiger Analyse beheben – etwa durch Protokollauswertung, manuelle Codec-Anpassungen oder längere Testläufe. Und das lohnt sich: Denn wenn das Setup einmal steht, funktionieren selbst ältere Geräte zuverlässig in einer modernen Open-Source-Videokonferenzlösung wie OpenTalk.

Mehr Medien, weniger Bugs: LiveKit trifft Rust

Während wir auf der SIP-Seite mit Asterisk, Obelisk und dem Cisco CallManager arbeiteten, stand auch auf der WebRTC-Seite ein größerer Umbruch an. Ursprünglich nutzte OpenTalk den bekannten Medienserver Janus, um Audio- und Videoströme zwischen Teilnehmer*innen zu verwalten. Doch mit steigender Teilnehmerzahl und wachsendem Funktionsumfang stießen wir immer häufiger an Grenzen – etwa, wenn einzelne Streams in größeren Konferenzen plötzlich abbrachen oder nicht mehr synchron liefen.

Deshalb haben wir uns entschieden, das Backend für die Medienverarbeitung vollständig neu aufzusetzen – und zwar mit LiveKit. Das Open-Source-Projekt bringt genau das mit, was wir brauchten – moderne WebRTC-Unterstützung, integrierte Skalierung über Kubernetes, stabile Verbindungen und ein echtes Plus in Sachen Performance und Flexibilität. Besonders hilfreich: LiveKit bietet ein Rust-SDK, das nahtlos zu unserem Technologie-Stack passt. 

Wir haben die Gelegenheit genutzt, unsere gesamte Medienlogik neu zu schreiben – in Rust, von Grund auf. Zuvor hatten wir mit GStreamer gearbeitet, einer C-basierten Bibliothek, die zwar viel kann, aber immer wieder mit instabilen Laufzeiten zu kämpfen hatte. Unser Neubau nutzt jetzt native SIMD-Instruktionen (Single Instruction, Multiple Data), verzichtet auf dynamische Konfigurationen zur Laufzeit und ist damit deutlich robuster.

Der Wechsel zu Rust hat nicht nur Bugs reduziert, sondern die gesamte Codebasis besser wartbar gemacht. Seitdem läuft unser Medien-Backend stabil – und OpenTalk ist technisch bereit für Konferenzen jeder Größe.

Fazit: Open Source macht’s möglich – nachhaltig und flexibel

Was als Experiment mit ein paar alten Cisco-Geräten begann, hat sich schnell zu einem tiefen Tauchgang in die Welt von SIP, SDP und Videocodecs entwickelt. Wir haben gelernt, dass selbst scheinbar standardisierte Protokolle wie SIP in der Praxis viele Grauzonen haben – und dass jedes Gerät seine Eigenheiten mitbringt, sei es bei der Bitrate, beim Codec oder bei der Firmware.

Trotz aller Stolpersteine konnten wir zeigen: Es ist möglich, ältere Cisco-Raumlösungen und Videotelefone nahtlos in OpenTalk zu integrieren – ganz ohne Webex, ganz ohne Cloud-Zwang. Mit Asterisk als SIP-Registrar, unserem Gateway Obelisk als Brücke zur WebRTC-Welt und einer modernen Medienverarbeitung auf Basis von LiveKit ist eine stabile und zukunftsfähige Lösung entstanden.

Der Aufwand war nicht gering. Aber die Erkenntnisse, die Flexibilität und die Unabhängigkeit, die wir damit gewonnen haben, sprechen für sich. Und vielleicht motiviert es auch andere, ihre bestehende Infrastruktur nochmal mit einem frischen, offenen Blick zu betrachten.