JITSI HELM deployed on managed K8S but UDP is blocked.....So JVB to work on TCP

[iasbm]

Hello, Thanks for awesome work on JITSI helm charts. We used this and successfully deployed JITSI on Managed K8S Cluster but we noticed issues with conference as follows...

Scenario-1 --> Step-1. Started Conference with 2 participants Person1 and Person-2. Step-2 Both can see and hear each other . Step-3 Now Person-1 started Recording both participants lost Videos and Audio. Step-4 Person-1 stopped recording. So the result is that conference is back to normal and both the participants have their media and can see and hear each other

So in this scenario its clear with 2 participants that when we start Recording Media is lost for both participants

Scenario-2 --> Started conference as Person-1 and 2 other participants joined. So total 3 participants. No media (Video, Audio) at all for all 3participatns even without attempting Recording.

we have done a lot of research on this and finally we raised a Support Ticket to our Cloud Provider and here is their response

Thanks for reaching us. Our managed K8s Load Balancer service doesn't accept UDP connections, but only TCP. Could you please change the protocol and see if it works?

So is there any way to make JVB work on TCP? For this i understand that we need to enable TURN server but, i don't seem to find any necessary config vars in the HELM chart. ANy suggestion would be helpful pls.

[spijet]

Hello @iasbm! Sorry for the late reply. Current versions of JVB require UDP support, as "native" TCP transport was removed from JVB quite a while ago. In your case, the possible options are:

1. Try using NodePort services instead of LoadBalancer ones, if your K8s provider supports it. This is what I'd recommend trying first;
2. Use a TURN server. This chart does not support TURN yet, but you can configure a TURN server separately and point your Jitsi installation to it;
3. Try to use an older Jitsi Meet version that doesn't have TCP transport removed yet. This might work, but may also lead to some problems, depending on the clients used.

[humble92]

The same problem I've had. What I found here is that the udp port is unstable. Sometimes the port seems not open while some changes in jvb are being updated in values yaml, but it is not consistent.

The followings are the command and response sent within cluster:

I have no name!@utilities-f4b5c6954-cnnc7:/$ nc -vz -u 10.244.0.156 10000
I have no name!@utilities-f4b5c6954-cnnc7:/$ nc -vz -u 10.244.0.156 31316
I have no name!@utilities-f4b5c6954-cnnc7:/$ nc -vz -u 10.244.0.156 10000
Connection to 10.244.0.156 10000 port [udp/*] succeeded!
I have no name!@utilities-f4b5c6954-cnnc7:/$ nc -vz -u 10.244.0.156 10000
Connection to 10.244.0.156 10000 port [udp/*] succeeded!
I have no name!@utilities-f4b5c6954-cnnc7:/$ nc -vz -u 10.244.0.156 10000
Connection to 10.244.0.156 10000 port [udp/*] succeeded!

[spijet]

Hello @humble92!

It seems to be a different problem, as you're trying to reach the JVB from inside the pod (AFAICT). It may (or may not) be caused by JVB itself. Also, port 31316 looks like something from a NodePort range. If you've set .jvb.nodePort in your values.yaml, it should only be reachable on your clusters' node IPs, not on the JVB pod IP (the pod will still use the port specified by .jvb.UDPPort).

[humble92]

Oh, sorry for the confusing. 31316 is just try for test, and what I want to say was these 2 commands' difference.

I have no name!@utilities-f4b5c6954-cnnc7:/$ nc -vz -u 10.244.0.156 10000
I have no name!@utilities-f4b5c6954-cnnc7:/$ nc -vz -u 10.244.0.156 10000
Connection to 10.244.0.156 10000 port [udp/*] succeeded!

Try using NodePort services instead of LoadBalancer ones

For me, when LoadBalancer is chosen and tried, jvb is still not working correctly. With LoadBalancer type., the following settings are not working.

  livenessProbe:
    httpGet:
      path: /about/health
      port: 8080
  readinessProbe:
    httpGet:
      path: /about/health
      port: 8080

It is because I can see the error about TCP health check related. In my case the provider is Digital Ocean.

Error syncing load balancer: failed to ensure load balancer: failed to build load-balancer request: no health check port of protocol TCP found

So, it brought me some questions in succession. Do we need some extra setup for JVB udp requests not explictly mentioned in README.md? I have tried w/ some ingress settings, but it is still not working.

[humble92]

In doc\jitsi-helm\templates\jvb\service.yaml, it seems that the following linea are required according to docs:

I am not sure whether it is only required in Digital Ocean only, or whether there are no side effects in other cloud providers. But, at least in DO, it works w/ the following additional lines in service.yaml.

    - port: {{ default 8080 .Values.jvb.livenessProbe.httpGet.port }}
      protocol: TCP
      name: tcp

[spijet]

I haven't used a setup like this before, so I'm not sure. It depends on how exactly does this check happen — if it's the external LoadBalancer that performs the check, then it might actually be required to add an additional TCP port to the service, but that would also mean that this TCP port gets opened for the wide world, which is not a good thing. Maybe it'd be safe to do if you add a NetworkPolicy on top, so it allows incoming connections to the TCP port only if the source address is from the LoadBalancer source IP pool.

[spijet]

Hello @humble92!

I opened #113 to track the issue you have with DigitalOcean LoadBalancer. I'm going to close this issue now, because we haven't heard from @iasbm for a while.