Categories: Collaboration Devices

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.

The problem

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?

Project scoping

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:

  1. Renders the web based user interface on any web browser that supports Web sockets, HTML5, Javascript with async/await and CSS
  2. Web socket server to orchestrate communications to/from and between multiple user sessions
  3. Redis Publisher to update data and send commands to video devices
  4. Redis Subscriber to receive notifications from video devices and other systems

(B) Message Broker – this is a Redis server that provides the following:

  1. Data store containing information about every video device (e.g. Serial #, Name, SIP URI, Display Name, Status etc)
  2. 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:

  1. Web socket client that connects to the codec and queries configuration data
  2. Subscribes to assigned codec’s xEvents and xStatus JSONRPC messages to monitor various states
  3. Sends xCommand and xConfig JSONRPC payloads to it’s assigned codec
  4. Redis Publisher to update codec data and send events/notifications from video devices
  5. Redis Subscriber to receive commands destined to the assigned codec
  6. 3 second preview snapshots using fetch()

The deliverable

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 – collab4devs-tme@cisco.com

Learn More

Apply branding to your conference devices

4 ways IT leaders can lead the change to create the next-generation workplace

Cisco Leap Frogs H.264 Video Collaboration with Real-Time AV1 Codec

 

Share
Published by
Amanda Holts

Recent Posts

  • Team Collaboration

Creating digital teams in Webex Teams series : Chapter 1: When you are with or without your office

The “Creating Digital Teams in Webex Teams” series we will spotlight techniques in managing and inspiring remote and #WFH teams.  Learn how the Webex Platform and Webex Teams can…

1 hour ago
  • Team Collaboration

March update of Webex Teams

If you're new to remote work, we're here to make the change easy—keeping you connected…

2 days ago
  • Team Collaboration
  • Tips

6 tips for working from home with kids

Here’s some tips and tricks to keep your little ones entertained and you productive while working…

4 days ago
  • Tips
  • Video Conferencing

Keeping our distance doesn’t mean we can’t stay close

On the design team at Cisco, we are all hands on deck to support our…

7 days ago
  • Collaboration Devices

RoomOS Monthly Update: March 2020

 In March, we are focusing on making the way you collaborate with your personal mode…

1 week ago
  • Video Conferencing

Higher education, meet Webex

Whatever your role in your higher ed community, there’s a way you can use Webex…

1 week ago