Mattermost helm version - Calls plugin

Summary
We can’t get the Call plugins to work on mattermost helm chart

Steps to reproduce
Enable the Call plugin in the System Console > PLUGINS > Calls
We tried both UDP and TCP ports 8443 and 443

Expected behavior
To have the calls plugin working without adding a rtcd server.

Observed behavior
Calls are available but impossible to join

Does someone has an example of working Calls plugin on a K8S/helm deployment?
What did you do?

Thank you!

Our values:

affinity: {}
config:
  MM_PLUGINSETTINGS_CLIENTDIRECTORY: ./client/plugins
deploymentStrategy:
  rollingUpdate: null
  type: RollingUpdate
externalDB:
  enabled: false
  externalConnectionString: ''
  externalDriverType: ''
extraDeploy: []
extraEnvVars: []
extraInitContainers: []
extraPodAnnotations: {}
extraPorts: []
extraVolumeMounts: []
extraVolumes: []
image:
  imagePullPolicy: IfNotPresent
  repository: mattermost/mattermost-team-edition
  tag: >-
    9.7.1@sha256:0d0ed3b351a54ecf10f1e8e24edf6bf2ff4cb796a6a7694c49141559ce6cf68b
ingress:
  annotations:
    cert-manager.io/cluster-issuer: keycloak-letsencrypt-prod
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/proxy-buffer-size: 16k
    nginx.ingress.kubernetes.io/proxy-read-timeout: '3600'
    nginx.ingress.kubernetes.io/proxy-send-timeout: '3600'
    nginx.ingress.kubernetes.io/server-snippets: |
      location ~ /api/v[0-9]+/(users/)?websocket$ {
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       client_max_body_size 50M;
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_buffers 256 16k;
       proxy_buffer_size 16k;
       client_body_timeout 60;
       send_timeout 300;
       lingering_timeout 5;
       proxy_connect_timeout 90;
       proxy_send_timeout 300;
       proxy_read_timeout 90s;
       proxy_http_version 1.1;
       proxy_pass http://mattermost-team-edition.mattermost.svc.cluster.local:8065;
      }
  className: ''
  enabled: true
  hosts:
    - mattermost.******************************.net
  path: /
  tls:
    - hosts:
        - mattermost.******************************.net
      secretName: mattermost.******************************.net-tls
initContainerImage:
  imagePullPolicy: IfNotPresent
  repository: appropriate/curl
  tag: latest
livenessProbe:
  failureThreshold: 3
  initialDelaySeconds: 1
  periodSeconds: 10
  timeoutSeconds: 5
mysql:
  enabled: true
  imageTag: 8.0.18
  mysqlDatabase: mattermost
  mysqlPassword: ******************************
  mysqlRootPassword: ******************************
  mysqlUser: mattermost
  persistence:
    accessMode: ReadWriteOnce
    enabled: true
    size: 20Gi
    storageClass: ''
  repository: mysql
  testFramework:
    enabled: false
nodeSelector: {}
persistence:
  data:
    accessMode: ReadWriteOnce
    enabled: true
    size: 20Gi
  plugins:
    accessMode: ReadWriteOnce
    enabled: true
    size: 1Gi
readinessProbe:
  failureThreshold: 3
  initialDelaySeconds: 15
  periodSeconds: 10
  timeoutSeconds: 5
revisionHistoryLimit: 1
route:
  enabled: false
securityContext: null
service:
  annotations: {}
  externalPort: 8065
  internalPort: 8065
  loadBalancerSourceRanges: []
  type: ClusterIP
serviceAccount:
  annotations: {}
  create: false
  name: null
startupProbe:
  failureThreshold: 30
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 5
testJob:
  annotations: {}
tolerations: []

We simply enabled calls within the Console interface.

Thank you!

Have you seen Calls self-hosted deployment - Mattermost documentation ?

Calls requires end-to-end connectivity… anything in between (firewalls, load balancers, security groups, ingress/egress rules, anything that affects the network)

Start with the simplest config possible, a test client on the same VLAN as the Mattermost server. Get that working, then extend out. kubernetes networking is no joke… by default, having traffic going through a route or service means there’s “something” between the client and server.

Calls plugin is not working in EKS - AWS Kubernetes Service - #3 by avinash might help