TURN communication - only towards JVB or also to participant?

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?

TURN server has no idea about the type of other peer. It only tries to transfer packages between peers. This peer may a client or JVB.

Yes, the other peer is always JVB in this case.

AFAIK, DTLS for source-TURN and UDP for TURN-destination

1 Like

Thanks for quick reply.

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.

Yes, it is disabled by default for latest Jitsi versions.

1 Like

Regarding DTLS, only way to get udp to work is with turn: and not turns:

Is DTLS on a lower level?

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.

1 Like