When deploying Jitsi Meet with a TURN server, would the TURN server (on behalf of a conference participant / the JVB) ever directly communication with another conference participant or would the TURN server always / typically contact the JVB only?
My understanding is that the use case for TURN is traversal of restrictive gateways. As such, a participant behind such a gateway would connect to the TURN server and the TURN server would initiate the communication that would usually be handled by the participant itself (if he wasn’t behind such a restrictive gateway).
Unless this is a p2p conference (two participants only with p2p enabled) - the TURN server would always be talking to the JVB, no?
If it was a p2p conference, would the TURN server try to contact the other peer - if yes using which protocol (UDP, TCP - probably only to ports higher than 1024?) or does that also depend on how the other participant is connected?
I wasn’t implying that the TURN server knows about the type of peer, but only wanted know how the TURN Server would be used by Jitsi.
As DTLS would also be UDP, it should be possible to safely disable tcp-relay on TURN server, right?
Any ideas about the typically used ports ranges (by Jitsi)? RFC 5766 states 49152 - 65535, but I suppose a NAT device in between may change the source port, so that 1024 - 65535 may be safer when using min/max ports in TURN server ACLs.
Yep, all media going out of webrtc is encrypted. The turns add another layer of encryption to ensure the link looks like a regular https link so it can be used in environments where only those links are accessible.
Disabling TCP on the TURN server does mean that some clients in restrictive networks will be unable to connect unless they get their network administrator to permit the traffic. Especially some corporate firewalls will lock down everything except tcp/443. Quality is impaired with TCP but it’s better than no connectivity at all.
AFAIK “--no-tcp” or “no-tcp-relay” do not break communication over TCP/443. These are always set in my setups and clients can connect to JVB over TURNS (which is proxied behind Nginx via TCP/443) when UDP/10000 is not permitted.
I think it should work since “--no-tls” or “--no-dtls” is not set.
Do you mean something else or are there some other cases which fail when “--no-tcp” or “no-tcp-relay” is set?
Ah yes, I forgot that tls (i.e., not specifying no-tls) implies opening the TCP listening sockets. And absolutely, if the TURN server’s TLS listening port is proxied behind something that listens on tcp/443 then that should be fine. For standalone TURN servers (e.g. when you don’t want all the TURN traffic to be funneled through nginx or you don’t have nginx at all) the config linked above will need to be tweaked.