Waiting room: admit (putonhold) sometimes fails

[harald.glanzer]

hi again,

i often observe the problem that admitting does not work:

1. using SDK 1.8.6, i open a meeting as host via the websdk with waiting room enabled

2. a user joins with a native client(linux/windows/sdk)

3. i admit the user via ZoomMtg.putOnHold({hold: false, userId: 1234, success_callback: …})

4. the corresponding success callback for ZoomMtg.putOnHold() is called

5. i can observe that the status of the client changes, as the it tries to reconnect.

6. the admitted user disappears from the waiting room list

nevertheless, sometimes/often reconnecting does not work, i can wait for minutes and watch the joining client trying to reconnect, but it does not succeed.

i also observed this behaviour by using your built-in ‘admit’ js button(the top blue bar that appears when a user comes into the waiting room).

is anybody aware of such a problem?

thx
hari

[MaxM]

Hey @harald.glanzer,

Thank you for reaching out to the Zoom Developer Forum. I wasn’t able to reproduce this issue on my end. I just have a couple of questions to get started:

1. Does this happen with one user, device, or network?

2. Do you see any errors in the browser console?

3. Are you able to provide a meeting ID where this happened?

4. Do you have the same issues when using the Sample Web App?

Thanks,
Max

[harald.glanzer]

hi,

1. this happened with different devices and users
2. there is no error logged, as written the success callback is executed
3. i sent the room id to developersupport@zoom.us
4. i did not try the sample web app so far.

thx
hari

[MaxM]

Hey @harald.glanzer,

Thank you for submitting a ticket. I’ll follow-up with you there.

Thanks,
Max

[alexander.brotzge]

Hi Max, I can confirm the behaviour with the putOnHold call @harald.glanzer described above,. I always need to wait for about ~ 5 seconds between each call to get it work, otherwise I get an error:

zoom-meeting-1.9.0.min.js:2 putOnHold 3633 undefined

without any error callback!

Thanks, Alex

[alexmayo]

Does this still happen with v1.9.0? This updated addressed bugs with the waiting room.

[alexander.brotzge]

@alexmayo: yes I can reproduce this with both sdk versions (1.8.6 and 1.9.0).

[MaxM]

Hey @alexander.brotzge,

Thank you for reaching out to the Zoom Developer Forum. I see that if I make calls to putonhold() too frequently on v1.9.0, I get the following error message:

zoomus-websdk.umd.min.js:2 putOnHold 3633 You have reached the API limit for this call.

This is when using the Sample Web App. Are you able to share a public git repo of the code you’re using? I’ll investigate this code you’re using further.

Thanks,
Max

[alexander.brotzge]

Hi Max,

the only thing we do is trying to admit multiple users in a short amount of time (within ~ one second).
We can get it work if we wait with the next putOnHold call for about five seconds.

This is our call we’re using the local websdk based on the sample-web-app.

ZoomMtg.putOnHold({
	userId: parseInt(user.id, 10),
	hold: false,
	success: function (res) {
		console.log("admit success: " + JSON.stringify(res));
	},
	error: function (res) {
		console.log("admit error: " + JSON.stringify(res));
	}
});

When we get the error 3633 there’s no error callback from the putOnHold call.

Is there anything we can further do, because waiting five seconds each is not a good solution?

Thanks,
Alex

[tommy]

Hey @alexander.brotzge ,

Are you saying that you can only call the putOnHold function every 5 seconds?

You should be able to call it more frequently than that, and less frequently than multiple times under a second without issue.

Thanks,
Tommy

[alexander.brotzge]

Hi Tommy,

I quickly tested it with a dirty hack and the current sample web app with the same results I expected before (first participant admit works as expected beginning with the second one I get the error 3633)
What am I doing wrong?:

ZoomMtg.inMeetingServiceListener('onUserIsInWaitingRoom', function (data) {
    console.log('inMeetingServiceListener onUserIsInWaitingRoom', data);
	
    if (data.isHold) {
	    waitingRoomParticipants.push(data);
	}
});

ZoomMtg.inMeetingServiceListener('onMeetingStatus', function (data) {
    console.log('inMeetingServiceListener onMeetingStatus', data);

    if (data.meetingStatus = 2) {
	    document.getElementById("admit_all").addEventListener("click", (e) => {
		    console.log('admit all');
		
		waitingRoomParticipants.forEach(function(item) {
			ZoomMtg.putOnHold({
					userId: parseInt(item.userId, 10),
					hold: false,
					success: function (res) {
						console.log("admit success: " + JSON.stringify(res));								
					},
					error: function (res) {
						console.log("admit error: " + JSON.stringify(res));
					}
			    });
		    });
	   });
	}
});

Thanks Alex

[MaxM]

Hey @alexander.brotzge,

Thank you for providing additional information. In the example provided, you’re encountering error 3633 because you are calling the function within a loop with no logic to throttle the requests. In this fashion, it’s possible that requests are being sent out within milliseconds of each other which would cause the rate limit error that we’re seeing.

I hope that helps! Let me know if you have any questions.

Thanks,
Max

[nvivot]

@alexander.brotzge

I’m curious about how you manage the user.id information between connection / disconnection of your users ?
You problem seems to be related to what i already reported here :

Blocking inconsistencies between inMeetingServiceListener() data and getCurrentUser() data

Description I wanted to subscribe to the events when a user is put on hold and then put back into a meeting to see if i can customize my application behavior. I faced several issues and tried to find workaround but in the end the way the SDK is designed now make it impossible to react correctly on an event. I won’t enter into the details, so long story short, if you want to apply a behavior on a specific user when he receive an event, and because the zoom web SDK broadcast a single event to al…

I did not check the details, but it looks like you keep track of userId on a list (waitingRoomParticipants) and invoke the function to put them back & so on. But because of the user id renewal stuf, it would work the first time only since your users are going to reconnect when putting back on the meeting from the waiting room and thus change their user id information. It might be the cause of the error code you get, because it’s kinda weird to receive such a message about rate limit when you are clearly not requesting much the API… if that’s the real cause, then Zoom should also fix that incorrect error code handling. (If not please just ignore)

If that’s not the real issue, it might also comes from the fact that you permanently add new user data to your list since the id of a user is renewed when reconnecting to your meeting from the waiting room.
Since you’re doing a loop from that list that potentially grow indefinitely (you do not seem to purge it), you may reach the API rate limit during one of your loop processing.

@MaxM So it looks like this whole user identity thing i reported a while ago is still not fixed. Could you please re-open my thread (see above) with a status update ? You’ve published a feature that is “half coded” and un-usable, that’s a pity. I think we all want to use it so, when is it going to work ?

[alexander.brotzge]

Hi Max,

can you provide me a short sample of how you achieve admitting all participants with less than 5 sec’ waiting in between each putOnHold command (with the sample web app)?

Because the only way I can do this is waiting 5 seconds between each putOnHold call

Thanks, Alex

[alexander.brotzge]

@nvivot we do not send the users back to the waiting room and let them join again. In our usecase the users only join the waiting room and the host decide which users he want to join the meeting → so no userid renewal

[MaxM]

Hey @alexander.brotzge,

Thank you for your question. I tested this extensively today and I saw that the interval between rate limit errors depended on the device/network that I was testing on. In most cases, I saw that it took ~4-6 seconds on my end as well.

That makes sense with an async function like this so I then tried adding the next call to putOnHold() within its own success callback but that didn’t seem to change the behavior.

Given such, I’ve since reached out to our engineering team to see if they are able to provide any insight into the API rate limit of this function. I’ll be sure to keep you posted here.

While I was testing, I used the following code in order to throttle the function calls. Here I used the lodash throttle() and the getAttendeesList() just to make testing easier.

As you’ve shown, this can be accomplished in a variety of ways including using the inMeetingServiceListener() function and built-in setTimeout() function:

ZoomMtg.getAttendeeslist({
    success(r) {
        const attendees = r.result.attendeesList;

        const putOnHold = _.throttle((a) => {
            ZoomMtg.putOnHold({
                userId: a.userId,
                hold: false,
                success(s) {
                    console.log('putonhold() success', s);
                },
                error(err) {
                    console.log('putonhold() error', err);
                }
            });
        }, 6000);

        attendees.forEach((a) => {
            if (!a.isHost && a.isHold) putOnHold(a);
        });
    }
});

I’ll update when I have more information. (CS-3015)

Thanks,
Max