Rocketchat direct call

ATSrl 2021-04-10 11:23:21 UTC #1

Hi All
Using Rocketchat I cannot make direct calls like in the picture.

once the call has started you receive an authentication error

on the other hand the called user receives the call signaling

but also in this case there is an authentication error

and the caller is notified that the call has not been answered.

It seems to me that the link is not correctly formed.
any suggestions ?
Thanks in advance

RalfBecker 2021-04-10 12:38:29 UTC #2

meet.jit.si uses no authentication, seems like you have authentication switched on under Admin > Applications > Status > Site configuration

Ralf

ATSrl 2021-04-10 18:10:24 UTC #3

Hi Ralf,
you are right I have modified the settings you mentioned and now no permission is required to meet.jit.si and the call starts.
Now I have this error that seems related to the permissions of chrome. the strange thing is that if I make a direct call this error appears

while if I make the call from

(in the upper right corner of the rocketchat window)

I do not receive any error signals and everything works correctly
Any suggestion.
Thanks in advance
Gabriele

RalfBecker 2021-04-10 18:35:08 UTC #4

@hadi.nategh any idea?

Ralf

ATSrl 2021-04-10 19:15:31 UTC #5

Hi All,
problem solved. I don’t know why but it was necessary to grant access to the camera from Chrome both as a general setting and at least once in the direct call window

Thanks

RalfBecker 2021-04-10 19:28:25 UTC #6

I don’t know why but it was necessary to grant access to the camera from Chrome both as a general setting and at least once in the direct call window

hadi.nategh 2021-04-12 08:33:34 UTC #7

That sounds like the iframe resources being blocked either by CSP or not having enough rights for resources (audio and video). Is your egroupware server running on https? Do you get any Javascript error on console?

ATSrl 2021-04-12 10:56:32 UTC #8

Hi Hadi,
you are right, the problem has been fixed. It was a permissions issue in Chrome. The strange thing is that the behavior was different using directly the link created by EGW or making the call. with the same link from inside EGW. Now in any case it works and is very useful.
Thanks
Gabriele

ATSrl 2021-04-22 11:21:17 UTC #9

Hi All,
Unfortunately, the problem is partially solved. I’ll give a brief summary.
A video call from rocketchat works correctly when made on the main screen

If a direct call is made instead:

The called person receives notification of the call.

the call correctly initiates. In previous posts I highlighted the problem that occurred when the call was initiated. Now, on the caller’s side everything works correctly.

If, however, the user answers the call, the camera is not activated, nor is it possible to activate it as it remains greyed out

any suggestions ?

Thanks in advance
Gabriele

StefanU 2021-04-22 18:35:49 UTC #10

Hi Gabriele

Video conference/call in EGroupware and Rocket.Chat are two completely different things!
In both systems, the video conference systems are configured respectively.
In both systems you can configure Jitsi or BigBlueButton.

Basically, you have to allow the browser to access the camera. The same applies to the microphone.
That is also a good thing. Otherwise, any website could switch on both. We certainly don’t want that.

If you have not allowed access in the browser, Jitsi/BBB will not be able to access it either, because they will not “see” any camera. The icon is then greyed out.

Another reason could be that your operating system has “given” the camera to another programme. You cannot access it from two programmes. It usually helps to unplug the camera and plug it in again.

This is a fundamental problem of any videoconferencing solution and has nothing to do with EGroupware.

–

Without naming the operating system / the web browser used and showing exactly what is happening with the called party (also the access rights in the browser), it will not be possible to say more about this.

Stefan

ATSrl 2021-04-23 09:18:08 UTC #11

Hi Stefan
I agree with you, but the problem is that we cannot understand why some computers allow access and others do not. All computers correctly allow what rocketchat calls “call”.

Most computers do not allow what rocketchat calls Video Call.

Even stranger is that the first response to the video call fails. If a user quickly clicks again on the link for the second time, access to the camera and microphone is granted.
I think this is a strange behaviour and I was hoping that someone had encountered a similar problem.
In any case, thanks for the indication. I will continue to analyse the problem
Gabriele

StefanU 2021-04-23 09:31:03 UTC #12

That Video Call ist NOT Rocket.Chat!
With this, you use the Jitsi/BBB that is configured in EGroupware.

Are you using the same Jitsi server in both cases? Or BBB?
Please check.

Stefan

ATSrl 2021-04-23 09:48:47 UTC #13

Hi Ralf,
you are right
anyway the problem is always there.
we are using Jitsi server installed on our server.
Gabriele

ATSrl 2021-07-19 19:30:04 UTC #14

Hi All,
Unfortunately we are still dealing with the direct call problem with Jitsi server. We have noticed that the behaviour of Jitsi seems to differ depending on how it is called in EGW.
If it is called by using the method shown in the picture:

the URL used is correct and is where Jitsi is actually installed. The videocall works perfectly.
The URL used is as shown in the picture:

If, on the other hand, the call is made using the method shown in the picture

A completely different URL is used as shown in the figure:

Is there any way to get the correct URL to be used?
Gabriele

RalfBecker 2021-07-20 10:01:22 UTC #15

Yes, by setting it in EGroupware:

EGroupware URL can be set in EGroupware setup > configuration (https://example.org/egroupware/setup/)
Rocket.Chat URL under Admin > Applications > Status > Site configuration > Jitsi Server Settings > Jitsi Domain

All URLs should be https, as browsers no longer allow to frame http in a https site!
EGroupware automatic detects it’s URL from the http-headers, IF your proxy configuration is correct.

Ralf

ATSrl 2021-07-20 19:35:22 UTC #16

Hi Ralf,
following your instructions, I changed the Jitsi setting.

once changed the URL is built correctly but only for the second part.

http://10.0.0.18/egroupware/index.php?menuaction=status.\EGroupware\Status\Ui.room&frame=https%3A%2F%2Fcollabora.atsrl.eu%2F10.0.0.18-9EvLVtUusOV9cDa4QRg7%23config.startAudioOnly%3D0

As indicated, I then tried to set EGW to https with the given setting. I tried both of the available options (see figure)

EGW does not work with either of them.
any suggestions?
Gabriele

RalfBecker 2021-07-21 05:46:46 UTC #17

Either fix your proxy on the host to set X-Forwarded-* headers, or set EGroupware’s URL to https://egw.example.org/egroupware instead of just /egroupware to not rely on proxy headers.

Ralf

ATSrl 2021-07-22 12:21:30 UTC #18

Hi Ralf,
I have tried the settings you suggested but the URL is still not formed correctly.
The server part is still listening on port 80 and therefore in http.
I think the following lines need to be changed:

in the apache.conf file
RewriteRule /egroupware/push ws://127.0.0.1:8080/egroupware/push [P]
ProxyPass /egroupware/ http://127.0.0.1:8080/egroupware/ timeout=4000 connectiontimeout=600 acquire=3000 retry=6
ProxyPassReverse /egroupware/ http://127.0.0.1:8080/egroupware/

ProxyPass /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync timeout=4000 connectiontimeout=600 acquire=3000 retry=6
ProxyPassReverse /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync

in the nginx.conf file
}
server {
listen 80 default_server;
location /egroupware {
proxy_pass http://127.0.0.1:8080;

Is this correct? Or is there a different setting to change?
Thanks for your precious help
Gabriele novembri

RalfBecker 2021-07-22 13:20:53 UTC #19

Changed from what? They were already http

Are you using Apache or Nginx as proxy on the host? You never need both files.

The files need no changing, if you set the correct URL in EGroupware or pass the correct proxy-headers, if not using our proxy or have an additional proxy in front.

Anyway you should not use http, but https, as - beside security issues - browses no longer frame https in iframes delivered via http!

Ralf

ATSrl 2021-07-22 15:58:24 UTC #20

Hi Ralf,
I am a bit confused because if I follow your indications and I set the url as https://10.0.0.45/egroupware as shown in the picture.:

The egroupware application doesn’t work in https as shown in the figure.

but it only works in http

Am I doing something wrong?
Gabriele