Posts by Category

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.
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):

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!

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:

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

 

Read more
One decade is coming to a close and 2020 brings in a new year and new opportunities
The future of work isn’t coming, it’s here

One decade is coming to a close and 2020 brings in a new year and new opportunities. In this busy season of holiday parties, copious amounts of shopping, and wrapping up end-of-year projects, people are also beginning to think about new resolutions and new ways to reset and reorient themselves for what this next year has in store.

At Cisco Webex, we’re doing this as well. The phrase, “Future of Work,” has been buzzing for a bit of time, but it’s time to move this from hype to reality and we’re ready. In fact, we’re already there. As we think about this coming year, and as we set goals for what we want to do as a company, now is the time to turn the “Future of Work” into today and seize the opportunities it presents to us.

In an article in Boss Magazine, Cory Treffiletti, Global Head of Marketing for Webex.com at Cisco refreshingly cuts through the sea of buzzwords related to this topic and highlights a few truly impactful trends that are driving this change in the workplace.

He calls out,

“While technology of the recent past has made businesses more productive and efficient, it tended to hamper the true human connection. Think email and even conference calls. The face-to-face interaction was missing. People are starting to realize that a call is far better than email, and a video call, even better. Picking up and reaching out to someone may never be as efficient as typing a message and hitting send, but it is more efficient when you factor in the resulting back and forth that results.”

Let’s consider this: The “Future of Work” is not five years from now, it’s tomorrow, and the next day, and the day after that. We all have a hand to play in how our businesses will run and what we want them to look like.

Check out Boss Magazine’s article on four trends to keep an eye on in the not so distant “Future of Work.”

Learn More

Cisco at SXSW 2019: Cognitive collaboration and the future of work

The Future of Work is Today

Cisco’s Single Platform and Unified App Make a More Human Approach to Transforming your Workplace

 

Read more