Zoom Room release 4.1.5

Today, Zoom posted a new version of the Zoom Room (Mac + Windows).

The new Zoom Room version is:

Mac Zoom Room: 4.1.5 (4.1.33237.0924)
Windows Zoom Room: 4.1.5 (4.1.33237.0925)

There are also new versions of the Zoom Room Controller: version 4.3.3. It looks like Google Play has the new ZRC version available; I assume the iOS version and Windows surface version will be available momentarily on those app stores.

The release notes are up:

https://support.zoom.us/hc/en-us/articles/115002847183-New-Updates-for-Zoom-Rooms-for-Mac

There are no new commands in the ZR-CSAPI that ships with the new Zoom Rooms version. New commands will come out in a beta release in a week or two. But there are two changes to the ZR-CSAPI:

Change #1: We still have a problem with Google Calendar not pushing changes to the Zoom Web site, and then onto Zoom Rooms, in a timely manner. It may take up to 15 minutes for new scheduled meetings, or changes to existing meetings, to get pushed from Google to Zoom Rooms. This problem happens with any configuration of Zoom Rooms: It is a problem independent of the ZR-CSAPI. The bugs for this calendar issue are:

ZOOM-33755
ZOOM-53011

As a work-around, the ZR-CSAPI provides the command:

zCommand Bookings Update

To force the Zoom Room to fetch the latest calendar entries from Google Calendar. A common paradigm is for ZR-CSAPI developers to issue this command every 10 seconds per Zoom Room, to maintain the most up-to-date Calendar information, which works great. Except that it imposes large costs on Zoom. That’s because Google has Usage Limits on the Google Calendar API:

https://developers.google.com/calendar/pricing

The Google Calendar API has a courtesy limit of 1,000,000 queries per day per API link (not per customer account), and Zoom must pay increasing cost to go beyond that limit. For a company with 100 Zoom Rooms running 24 hours/day, that amounts to a total of 864,000 queries per day. We are budgeting for much less than that.

So we have 3 phases of work-around for this problem:

  1. The new version of the ZR-CSAPI that is rolling out with today’s Zoom Room release will limit the zCommand Bookings Update command to once per 180 seconds; If you issue another zCommand Bookings Update within 180 seconds of the last one, then the ZR-CSAPI will accept the command, and appear to handle it normally (for backward compatibility), but it will not forward the command to the Zoom Room. If you still want to issue a periodic bookings update request as often as possible, then issue it once every 135 seconds or so. If you issue the command within 180 seconds of the last command, there is an error message that gets logged to the log file at (on the Mac) ~/Library/Logs/zoom.us/zaapi/zaapi_x.log.

  2. The next beta release will be smarter, and allow up to 1000 additional zCommand Bookings Update commands per day that come in within 180 seconds of the last command. That will handle the case where end users want to keep pressing a meeting refresh button on a UI.

  3. At the same time, I’m going to push our Web folks to solve the root problem, so that we can get Google Calendar change notifications in real time.

Change #2: A recent new update as of September 16 to the Zoom Web Portal allows customers to turn on encryption for the network connection protocol that connects Zoom Rooms to Zoom Room Controllers. Today’s version of the Zoom Room now supports this functionality. On the Zoom web site, the setting is under:

Account Settings Link on the left -> Meeting tab at the top -> Zoom Rooms Section -> Secure connection channel

This setting is account-wide: you can’t control it per Zoom Room. It’s important to turn this encryption off if the ZR-CSAPI is used with a Zoom account.

The ZR-CSAPI uses this network connection protocol, even though it runs on the same machine as the Zoom Room. However, the ZR-CSAPI does not support encryption. As a result, there are two problematic scenarios: If you see any of these scenarios, it means someone turned on encryption on the Web portal, and they need to turn it off:

Scenario 1: Encryption is turned on in the web settings, then the Zoom Room is launched: The ZR-CSAPI will launch along with the Zoom Room, but will be unable to connect to the Zoom Room process. In this scenario, when the user logs into the ZR-CSAPI, the user will get the login banner message:

*e Connection rejected
** end

If the user attempts to enter a command, the same error message gets printed. The ZR-CSAPI is non-functional in this mode. To get out of this mode, turning off encryption on the Web server is not sufficient, because the ZR-CSAPI process will not attempt to periodically reconnect to the Zoom Room. The customer must turn off encryption on the web portal, and then restart the Zoom Room, which also causes the ZR-CSAPI to re-launch.

Scenario 2: Encryption is off in the web settings, then the Zoom Room is launched; the ZR-CSAPI successfully connects to the Zoom Room; But if encryption is then turned on at the web portal, the ZR-CSAPI will not detect this change, and will run in local-cache-only mode, with no error messages; the ZR-CSAPI will not print an error message to the console. Commands that fetch state information from the ZR-CSAPI’s data cache, like phonebook listings, will work. But commands that cause action to happen on the Zoom Room will have no effect. Also, notifications from the Zoom Room, like phonebook updates, will not happen. This failure can be detected by the absence of the usual CLI/JSON reply to ZR-CSAPI commands that either set parameter values on the Zoom Room (zConfiguration), or cause the Zoom Room to perform an action (zCommand). Then, if encryption is turned off at the web portal, normal ZR-CSAPI operation resumes.

We have a bug number for supporting encryption on the ZR-CSAPI:

ZOOM-55428: ZAAPI: Support Encrypted Communication Channel

It’s unclear if I can get this fix included in the beta release scheduled for the next week or two, but it is committed for the next GA release of the Zoom Room.