This message was deleted.

Here are some good resources on why and how to use TURN: • https://docs.livekit.io/realtime/self-hosting/deployment/#improving-connectivity-with-turn • https://bloggeek.me/webrtc-turn/

Is a TURN server needed if the connection already exists?

@enough-boots-69343 TURN is another tool in the toolbox. It’s mainly used if other NAT methods don’t work in establishing connectivity between two users.

@magnificent-art-43333 Can TURN fix packet loss or image distortion during a call?

Not generically or directly (cc @fancy-wire-61616 in case he has more thoughts) — it may provide an alternate network path which has lower packet loss.

Yeah, that is correct. There is nothing in the protocol that will fix packet loss/image distortion because of use of TURN. TURN is useful when direct routes are block, for example, corporate firewalls might block all UDP except for one port which is advertised by TURN server.

@fancy-wire-61616 You're saying there's no solution to packet loss, right?

Yeah, that is not a solution to packet loss.

Complaints from viewers are as follows; While some broadcasters' images are good, some broadcasters' images are of such poor quality that it is almost impossible to distinguish their faces.

It is potentially congestion control. That could mean problem in either direction. If up stream is congested, clients will lower bit rate to fit in channel. If down stream to the subscriber is congested, SFU will adjust simulcast layer it forwards so that the channel is not overloaded.

What could be the causes of congestion? I am using Kubernetes helm.

It could be any time. It is a network and it could congest. If you are cell phones and using data connection, that is high chance. WiFi interference can cause it. There are several places it can happen. That's why the system adapts to channel conditions.

For broadcasters and viewers in different places, for example 20 broadcasters, the picture is clear, but 10 broadcasters have a very bad picture and this problem lasts for an average of 10 minutes, not short-term. Can we still say the problem is congestion? Is it normal for the congestion to last for a long time?

If it is reproducible exactly like that, I would say it is not congestion. It is possibly something else. Don't know what that could be without seeing more details of the session. But, if it is not consistent, it is possible for congestion to last a while. Especially, if you are using cellular data and if the signal strength is low, it could be on very low bandwidth and that could last for long time.

I have a system with 1 master and 20 nodes. Publishers broadcast to a domain connected to the master. Are the packets sent to the relevant node via the master? if so, can we say that there may be network congestion between master and node?

Not able to understand what you meant by that configuration. But, guessing that if all publishers are connected to one server, would be good to check the network capacity of that server.

I'm using livekit-helm and replicaCount: is set to 21. Currently, livekit is running in pods on all 21 servers. In this system, all broadcasters and viewers connect to the master server connected to wss://mydomain.com. As far as I know, when a broadcast is opened, the master server forwards the broadcaster to an appropriate pod. My question is: if the broadcast comes to the master server and is transmitted from there to the node, with some kind of proxy logic, then when the load increases, there may be congestion between the master and the node and there may be disruptions in the broadcast. Does this structure work like this or does the publisher send the image directly to the node?

All your publishers and viewers will be in the same room. So, they will all connect to one media node directly. In the OSS version of server, all participants in the room will have to connect to the same media node. Once a media node is assigned for a room, all the publishers and viewers will be sending/receiving media from that media node. So, if your media node has less capacity (could be CPU or network bandwidth), it is possible that the server cannot handle that many participants.

Yes that is right. Well, if everyone is not in the same room and there are 20 broadcasters with 5 viewers for each broadcaster, and each broadcaster is in a node, does the viewer receive the image from the node through the master or directly through the node? What I'm trying to learn is, does the data transfer between the node and the viewer occur through the master or directly through the node?

Sorry about the confusion. Just to align on terminology I think what you are referring to as

master

is what we call

controller

or

signalling server

. There is nothing like

master

in the system. So, when a client connects to a room in your domain, the

controller

will do either • If the

room

does not exist already, it will find a

media node

based on some rules (by default it picks the least loaded

media node

) and start the

room

on that node. • If the

room

already exists, the

media node

on which the room is running will be used. The

controller

then sends reply back to the clients to connect directly to a

media node

for media exchange. You are referring to that as just

node

. Calling it

media node

makes things clear in my head 🙂 . Once the clients have the

media node

information, they directly connect to the

media node

and exchange media. The

controller

(or

master

) is not involved in the media path. If each of your room has 20 publishers and 5 viewers, that is still • 20 audio streams published to that

media node

• 20 video stream published. • if the publishers are also viewers, that is 20 * 19 = 380 audio + 380 video streams consumed by the publishers. • In addition, five viewers will consume 20 * 5 = 100 audio streams + 100 video streams. So, it is possible that the

media node

processing all this traffic is not sized correctly to handle that much traffic.

what I mean by master is controller yes my fault 🙂 You answered exactly what I wanted to know. Thank you for your support 🙂