docs(livekit): document nginx websockets too

Signed-off-by: rooot <hey@rooot.gay>

.typos.toml

@@ -24,3 +24,5 @@ extend-ignore-re = [
 "continuwity" = "continuwuity"
 "execuse" = "execuse"
 "oltp" = "OTLP"
+
+rememvering = "remembering"

docs/_meta.json

@@ -15,9 +15,9 @@
         "label": "Deploying"
     },
     {
-        "type": "file",
-        "name": "turn",
-        "label": "TURN"
+        "type": "dir",
+        "name": "calls",
+        "label": "Calls"
     },
     {
         "type": "file",

docs/_nav.json

@@ -2,7 +2,7 @@
     {
         "text": "Guide",
         "link": "/introduction",
-        "activeMatch": "^/(introduction|configuration|deploying|turn|appservices|maintenance|troubleshooting)"
+        "activeMatch": "^/(introduction|configuration|deploying|calls|appservices|maintenance|troubleshooting)"
     },
     {
         "text": "Development",

docs/calls.mdx

@@ -0,0 +1,13 @@
+# Calls
+
+Matrix supports two types of calls:
+
+- Element Call powered by [MatrixRTC](https://half-shot.github.io/msc-crafter/#msc/4143) and [LiveKit](https://github.com/livekit/livekit)
+- Legacy calls, sometimes using Jitsi
+
+Both types of calls are supported by different sets of clients, but most clients are moving towards MatrixRTC / Element Call.
+
+For either one to work correctly, you have to do some additional setup.
+
+- For legacy calls to work, you need to set up a TURN/STUN server. [Read the TURN guide for tips on how to set up coturn](./calls/turn.mdx)
+- For MatrixRTC / Element Call to work, you have to set up the LiveKit backend (foci). LiveKit also uses TURN/STUN to increase reliability, so you might want to configure your TURN server first. [Read the LiveKit guide](./calls/livekit.mdx)

docs/calls/_meta.json

@@ -0,0 +1,12 @@
+[
+    {
+        "type": "file",
+        "name": "turn",
+        "label": "TURN"
+    },
+    {
+        "type": "file",
+        "name": "livekit",
+        "label": "MatrixRTC / LiveKit"
+    }
+]

docs/calls/livekit.mdx

@@ -0,0 +1,269 @@
+# Matrix RTC/Element Call Setup
+
+:::info
+This guide assumes that you are using docker compose for deployment. LiveKit only provides Docker images.
+:::
+
+## Instructions
+
+### 1. Domain
+
+LiveKit should live on its own domain or subdomain. In this guide we use `livekit.example.com` - this should be replaced with a domain you control.
+
+Make sure the DNS record for the (sub)domain you plan to use is pointed to your server.
+
+### 2. Services
+
+Using LiveKit with Matrix requires two services - Livekit itself, and a service (`lk-jwt-service`) that grants Matrix users permission to connect to it.
+
+You must generate a key and secret to allow the Matrix service to authenticate with LiveKit. `LK_MATRIX_KEY` should be around 20 random characters, and `LK_MATRIX_SECRET` should be around 64. Remember to replace these with the actual values!
+
+:::tip Generating the secrets
+LiveKit provides a utility to generate secure random keys
+```bash
+docker run --rm livekit/livekit-server:latest generate-keys
+```
+:::
+
+```yaml
+services:
+  lk-jwt-service:
+    image: ghcr.io/element-hq/lk-jwt-service:latest
+    container_name: lk-jwt-service
+    environment:
+      - LIVEKIT_JWT_BIND=:8081
+      - LIVEKIT_URL=wss://livekit.example.com
+      - LIVEKIT_KEY=LK_MATRIX_KEY
+      - LIVEKIT_SECRET=LK_MATRIX_SECRET
+      - LIVEKIT_FULL_ACCESS_HOMESERVERS=example.com
+    restart: unless-stopped
+    ports:
+      - "8081:8081"
+
+  livekit:
+    image: livekit/livekit-server:latest
+    container_name: livekit
+    command: --config /etc/livekit.yaml
+    restart: unless-stopped
+    volumes:
+      - ./livekit.yaml:/etc/livekit.yaml:ro
+    network_mode: "host" # /!\ LiveKit binds to all addresses by default.
+    # Make sure port 7880 is blocked by your firewall to prevent access bypassing your reverse proxy
+    # Alternatively, uncomment the lines below and comment `network_mode: "host"` above to specify port mappings.
+#    ports:
+#      - "127.0.0.1:7880:7880/tcp"
+#      - "7881:7881/tcp"
+#      - "50100-50200:50100-50200/udp"
+```
+
+Next, we need to configure LiveKit. In the same directory, create `livekit.yaml` with the following content - remembering to replace `LK_MATRIX_KEY` and `LK_MATRIX_SECRET` with the values you generated:
+
+```yaml
+port: 7880
+bind_addresses:
+  - ""
+rtc:
+  tcp_port: 7881
+  port_range_start: 50100
+  port_range_end: 50200
+  use_external_ip: true
+  enable_loopback_candidate: false
+keys:
+  LK_MATRIX_KEY: LK_MATRIX_SECRET
+```
+
+#### Firewall hints
+
+You will need to allow ports `7881/tcp` and `50100:50200/udp` through your firewall. If you use UFW, the commands are: `ufw allow 7881/tcp` and `ufw allow 50100:50200/udp`.
+
+### 3. Telling clients where to find LiveKit
+
+To tell clients where to find LiveKit, you need to add the address of your `lk-jwt-service` to your client .well-known file. To do so, in the config section `global.well-known`, add (or modify) the option `rtc_focus_server_urls`.
+
+The variable should be a list of servers serving as MatrixRTC endpoints to serve in the well-known file to the client.
+
+```toml
+rtc_focus_server_urls = [
+    { type = "livekit", livekit_service_url = "https://livekit.example.com" },
+]
+```
+
+Remember to replace the URL with the address you are deploying your instance of lk-jwt-service to.
+
+#### Serving .well-known manually
+
+If you don't let Continuwuity serve your `.well-known` files, you need to add the following lines to your `.well-known/matrix/client` file, remembering to replace the URL with your own `lk-jwt-service` deployment:
+
+```json
+  "org.matrix.msc4143.rtc_foci": [
+    {
+      "type": "livekit",
+      "livekit_service_url": "https://livekit.example.com"
+    }
+  ]
+```
+
+The final file should look something like this:
+
+```json
+{
+  "m.homeserver": {
+    "base_url":"https://matrix.example.com"
+  },
+  "org.matrix.msc4143.rtc_foci": [
+    {
+      "type": "livekit",
+      "livekit_service_url": "https://livekit.example.com"
+    }
+  ]
+}
+```
+
+### 4. Configure your Reverse Proxy
+
+Reverse proxies can be configured in many different ways - so we can't provide a step by step for this.
+
+By default, all routes should be forwarded to Livekit with the exception of the following path prefixes, which should be forwarded to the JWT/Authentication service:
+
+- `/sfu/get`
+- `/healthz`
+- `/get_token`
+
+<details>
+    <summary>Example caddy config</summary>
+    ```
+    matrix-rtc.example.com {
+
+        # for lk-jwt-service
+        @lk-jwt-service path /sfu/get* /healthz* /get_token*
+        route @lk-jwt-service {
+            reverse_proxy 127.0.0.1:8081
+        }
+
+        # for livekit
+        reverse_proxy 127.0.0.1:7880
+    }
+    ```
+</details>
+
+<details>
+    <summary>Example nginx config</summary>
+    ```
+    server {
+        server_name matrix-rtc.example.com;
+
+        # for lk-jwt-service
+        location ~ ^/(sfu/get|healthz|get_token) {
+            proxy_pass http://127.0.0.1:8081$request_uri;
+            proxy_set_header X-Forwarded-For $remote_addr;
+            proxy_set_header X-Real-IP $remote_addr;
+            proxy_set_header Host $http_host;
+            proxy_buffering off;  
+        }
+
+        # for livekit
+        location / {
+            proxy_pass http://127.0.0.1:7880$request_uri;
+            proxy_set_header X-Forwarded-For $remote_addr;
+            proxy_set_header X-Real-IP $remote_addr;
+            proxy_set_header Host $http_host;
+            proxy_buffering off;
+
+            # websocket
+            proxy_http_version 1.1;
+            proxy_set_header Upgrade $http_upgrade;
+            proxy_set_header Connection $connection_upgrade;
+        }
+    }
+    ```
+
+    Note that for websockets to work, you need to have this somewhere outside your server block:
+    ```
+    map $http_upgrade $connection_upgrade {
+        default upgrade;
+        ''      close;
+    }
+    ```
+</details>
+
+<details>
+    <summary>Example traefik router</summary>
+    ```
+    # on LiveKit itself
+    traefik.http.routers.livekit.rule=Host(`livekit.example.com`)
+    # on the JWT service
+    traefik.http.routers.livekit-jwt.rule=Host(`livekit.example.com`) && (PathPrefix(`/sfu/get`) || PathPrefix(`/healthz`) || PathPrefix(`/get_token`))
+    ```
+</details>
+
+
+### 6. Start Everything
+
+Start up the services using your usual method - for example `docker compose up -d`.
+
+## Additional Configuration
+
+### TURN Integration
+
+If you've already set up coturn, there may be a port clash between the two services. To fix this, make sure the `min-port` and `max-port` for coturn so it doesn't overlap with LiveKit's range:
+
+```ini
+min-port=50201
+max-port=65535
+```
+
+To improve LiveKit's reliability, you can configure it to use your coturn server.
+
+Generate a long random secret for LiveKit, and add it to your coturn config under the `static-auth-secret` option. You can add as many secrets as you want - so set a different one for each thing using your TURN server.
+
+Then configure livekit, making sure to replace `COTURN_SECRET`:
+
+```yaml
+# livekit.yaml
+rtc:
+  turn_servers:
+    - host: coturn.ellis.link
+      port: 3478
+      protocol: tcp
+      secret: "COTURN_SECRET"
+    - host: coturn.ellis.link
+      port: 5349
+      protocol: tls # Only if you've set up TLS in your coturn
+      secret: "COTURN_SECRET"
+    - host: coturn.ellis.link
+      port: 3478
+      protocol: udp
+      secret: "COTURN_SECRET"
+```
+
+## LiveKit's built in TURN server
+
+Livekit includes a built in TURN server which can be used in place of an external option. This TURN server will only work with Livekit, so you can't use it for legacy Matrix calling - or anything else.
+
+If you don't want to set up a separate TURN server, you can enable this with the following changes:
+
+```yaml
+### add this to livekit.yaml ###
+turn:
+  enabled: true
+  udp_port: 3478
+  relay_range_start: 50300
+  relay_range_end: 50400
+  domain: matrix-rtc.example.com
+```
+
+```yaml
+### Add these to docker-compose ###
+- "3478:3478/udp"
+- "50300-50400:50300-50400/udp"
+```
+
+### Related Documentation
+
+- [LiveKit GitHub](https://github.com/livekit/livekit)
+- [LiveKit Connection Tester](https://livekit.io/connection-test) - use with the token returned by `/sfu/get` or `/get_token`
+- [MatrixRTC proposal](https://half-shot.github.io/msc-crafter/#msc/4143)
+- [Synapse documentation](https://github.com/element-hq/element-call/blob/livekit/docs/self-hosting.md)
+- [Community guide](https://tomfos.tr/matrix/livekit/)
+- [Community guide](https://blog.kimiblock.top/2024/12/24/hosting-element-call/)
+-

docs/calls/turn.mdx

@@ -0,0 +1,214 @@
+# Setting up TURN/STUN
+
+[TURN](https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT) and [STUN](https://en.wikipedia.org/wiki/STUN) are used as a component in many calling systems. Matrix uses them directly for legacy calls and indirectly for MatrixRTC via Livekit.
+
+Continuwuity recommends using [Coturn](https://github.com/coturn/coturn) as your TURN/STUN server, which is available as a Docker image or a distro package.
+
+## Installing Coturn
+
+### Configuration
+
+Create a configuration file called `coturn.conf` containing:
+
+```ini
+use-auth-secret
+static-auth-secret=<a secret key>
+realm=<your server domain>
+```
+
+:::tip Generating a secure secret
+A common way to generate a suitable alphanumeric secret key is by using:
+```bash
+pwgen -s 64 1
+```
+:::
+
+#### Port Configuration
+
+By default, coturn uses the following ports:
+- `3478` (UDP/TCP): Standard TURN/STUN port
+- `5349` (UDP/TCP): TURN/STUN over TLS
+- `49152-65535` (UDP): Media relay ports
+
+If you're also running LiveKit, you'll need to avoid port conflicts. Configure non-overlapping port ranges:
+
+```ini
+# In coturn.conf
+min-port=50201
+max-port=65535
+```
+
+This leaves ports `50100-50200` available for LiveKit's default configuration.
+
+### Running with Docker
+
+Run the [Coturn](https://hub.docker.com/r/coturn/coturn) image using:
+
+```bash
+docker run -d --network=host \
+  -v $(pwd)/coturn.conf:/etc/coturn/turnserver.conf \
+  coturn/coturn
+```
+
+### Running with Docker Compose
+
+Create a `docker-compose.yml` file and run `docker compose up -d`:
+
+```yaml
+version: '3'
+services:
+  turn:
+    container_name: coturn-server
+    image: docker.io/coturn/coturn
+    restart: unless-stopped
+    network_mode: "host"
+    volumes:
+      - ./coturn.conf:/etc/coturn/turnserver.conf
+```
+
+:::info Why host networking?
+Coturn uses host networking mode because it needs to bind to multiple ports and work with various network protocols. Using host networking is better for performance, and reduces configuration complexity. To understand alternative configuration options, visit [Coturn's Docker documentation](https://github.com/coturn/coturn/blob/master/docker/coturn/README.md).
+:::
+
+### Security Recommendations
+
+For security best practices, see Synapse's [Coturn documentation](https://element-hq.github.io/synapse/latest/turn-howto.html), which includes important firewall and access control recommendations.
+
+## Configuring Continuwuity
+
+Once your TURN server is running, configure Continuwuity to provide credentials to clients. Add the following to your Continuwuity configuration file:
+
+### Shared Secret Authentication (Recommended)
+
+This is the most secure method and generates time-limited credentials automatically:
+
+```toml
+# TURN URIs that clients should connect to
+turn_uris = [
+    "turn:coturn.example.com?transport=udp",
+    "turn:coturn.example.com?transport=tcp",
+    "turns:coturn.example.com?transport=udp",
+    "turns:coturn.example.com?transport=tcp"
+]
+
+# Shared secret for generating credentials (must match coturn's static-auth-secret)
+turn_secret = "<your coturn static-auth-secret>"
+
+# Optional: Read secret from a file instead (takes priority over turn_secret)
+# turn_secret_file = "/etc/continuwuity/.turn_secret"
+
+# TTL for generated credentials in seconds (default: 86400 = 24 hours)
+turn_ttl = 86400
+```
+
+:::tip Using TLS
+The `turns:` URI prefix instructs clients to connect to TURN over TLS, which is highly recommended for security. Make sure you've configured TLS in your coturn server first.
+:::
+
+### Static Credentials (Alternative)
+
+If you prefer static username/password credentials instead of shared secrets:
+
+```toml
+turn_uris = [
+    "turn:coturn.example.com?transport=udp",
+    "turn:coturn.example.com?transport=tcp"
+]
+
+turn_username = "your_username"
+turn_password = "your_password"
+```
+
+:::warning
+Static credentials are less secure than shared secrets because they don't expire and must be configured in coturn separately. It is strongly advised you use shared secret authentication.
+:::
+
+### Guest Access
+
+By default, TURN credentials require client authentication. To allow unauthenticated access:
+
+```toml
+turn_allow_guests = true
+```
+
+:::caution
+This is not recommended as it allows unauthenticated users to access your TURN server, potentially enabling abuse by bots. All major Matrix clients that support legacy calls *also* support authenticated TURN access.
+:::
+
+### Important Notes
+
+- Replace `coturn.example.com` with your actual TURN server domain (the `realm` from coturn.conf)
+- The `turn_secret` must match the `static-auth-secret` in your coturn configuration
+- Restart or reload Continuwuity after making configuration changes
+
+## Testing Your TURN Server
+
+### Testing Credentials
+
+Verify that Continuwuity is correctly serving TURN credentials to clients:
+
+```bash
+curl "https://matrix.example.com/_matrix/client/r0/voip/turnServer" \
+  -H "Authorization: Bearer <your_client_token>" | jq
+```
+
+You should receive a response like this:
+
+```json
+{
+  "username": "1752792167:@jade:example.com",
+  "password": "KjlDlawdPbU9mvP4bhdV/2c/h65=",
+  "uris": [
+    "turns:coturn.example.com?transport=udp",
+    "turns:coturn.example.com?transport=tcp",
+    "turn:coturn.example.com?transport=udp",
+    "turn:coturn.example.com?transport=tcp"
+  ],
+  "ttl": 86400
+}
+```
+
+:::note MSC4166 Compliance
+If no TURN URIs are configured (`turn_uris` is empty), Continuwuity will return a 404 Not Found response, as specified in MSC4166.
+:::
+
+### Testing Connectivity
+
+Use [Trickle ICE](https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/) to verify that the TURN credentials actually work:
+
+1. Copy the credentials from the response above
+2. Paste them into the Trickle ICE testing tool
+3. Click "Gather candidates"
+4. Look for successful `relay` candidates in the results
+
+If you see relay candidates, your TURN server is working correctly!
+
+## Troubleshooting
+
+### Clients can't connect to TURN server
+
+- Verify firewall rules allow the necessary ports (3478, 5349, and your media port range)
+- Check that DNS resolves correctly for your TURN domain
+- Ensure your `turn_secret` matches coturn's `static-auth-secret`
+- Test with Trickle ICE to isolate the issue
+
+### Port conflicts with LiveKit
+
+- Make sure coturn's `min-port` starts above LiveKit's `port_range_end` (default: 50200)
+- Or adjust LiveKit's port range to avoid coturn's default range
+
+### 404 when calling turnServer endpoint
+
+- Verify that `turn_uris` is not empty in your Continuwuity config
+- This behavior is correct per MSC4166 if no TURN URIs are configured
+
+### Credentials expire too quickly
+
+- Adjust the `turn_ttl` value in your Continuwuity configuration
+- Default is 86400 seconds (24 hours)
+
+### Related Documentation
+
+- [MatrixRTC/LiveKit Setup](./livekit.mdx) - Configure group calling with LiveKit
+- [Coturn GitHub](https://github.com/coturn/coturn) - Official coturn repository
+- [Synapse TURN Guide](https://element-hq.github.io/synapse/latest/turn-howto.html) - Additional security recommendations

docs/deploying/docker.mdx

@@ -217,4 +217,4 @@ ### Use Traefik as Proxy
 
 ## Voice communication
 
-See the [TURN](../turn.md) page.
+See the [Calls](../calls.mdx) page.

docs/deploying/generic.mdx

@@ -277,7 +277,7 @@ # What's next?
 
 ## Audio/Video calls
 
-For Audio/Video call functionality see the [TURN Guide](../turn.md).
+For Audio/Video call functionality see the [Calls](../calls.md) page.
 
 ## Appservices
 

docs/turn.mdx

@@ -1,94 +0,0 @@
-# Setting up TURN/STURN
-
-In order to make or receive calls, a TURN server is required. Continuwuity suggests
-using [Coturn](https://github.com/coturn/coturn) for this purpose, which is also
-available as a Docker image.
-
-### Configuration
-
-Create a configuration file called `coturn.conf` containing:
-
-```
-use-auth-secret
-static-auth-secret=<a secret key>
-realm=<your server domain>
-```
-
-A common way to generate a suitable alphanumeric secret key is by using `pwgen
--s 64 1`.
-
-These same values need to be set in Continuwuity. See the [example
-config](./reference/config.mdx) in the TURN section for configuring these and
-restart Continuwuity after.
-
-`turn_secret` or a path to `turn_secret_file` must have a value of your
-coturn `static-auth-secret`, or use `turn_username` and `turn_password`
-if using legacy username:password TURN authentication (not preferred).
-
-`turn_uris` must be the list of TURN URIs you would like to send to the client.
-Typically you will just replace the example domain `example.turn.uri` with the
-`realm` you set from the example config.
-
-If you are using TURN over TLS, you can replace `turn:` with `turns:` in the
-`turn_uris` config option to instruct clients to attempt to connect to
-TURN over TLS. This is highly recommended.
-
-If you need unauthenticated access to the TURN URIs, or some clients may be
-having trouble, you can enable `turn_guest_access` in Continuwuity which disables
-authentication for the TURN URI endpoint `/_matrix/client/v3/voip/turnServer`
-
-### Run
-
-Run the [Coturn](https://hub.docker.com/r/coturn/coturn) image using
-
-```bash
-docker run -d --network=host -v
-$(pwd)/coturn.conf:/etc/coturn/turnserver.conf coturn/coturn
-```
-
-or docker-compose. For the latter, paste the following section into a file
-called `docker-compose.yml` and run `docker compose up -d` in the same
-directory.
-
-```yml
-version: 3
-services:
-    turn:
-      container_name: coturn-server
-      image: docker.io/coturn/coturn
-      restart: unless-stopped
-      network_mode: "host"
-      volumes:
-        - ./coturn.conf:/etc/coturn/turnserver.conf
-```
-
-To understand why the host networking mode is used and explore alternative
-configuration options, please visit [Coturn's Docker
-documentation](https://github.com/coturn/coturn/blob/master/docker/coturn/README.md).
-
-For security recommendations see Synapse's [Coturn
-documentation](https://element-hq.github.io/synapse/latest/turn-howto.html).
-
-### Testing
-
-To make sure turn credentials are being correctly served to clients, you can manually make a HTTP request to the turnServer endpoint.
-
-`curl "https://<matrix.example.com>/_matrix/client/r0/voip/turnServer" -H 'Authorization: Bearer <your_client_token>' | jq`
-
-You should get a response like this:
-
-```json
-{
-  "username": "1752792167:@jade:example.com",
-  "password": "KjlDlawdPbU9mvP4bhdV/2c/h65=",
-  "uris": [
-    "turns:coturn.example.com?transport=udp",
-    "turns:coturn.example.com?transport=tcp",
-    "turn:coturn.example.com?transport=udp",
-    "turn:coturn.example.com?transport=tcp"
-  ],
-  "ttl": 86400
-}
-```
-
-You can test these credentials work using [Trickle ICE](https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/)

rspress.config.ts

@@ -56,6 +56,9 @@ export default defineConfig({
         }, {
             from: '/community$',
             to: '/community/guidelines'
+        }, {
+            from: "^/turn",
+            to: "/calls/turn",
         }
         ]
     })],