Installing Conference Calling 2.0 (aka SFT)¶

Background¶

Please refer to the following section to better understand SFT and how it works.

As part of the wire-server umbrella chart¶

By default, sftd will be installed as part of the wire-server umbrella chart.

In your ./values/wire-server/values.yaml file you should set the following settings:

sftd:
  host: sftd.example.com # Replace example.com with your domain
  allowOrigin: webapp.example.com # Should be the address you used for the webapp deployment

In your secrets.yaml you should set the TLS keys for sftd domain:

sftd:
  tls:
    crt: |
      <TLS CRT HERE>
    key: |
      <TLS KEY HERE>

You should also make sure that you configure brig to know about the SFT server in your ./values/wire-server/values.yaml file:

brig:
  optSettings:
    setSftStaticUrl: "https://sftd.example.com:443"

Now you can deploy as usual:

helm upgrade wire-server wire/wire-server --values ./values/wire-server/values.yaml

Standalone¶

The SFT component is also shipped as a separate helm chart. Installation is similar to installing the charts as in Installing wire-server (production) components using Helm.

Some people might want to run SFT separately, because the deployment lifecycle for the SFT is a bit more intricate. For example, if you want to avoid dropping calls during an upgrade, you’d set the terminationGracePeriodSeconds of the SFT to a high number, to wait for calls to drain before updating to the new version (See technical documentation). that would cause your otherwise snappy upgrade of the wire-server chart to now take a long time, as it waits for all the SFT servers to drain. If this is a concern for you, we advice installing sftd as a separate chart.

It is important that you disable sftd in the wire-server umbrella chart, by setting this in your ./values/wire-server/values.yaml file

tags:
  sftd: false

By default sftd doesn’t need to set that many options, so we define them inline. However, you could of course also set these values in a values.yaml file.

SFT will deploy a Kubernetes Ingress on $SFTD_HOST. Make sure that the domain name $SFTD_HOST points to your ingress IP as set up in Installing wire-server (production) components using Helm. The SFT also needs to be made aware of the domain name of the webapp that you set up in Installing wire-server (production) components using Helm for setting up the appropriate CSP headers.

export SFTD_HOST=sftd.example.com
export WEBAPP_HOST=webapp.example.com

Now you can install the chart:

helm upgrade --install sftd wire/sftd --set
helm install sftd wire/sftd  \
  --set host=$SFTD_HOST \
  --set allowOrigin=https://$WEBAPP_HOST \
  --set-file tls.crt=/path/to/tls.crt \
  --set-file tls.key=/path/to/tls.key

You should also make sure that you configure brig to know about the SFT server, in the ./values/wire-server/values.yaml file:

brig:
  optSettings:
    setSftStaticUrl: "https://sftd.example.com:443"

And then roll-out the change to the wire-server chart

helm upgrade wire-server wire/wire-server --values ./values/wire-server/values.yaml

For more advanced setups please refer to the technical documentation.

Firewall rules¶

The SFT allocates media addresses in the 32768-61000 UDP range. Ingress and egress traffic should be allowed for this range. Furthermore the SFT needs to be able to reach the Restund server, as it uses STUN and TURN in cases the client can not directly connect to the SFT. In practise this means the SFT should allow ingress and egress traffic on the UDP port range 32768-61000 from and to both, clients and Restund servers.

The SFT also has an HTTP interface for initializing (allocation) or joining (signaling) a call. This is exposed through the ingress controller as an HTTPS service.

SFT does require access to the TURN control port during process startup, but does not use it for any real purpose. It is a health check, that is goung to be removed eventually.

An SFT instance does not communicate with other SFT instances, TURN does talk to TURN.

Recapitulation table:

Name	Origin	Destination	Direction	Protocol	Ports	Action (Policy)	Description
Denying all ingress	Any / none.	Here	Incoming	All	None	Deny	Deny anything incoming: by default nothing is allowed to come in, and we will individually allow specific ports below.
Allowing all egress	Here	Any	Outgoing	All	All	Allow	Allow everything outgoing, by default everything is allowed (all ports) in the outgoing direction.
Allowing HTTP(S) ingress	Any	Here	Incoming	TCP	sft_nginx_certbot_port, sft_nginx_sft_port, sft_nginx_metrics_port	Allow	Allow HTTP(S) access to three different (nginx) confiigured ports. This interface is for initializing (allocation) or joining (signaling) a call.
Allowing SSH ingress	Any	Here	Incoming	TCP	22 (SSH)	Allow	Allow Secure Shell Protocol access for administration.
Allowing SFT media ingress	Any	Here	Incoming	UDP	32768-61000	Allow	Allow ports in the “Ephemeral range” (https://en.wikipedia.org/wiki/Ephemeral_port), defined by the Linux Kernel ass the range from ports 32768 to 61000, used for UDP transmission of media.
Allowing SFT media egress	Here	Anny	Outgoing	UDP	32768-61000	Allow

For more information, please refer to the source code of the Ansible role: sft-server.