Solving a persistent problem between two meeting clients
The Problem
A client recently came to us with an issue they were having with their suite of various models of Cisco Cloud registered Room Kit systems. Zoom and WebEx are both utilized for their meeting clients. They were able to use the one button to join feature to join WebEx meetings, but the Zoom meetings were prompting for a meeting ID and a passcode. The issue was relayed to our team who began to investigate
What is One Button to Push? (OBTP)
The client has been utilizing a feature in the Room Kit software called One Button to Push (OBTP). It allows users to integrate their calendars with the Room systems and join SIP enabled meetings with a single button. This feature parses the calendar entries looking for meeting information and populates the system with as much of the provided information as possible, limited by the data format and the codec’s interpretation. The full features of OBTP come out when the data contains a properly formatted SIP address. The system will do a few things behind the scenes, then it will send a reply stating that it accepted or declined the invite. If the invite was accepted, then the Touch10 will display the OBTP Join Meeting overlay 5 minutes prior to the start of the meeting. This can also be set to automatically join the meeting 1 minute prior to the start of the meeting, which can be very useful for unmanaged meetings or for those users that need to have a meeting started while they are away from their desk.
Note: There is a lot of backend set up to get this working and as this post is not directly related to how to set up OBTP, I will keep the explanation short and related specifically to the moving parts related to the issue.
OBTP requires a new mail and service account to be generated (O365, exchange, and google). This is the email address that is “owned” by the Room Kit and the calendar of this account is the way in which the system handles reservation management and responding to invites. The Zoom integration requires a secondary and tertiary step of creating a Cisco Room in the Zoom admin portal and installing an .msi on a server in the local network respectively. This allows the zoom invite to be sent directly to that email address to be interpreted by the system.
Resources: The full guide to installation can be found here: https://support.zoom.us/hc/en-us/articles/115003126346-Using-the-Legacy-Zoom-Connector-for-Cisco
Researching the issue between Zoom and Room Kit OBTP
The first thing our DevOps engineers did was set up a lab in our environment to mimic the issue that our client was having, which meant setting up a Zoom account and modeling our settings from those that our client is using. After being able to replicate the issue and scraping the logs we noticed an SSL error that seemed to be the root cause.
Call disconnected, error shown to be SSL rejection
After chasing that false lead for a while, we determined that there were no issues with the SSL CA that was being used for zoomcrc.com. During our testing for that we found that the voice join function works for Zoom meetings, only the button is broken. When the button is pressed, you get this failed call error in the logs. This provided for a successful joining of the meeting and some obvious differences. Most noticeable is the protocol being used is not SIP, but Spark instead.
Yellow Highlight: Where we identified the Spark Protocol over SIP
Red Arrow: Call 23 showing connecting
Resources: More information on this protocol can be found on page 56 of this PDF of protocols.
This showed that there are different modules being used between the two methods of call and one of those is unable to format that SIP call correctly. This also allowed us to write a macro to successfully dial this number. The next thing we tried was to modify the OBTP overlay so that it was able to format the call the correct way. Unfortunately, the overlay is immutable on the user end, so that idea was scrapped. We briefly toyed with the idea of removing the overlay completely for Zoom meetings and having a custom overlay appear in its stead, but the margin for error was relatively high, the issue could compound during the next software update, and it was a clunky solution. It felt like using a shotgun for a bothersome fly.
Getting in the fix for Zoom and Cisco Room Kit OBTP
We ended up writing a simple listener as the solution to this problem which elegantly stops being called when either Zoom or Cisco fix the issue. This listener looks specifically for calls that are failing for an SSL error to the zoomcrc.com URI, reconstructs the call data correctly, then sends the call. There is a brief ‘Call Failed’ pop-up, then the call connects and does not require a meeting ID or a passcode. While this solution has the small aesthetic negative of the pop-up, it was determined to be the least invasive and most effective mitigation of the issue until these two tech giants decided to play together a bit more nicely.
Have you run into any similar issues? We’d love to hear about it, so feel free to comment below and check our our Zero Trust Philosophy by our own Chris Crotteau.
By: Ben Barnard