Description
When using the Zoom Web Meeting SDK and joining as a host assistant, sometimes, the “Admit participant” feature (using the [zoomMtg.putOnHold function with the parameter hold: false), stops working. All other Web SDK functions such as expel , rename and even putOnHold with the hold: true parameter (putting a participant into the waiting room) all work well.
One of our users first encountered this issue on September 9, 2021.
We were able to reproduce this issue and debug it on our end. We verified that the userId sent with the request is correct, the success callback from the putOnHold function is triggered and no visible errors occur. The participant just doesn’t get admitted to the Zoom meeting. All other functions keep working well.
We found that the Websocket response on a successful bHold: false request is different from a response of when a participant doesn’t get admitted. Below are a few the screenshots showing the network with opened Websocket connection with more details.
As far as we can see when bHold: false performs successfully, a number of specific messages will come through the websocket connection. For example nUserStatus, bVideoOn, bAudioUnencrypted, etc (highlighted in the successful websocket response image below with green).
When bHold: false is not successful, those messages don’t show up in the websocket messages like nUserStatus, bVideoOn, bAudioUnencrypted, etc…
When the issue occurs, switching to a different browser doesn’t resolve the issue. For example, we ran into an issue using Brave and then switched to Safari connecting to the same meeting through the SDK and we were still not able to use the Admit feature (zoomMtg.putOnHold function with parameter hold: false), while other features were working well.
This points us to the conclusion that the issue is not related to browser session, cookies or cache state.
It seems like it might have something to do with the state of the meeting on the Zoom end.
The workaround we found to make the Admit function work again is to Admit the participant directly through the Zoom native application which will temporarily fix the Admitting issue on the Web SDK for a single participant only.
Error
There is no error response. We did however find differences between a successful and an unsuccessful responses in the Webscokets.
Which Web Meeting SDK version?
Zoom Web Meeting SDK v1.9.8
To Reproduce(If applicable)
It is very hard to reproduce this issue, sometimes it occurs frequently other times it doesn’t occur at all. We don’t yet have a way of consistently reproducing the issue.
We haven’t been able to reproduce this issue in the last 2 days. We hope that this documentation can help in the investigation and identifying the issue.
We believe this issue might have something to do with the computer environment or internet connection since it was easy to reproduce for some developers while for the other developers it took many attempts to recreate the issue.
When using a VPN connection the issue seems to occur more frequently.
Screenshots
I couldn’t upload screenshots, but screenshots can be found in this document - Issue with Admitting participant in Web Meeting SDK - Google Docs
Device (please complete the following information):
Browsers and OS versions we tested:
- Brave 1.29.79 (MacOS Big Sur)
- Safari 14.1.1 (MacOS Big Sur)
Additional context
We tried to reproduce this issue with the official zoom/sample-app-web using the latest version (v1.9.8) and encountered a different issue which we think might be correlated.
Steps to reproduce the issue:
- Join a meeting through the Web Meeting SDK as a host assistant
- Join as a participant to the same meeting
- Issue: the participant does not show up on the list of participants on the Web Meeting SDK but it does show up on a Zoom native app.
The issue (like the main issue reported) was hard to reproduce and doesn’t occur every time.
