search

RocketChat / Rocket.Chat

The communications platform that puts data protection first.
https://rocket.chat/
Other
40.84k stars 10.76k forks source link

RocketChat Genarates Same Jitisi meet URL every time #24839

Open Sx3 opened 2 years ago

Sx3 commented 2 years ago

Description:

Steps to reproduce:

By creating a new call in rocket chat (configured with jitsi meet)

Expected behavior:

A Randomized URL each time a call is made.

Actual behavior:

Same URL each time a call is made even for a different user too.

Server Setup Information:

Latest build of jitsi meet us used

Client Setup Information

Additional context

As Jitisi meet has capability to initialize a video conference room in any given name,I suspect it is something to do with rocketchat,means rocketchat is not genarating a random room name and append it the jitisi meet url (may be I am wrong)

any directions to fix this issue will be helpful Thanks.

Relevant logs:

ankar84 commented 2 years ago

How user will get same Jitsi call if every single user will get different Jitsi room name? In that case there will be set of different rooms (calls, conferences) with only one participant. It's non sense.

Now in Rocket.Chat you have 2 options in Jitsi meet room name generating process:

  1. Hashed name - it will be RC Deployment ID concatenate with room id (rid) - about rid this is my guess
  2. Plain name - it will be just room name as you see it in RC
nikolas-digitalBabylon commented 2 years ago

How user will get same Jitsi call if every single user will get different Jitsi room name? In that case there will be set of different rooms (calls, conferences) with only one participant. It's non sense.

1) when a new call is generated, the link is posted as a message in the chat so that everyone in the chat has it. Like it is already done: When there is a call, the link is right there, in the chat and people click and open it. So I do not understand the difficulty of sharing a link among people that are in a common chat tbh...

1) Unique link could be in the form of "RC deployment ID + room id + random new token for each call", hashed. This way, if you add a guest ONCE in a call (share the link manually with someone), he doesn't have a permanent link for all the future calls initiated from the specific chat, e.g. a room.

2) Call button always follows last call link in chat, generated in step 1. So when users click, they join the last running call if it is still on, or create a new call link is generated (see 1), if the call has ended. I see no difficulty in that.

3) How to know if a call has ended? RC itself joins with an agent account all new calls (a bot, by simply following the relevant link generated in 1, and applied in 2). RC bot stays in the call, and when it is the only user in the call, waits for a configurable time period (e.g. 30 seconds). If after this configurable window (30 seconds) RC is still the only user in the call, exits and then marks the call as "ended". If in the meanwhile a user joins, timer resets again until agent is left alone. When the call has ended, the "call" button back in RC generates a new link, like step 1.

A flow like that maybe addresses some privacy issues, some functionality issues and the recurring bug "this call has ended". Now if you think about it, you could make this agent configurable on more aspects, in order to administer the call. Just some thoughts out of my head.

I wouldn't call it "nonsense".

ankar84 commented 2 years ago

I see your point now. But with my experience, there is a tons of Jitsi integration issue like "Call already ended", where users need to start call by them self, issues where button don't appears in chat on call start. So, if your call logic would be implemented, will be much worth. To protect Jitsi from guest you need to implement Secure Domain with JWT authentication, also you can select plain call name and rename chat - call name will be different and guest will not know it.

nikolas-digitalBabylon commented 2 years ago

I see your point now. But with my experience, there is a tons of Jitsi integration issue like "Call already ended", where users need to start call by them self, issues where button don't appears in chat on call start. So, if your call logic would be implemented, will be much worth. To protect Jitsi from guest you need to implement Secure Domain with JWT authentication, also you can select plain call name and rename chat - call name will be different and guest will not know it.

JWT is not solving the issue in this scenario. Assume the following: We have a channel with chat participants. A call is initialized, and chat members jump in. Now, I want to invite in this call a new external user (not from chat). So I send him the link. If I send the link, this external guest has a link for all future calls initiated from within that chat. Manually changing the chat name only to change the call url is not efficient and error prone.

At the end of the day, the approach of having a bot + a unique url per call, is not rocket science and could solve multiple issues. I wish I could contribute implementing it, but no time here... Nevertheless, such an approach as described here could be valuable for contributors/maintainers to consider.

Sx3 commented 2 years ago

How user will get same Jitsi call if every single user will get different Jitsi room name? In that case there will be set of different rooms (calls, conferences) with only one participant. It's non sense.

1. when a new call is generated, the link is posted as a message in the chat so that everyone in the chat has it. Like it is **already** done: When there is a call, the link is right there, in the chat and people click and open it. So I do not understand the difficulty of sharing a link among people that are in a common chat tbh...

2. Unique link  could be in the form of "RC deployment ID + room id + random new token for each call", hashed.
   This way, if you add a guest ONCE in a call (share the link manually with someone), he doesn't have a permanent link for all the future calls initiated from the specific chat, e.g. a room.

3. Call button always follows last call link in chat, generated in step 1. So when users click, they join the last running call if it is still on, or create a new call link is generated (see 1), if the call has ended. I see no difficulty in that.

4. How to know if a call has ended? RC itself joints with an agent account all new calls (a bot, by simply following the relevant link generated in 1, and applied in 2). RC bot stays in the call, and when it is the only user in the call, waits for a configurable time period (e.g. 30 seconds). If after this configurable window (30 seconds) RC is still the only user in the call, exits and then marks the call as "ended". If in the meanwhile a user joins, timer resets again until agent is left alone. When the call has ended, the "call" button back in RC generates a new link, like step 1.

A flow like that maybe addresses some privacy issues, some functionality issues and the recurring bug "this call has ended". Now if you think about it, you could make this agent configurable on more aspects, in order to administer the call. Just some thoughts out of my head.

I wouldn't call it "nonsense".

Thank you very much for the explanation

agsupport commented 2 years ago

How can Rocket Chat tout that it works with Jitsi when it shows "Meeting Ended" when a user clicks on a "Click to Join". A unique unique URL for the meeting would fix the issue or the ability to reuse the URL.

Is there a better way to handle video calls?

nikolas-digitalBabylon commented 2 years ago

How can Rocket Chat tout that it works with Jitsi when it shows "Meeting Ended" when a user clicks on a "Click to Join". A unique unique URL for the meeting would fix the issue or the ability to reuse the URL.

Is there a better way to handle video calls?

Hi,

to my understanding, rocketchat is not aware if the call internals, as external systems provide this functionality (Jitsi). Moreover, jitsi calls are based on webRTC, so they are run over P2P connections. The solution would be something like I described above:

https://github.com/RocketChat/Rocket.Chat/issues/24839#issuecomment-1076189158

From my perspective this would actually open the way for so many use-cases to be addressed, but most importantly: could FIX the integration with call providing services. Current state is a let-down. I do know this is a free and open source project and we should not complain, but I see that as very important. Would love to work on it myself if I had the time. I hope someone would pick it up.