CE WebSocket v SSH v HttpFeedback. Which is Best?

I thought this would be an interesting comparison to write code for all three different connection types in their most simplistic form and do a comparison. Cisco collaboration endpoints now have three main methods to get data from an endpoint over the network ( I am not talking about a serial connection) for the purposes of interacting with the endpoints API. They are WebSocket, SSH and HttpFeedback. The example I am using in my comparisons is based on a very simple idea of I want audio status changes to be pushed to my server from the collaboration endpoint. In my examples I am using a Webex Room Kit to send commands to. If you don't know what that is stop reading now this post is not for you.

I am a part time Nodejs developer (I think so, so to hell with everyone else) so all the examples I am going to post will be in JavaScript. I am not the most elegant of developers though. I basically create stuff that works for the purposes of prototypes so don't expect JS ninja magic. My examples are good enough though for most to get the idea of what the hell is going on.

Lets get on with it....


This example comes to us from Magnus's Cisco Community Post.

Magnus created a nice clean Node example, so I am going to rip it right off of him.

A couple of things of note. This example uses two main libraries, JSxAPI and ws (WebSocket) libraries both of which are on NPM. Its a simple setup and responses from the endpoint are very quick. What I love about WebSockets is that you can use it over port 80 or 443 and using the WS library makes coding your WebSockets install very easy and clean.

There are however some considerations to make. If you are scaling out you application, just like SSH which I will get into in a minute, you now have to start thinking about how do I manage persistent connections potentially across multiple servers. Running everything on a single server should be pretty easy but on multiple servers connecting to a database can be much more difficult depending on what your trying to achieve. In saying that most use cases for using the API on a collaboration endpoint usually only requires to scale to just a few hundred endpoints or less which a single Nodejs server will easily handle.

An important point which also applies to SSH is how much chatter will there be from your endpoints. If you a monitoring a lot of events and status which causes a constant stream of communication your scale will ultimately be diminished. A single server can comfortable handle thousands of WebSocket connections if they are relativity idle most of the time but if your chatter from every endpoint is high then this brings down the amount of concurrent connections and something to monitor as you scale.


Talk about simple brah! SSH is even simpler from a coding standpoint as the JSxAPI library has the SSH2 library as a dependency you can just launch and control the session using the JSxAPI library.

While having an SSH library as a dependency is helpful at time this can be a little bit of a hindrance as well. If things go wrong you have to pull the covers back a little to explore how the two libraries work together and generally I have found scaling this out to anything beyond a 100 endpoints is more bother than it's worth. Connection failures, dropped connections etc etc just become a pain to deal with once you start connecting to an 1000 endpoints using SSH. Managing the connection state does have some benefits though.

If you know your connected SSH state then you don't have to poll your endpoints to check their state for at least the network connectivity. Event messages and responses are generally fast and there is little code required to create the connection. I have used this method many times when I have a single endpoint I need some form of app or controller to connect to it. My CE-Deploy app is a great example where I have used this method. I only need to connect to one endpoint at a time and the connection gets closed once the work is done to move onto configuring the next endpoint. Its simple and effective.


This is the most complex of the three to code but can be the most flexible and scalable. I say this because there is no persistent connection to maintain or monitor. It follows the typical HTTP pattern of request, response and done from a TCP connection standpoint.

If you can excuse some sloppy code (yeah yeah its not perfect) you will see that I used Express to help create a simple web server. I got a little help from a TP client library I use sometimes to help post my XML although this could have been simply done using the request module as well just a little more code. There are lots of options using HttpFeedback as the underlying code listening to the feedback messages is just a web server. The most difficult piece is configuring the client/endpoint to send the events and status updates to the server to start with. You have to let you endpoint know your server URI so it knows where to send its events and this is done using a XML message you can see in the code.

Another complex piece not shown is responding to an event like a user pushing to a button on the touch 10.  Just like registering feedback you now have to create your XML response to tell the codec what to do next. Plus since you are not maintaining a persistent connection how do you know if you should send your endpoint any commands you may need it to carry out. Say at midnight you want all endpoints to reset a setting to your default. this can be done by sending them a XML message to the XML API. With a persistent connection you might be able to work this out pretty simply but now you don't have that. Do you poll the endpoint regularly to check or just hope that it eventually comes back online and everything rights itself? What if you bring you app online and an endpoint is offline, how do you let your endpoint know when it comes online where to send its data. Some of this can be solved using TMS or a management platform but what if this is your own homegrown TMS? This method can be lots of work.

To Sum Up...

There are loads of great API's to work with once you connected to your endpoint and depending on your requirements one connection method might work better than another. For myself, I think for smaller to mid sized projects WebSockets is where I will spend most of my time and for larger projects, well, I will just try to avoid those for now at least :)

Hope you enjoyed the post.


CE-Deploy for Cisco Collaboration Endpoints

This is a on-going project I have been working on for a while. Originally I created CE-Deploy to just deploy macros to multiple Cisco collaboration endpoints but once I published the first builds I got a number of requests to add more features. 

CE-Deploy has the following deployment options:

  • Wallpapers
  • Macro Files
  • Touch 10 UI controls
  • Download logs for troubleshooting
  • Digital Signage
  • Branding
  • Webex Board Touch 10 enablement
  • Admin password update

It doesn't aim to replace TMS, Control Hub or CUCM management but targets certain things that are difficult to do on these platforms or are not available.

Check out the video demo here:

If you would like to contribute or  create a build for your OS the code is available on Github below:


To find out more about CE-Deploy there is a Webex Teams space available for feedback and request access to builds:


This link requires you to sign up for Webex Teams to have access to the space, you have been notified!


VoIPNorm where have you been, again?

It has been a while since I last posted on my blog. I like this forum I was not sure that many people still pay attention to blogs. Seems like twitter, vlogs and you name your social media have taken its place but then I realized how often I still read other people’s blogs. While the material in my blog is a little different than it used to be hopefully it’s still of value to people that follow.

The number of people doing xAPI development for Cisco collaboration endpoints has certainly grown over the last 12 months so hopefully I can help provide some ideas and with all the new features coming in CE9.x there is no shortage of material.

If you have any questions or ideas for topics, please comment below.


Running Macro's for Cisco SX10 endpoints (or any Cisco video endpoint for that matter)

SX10 devices are unable to run the macro framework directly on the device. These devices are left out in the macro cold unable to do what other more powerful endpoints can. I can feel the chill now. But...

Thanks to a Nodejs library jsxapi we can bring these codec in from the cold and give them some powerful tools to handle in-room controls from the Touch 10 interface. My example focuses on in-room controls but this logic can be applied across monitoring any of the events that a Cisco video endpoint could generate.

There are some great macro examples on the DevNet Github repo. I am going to use one as an example to show how to convert it into a nodejs server application. The example I am using today is the audio only dial button. The example interface is shown below.


Typically when you select said button you get this interface:


 I am going to change this up slightly and instead of providing a straight dialing interface for an audio call, I am going to provide the ability to enter a meeting number to join a Webex. See below:

Once the meeting number is entered and the Join button is pressed the appropriate @mysite.webex.com is appended to the call and the calling interface launches. So a slight change but easy dialing into a meeting is always a good thing. If you want to stick to the original like the example it should be a matter of a few small changes.

To turn this into a Nodejs application we need two files. First is the typical Node application launch file index.js. This file is pretty simple and launches the application  by creating an array of endpoint objects using the TPXapi module which is our second file. My list of endpoints is a simple array but feel free to use a database or json file in its place to store your list of host URL's or IP addresses.
The TPXapi module below forms the core of our application and controls the SSH connection, provides error correction and most importantly monitors events coming from our video endpoint.  New functionality can be adding by extending the prototype with new functions. Error correction provides a way to reconnect to the endpoint should the SSH session fail. Any other type of error will close the connection and reopen it. This may or may not be preferred.
This is a very simple example of using in-room controls and converting a macro to a server side application. The possibilities of more complex functionality are endless.