Holy cows! (XoWS) Delivering the art of possible with video devices
Connecting video devices with XoWS
Cisco manufactures, hands down, best of breed Collaboration Video Devices in the world. Around April of this year, one of our Technical Leaders, Magnus Ohm, published a fantastic blog about xAPI-over-WebSockets (XoWS). It got our Python developers stoked! Connecting to our award-winning video devices using persistent web socket connections opened tremendous opportunities into delivering some fantastic use cases.
At Cisco, Technical Marketing Engineers help demystify complex architectures. We build out-of-the-box demonstrations and often times, we develop highly specialized proof of concepts. In this blog, I’ll discuss how the XoWS feature was used to articulate the “art of the possible” for one our customers.
While preparing for Cisco Live US in June, I was asked to help solve an interesting customer problem; manage multiple integrator video devices from a single pane of glass. If you’ve been surrounded by Cisco Collaboration as long as I have, then you may already be considering our Telepresence Management Suite application as the viable solution – remember Conference Control Center? What was so unique about this challenge then? Well, for one, the solution needed to manage several on-premises registered video devices, with the potential to control cloud registered (Webex) video devices as well; some potentially registered to different organizations or perhaps no call controller at all. Of course, these devices would be deployed across disparate networks and “Swiss cheesing” firewalls to access every codec’s web-based user interface was out of the question! The users needed a “bulk management” or “white-glove-service” portal of sorts.
Delivering the best solution
To get started, I was provided a handful of requirements –
(1) The users need to Dial / Answer / Hang-up / Transfer calls on the video devices
(2) They would like a preview of the Remote participant currently on a call
(3) 10 or more users would concurrently access this web page
(4) 15 or more video devices would need to be controlled from this web page
(5) Users would access this web page from different locations
(6) The video devices are hosted in different data centers
(7) There may be a mix of on-premises or cloud registered video devices
Surely, I could have wired up a single page application that could connect to every video codec the customer needed to control, but where’s the fun in that? How would you scale gracefully when you’re told ten or more users would tinker with fifteen, maybe twenty or more video devices from different physical locations – concurrently? Now before we go any further, let’s all keep in mind that this was a Proof-of-Concept to be built, not a TAC supported product. Just a creative yet scalable way to solve a problem. If you’re familiar with our XAPIs, or may have used the jsxapi library, your mind may already have connected the dots and creatively “solutioned” the problem, but wait! We had just released support for XoWS with CE 9.7.1! Wouldn’t that theoretically provide a scalable way to accomplish the mission?
Let’s dive into those requirements I mentioned earlier:
Requirement #1 (Need to Dial / Answer / Hang-up / Transfer calls ) – Whether you use the jsxapi library and connect over SSH, or decide to POST over HTTPS, this requirement can be easily fulfilled by understanding the codec’s xCommands. See API Reference Guide
For example, xCommand Dial Number: “12345” Protocol: H323
Eine Minute Bitte! Hold up! Requirements #3 (10 or more users with concurrent access) and #4 (15 or more video devices) suggest we would need a way to send these xCommands to multiple video devices and somehow avoid multiple users from sending redundant commands to the same codec from separate sessions! Does that mean I need to consider managing user sessions, and, communication between these sessions?
Any web server with the right network access would address requirement #5 (Access web page from different locations) and if the video devices are on a routable customer network, requirement #6 (Video devices hosted in different data centers) would be met by this web server as well.
Requirement #7 (Mix of on-premises or cloud registered video devices) sounds tricky. At the time of writing this blog, we did not have the Cloud xAPI feature generally available for our cloud registered video devices. However, since we would deploy a web server for the user interface, why not develop “agents” or “connectors” that could access these video devices using the Integrator or Room Control roles!! Let’s also de-centralize the architecture for scale while we’re at it!
I’ve saved the best for last! Requirement #2 (Remote snapshots) – we do not officially support any way of providing snapshots of the “Remote” participant on a call, unless the call is “unencrypted” – full disclosure, this is a caveat and as such, I will not dive deeper into this topic. The objective here is to highlight the benefit of WebSocket support on our video devices!
Enter Project Codec Commander! A proof-of-concept powered by NodeJS, Redis and leveraging the XoWS feature available exclusively on Cisco Video Devices. For folks new to Cisco Collaboration, the word “codec” is often used to describe a video device.
NodeJS provides us the flexibility to consume it as a web server as well as an “agent”. It’s extremely easy to get started with NodeJS over just an Internet connection; check out Glitch! NodeJS also has several well-documented and mature packages for developing WebSocket client and servers, drivers for datastore connectivity, and your script can also be easily packaged or run as a “forked” process.
Redis is an absolutely fantastic in-memory data structure store. Some readers may argue a case for Kafka, RabbitMQ or others, but when asked to deliver a quick solution, I believe one should do so with the method they are most comfortable executing. In this case, Redis was used for storing JSON objects containing information about the code, but the real magic of commanding numerous video devices was best experienced when Redis was also utilized a message broker! (Illustration below):
What? Message broker? Yes! Think back to the requirements. We need a way to transmit commands from a user’s browser session, across and over to an individual video device, racked in a remote data center somewhere. This system would also need to accept xEvents from every video device, transmit the information back over to every active user’s browser, and manipulate the user interfaces. “Proof-of-concept” by definition is proof that a solution is viable in a very short amount of time and Redis provides the best-fit “Message Broker”, easy to consume on-premise, or inexpensively sourced from a cloud provider like Redis Labs.
Let’s get to the nitty gritty
Now that you have a view into the high-level architecture, let’s dive into some of the design details. (Refer to above illustration)
(A) Client Commander – This is a NodeJS web server that provides the following:
- Web socket server to orchestrate communications to/from and between multiple user sessions
- Redis Publisher to update data and send commands to video devices
- Redis Subscriber to receive notifications from video devices and other systems
(B) Message Broker – this is a Redis server that provides the following:
- Data store containing information about every video device (e.g. Serial #, Name, SIP URI, Display Name, Status etc)
- Pub/Sub broker sending/receiving data payloads across (A) Client Commander and (C) Codec Commander
(C) Codec Commander – These are individual NodeJS scripts that act as “agents”. Each agent is assigned to a particular video device for scalability and resilience. These scripts provide the following:
- Web socket client that connects to the codec and queries configuration data
- Subscribes to assigned codec’s xEvents and xStatus JSONRPC messages to monitor various states
- Sends xCommand and xConfig JSONRPC payloads to it’s assigned codec
- Redis Publisher to update codec data and send events/notifications from video devices
- Redis Subscriber to receive commands destined to the assigned codec
- 3 second preview snapshots using fetch()
In less than 2 weeks, XoWS provided us the ability to build a functional demonstration. Here’s a glimpse of an early release of the web interface:
** UI credits: Lauren Ramgattie & Peter Welburn
Note: I was lucky to have Lauren & Peter help design and develop the user interface.! That’s not my area of forte and I cannot express enough, the importance of partnering with interface designers! No software demonstration or PoC can communicate its value proposition without an effective user interface! Thank you Lauren & Peter!
Deliver the art of possible
In conclusion, the XoWS feature provides developers with exceptional control and scale over Cisco video devices. Starting from release CE 9.7.1 and above, WebSocket connectivity on Cisco video devices will provide persistent connection capabilities for your client applications. It’s availability as a protocol on our Collaboration Endpoint ecosystem creates invaluable opportunities for our customers and partners. XoWS is an extremely powerful differentiator that enables highly scalable and secure ways of codec management, control and transformative workflow integrations. Reach out for more information or tell us more about how you are using XoWS creatively to solve your unique collaboration challenges!
For more information on xAPI-over-WebSockets (XoWS), I highly recommend you read Magnus’ blog posted here
To learn more about Codec Commander, send us an email – email@example.com
Jun 10, 2021 — Justin Ramirez