PutInWaitingRoom / ExpelUser do not work properly from the host perspective

Description
App use CustomizedUI / C# wrapper and works as a host
The issue I am facing is shown in the following:

All initialization succeeds. When a new user connects, I get an event
OnWatingRoomUserJoin (uint userId)
After that, I can successfully execute
AdmitToMeeting (uint userId)
Then I receive an event
OnWatingRoomUserLeft (uint userId)
And further
OnUserJoin (List lstUserID)

  1. After that, if the program trying to execute
    PutInWaitingRoom (uint userId)
    On the user’s side, everything is fine (user app returns to the waiting room state). However, on the host side, I am not receiving any events such
    OnWatingRoomUserJoin (uint userId) and/or OnUserLeft (List lstUserID) but VideoElement video stream stopped.

  2. Or If the program trying to execute ExpelUser (uint userId) on the host side, I receive an event
    OnWatingRoomUserLeft (uint userId)
    which is very strange.

Which Windows Client SDK version?
Windows Zoom SDK v.5.5.1 (12509.0330); 5.4.54802.0124; 5.4.54524.1229

Device (please complete the following information):

  • Device: desktop pc
  • OS: Windows 10 Enterprise 1809

Logs: Zoom SDK Logs

Hey @aliaksei.luferau,

Thanks for using the dev forum!

Is this only in regards to the user that was put in the waiting room? Or do these callbacks stop entirely for all users on the host’s side?

Thanks!
Michael

Michael, thanks for your attention.

Host still receives events from other users.
I will describe what I observe as a sequence of events and methods:

Scenery (1)

userA trying to join
EVENT OnWatingRoomUserJoin (userAId_1)
RUN_METHOD AdmitToMeeting (userAId_1)
EVENT OnWatingRoomUserLeft (userAId_1)
EVENT OnUserJoin (userAId_2)
RUN_METHOD PutInWaitingRoom (userAId_2)
no any userA related events; userA VideoElement video stream stopped

userB trying to join
EVENT OnWatingRoomUserJoin (userBId_1)
RUN_METHOD AdmitToMeeting (userBId_1)
EVENT OnWatingRoomUserLeft (userBId_1)
EVENT OnUserJoin (userBId_2)

Scenery (2)

userA trying to join
EVENT OnWatingRoomUserJoin (userAId_1)
RUN_METHOD AdmitToMeeting (userAId_1)
EVENT OnWatingRoomUserLeft (userAId_1)
EVENT OnUserJoin (userAId_2)

userB trying to join
EVENT OnWatingRoomUserJoin (userBId_1)

RUN_METHOD List GetWaitingRoomLst() received for some reason List { userAId_2, userBId_1}

RUN_METHOD AdmitToMeeting (userBId_1)
EVENT OnWatingRoomUserLeft (userBId_1)
EVENT OnUserJoin (userBId_2)

Scenery (3)

userA trying to join
EVENT OnWatingRoomUserJoin (userAId_1)
RUN_METHOD AdmitToMeeting (userAId_1)
EVENT OnWatingRoomUserLeft (userAId_1)
EVENT OnUserJoin (userAId_2)
RUN_METHOD ExpelUser (userAId_2)
EVENT OnWatingRoomUserLeft (userAId_2)
userA VideoElement video stream stopped

Scenery (4)

userA trying to join
EVENT OnWatingRoomUserJoin (userAId_1)
RUN_METHOD AdmitToMeeting (userAId_1)
EVENT OnWatingRoomUserLeft (userAId_1)
EVENT OnUserJoin (userAId_2)
userA leaves from meeting by yourself
EVENT OnWatingRoomUserLeft (userAId_2)
userA VideoElement video stream stopped

Hey @aliaksei.luferau,

Can you run the C++ Demo application and let me know if you are seeing the same behavior there?

Thanks!
Michael

Michael,
This issue probably is not really SDK related. I am 100% sure that your C++ Demo application example works. Before I have also developed an application that uses the same version of the SDK and everything works well. however, in my new project, I ran into the described problem. I do not know what information is stored in the log file, can you see if the SDK is in some wrong state?
Thank you

Hey @aliaksei.luferau,

I will submit the log file to the engineers to see if they can find the issue there, however they do not provide much support for C# projects. Will keep you posted.

Thanks!
Michael

I am experiencing the exactly the same problem. I am not using multiple threads, but I do useTasks in my code. Having said that, all of them are executed under the same Thread: according to debug, all the requests are executed under Thread #1 (the same thread where Zoom SDK was initialized.

At first I suspected that the issue had to do with using different threads, but according to logs, I am using the same thread. Then I suspected that it may be something to do with racing; however, again, looking at the log output, all the requests and events seem to be in order.

The only difference I see between the new version and old version is the usage of Tasks… Can someone confirm whether or not Tasks break Zoom SDK?

Hi @Alex.Peters01, thanks for using our SDK.

Can you please confirm the following information?

  • Whether you are using the C# wrapper or C++ SDK
  • What version of the SDK you are using

Thanks!

I am using C# wrapper and version 5.5.1 (12509.0330) . What I find very puzzling is that AdmitToRoom works perfectly and I get all the events. The moment I send the participant into the waiting room, the video elements are removed from the host’s screen, all the signalling on the participant’s side works as expected and participant is moved into the waiting room, yet I do not get any events regarding the participant leaving on the host’s side.

I tried different things to try to debug it, including:

  • programmatically pushing the participant into the waiting room 10 seconds after joining
  • adding Thread.Sleep(5000) after putInWaitingRoom
  • adding a second participant after moving the first one into the waiting room (the second user was able to join and be moved into the waiting room, but there would be no events on the host side indicating that the participant left.

I logged ThreadID and it is all the same… So, we know that we are all operating within the same thread as where SDK was initialized…

If I did not know better, I would think that Zoom just forgets to do the callback… I do not think it is related but I recall a post from a long time ago where there would be a racing condition if an object is destroyed prior to receiving some sort of event from SDK…

Hi @Alex.Peters01,

Thanks for the additional information. Can you please provide the SDK logs?

Thanks!

Logs from starting post

Hi @aliaksei.luferau,

Thank you, but @Michael_Condon has already added the logs from your post to the internal ticket created for this issue. Usually getting logs from multiple users’ instances of an issue makes it a bit easier to isolate the cause of an issue. :slightly_smiling_face:

Thanks!

Hello everyone,

In continuation of this topic, after executing the AdmitToMeeting method, the list that we get from the IMeetingWaitingRoomControllerDotNetWrap.GetWaitingRoomLst method does not change (it continues to display the user who was added to the meeting only with a different id). Is this how it should be?

SDK: 5.5.1 (12511.0422)

Hey @SmartSoftware,

I do not believe this is intended behavior and may be an issue with the wrapper. Can you see if the same issue occurs in the C++ SDK?

Thanks!
Michael

Hey @aliaksei.luferau,

The logs did not indicate a clear issue here. This is likely a wrapper issue. Can you verify the SDK callbacks and interfaces are being called on the main thread?

Thanks!
Michael

Ended up we discovering one interesting thing.

Usual user connecting process goes like this:

  • user got into the waiting room with USERID_WAITINGROOM
  • host calls AdmitToMeeting(USERID_WAITINGROOM)
  • user leave waiting room with USERID_WAITINGROOM
  • user got into the meeting with USERID_MEETING

If on this stage host try to call method

UserInfo  IMeetingWaitingRoomController.GetWaitingRoomUserInfoByID(USERID_MEETING)

Host will receive UserInfo object that is not NULL and contains actual user data. However, after this call, the Zoom SDK (or wrapper?) breaks down as described at the beginning of the discussion.

Of course in this place there must be a call method (and the replacement solved the described issue)

UserInfo  IMeetingParticipantsController.GetUserByUserID(USERID_MEETING)

But probably such a call method

GetWaitingRoomUserInfoByID(USERID_THAT_NOT_IN_WAITING_ROOM)

should return NULL.

Hey @aliaksei.luferau,

Thank you for providing this :slight_smile:

Michael

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.