New Features not in latest version of the API (version 11)

API and Webhooks
1

The following features are minimally viable for a full working ZRC to allow integrators to fully utilize a close enough representation of the zoom room controller.  I wont be releasing anything on my end until all of these features are scoped out in a stable release on both windows and mac clients.

 

Feature #1: Sharing-only meetings: share laptop and iPhone/iPad/Mac, for a specific duration feature.

 

Feature #1 Description:  In the iPad app, there is a sharing tab.  When a user clicks it a new meeting ID is given to the iPad app so that they might start sharing and know the meeting ID.  In the ZRC API, we do not have this ability to start a share and get a meeting ID returned back to us.  It should be a new zEvent when the sharing meeting is live and we have a number to show to the user.  It should possibly have a status of 1 like when you are starting a meeting that it is loading the meeting ID.

 

Feature #2 Title:  Share content in a meeting: laptop and iPhone/iPad/Mac, sharing key, sharing URL, sharing meeting ID

 

Feature #2 Description: Currently there is a read only screen that shows on the iPad airplay screen that shows the sharing url the meeting ID and the sharing key.  I want to expose a way when asking about a meeting or a “sharing only meeting” that we have the sharing key shown in the iPad.

 

Feature #3 Title:  Claim host: we also may need to accept a claim host key.

Feature #3 Description: If you are not the host in the meeting, we need the ability to claim the host using the claim host key to submit the host key via the number a user enters.

 

Feature #4 Title:  Add video recording start/stop

Feature #4 Description: Currently the ZRC does not provide facilities to initially enter an email address when the user clicks start recording.  We need to know first off whether the meeting is automatically having recording ON/OFF, where is this information stored so that we can know whether the meeting already has an email address to send to and we don’t have to ask for one.  If the meeting is not being recorded and we don’t have an email address, we will prompt for an email address and then pass that to the ZRC for recording emails.  Later after the initial one is recording, the user has the ability to stop the recording so we need a stop recording feature to notify of a clipped video to clip.  Then the user can start recording again if we already have sent an email to the ZRC.

 

Feature #5 Title:  Windows preview build is still not available to test

Feature #5 Description: Alex still has not been able to get a non-wire shark build going so we can preview the windows build of zoom rooms SSH client.  He needs something done on the core app build so that 3rd party developers can be able to interface with the SSH client without a long drawn out wire-shark process.

  

Feature #6 Title: Pan/Zoom/Tilt is not supported for the hosts Camera

Feature #6 Description:  We don’t need presets for v1 release, but we need basic abilities to fire pan zoom and tilt requests to supported cameras.

2

Feature #7 and 8: For a participant we should allow a “Make Host” ability and “Remove”.  These are bare minimum features I feel users will accept.  The rest of the context menu on participants when in a meeting can wait for a future version.

3

Scott, getting any closer on any of these items and new features?  I would love to experiment with any alpha or beta features to see how they hold the test of “Dave testing”

4

I am having to implement PZT macros in place of the lacking of camera control myself and i will just allow the integrator control that way until your solution is in place to call the functions themselves.  I really think the best way for pan and zoom and tilt would be that we send you a startPan and endPan request and keep panning zooming or tilting until we end it.  Or possibly unit test some really fast ssh command events where things pan/zoom or tilt quickly and smoothly.

5

Dave: We are progressing very slowly on these features. I have no firm dates for when these are going to be available.

6

Yea just let me know if you get 1 done I can test on a beta and implement callers to your functions.  Thank you.

7

We also need to be able to remove a participant in a meeting

8

Yes: These additional items will be in 1.1 because they are easy to implement:

  • Remove a participant in a meeting (Expel)
  • Test microphone
  • Test Speaker
  • Lock meeting
  • Windows build connection bug fix.
9

Feature #9:  We had talked about this originally, but I forgot to append it here.  We need various support for toggling the different monitor view features shown in the middle row on the left side where you can switch positions of a few things and how you want your meeting displays to show things.

10

Feature #10 - Currently there is no way to join a meeting from the SSH client by using a password in a meeting.  Maybe when you join, a password response error should be responded with so we can show something in the UI to enter a password

11

Feature #12: Discrete mute capabilities for MUTE ON/MUTE OFF for the audio output.  I would have thought these would be in there, but maybe I missed them in the API.  It’s not ideal for us to keep track of a mute state and send zero or the previous mute levels.

12

For Feature #12: For audio output devices, there is no mute/unmute; instead, you set the volume to zero for that device.

However, it is true that the API uses “Windowing”. There is a separate volume level per audio output device, and when you switch to a new output device, the output volume switches to the volume level for that output. You’ll get a notification if the volume changes as a result of switching to a new audio output device.