This message was deleted.

cc @great-umbrella-58130

Hello, I can answer most of these. Let us know if you have more questions! 1. Correct, TURN/TLS can be load-balanced and it's irrelevant which livekit instance the user is connected to. You should configure your livekit server to use your load balancer for TURN/TLS here https://github.com/livekit/livekit/blob/master/config-sample.yaml#L249 2. TURN/UDP is embedded in livekit server, so you don't need to load balance it. 3. You can route initial websocket connections for signaling to different servers based on settings here: https://github.com/livekit/livekit/blob/master/config-sample.yaml#L264-L279. In OSS livekit rooms are single-home; this means that after a user is connected via websocket, their RTC connection will be routed to and served by the livekit server instance already hosting the room. If the room doesn't exist yet, it will be created on the server they are currently connected to.

@echoing-kitchen-90064 Thank you so much! That answers most of my questions! However, just to confirm - as I understand, it's recommended to configure the TURN/UDP port to be 443, to benefit from firewalls allowing HTTP3/QUIC targets, yes?

I have only used the default TURN/UDP port; but could potentially work if you're certain firewalls between your users will allow udp on 443? Maybe @flat-raincoat-62120 has some more info there.

I agree with that!

Why is TURN/UDP used at all? If TURN/UDP is not set to 443, why does it make sense to try TURN/UDP if ICE UDP (direct connection to Livekit SFU) fails?

TURN/UDP is useful when working with restrictive networks and is more performant than TURN/TCP. Standard RTC candidates will be over a wide range of ports which makes it difficult for whitelisting on corporate firewalls. However, it's much easier for them to whitelist a single port for TURN/UDP. If the network doesn't want to whitelist anything the last resort would be TURN/TLS on 443.