Posts by Category

Workplaces are becoming more and more lenient on where their employees can work,
Get the most out of work-life balance

Balancing work and life

Workplaces are becoming more and more lenient on where their employees can work, due to enhancements in technology, making people accessible wherever they are. As of August 2019, a Global Workplace Analytics survey showed that 40% more U.S employers offered flexible workplace options than they did five years ago.

Video conferencing has been a huge enabler of this shift. Employees no longer need to be in a conference room or office setting to take meetings. Meetings can be taken from a home office, a car, even the sidelines of a soccer match.

A ValueWalk article on work/life balance mentions, “we operate in a world where “balance” can be achieved through advancements in technology.  Conference calls have become video calls and most video calling platforms are now integrating other tools that increase the opportunity for collaboration. Most importantly, all of these solutions are available on mobile platforms.”

The ability to work anywhere, anytime, without sacrificing human connection brings more opportunities and flexibility than ever before.

Check out this article to dive deeper on the role mobile platforms play, how team collaboration tools enhance how people collaborate, and how artificial intelligence and virtual assistants are helping people save time on otherwise timely activities.. like taking meeting notes.

Try Webex Meetings for free

And hear what a few Cisco employees thoughts on why they value work/life balance:

Learn More

Personalize your team meetings with these top four screen sharing features 
Cisco Webex Meetings 39.9: Discovering some video conferencing hacks
How web conferencing can be utilized for real-time online collaboration
Webex Devices: Transforming Workspaces So You Can Get Stuff Done

Read more
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
oculus-rift
What’s next in Collaboration?

We’re faced with a world where it’s becoming increasingly harder to keep up with advances in technology and where our brains hardly have the capacity to grasp what the world might look like even 10 or 20 years down the line. At Cisco’s Collaboration Group we naturally spend a lot of our time on what lies ahead – tackling both the giant technology leaps we need to make in the future as well as the incremental improvements we can make to dramatically impact people’s everyday work lives and productivity. In this post I will give a brief look into what we think are some of the challenges that lie ahead in the collaboration industry, along with a peek at some technologies that may help shape the future of teams and their work together.

Read more