Running TURN server on port 443 only matters for setups where a Client is unable to contact the server on non-port 443. This is only common in some ultra locked down intranet setups.

There is now an update in the Cloudron Appstore that brings both a fix for this and also updates Meet to version 2.3.1.

@girish thanks

@oj said in Meet Kopano (unstable version) - a few questions & problems 🙂:

packages "Kopano Meet Boost" on Cloudron

thats unfortunately a bit impractical to do. kwmbridge requires a large range of udp ports so running it in a container with forwarded ports is quite inefficient (because there is also quite a memory overhead in Docker in this case).

But it should be easy to make the app configurable enough to have kwmbridge running on a dedicated host and simply hook up to kwmserver inside of the app. having (multiple) external kwmbridge endpoints is kind of the setup we are expecting anyways.

@fbartels Sweet. Will give it a spin.

@fbartels this week 3 Kopano Meet meetings (5 users, 6 users and 2 users + 3 guests) went completely fine!!!

Thanks for this great app and looking forward to the translations update.

Groeten,

Marcel.

@imc67 said in Kopano Meet not working in Firefox?:

Dutch translations are not all completed

looking at our translation system these strings have been translated meanwhile, but it seems translations haven't been pulled in in a while so I just created a pr to update them for the next release.

@fbartels I found the problem...

I had the my.domain of my Cloudron homepage, DNS-proxied @Cloudflare.

That way TURN/STUN is also proxied and in somekind of way blocked by Cloudflare. I think the problem is it exceeds the Cloudflare max upload policy, when things get over 150MB and are proxied.

As soon as i greyed out the DNS-proxied @Cloudflare, things worked as a charm 🙂

One question left.....

I opened these ports on my firewall for TURN/STUN server to work,
port:5349 tcp/udp
and
port:3478 tcp/udp

Is this the safe and described way to do this?

The ports are redirected to the ip of my Cloudron instance running at home....

The following configuration needs to be added to the identifier registration of Kopano Konnect to enable SSO with Rocketchat:

- id: rocketchat.9wd.eu name: Rocketchat trusted: true application_type: web redirect_uris: - https://rocketchat.9wd.eu/_oauth/konnect

Remember to restart Konnect after modifying the registry. If you want to verify that the configuration was properly loaded you have to modify log_level in /app/data/konnectd.cfg to read /app/data/konnectd.cfg. With another restart Konnect will then print a message like the following at startup:

Apr 20 20:21:30 time="2020-04-20T18:21:30Z" level=debug msg="registered client" application_type=web client_id=rocketchat.9wd.eu insecure=false origins="[https://rocketchat.9wd.eu]" redirect_uris="[https://rocketchat.9wd.eu/_oauth/konnect]" trusted=true with_client_secret=false

In Rocket.chat the following configuration needs to be added. For this go into the admin backend, select "OAuth" and there "Add custom oauth". I am using the following settings:

URL: https://meet.9wd.eu Token Path: /konnect/v1/token Token Sent Via: Header Identity Token Sent Via: Same as "Token Sent Via" Identity Path: /konnect/v1/userinfo Authorize Path: /signin/v1/identifier/_/authorize Scope: openid profile email Id: rocketchat.9wd.eu Secret: rocketchat Login Style: Default Button Text: Kopano Konnect (needs to be something the user can relate to) Button Text Color: #FFFFFF Button Color: #13679A Username field: preferred_username Merge users: false

After storing these log out of Rocket.chat and you will see a new button on your login page titled "Kopano Konnect", which will then use the new login method.

I had the same experience but was told I was "wrong"... glad more people are bringing this to attention.