Coturn over websockets

After investing a lot of time trying to get the nginx ssl_preread to work as I want with other services I host (by using proxy_protocol to get the real remote ip in the application logging and making another map based on server name; but that’s a story for another time), I noticed in the latest config that this way will be deprecated and replaced by websocket. It had this link accompanying it:

Now I’ve done exactly what it states in the document but I still wonder:

  • does this only apply to ‘turns’ or is now everything (stun, turn and turns) routed through the websocket?
  • so this means I only need port 443 open, and not the turnservers 3478 and 5349?
  • as this is a application specific way, I cannot use to test stun, turn or turns?
  • If not, what is a easy way to to test these?

Thanks for your help. I like how this (future) change will make configuring jitsi less of a hard task when hosting other services as well.

Here is my understanding of it (not Jitsi dev here)

Websockets are replacing Sctp. Sctp means Stream Control Transmission Protocol (RFC 4960). Sctp is a reliable transport protocol operating on top of a connectionless packet network, as such it can be replaced by a web socket protocol (that is, something inherently based on TCP whose main characteristic is to be reliable)

To achieve best performance in all cases, the streams themselves (not the control of them) need to be transported by an unreliable protocol , that is, UDP. Browsers can’t support direct access to UDP, so UDP is supported through WebRTC. When nasty network people are blocking UDP, TCP has to be used, and here Coturn comes in action.

1 Like

Thanks for your response @gpatel-fr .
So (since I changed the configuration) in case you have a network where there is a application firewall that blocks uncommon ports and UDP you won’t be able to use jitsi anymore?
The multiplexing configuration was for these situations because ‘turns’ on 443 could be used to relay the steam, which couldn’t be blocked because it’s TLS traffic over a standard port.
I thought the new websocket was also used to relay media in this specific last resort case as a replacement for the multiplexing.

So, in conclusion:

  • I need to open ports 3478 and 5349
  • I lost TURN/TLS relay capability on 443

I know that the last point is normally quite rarely used, but in cases when someone is traveling and on hotel / airport WIFI it changes a lot. These networks block so much.

if I made this impression it’s bad because this is not correct.
I have connected to my jitsi-meet instance using only port 443 as I explained here. This is not the preferred way though, but you can see something more like it here. In both cases Coturn is advertised in prosody on port 443.

1 Like