Can UDP:10000 and TCP:443 *both* be used?

Install & Config
#1

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?

Many thanks for any insight.

#2

UDP/10000 is only for audio/video packets. TCP/443 is required mainly for UI, websocket, signaling etc

TURN is required when the clients cannot connect to each others or to JVB directly.

jitsi-buster-installer

#3

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?

#4

only use TCP:443 as a failover to access JVB’s UDP/10000

#5

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:
image
… 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?

#6

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.

#7

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)

#8

@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, false alarm… temporary DNS issue.

#9

This error message mean that certbot (Lets Encrypt agent) cannot resolv the Lets Encrypt IP because of the temporary DNS problem.

Try the same command (with 2 domain) again

#10

Could you send me the dump as a private message?

1 Like
#11

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:
image
… and here’s what I get when UDP:10000 is blocked in my local firewall:
image
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 :frowning:

#12

Yes, this is the defaut behaviour.

Did you test your client side if it can connect to the server through UDP/10000. There may be a client side issue too

If you can send me your host address as a private message, I can test your server from my side

#13

Thanks so much for your generous offer. DM has been sent. I will post back to this thread when I have a solution.

#14

I tested it, the same result for me too. Always use TURN

  • Can you paste your /etc/jitsi/videobridge/sip-communicator.properties

  • Are the IP addresses the same for both?

host your-host-fqdn
curl ifconfig.me
  • Can you create a meeting with 3 participants when you stop the coturn service? Don’t forget to check audio/video
systemctl stop coturn
#15

Hi Emrah, thanks for having a look. I have created a ZIP file of the configuration files. I cannot attach a ZIP file, so here’s a link…

The domains all have the same IP:
ubuntu@ip-172-31-4-21:~ host jitsi-8a.jessian.io* *jitsi-8a.jessian.io has address 18.133.44.98* *ubuntu@ip-172-31-4-21:~ host jitsi-8b.jessian.io
jitsi-8b.jessian.io has address 18.133.44.98
ubuntu@ip-172-31-4-21:~$ host turn-jitsi-8a.jessian.io
turn-jitsi-8a.jessian.io has address 18.133.44.98

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.

#16

this output?

#17

Change STUN_MAPPING_HARVESTER_ADDRESSES in your sip-communicator.properties. Try the following one

org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
#18

The curl command has the same result

ubuntu@ip-172-31-4-21:~$ curl ifconfig.me
18.133.44.98

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:

org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=turn-jitsi-8a.jessian.io:443

But I am delighted that your suggestion does work. Thank you so much for that.

#19

No, this is STUN service, not TURN…

JVB asks for its remote IP to this service and it promotes the replied IP address.

Continue to use your own turn server, STUN and TURN are not the same thing

#20

Thanks again for your responses.

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?