The same user can't join a room multiple times

[fancycode]

While looking into the fix for #1586 reported by @danxuliu, I noticed a similar issue can happen with the default PHP backend if you join the same room with different browsers but the same user. While different browsers is probably not a real issue, using a mobile client and the browser could be a potential scenario.

How to reproduce:

• Join room with user in browser A
• Join room with user in browser B
• Navigate away in browser A

What happens:

After a couple of seconds, browser B shows the user as no longer in the room and also navigates away - from the room (to /apps/spreed) after some more seconds.

What should happen instead:

Browser B should stay in the room / call.

[nickvergessen]

This would require a major rework of the API and the database, as it means we need to split the participants from the sessions.

Also what should happen when a user joins twice? Do they connect to themselves too?

[nickvergessen]

Also this means that all the participant handling needs to be done on user+session even for logged in users, because you might want to mute one of the sessions but not the other one.

[nickvergessen]

How should 2 videos for the same user be displayed?

[fancycode]

Also what should happen when a user joins twice? Do they connect to themselves too?

Why not? You could call from your mobile to your desktop?

How should 2 videos for the same user be displayed?

I don't get that. For subscribers it doesn't matter if it's the same user connected with two devices streaming the video or if it's two different users. On the publishing side, the two devices are also independent.

Of course a valid solution to this issue would also be to reject the behaviour completely and show the second session an error like "You are already connected to this room." when trying to connect. Right now the behaviour is undefined/confusing in that the one session leaving a room can kick out the other session of a user.

[fancycode]

Also this means that all the participant handling needs to be done on user+session even for logged in users, because you might want to mute one of the sessions but not the other one.

Yes, all that handling should only be done on sessions.

[nickvergessen]

Of course a valid solution to this issue would also be to reject the behaviour completely and show the second session an error like "You are already connected to this room." when trying to connect. Right now the behaviour is undefined/confusing in that the one session leaving a room can kick out the other session of a user.

The reason we do not do this is, that if your connection to the server is disconnected, and you reload, you can not join the call again for 90 seconds until your old session is timed out.

[parafin]

Encountered this bug with discussed scenario - connected through both mobile client and desktop browser. What I wanted is to have audio connection on the phone and chat on the desktop. It's impossible currently to access chat when call is in progress on mobile client and using desktop is a nice workaround. Even if such feature gets added to mobile client, having access to the chat on the desktop too is still useful, e.g. for opening links. There's no need IMHO for possibility to have concurrent audio/video connections for same user on different devices, but chatting should work.

[beccon4]

@parafin sometimes you might want to talk from one endpoint such as your mobile (which doe best what it is designed to -> transmit voice) and share your screen to the crowd from your desktop which may not even have neither speakers nor microphone.

[parafin]

Does #3591 mean that this feature request is "won't fix"? It actually worked fine with https://github.com/strukturag/nextcloud-spreed-signaling but with latest talk release it broke again due to #3591. Also #3591 doesn't affect mobile app, so I can still create a situation where both browser and mobile are in the same room...

[nickvergessen]

It didn't work fine before #3591
If you join a call in the first window and then open it in a second device new users joining the call will not connect to you and they will not be able to hear you. Since this created rather bad impressions on the experience resulting in comments ala "does not work" and "you have to reload the page" we did this intermediate step. Note while mobile clients were not patched, they will still correctly terminate your session from the browser, making sure you know this happened.

The ultimate goal is still to get this working at some point, but preventing this from happening is better than silently breaking for calls which happened before.

[parafin]

OK, I see. I mostly meant that I was able to use text messages from both devices and they were delivered correctly. Maybe video connection worked by accident. Anyway for the time being I will consider talk being mostly targeted at audio/video conferencing and text being just an add-on to that. For text communications something else can be used.

[Pilzinsel64]

Anyway for the time being I will consider talk being mostly targeted at audio/video conferencing and text being just an add-on to that. For text communications something else can be used.

😥

[nickvergessen]

Works now at least on different devices/browser with #5194
Within the same browser this is not possible due to the shared PHP session.