Incorrect web socket management?

Client Web SDK
#1

Problem

A same client joining a meeting, then leaving and re-joining is seen as two distinct participants by Zoom system (probably because it’s identified based on the socket ID ?)
In such case, from Zoom meeting dashboard we can sometime observe that data continue to be streamed to the first connection, as well as the new one.

Details

Let’s take this example:

websockets_01
websockets_011689×182 48.1 KB

The “client” participant is the same for both rows. He just left the meeting and re-joined.

As you can see, he left the meeting at 11:13 AM, and re-join within the same minute. He finally left at 11:26 AM.
But it looks like Zoom still continue to monitor the first connection.
When we open that connection, we can see that Zoom continue to send the data to that connection:

websockets_02
websockets_021663×580 85.6 KB

Question

I wonder:

  • Is that a bug on the zoom dashboard ?
  • Is that an issue on Zoom backend which do not release / correctly detect that the connection has been released and really continue to send data
  • Is that a bug on the web SDK keeping the socket for audio opened on client side even after performing a leave meeting ?

I would like you to clarify that if it’s possible ?

Which version?
1.8.1

1 Like
If participant looses internet, there is no indication that it was disconnected from the meeting
Closing app does not properly leave the meeting
#2

Hey @nvivot,

Thanks for sharing this. I will speak with our Web SDK engineers and get back to you with answers to your questions. :slight_smile: (CS-2428)

Thanks,
Tommy

1 Like
#3

Hey @nvivot,

We will be fixing this in our 1.8.5 Web SDK release. I will keep you updated if anything changes. :slight_smile:

Thanks,
Tommy

#4

Hey @tommy

Thank you for the update.

1.8.5 sound likes it’s going to be fixed in months since 1.8.2 is still not there. As mentioned, i’m also interested in knowing where the problem is, not just that something is going to be fixed one day.
Depending on the root cause, this might be a critical fix (from our point of view), especially if it relates and causes this kind of other issue. (if it’s on web SDK side)

Do you have more details about the cause that you could share with us ?

#5

Hey @nvivot,

I will get back to you on the root cause shortly. :slight_smile:

Thanks,
Tommy

#6

Hey @nvivot,

Just letting you know we have pushed this fix back to our 1.9.0 release currently slated for January.

I will let you know if anything else changes.

Thanks,
Tommy

#7

@tommy ok, thank you

1 Like
#8

You are welcome! :slight_smile:

-Tommy