Connect Cisco Room Kits with OpenTalk – SIP, Obelisk, and LiveKit in use

Cisco Room Kits and video phones such as the Cisco Webex DX80 were once real status symbols – expensive, high-quality, designed for professional use. Today, they lead a shadowy existence in many government agencies and companies. Since video conferencing has become possible with any laptop, the devices of yesteryear often seem like oversized relics.

But this hardware still has a lot of potential. Many of these devices can not only make phone calls, but also transmit video via SIP – a feature that has hardly been used in modern open source setups to date.

We wanted to know: Can we continue to use these Cisco devices in a meaningful way? Can we connect them to OpenTalk, including image and sound, without any Webex restrictions or cloud connection – simply in our own network?

The short answer: yes, it works. You can find the long answer in this blog article.

We show you how we connected various Cisco phones and room kits to our OpenTalk video conferencing solution – via SIP, with a custom-developed service called Obelisk, and completely redesigned media processing based on LiveKit and Rust. Getting there was technically challenging, with a few stumbling blocks along the way – but that's exactly what made it so exciting for us.

Cisco Room Kits & Desk Phones: Old technology, new opportunities

Why Cisco of all companies? Quite simply because the devices are still everywhere. In government offices, companies, meeting rooms – often on every other desk. And because they can do much more than you might think at first glance.

Devices such as the Cisco Webex DX80 or the 8945 desk phone initially look like classic SIP phones. But many of them also support video telephony – and that's exactly what makes them interesting for modern conference solutions. Especially if you want to connect them to an open source video platform such as OpenTalk.

A real plus point: Cisco devices can be provisioned centrally. When switched on, they automatically retrieve their configuration via TFTP (Trivial File Transfer Protocol) – using their custom MAC address, they search specifically for a suitable XML file in the format SEP[MAC].cnf.xml. Although this file does not contain any information about the codecs actually supported (this varies greatly from model to model), it does contain all the important details such as SIP accounts, phone book entries, and other settings. This makes it easy to set up and manage even large fleets of devices.

The Cisco Room Kits are even more interesting: they consist of a high-quality camera and microphone unit (usually mounted on the monitor as a “bar”) and a tablet for control. These devices are designed for conference rooms, automatically recognize speakers, zoom dynamically, and deliver clear audio and video even in larger groups. Also tested: a Cisco Webex DX80, which uses the same firmware as the Room Kits. It runs on Android.

The integrated web dashboard allows the devices to be customized with remarkable flexibility – if you know where to look. In our case, one of the first steps was to disable the Webex button. After all, we didn't want to tie the hardware to the cloud, but rather integrate it into our custom open-source video conferencing system.

SIP can do more – if you use it right

The key to integrating Cisco devices lies in the SIP protocol (Session Initiation Protocol). Although the hardware was originally developed for proprietary systems such as Webex, SIP allows it to be integrated into open infrastructures – such as OpenTalk.

Our solution is based on two components: Asterisk and Obelisk.

• Asterisk acts as the SIP registrar in our setup. The Cisco phones log in there with their SIP access data, just like with a traditional IP telephone system. Each participant is assigned a custom extension number, such as 1000, 1001, or 1002 – just like in a traditional system. When one device calls another number, the call is forwarded via Asterisk.
• Obelisk is our custom link between the SIP world and the browser-based WebRTC world of OpenTalk. The service receives SIP requests, interprets SDP (Session Description Protocol) data, and uses the available codecs to decide whether a connection is possible – and how.

In order for Cisco phones and OpenTalk to work together, a translation between the formats is required – and that's exactly what Obelisk does. In the SIP world, H.264 is widely used as a video codec, while in OpenTalk, based on WebRTC, we currently use VP8 for video and Opus for audio. (The choice of codecs is not fixed in WebRTC, but VP8 and Opus are a robust solution in many setups.)

When establishing a connection, Obelisk automatically detects which codecs are available on both sides and converts the media streams accordingly. For example, an incoming H.264 video stream is translated live into VP8 – and vice versa, if necessary, from VP8 back to H.264. The same applies to the audio channel, typically from G.722 to Opus.

This allows Cisco devices and OpenTalk clients to communicate seamlessly, regardless of which codecs they originally speak.

How a SIP call with OpenTalk works in detail

When a Cisco device such as the DX80 is to participate in an OpenTalk video conference, everything starts with a classic SIP call – more precisely, with a so-called INVITE message. This contains a technical offer for media transmission: the so-called SDP offer. SDP stands for Session Description Protocol and defines the framework for the connection. However, Cisco phones do not explicitly reveal which resolutions or frame rates they support. Instead, they provide information about the available audio and video codecs (such as G.722 or H.264) and the maximum bit rate.

We therefore calculate the actual usable resolution and frame rate (frames per second, FPS) ourselves: Based on the bit rate, we determine the optimal ratio of resolution and frame rate – with the aim of achieving a constant 25 FPS without exceeding the bandwidth. Sometimes this means a lower resolution with more frames per second, sometimes the other way around – depending on what the device and connection can handle.

Obelisk checks this offer, decides which options are suitable for OpenTalk, and responds with a matching SDP answer as part of the 200 OK message. If the connection is accepted, the media flow starts: Obelisk then transcodes in real time, for example from H.264 to VP8 or from G.722 to Opus – and vice versa. This turns a classic SIP call into a modern WebRTC stream in OpenTalk.

CUCM in testing: Between VMware and video image

Although our setup with Asterisk and Obelisk was already working well, we wanted to go one step further. Many larger organizations do not rely on Asterisk, but use Cisco Unified Communications Manager (CUCM) – also known as CallManager. So anyone who wants to connect existing Cisco infrastructures to OpenTalk will sooner or later end up there.

Our idea: if we can bring SIP video calls from CUCM into OpenTalk, we will lay the foundation for truly broad support of Cisco systems – without having to rebuild existing telephony infrastructures. The reality: much more complex than expected.

Setting up CUCM is not entirely trivial. It starts with the installation – CUCM only runs on VMware, requires certain network settings, special ISO images, and a lot of patience. The web interface is functional, but convoluted – if you want to integrate a video phone correctly, you need to know which screws to turn. A look at the manual is recommended!

Ultimately, we managed to successfully set up CallManager, activate the services, and register the first test devices. The first call? It worked. But then small but crucial problems arose: video images were faulty, bit rates were misinterpreted, and devices responded unexpectedly. Some of this was due to encoding, some to protocol details, and some to settings that were not documented.

Particularly challenging: Different Cisco devices do not always behave the same way, even with identical firmware. Some only support video streaming in one direction, others require an adjusted bit rate, and still others prefer the proprietary SCCP protocol (Skinny Client Control Protocol) instead of SIP.

In short: CallManager works—but it is demanding. It takes experience, patience, and good troubleshooting skills to connect the devices to OpenTalk. We learned a lot in the process. And that was exactly our goal.

Firmware, bit rate, custom behavior – a field report

In practical use with various Cisco devices, it quickly became clear that each model has its own peculiarities – not only in terms of operation, but also in the technical implementation of video calls.

For example, some devices delivered a faulty video image during the first test with Cisco CallManager. The cause was an incorrect calculation of the maximum bit rate – the solution was surprisingly simple: the bit rate simply had to be divided by two. Background: Some models expect the specification for the entire data flow (back and forth), others only for one direction. Without clear labeling in the log, the only option is to try it out – or use a conservative default value for all devices.

Another issue was devices with company-specific configurations: Some used Cisco devices, for example from previous company installations, were equipped with custom firmware. When started, this firmware attempted to connect to external servers to download updates or retrieve policies – usually on IP addresses or ports that were not accessible. Without this connection, the devices refused to work, regardless of the current network configuration.

Particularly problematic: Some of these settings can only be removed via the original Cisco CallManager. Without access to this, the device can remain permanently blocked – a complete reset or firmware update is then no longer possible. Anyone using used hardware should therefore check carefully whether it can be completely re-provisioned.

However, many problems can be solved with patience and careful analysis – for example, by evaluating logs, manually adjusting codecs, or running longer test runs. And it's worth it: once the setup is complete, even older devices work reliably in a modern open-source video conferencing solution such as OpenTalk.

More media, fewer bugs: LiveKit meets Rust

While we were working with Asterisk, Obelisk, and Cisco CallManager on the SIP side, a major change was also underway on the WebRTC side. Originally, OpenTalk used the well-known Janus media server to manage audio and video streams between participants. However, as the number of participants increased and the range of functions grew, we increasingly reached our limits – for example, when individual streams suddenly dropped out or became out of sync in larger conferences.

That's why we decided to completely rebuild the backend for media processing – with LiveKit. The open source project offers exactly what we needed: modern WebRTC support, integrated scaling via Kubernetes, stable connections, and a real plus in terms of performance and flexibility. Particularly helpful: LiveKit offers a Rust SDK that fits seamlessly into our technology stack.

We took the opportunity to rewrite our entire media logic in Rust from scratch. Previously, we had been working with GStreamer, a C-based library that can do a lot but repeatedly struggled with unstable runtimes. Our new build now uses native SIMD (single instruction, multiple data) instructions, eliminates dynamic configurations at runtime, and is thus significantly more robust.

The switch to Rust has not only reduced bugs, but also made the entire code base easier to maintain. Since then, our media backend has been running stably – and OpenTalk is technically ready for conferences of any size.

Conclusion: Open source makes it possible – sustainably and flexibly

What began as an experiment with a few old Cisco devices quickly developed into a deep dive into the world of SIP, SDP, and video codecs. We learned that even seemingly standardized protocols such as SIP have many gray areas in practice – and that every device has its own peculiarities, be it in terms of bit rate, codec or firmware.

Despite all the stumbling blocks, we were able to show that It is possible to seamlessly integrate older Cisco room solutions and video phones into OpenTalk – without Webex and without cloud constraints. With Asterisk as the SIP registrar, our Obelisk gateway as the bridge to the WebRTC world, and modern media processing based on LiveKit, we have created a stable and future-proof solution.

It took a lot of effort. But the insights, flexibility, and independence we have gained speak for themselves. And perhaps it will motivate others to take a fresh, open look at their existing infrastructure.