We have some participants behind a corporate proxy. They’re able to join the meeting without audio and video.
I set up an external Coturn server on a separate machine. I can see the difference in the web-internals ICE candidate grid but still when a corp user joins. No audio and video and the JVB is trying to send the streams to their local IP instead of the public one.
Anyone has any idea how to solve this?
The path should be the following:
client → turn server port 443 or 5349 → jvb public address & port (udp 10000) → jvb
If you see the jvb trying to reach their internal address … that means UDP packets have reached jvb, and probably turnserver is not needed. What do you have configured in config.js for stun servers?
Good question … yeah, actually for the media to the bridge the stun server is not needed.
Well… how are these users being identified with their local IP? The JVB is sending the streams to the endpoints local IP.
Here’s a screenshot
This means the bridge is trying (and failing) to establish a connection using the private address. It’s therefore not using it to send media.
Did you use for turn config our template: jitsi-meet/turnserver.conf at master · jitsi/jitsi-meet · GitHub
Maybe share the coturn configuration
Here is our coturn config.
# /etc/turnserver.conf
# STUN server port is 3478 for UDP and TCP, and 5349 for TLS.
# Allow connection on the UDP port 3478
listening-port=3478
# and 5349 for TLS (secure)
tls-listening-port=443
# External IP-Address of the TURN server
external-ip=PUBLIC_IP
# Require authentication
fingerprint
lt-cred-mech
#log-file=/var/log/turnserver.log
# We will use the longterm authentication mechanism, but if
# you want to use the auth-secret mechanism, comment lt-cred-mech and
# uncomment use-auth-secret
# Check: https://github.com/coturn/coturn/issues/180#issuecomment-364363272
#The static auth secret needs to be changed, in this tutorial
# we'll generate a token using OpenSSL
# use-auth-secret
static-auth-secret=__SECRET__
# ----
# If you decide to use use-auth-secret, After saving the changes, change the auth-secret using the following command:
# sed -i "s//$(openssl rand -hex 32)/" /etc/turnserver.conf
# This will replace the 65bf303f069496b35bc4fa4157e268a2e5d2a61aa3e666a5c2d70b206428b39e text on the file with the generated token using openssl.
# Specify the server name and the realm that will be used
# if is your first time configuring, just use the domain as name
server-name=coturn.domain
realm=coturn.domain
total-quota=100
stale-nonce=600
# Path to the SSL certificate and private key. In this example we will use
# the letsencrypt generated certificate files.
cert=/usr/local/cert.pem
pkey=/usr/local/privkey.pem
# and 5349 for TLS (secure)
tls-listening-port=443
# Specify the allowed OpenSSL cipher list for TLS/DTLS connections
cipher-list="ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384"
# Specify the process user and group
proc-user=turnserver
proc-group=turnserver
no-sslv3
no-tlsv1
no-tlsv1_1
no-tlsv1_2
syslog
This is not correct. Drop that and make sure turn server can connect to port 10000 on public IP address of jvb.
Also, make sure you add the denied rules from our template to avoid exposing your internal network to the outside world.
We made the modifications (including the denied-peers) and still the JVB log show the JVB is trying to establish connection on the private IP.
On meet.jit.si the users can connect without an issue.
Any other ideas?
Yes I can connect from coturn to jvb using port 10000
That is expected and not a problem.
What about the certificates the coturn is using, are those valid? With full chain?
Are you testing with browsers or mobile clients?
Looking into that now. Thanks
Doesn’t matter when behind a corp proxy
Well, I’m asking cause at some point there was a known problem with mobile clients, turnserver and let’s encrypt certificates.
Not sure in which version is fixed, and whether that fix is already out.
No we just tried with web browser that connected to meet.jit.si.
The certs and keys are verified.
Yeah, meet.jit.si is not using let’s encrypt, so that’s one difference and that’s why I was asking what you are using and are you testing with browsers.
Check that you have the full chain https://whatsmychaincert.com/
We aren’t either. We have an EV SSL certificate in place.