When using websockets a client with a bad connection comes back without sound or video

[small1]

Description:

When using jitsu with websockets. If s user gets disconnected for more than 45 second (something like that) and then gets internet back the person gets what everyone else says but doesn't transmit video or audio. The person can only use the chat and had to leave and rejoin to come back fully.

Steps to reproduce:

1. Create a meeting with a few participants.
2. After a while disconnect the computer from the Network to simulate an outage.
3. Wait for more than 45 seconds
4. Reconnect.
5. See the meeting come back but other won't see or hear you

Expected behavior:

Get audio and video back or get s window asking to reconnect (it works like that with Bosh but not with websockets)

Actual behavior:

The user can only chat until he reloads

Server information:

• Jitsi Meet version: 2.0.9111
• Operating System: Ubuntu 22.04 and 20.04

Client information:

• Browser / app version: chrome and edge
• Operating System: Linux, windows, mac

Additional information:

I will try to gather a few logs from browser console

[saghul]

You didn't get the reload screen, right?

[small1]

Nope. No reload screen. Longest I waited was 2 minutes.

[saghul]

Ping @damencho are we missing anything?

[damencho]

@small1 can you reproduce this on meet.jit.si?

[damencho]

If you do it before the 1 minute mark it will resume the previous xmpp session ... I suspect that this maybe a bug where because of checks timeout the channels on the bridge are expired for this 45 seconds... @bgrozev wdyt?

[small1]

can you reproduce this on meet.jit.si?

Ill check.

New info is that it mostly seems to affect users that has a jwt set. (it seems unlikely for me but could be something)

[small1]

Not able to reproduce on meet.jit.si on my two tests

[damencho]

Hum, then no idea. Js console logs will be helpful when you reproduce it.

[small1]

Ok. Based on what i saw on meet.jit.si There just above the 1 minute mark leave the conference for the connected users. And when i reconnect i get the rejoin countdown. On the instance i setup i dont get that until 5 minutes or so. Ill do one more test

[small1]

On the 2 minute mark och slightly above i got it two times. But it should happen below 1 minute

[damencho]

Attach some js console logs when you reproduce it, please.

[saghul]

@damencho Any chance this is related to this? https://github.com/jitsi/docker-jitsi-meet/issues/1545

[damencho]

Maybe ... let me check how do we enable websocket there.

[damencho]

we do not enable websocket under guest domain and no smacks there ...

[bgrozev]

I suspect that this maybe a bug where because of checks timeout the channels on the bridge are expired for this 45 seconds... @bgrozev wdyt?

I don't understand the report. If the user is able to hear/see others that's inconsistent with a timeout on the jvb side.

If the user is not able to see/hear others it could be a jvb timeout. In this case the client should detect and fire an ICE failed event and either signal that to jicofo or reload depending on configuration.

[damencho]

But what will happen if during the ICE failed there is no network, we cannot send to jicofo, but after the 45 seconds we do resume the connection and everything continues ... but no media as ice failed ... is this scenario possible?

[small1]

That sound like a sensible thing. We do get the window about degraded video. I'll clean up the hostnames from a few logs

[small1]

Are there any timeouts that can be tweaked in the configs?

[saghul]

Not at this time I don't think so.

[saghul]

@andrei-gavrilescu You were looking at something similar not too long ago g ago, right? Can you shed any light?

[andrei-gavrilescu]

I was, but didn't encounter the above scenario, nor am I able to reproduce it. It's always as you guys described it above, either successful reconnect or the reload screen after aprox the 1 min mark.

[bgrozev]

But what will happen if during the ICE failed there is no network, we cannot send to jicofo, but after the 45 seconds we do resume the connection and everything continues ... but no media as ice failed ... is this scenario possible?

Wouldn't strophe buffer stanzas until they are able to be send, and send the ICE failed notification afterwards? I'm not sure what happens if the ICE failed notification never reaches jicofo. If it tries to reference the endpoint in a colibri message it would get and error and probably automatically re-invite the endpoint.

The bridge timeout for an endpoint is 1 minutes (configurable as videobridge.entity-expiration.timeout in jvb.conf).

[damencho]

Wouldn't strophe buffer stanzas until they are able to be send, and send the ICE failed notification afterwards? I'm not sure what happens if the ICE failed notification never reaches jicofo. If it tries to reference the endpoint in a colibri message it would get and error and probably automatically re-invite the endpoint.

I'm not sure either ... I think it errors out and drops the message ... so it seems like a possible scenario if that is the case.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.