@longsleep said in COTURN & Meet behind a Firewall (LAN/NAT)?:

@pixel TURN servers are not really meant to be run behind NAT - having that said, it is possible if you carefully setup your filewall rules and do 1 to 1 port forward in both directions.
See https://github.com/coturn/coturn/blob/master/examples/etc/turnserver.conf#L110 for hints.

Thank you for pointing this out. Like the other VMs, the TURN server is accessible under 443 via HA proxy.

I have already set the value “external-ip=…” to the external WAN IP of the local gateway. However, I cannot find any indication in the readme that I need two external IPs.

I suspect it is due to the 1:1 port forwarding in the outgoing direction. Which ports with which protocol are required here?

We have tried using the Kopano server (https://ucs-turn.kopano.com/turnserverauth/). Despite a good local data line, we often have a standstill with the video. In addition, all data should “stay” here in the house as far as possible with regard to data protection.

Sorry it’s not a kopano issue but an haproxy one. I just update it too from 2.1.10-1~bpo10+1 to 2.2.6-1~bpo10+1

I just test with an rewrite of my /etc/hosts and kopano is working well without haproxy.

Hi @kios_gmbh,

grapi is a dependency that can be resolved through the following repository https://download.kopano.io/supported/core%3A/8.7/

@ckruijntjens i don’t understand the question. Just like you would install any other package.

If you had a subscription you could simply configure our repository. Since you have not you either need to build a local repository or manually install the package.

@Jochen77 said in Kopano Meet with UCS after "Login" 404 not found:

and the ssl certificates are valid.

curl does disagree with you:

curl $(ucr get oidc/konnectd/issuer_identifier)/.well-known/openid-configuration curl: (51) SSL: no alternative certificate subject name matches target host name 'ucs-sso.url.intranet' curl $(ucr get oidc/konnectd/issuer_identifier)/signin/v1/welcome curl: (51) SSL: no alternative certificate subject name matches target host name 'ucs-sso.jh-edvservice.intranet'

Its also strange that this complains about two different domains not being part of the domain. as in the ucr variable has a different domain stored each time you request it. Is that a system with multiple ucs nodes?

@Jochen77 said in Kopano Meet with UCS after "Login" 404 not found:

curl https://$(ucr get kopano/docker/FQDN_SSO)/signin/v1/welcome [..] <address>Apache/2.4.25 (Univention) Server at ucs."External domain.de Port 443</address>

This (that its an Apache error) indicates that the univention openid provider is not configured properly (which has to be done manually when changing the domain name). Normally it should proxy that url to a Docker container, but that proxy seems to be missing in your case.

Hi @pixel,

I’ve answered the phone question at https://help.univention.com/t/meet-webmeetings-matterhost/16230/2

@ilmix No we stopped developing WebMeetings, you should switch to Kopano Meet.

@notifyme

If you have a running Meet, you only have to configure it in the intranet-Plugin,
so you can see an extra entry in the Menu

Something like this:
define(‘PLUGIN_INTRANET_BUTTON_TITLE’, ‘Kopano-Meet’);
define(‘PLUGIN_INTRANET_URL’, ‘https://<your address to meet>/meet/’);

Hi @mniehren,

at least from our side there are currently no plans for this. But if someone from the community/Mattermost wants to work in this we will gladly help.

Some more details can be found in a previous discussion at https://github.com/Kopano-dev/meet/issues/9.

I checked this, chrome is working fine with meet and simpl.infi

ff is still struggling and i cant figure out why. The internal cam works as expected (both, in meet and simpl.info).
i will do further research and report back if i get it to work.
in the meantime, if someone had a similar issue and got some more hints, i appreciate it.

best regards,
coffee_is_life

@plzk-de yes, of course I have verified the version.

The 2.2.x release has also been available in meet:master for a while. So its not like this update comes out of the blue.

Hi @ScriptorXO,

No at the moment this is not possible.

OK, very similar to how I did mine as well. I’m calling a function which does it so I can use it some of my other images.
While I am going for a single container solution, I also have the functionality to split out each service into their own discrete container, yet using the same image, which I believe you are doing as well for many services. While that functionality hasn’t entirely been tested on the meet services, it is certainly working on KC components using shared sockets. One difference is I’m not using Kweb but pure nginx. I hope to have some of the bits that are bothering me sorted out in the next few days and I’ll put it up for review.

parse_config() { if [ -f ${1} ] ; then print_debug "Parsing Config ${1}" while IFS="" read -r line || [ -n "$line" ] do if [[ "${line}" == *" = "* ]] ; then name=`echo $line | awk '{print $1}'` value=`echo $line | awk '{print $3}'` export $name=$value fi done < ${1} else print_error "Tried to parse config ${1} but it doesn't exist!" fi }

@mniehren said in A nearly working apache config for Meet:

Mhm i have no idea whats wrong with your Apache. Look at the requests in detail (in the browsers web console). At the start of meet, two requests to the users endpoints are made. First one with top=1&skip=100 and then based on the result the next one to fetch the first 100 users with top=100&skip=0.

Hi Felix,

i found the error. I forgot to open the firewall for the turnserver UDP Port’s. Now,
everything is runnig :-)). Many thanks for your help.

Hi!

Just smashing my head against the table.

If you use https://meet.mydomain.at/meet/r/group/public/test instead of:
https://meet.mydomain.at/meet/r/join/group/public/test

it cannot work.

I wonder how this happend when copy and pasting… (well it cannot be copy/pasted).

Sorry!

Note to myself: Don’t do a lot of things simultaneously! :-(

Hi Felix,
thanks for the information!

Hi @mniehren,

thanks for the feedback regarding Vivaldi. On first look it seems it does not support all features of WebRTC that Meet requires. I have put on my list to test his locally as well.

Edit: just gave this a quick try with the default installation of Vivaldi against our internal system and I was able to make a call.

Hi @mcdaniels,

yes when running Meet in “secure” mode (which should only be turned off for debugging) you have to make sure that all certificates can be verified.

Will do, thanks!