show, that the new way of integrating the turnserver with h2 is very appealing on the one hand but it is creating possibly insurmountable difficulties for others, particularly if there is no separate IP for jitsi, but if one uses SNI, HAProxy (or similar), NAT and possibly SSL offloading. All of those techniques are typically used for valid reasons and they are difficult to replace if the infrastructure is used for other purposes in parallel. It would be good if they did not prevent a full installation of jitsi.
What does work in such settings is to purge the turnserver, forward port 443 tcp through the proxy and port 10000 udp directly to the one and only jitsi server used. But then, the turnserver functionality is lost. If I am not mistaken, the following way should also be feasible:
Use one SNI/Proxy/NAT (and possibly SSL offloading) for one subdomain, such as meet.[URL] for the core functions.
Use a second SNI/Proxy/NAT subdomain, such as turn.[URL] for the turnserver.
Publish the turnserver subdomain through /etc/jitsi/meet/[URL]-config.js
While I am unable to implement this mysel: Is this feasible? Could someone with adequate knowledge please be so kind to publish a how-to?
I believe I have a similar setup as you. I use HAproxy as a reverse proxy, and sni/ssl offloading to map to various back-ends. Since haproxy doesn’t support udp proxying, I restored the fallback to tcp 4443. created a front-end in haproxy to listing to 4443 and use tcp mode, and then the backend. Another would have been to use additional IP address…
Here is what I did:
removed jitsi-meet-turnserver (apt purge jitsi-meet-turnserver). This removed the nginx module 60-jitsi-meet.conf and likely changed some other nginx configs.
Changed turnserver.conf listening ports. in my case, I used 4444 and 4443 for tls
verified nginx site was listing to 443 instead of 4444
edit prosody config. Under turncredentials, I commented out the lines for stun and turn. Then updated the port for turrns to match what I used in step2, 4443
Thank you very much! I am not certain, that I fully understand your setup. The following questions remain:
A user of your service will enter https://[URL] (i. e. port 443 not https://[URL]:4443), correct?
Your setting does still provide TURN, correct? TURN is not provided by jitsi-meet-turnserver itself, but by package coturn (which I did remove by apt autoremove after purging jitsi-meet-turnserver) itself, correct?
3)The (additional?) frontend on port 4443 is only for the turnserver, correct? On a backend with a single server, tcp is close to forwarding the port, I think.
You made no manual changes in the nginx configuration, correct? You did change turnserver.conf and prosody config as described but you did not need to change the turnserver announcement in /etc/jitsi/meet/[URL]-config.js, correct?