-
-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: Why stunner gives the POD_IP as the RELAY candidate? #25
Comments
here is my configMap |
|
Hi imcom, First of all if you install stunner with helm the deployment will fallback to nodeport if there is no load balancer in your cluster. So, basically you just have to deploy it with helm. For the publicly visible POD_IP there is a small description in the [security doc].(/~https://github.com/l7mp/stunner/blob/main/doc/SECURITY.md) |
Hi @VidarHUN sorry for the late reply, but I still did not get it to work. I installed Metallb in my cluster so I have LoadBalancer service now. Here is my setup, it looks OK from my perspective
172.16.8.21 is the "public IP" I could use for TURN relay. However I am still getting this
Thanks in advance |
Oh, I get it, the relay candidate indeed should be the POD IP. Sorry for the confusion. Once I have a LoadBalancer in place, this is working smoothly! |
I am not sure though if stunner requires a LoadBalance service with Public IP to work. In my on-prem k8s there is no LB available. So instead I changed the gateway svc to be NodePort instead.
But then when I do ICE trickle, I got the POD_IP as the relay candidate hence WebRTC could not establish.
I also noticed that the stunner pod has this configuration
So what am I doing incorrectly here? I wanted to setup a headless stunner just act as TURN server for two media endpoints.
Thanks in advance
The text was updated successfully, but these errors were encountered: