Fallback to TCP for WebRTC [FeatureRequest] about server HOT 8 CLOSED

Screego already exposes the TURN server via TCP. Tho the main use case is for serving it on port 443 to hide it as normal https traffic. This is not that easy possible because (probably) an external server is needed (1x Website on 443 & 1x TURN on 443 via tcp)

from server.

nice! so SCREEGO_TURN_ADDRESS=0.0.0.0:3478 is already UDP/TCP ready or is this a planned feature (since you referenced a commit which is behind current release)?

from server.

Yeah, it does already listen on tcp, but (I guess) WebRTC doesn't use TCP by default. The commit explicitly defines TCP as transport protocol (And fixes a bug in authentication).

from server.

Nice... would love to see an example for this. Is there an environment var which has to be set? How does the apache rev proxy config should look like?

from server.

This is kinda difficult to check, because WebRTC is responsible connection establishment. It will fallback to TCP if it can't establish a connection via udp. You could try to block (via firewall) the udp port (default 3478) and check if it still works.
The reverse proxy does only proxy http requests, the ICE is done via the embedded TURN server.

from server.

i run screego in an dockerized environment. Sadly, docker-compose does not respect the udp-only setting (docker/compose#7627), so I have to configure the host fw. Some reverse proxies are able to proxy tcp requests...

from server.

muy bueno

from server.

I do not think the fallback to tcp is working correctly, because i can not see that tcp requests on my Workstation. UDP is blocked via iptables on my WS and the screego server :-(

I know this is kind of hard to debug.

from server.