This message was deleted.
# helpdesk
s
This message was deleted.
c
re: the STUN issue, have you tried just explicitly specifying STUN servers in your config?
d
interesting use case with 1. previously it advertised both private and public IP as a side-effect; it was not intentional. I think @early-gigabyte-44411 improved upon that behavior in master, that's yet unreleased. I'm not sure if it'll advertise both private and public IPs at the same time. that said, your use case is an interesting one and I hope we'll be able to support TURN servers that can go through the private IP address. Could you file an issue in GH for this? 2. with forceRelay, a new change was merged yesterday that would honor client-side settings instead of overriding it. So I think this should do what you are looking for?
e
The server side switch transport to
relay
only if the direct connection is not stable. It will not change your setting if your client config is
relay
too. I’m not sure what is
more control
on it, if it is
all
, then it will contain
direct
and
relay
, so switch to
relay
automatically is ok since
direct
can’t establish or not stable.
f
@clever-motorcycle-90824 yes, but that does not make any diference, because the we do not go inside the else statement here: https://github.com/livekit/livekit/blob/master/pkg/rtc/config.go#L197
@dry-elephant-14928 as for 1., sure Im going to create one. As for 2: an easy fix could be to move this if statement: https://github.com/livekit/client-sdk-js/blob/08fcc156f9fb83eb3648e9db1ab10a50d1568bac/src/room/RTCEngine.ts#L263 inside the condition above because if I want to use my previously provided ice servers then probably I’d want to control the forceRelay flag as well, otherwise Livekit’s decision is acceptable. I have scenarios where I want to tell the client, it must use relay because of several reasons, not just because the webrtc connectivity.
@early-gigabyte-44411 I think my scenario is the opposite: I know that relay is more stable then public - because of the network setup. In a single cluster setup it does not make improvement, but with multiregion, world-wide rooms, TURN could be leveraged to have better connection than the direct connection.
d
@few-night-99427 if you are passing in forceRelay, it will be honored. are you saying you'd want to keep forceRelay to
off
? but for some reasons the server indicates it should be used?
1
e
It should not be override if you set policy to
relay
f
the point is that ice servers can be set from client and the client will not update it from the joinresponse - thanks to the
!rtcConfig.iceServers
condition, but there an opportunity, Livekit will set
iceTransportPolicy
to relay based on the ice servers Livekit knows, but I want to use other ice servers and may want other
iceTransportPolicy
. this is really minor thing, and for most use cases it will not ever be a thing, I am just saying that ice servers and
iceTransportPolicy
should have the same “lifecycle” - that’s why I wrote, if the forceRelay condition would be placed into to condition above, I think that would satisfies edge cases as well - once again, it is a very minor thing 🙂