click Video chat "click to join" appear "Call Already Ended"

[TimZhou1987]

Description click to join button can't work always showing call already ended

Server Setup Information: Version of Rocket.Chat Server: 0.63.3 Operating System: Centos 7.5 Deployment Method(snap/docker/tar/etc): docker Number of Running Instances: 2 mongoDB Version: 3.6

Steps to Reproduce: one user create a new video chat for sharing screen to another person another person click the "click to join" button always showing "call already ended"

Expected behavior: want to connect the jitsi video chat

Relevant logs seems rocket chat hasn't update the Jitsi timeout value. Reboot the rocketchat container will fix the issue temporary

[cfarthingale]

Experiencing a similar issue on Debian 9.

[kekscode]

Same issue using the docker container:

• Rocket.Chat Version: 0.72.0
• NodeJS Version: 8.11.3 - x64
• Platform: linux
• Process Port: 3000
• Site URL: https://rocket.tld
• ReplicaSet OpLog: Disabled
• Commit Hash: abe1f41202
• Commit Branch: HEAD

[rockneverdies55]

Don't even remember since when but we're having this issue for a long time by now as of v0.74.2. Each time one of us starts a video call, "i" (info) icon has to be clicked on jitsi-meet window and meeting access link has to be copy pasted to the rocket.chat room manually for everybody to join the video meeting.

[kokotko1337]

same isue on ubuntu 16.04

[renanstn]

Same isue on manjaro.

[woulf]

Same problem on one out of 3 client, using the latest desktop app on Windows 10

[woulf]

Same problem on one out of 3 client, using the latest desktop app on Windows 10

one way to work around this is for the user that want to join to reclick on the "video chat" button, it will make them join the proper jitsii meeting instead of launching another one.

[lixiran]

this issue still reproduced on the latest build

[wreiske]

Found the code:

https://github.com/RocketChat/Rocket.Chat/blame/926f629e831b21ad16567ebe3b5d2e2571a9cf89/app/videobridge/client/actionLink.js

There is a timeout that isn't getting increased. It may be better to just remove this check altogether and always open the video call, even if it may have ended.

[justinr1234]

@wreiske can you do a PR for the fix? Thanks for finding!

[wreiske]

@wreiske can you do a PR for the fix? Thanks for finding!

Possibly. I know @geekgonecrazy knows more about this code. Maybe some newer jitsi API updates are needed here rather than just ripping out the timer.

[bhadilov]

This bug has been killing us for 3 weeks. A fix will be greatly appreciated. :-)

[TimmiORG]

What is needed to get this fixed in the near future? I would agree that the removal of the time-out would help for the moment if there is not possibility to check the usage of the room through a jitsi meet API or so.

` actionLinks.register('joinJitsiCall', function(message, params, instance) { if (Session.get('openedRoom')) { const rid = Session.get('openedRoom');

    const room = Rooms.findOne({ _id: rid });
    const currentTime = new Date().getTime();
    const jitsiTimeout = new Date((room && room.jitsiTimeout) || currentTime).getTime();

    if (jitsiTimeout > currentTime) {
        instance.tabBar.open('video');
    } else {
        toastr.info(TAPi18n.__('Call Already Ended', ''));
    }

`

[ankar84]

We have the same issue. We have that issue in DM and in private groups\channels as well. For example all actions a made in Winodws desktop application (Electron). But it is true and for mobile clients. User1 press 3 dots and select Video Chat. It generates Click to Join! button in chat. User2 in a moment press Click to Join! button and see warning Call Already Ended User2 press 3 dots and select Video Chat and gets in User1 Jitsi Meet call.

Click to Join! button should be fixed.

[JohnLukeP]

As of today, the issue has not been solved yet. Still present on our (manually installed) environment:

Rocket.Chat Version: 2.4.2 NodeJS Version: 8.17.0 - x64 MongoDB Version: 4.0.13 Platform: linux ubuntu 18.04.3 LTS Process Port: 3000

Tested on rocketchat webapp and rocketchat desktop app version 2.17.2

[dasfreak]

Also present on our (docker/latest) installation:

Version: 3.0.4 Node: v12.14.0 Mongo: 4.0.16

[dasfreak]

Tested on:

Desktop app version: 2.17.7 Rocket.chat. installation (manual): 3.0.3 Mongo: 4.0.16 Node: 12.16.1

The bug has disappeared and the button is showed properly.

yeah the button is there but it says "call has ended" way too fast

[melroy89]

I also hope there is a way to delete this message. Since I do not see 'Delete' menu for this kind of notifications.

While I could delete "Click to join" messages, only when I select 'Prune messages' which deletes all messages.

[bkraul]

I am a little surprised that this has been an open issue for quite sometime. We have integrated our own jitsi server and were hoping to use this functionality, but we are getting the "Call has already ended" message, which renders the whole thing worthless. Hopefully we will have a solution soon? 🙂

[ankar84]

@bkraul as a workaround I can suggest you just to start video call as usual in chat with call already ended error. You will get video call that you need

[bkraul]

@ankar84 I am not sure I understand your message. The whole point is that it doesn't work. I can "start" the call, but the other party cannot join the call because it says "Call Already Ended". We are currently instead using the jitsi market place app that allows to start a call with /jitsi [room name]

[ankar84]

but the other party cannot join the call because it says "Call Already Ended"

In that case other party should not press click to join button again, but they need to start video chat from chat menu. And that other party will join video chat. We are using our own jitsi server and that workaround works like a charm.

[bkraul]

I just tested, and you are correct. It works. Not very intuitive though. I think we will stay with the slash command or the jitsi electron app for the moment. Thanks for the tip, though.

[melroy89]

So still could somebody look into a better long term solution?

[hever]

Joining video call sometimes work and sometimes not (Call already ended). I try to find when it's happened and I found no context. Only what coming on my mind is that there is some problem with timezones or time shifts on every clients - there might be jitsiTimeout on other history on device. But it really makes it impossible to use for many many people. And on other hand - benefit of watching timeout is near zero. So temporary disable function is the way! Do it! Somehow, please. e.g. https://github.com/RocketChat/Rocket.Chat/pull/16966

For those who don't know what about we speaking about. There is way to do video call, so one trigger video call and other side click on in immediately and see only "Call already ended" and it does nothing. So for non tech people - video call not work.

[PotatoCarl]

We have the same problem which is really annoying. the "/Jitsi room name" works, but is kind of an annoying workaround.

[bkraul]

What am puzzled by is: Why is time synchronization even a factor on clicking the "Click To Join" button? What happens when we are tying to a jitsi server we can't control??

This is not even so on jitsi itself. You enter a room, if the meeting is not in progress or it doesn't exist, it gets created, and the worst thing that can happen is the person will be alone in the room waiting. I don't see why there should be check for whether the meeting has already ended. In any case, IF we need to check if the room exists the colibri REST API (which would likely require the use of a JWT configuration for authentication) should be used instead to get room information.

[adrianovieira]

We also found this behaviour on environment:

Version: 3.0.12
Node: v12.14.1
Mongo: 4.0.17

What I've just done here was to change the default timeout value.

https://github.com/RocketChat/Rocket.Chat/blob/develop/app/videobridge/constants.js

So users have more time (~5min in my case) to click and enter on video chats.

Do you have any concerns / consideration about?

PS: I don't know what can be the collateral effect of this change, yet.

[mblo]

So still could somebody look into a better long term solution?

What about writing a very simple Jitsi prosody module, so that Rocket.Chat gets a callback (rest call) when a Jitsi room is destroyed. Similar to the example of the speaker stats module.

When Rocket.Chat receives such a rest call, it could simply update the "join call" button and change it to "Call ended (hh:mm:ss)".

[Fiambre]

After some test's i can say that problem is the following, The jitsiTimeout variable is updated on the following file:

https://github.com/RocketChat/Rocket.Chat/blob/develop/app/videobridge/server/methods/jitsiSetTimeout.js

That file is executed on server side, so the jitsiTimeout timestamp is set from server date. When we press the "Click to join!" button, this executes the following file:

https://github.com/RocketChat/Rocket.Chat/blob/develop/app/videobridge/client/actionLink.js

That file is executed on client side, so currentTime is set with client local time. So as @adrianovieira says, the timeout default value is 30 seconds. If client and server time are out of sync in more than 30 seconds "Call already ended" hapens, specifically if the server time is behind the client.

I quickly fixed this by adjusting the server time at least 1 minute ahead. You can also set a higher timeout but that requires compile.

[bkraul]

How about the time out just gets removed altogether or a better method is use like what @mblo suggests 🙂

[geekgonecrazy]

@Fiambre ah! The client side being out of sync that makes sense.

@mblo i like the idea.. but it’s not really so great to make someone install a prosody module to use jitsi :(

~Maybe there is some call to prosody to get a room state?~ nvm... all signs point to having to add prosody module to do that too: https://community.jitsi.org/t/jitsi-dev-isconferenceactive-http-request/12506/5

~But that would require us to still check at some sort of interval... and I think also do it server side because calls to the /http-bind endpoint that goes through to prosody is a POST~

[mblo]

@geekgonecrazy agree.. it is not so great to ask people to install something extra. However, we could contribute a "general room-ended callback module" to Jitsi, so that this guy simply makes rest calls to a given URL. If this is part of Jitsi, Rocket.Chat simply needs to provide an endpoint to consume room-destroyed messages.

So a user simply needs to check the endpoint-url in the Rocket.Chat admin panel, and add this in the Jitsi config so that Jitsi knows where to send callbacks.

(A nice advantage of such a solution would be to have even more information in this callback, like duration, speaker stats, ...)

[bkraul]

@mblo i like the idea.. but it’s not really so great to make someone install a prosody module to use jitsi :(

With respect, what's really not so great is to have a jitsi "integration" that does not reliably work. It is sad when a simple rocket.chat slash app is the only thing that can reliably be used to integrate jitsi to rocket.chat.

I still say this an over-complication of a very simple issue. Please, just remove the time out / call-ended check (or maybe make it configurable, to where it can be turned off in the Admin? Like an "Enable call-ended check"). Done. Best thing that happens, 2 or more people connect. Worst thing that happens, person sits alone in room, gets tired, closes the window. As I mentioned. Not even jitsi itself has this behavior (where a user would get a "Call has ended" notification and not allowed to access). A new room simply gets created with the same name.

What is the point of having a button that checks for the conference ending that does not work reliably and it is dependent on client-server time synchronization (which can vary tremendously)?...

I apologize for the frustration. I mean no offense to anyone. But I feel this integration seems like it's really missing out on its time to shine in this particular season.

[hever]

Yes "over-complication of a very simple issue" - that is the point here.

I have rocket.chat server with manual install. So i made my workaround - after download and unpack server files i manualy edit javascript file and in that one condidtion i put false so it will never say "Call already ended". We are absolutely happy, there is no side effect and no problem. And we may stuck in this version until that condition live anymore.

TLDR: Let's remove video call timeout at all.

[PotatoCarl]

Havin the same issue and agreeing 100% to this, would you mind enlightening me were this file is? I am using it as a snap and could not find it anywhere.

If the developers feel unsafe about the timeout, why not adding a simple PIN code automatically to the meeting? By "joining" it would automatically be used and now you are protected AND it works.

[bkraul]

@PotatoCarl the thing is, adding or not adding a PIN is handled on jitsi itself, whether by enabling authentication or by setting up a password for the room in the meeting interface. Both things are incredibly simple to set up.

The really cool thing about integrating jitsi into rocket.chat is not really the buttons or interaction. It basically boils down to the use of the same chromium window/panel (when using the rocket.chat client). You don't get that with the jitsi slash app. I say it is cool, because it eliminates the need for people to check if they are using a compatible browser for jitsi.

[wreiske]

Maybe this has been mentioned before... if you start a jitsi call inside of rocket.chat, why not insert the call status into a collection a real-time reactively show the status of the call, who all has clicked the join link, etc. If they leave or close the window, just remove them and everyone will reactively get the updates. When everyone leaves, the button to join will change to ended.

[bkraul]

@wreiske When you say status, you mean purely the status of the button click, and window (or side panel) opened, right? This means it would not need any feedback at all from jitsi, and it would also depend on flags rather than on time? That actually makes a lot of sense!

[PotatoCarl]

@bkraul the Pin was rather a suggsetion to make it safer (so nobody could stuble into the room by accident). I am all in favor for a working integration in RocketChat - basically this was one of the reasons why we have set it up in house. But as we are using the public Jitsi-Server at this time, it is just not functional - which is a pity.

When it comes to integrating, ActiveSync to integrate out Groupware would ab amazingly great, because that way we would not have to use a special Google-Calendar to organize the Jitis-Meetings, but could do this from Rocket Chat or our Groupware...

[wreiske]

Exactly. On the window.open code you can talk to the opened window to know when it opens and closes. Time in the meeting would just be a timestamp of when the join button was pressed to now. I would argue you should keep the call info too for analytics, so you'd have an end time and if the end time exists then you assume that caller is no longer in the call.

[Fiambre]

I think that increase timeout time is the shortest solution, cause this works for mobile version and desktop.

The other suggestions would works only for desktop.

On the other side, if someone can really explain to us what is the purpose of the timeout, thats will be great.

[wreiske]

For what it's worth, the solution I proposed above would absolutely work on mobile and desktop.

[Fiambre]

I don't think I really understood you. If the mobile app uses the Jitsi app, wouldn't that require modifying the React Native app too?

[wreiske]

I don't think I really understood you. If the mobile app uses the Jitsi app, wouldn't that require modifying the React Native app too?

If they were to implement my idea including subscriptions, a collection to track the video calls, etc., it would be new APIs on the server that can be utilized by the desktop and the mobile app. Yes, it would require a change to the mobile app and the desktop app, but it is possible in both place and my original statement still applies that it would absolutely work on mobile and desktop.

The "Jitsi App" is part of the Rocket.Chat React Native. No need to modify Jitsi's React App if that's what you mean.

[mblo]

@mblo i like the idea.. but it’s not really so great to make someone install a prosody module to use jitsi :( ... I still say this an over-complication of a very simple issue. Please, just remove the time out / call-ended check (or maybe make it configurable, to where it can be turned off in the Admin? Like an "Enable call-ended check"). Done. Best thing that happens, 2 or more people connect. Worst thing that happens, person sits alone in room, gets tired, closes the window. As I mentioned. Not even jitsi itself has this behavior (where a user would get a "Call has ended" notification and not allowed to access). A new room simply gets created with the same name.

...

I totally agree.
Let's fix this issue, simply by deactivating the timeout check. (TLDR It is a pity that this bug requires us to copy paste so often the call URL in the very same chat simply because the button claims the call to be over.)

On a long term perspective, having a more powerful integration with call statistics would be nice but should be covered in a dedicated ticket.

[ankar84]

TLDR It is a pity that this bug requires us to copy paste so often the call URL in the very same chat simply because the button claims the call to be over

Actually you don't need to copy and paste any URL, you need just start call in that chat from scratch. You will connect to correct call. I teached my users that workaround while that issue not fixed.

[hever]

@PotatoCarl

Havin the same issue and agreeing 100% to this, would you mind enlightening me were this file is? I am using it as a snap and could not find it anywhere.

In snap version you can't touch the code IMHO, so you will need another method to run your server. If someone would like to solve this problem earlier than will be solved philosophy around it and someone will start to repair this pitty problem, you can do this.

This is really bad boy fixing. But hard times needs hard fixes... B-)

There is .js file in /programs/web.browser/ named like 79783f18096ead049b98ddeadbf4cc68a446da5b.js - it is about 5MB and name is different in different version. In this file just find string Call Already Ended. There is something like

some-condition?n.tabBar.open("video"):s.info(o.__("Call Already Ended","")

If you don't understand this syntax, it's mean true-or-false?if-true:if-false

So, simply put as condition 1 and it will never ever show you the Call Already Ended again. So in my version I have this:

...blahblabblah.getTime();1?n.tabBar.open("video"):s.info(o.__("Call Already Ended","")...

As I mentioned before, I have my server with manual install. So I download new version, after download and unpack server files i manualy edit javascript file and then continue in upgrade process. You can't do just edit your actual version .js file, because browsers (and mobile apps) have cached this file and this change will not pop up. You have to do it together with publishing new version.

Someone should remove this useless and fatal-problem-causing timeouting. This is really bizarre.

[aminvakil]

I'm using rocketchat docker and I can't find the js files mentioned in temporary fix or other comments, in fact in my app folder is only two folders, bundle & uploads.

[aminvakil]

@hever Thanks!

Havin the same issue and agreeing 100% to this, would you mind enlightening me were this file is? I am using it as a snap and could not find it anywhere.

Docker version is like snap version, I had to change /app/bundle/programs/web.browser/bc93399a9122d2e71109d1a2bef92c0ef47648f4.js file in rocketchat container.