Hi,
I have now created scripts to allow us to easily install and configure a Jitsi server that has the coturn TURN server sharing port 443, as per the guide here:
This allows clients which have firewalls/proxies to use the wonderful Jitsi service.
However, I wanted to confirm if this will mean that port 443 and the TURN server are used for all participants, or just those that cannot communicate with UDP:10000 on the server?
From experimental evidence it seems that clients will connect via 443 even if they can use the more-performant direct connection to UDP:10000. Isn’t it possible that the server offers several ICE candidates, including UDP 10000 as a preferred medium and the TCP 443 as a failover?
Yes, but I have configured a TURN server to be available on port 443 (as per the guide I linked to) and therefore prosody will advertise it on port 443:
{ type = "turns", host = "turn-jitsi-meet.example.com", port = "443", transport = "tcp" }
…and therefore clients will use that port/TURN server for audio/video packets. Correct me if I’m wrong?
My question is whether clients will still be able to use UDP:10000 to connect to the JVB directly with this approach (if they are able to) and only use TCP:443 as a failover? Or will all clients now use TCP:443 exclusively?
OK, thanks. That’s what I presumed. It would make sense. My follow up question would then be… how can I confirm this is happening?
At the moment I am seeing this:
… regardless of whether UDP:10000 is open to the world on the server or completely blocked (deleted from the AWS security group). It seems that clients are always using the TURN server. Also, before the TURN server was installed, I could confirm that communication was being made on port 10000 by deleting it from the security group during a conference and all video/audio streams would freeze and fail, confirming that UDP 10000 was being used. But now, it has no affect whatsoever.
This would suggest that UDP:10000 is not being used externally. Is this correct? Could my configuration be incorrect which means port 10000 is not “advertised” to the clients and therefore never used?
your connection to an internet server is not exactly typical; your internet server has a private ipv4 address (in the 172.16 block) and your local address is localhost. This suggest that you are connecting through a VPN that could filter the port 10000/udp, or maybe you have a proxy fooling the javascript code reporting the connection status.
When I connect to my test jitsi server I see 2 true public ipv4 addresses without turn - but as I have a proxy when port 10000 is blocked, I see a private local address - the remote address stay unchanged - while the use of turn is not shown. But turn is used, I know it because…
turn use can be looked at server side: see this post
Ah and beware also of established connections; before blocking port 10000 you have better to close a meeting and create a new one.
Neither of those is true. The 127.0.0.1 is reported here because my 60-jitsi-stream.conf is redirecting traffic from port 443 to 127.0.0.1:5349 on the server. The 172.31.14.16 address is the private IP of the EC2 server itself.
(P.S. I know that it’s better to use the public IP in 60-jitsi-stream.conf (nginx module) but I changed it as a cheap way of avoiding the public IP to be shown in that screenshot - both work the same)
I would say my internet connection is typical. I am not currently using any VPNs or proxies anymore, as I have confirmed the server works perfectly now using port 443, and so it works well for users with VPN/proxy. I am now just ensuring it works perfectly (using UDP:10000) for users that have less restricted connection. Before the TURN server setup it would work find over UDP:10000.
I am only choosing to close port 10000 to confirm that it is being used; if the video freezes then that tells me that port was being used for video. If the video doesn’t freeze, then it must be using a different route (i.e. 443 and the TURN server)
@emrah I also tried installing Jitsi on a Debian Buster server using your emrah-buster-templates. The instructions were great and it went very smoothly except for the instruction to create the certificates
Sorry, as you have confirmed it was a temporary DNS issue. The server isn’t working for me but that’s now probably my fault.
So @emrah to your knowledge, if I had run through your scripts correctly, do the servers created with your scripts correctly use UDP:10000 by default and then TCP:443 as a failover?
I can see that the meet.jit.si servers do this just by looking at the statistics. Here’s is a standard call:
… and here’s what I get when UDP:10000 is blocked in my local firewall:
It uses the TURN server in this case.
When using my own server it will always use the TURN server. There must be some further configuration that I need
After stopping the TURN service, there is no audio/video received in a three-way conversation, and I get the annoyingly familiar message “Bridge Channel send: no opened channel.” in the browser console.
Changing the sip-communicator.properties file fixed it! The server now appears to use UDP:10000 by default and TCP:443 as a failover! Well done and thank you for that fix.
Does this mean the service is now relying on meet-jit-si-turnrelay.jitsi.net:443 for some purpose? I have struggled to find out what STUN_MAPPING_HARVESTER_ADDRESSES actually is for. My scripts should have been replacing the whole meet-jit-si-turnrelay.jitsi.net domain with turn-jitsi-8a.jessian.io but instead were not replacing the whole value. Although even if I was doing that correcly, using this does not seem to work:
I mean if this service (provided by jitsi.net) was ever to be unavailable, would my Jitsi instance fail to coordinate communication between participants in a call? i.e. we are relying on the availability of jitsi.net? We currently provide jitsi servers as a video conferencing service on private networks where an outside connection to jtisi.net might not be available.
I am aware of the difference between STUN/TURN but my understanding was that coturn is a STUN and TURN server and therefore could be used for both?
