Self-Hosting Element Call: MatrixRTC Setup

If calls on your self-hosted Matrix server were working in July and now say "Call is not supported," don't assume you broke something. The rules changed.

Element Call v0.24.0, released on 18 August 2026, stopped reading the org.matrix.msc4143.rtc_foci entry in .well-known/matrix/client. That's exactly where most self-hosting guides tell you to announce your LiveKit backend. If you host Element Call standalone and your server's .well-known/matrix/client file contained that key, you can now remove it.

It was one of five changes to the MatrixRTC stack between June and September. The official docs haven't fully caught up with each other either: the lk-jwt-service README still tells you to add rtc_foci to .well-known, while Element Call's own guide has moved on to a Synapse config block that Synapse 1.161 has since partly deprecated. This guide sorts that out, using the current releases as of 22 September 2026.

Why your calls stopped

There are two separate reasons, about a year and a half apart.

The first is old news. In April 2025, Element announced that the free MatrixRTC backend it had been running for the community was no longer sustainable. Element X, Element Web, and Element Desktop stopped falling back to it. That meant every self-hosted homeserver that wanted calls needed its own LiveKit SFU and authorization service. Most admins set that up in 2025 by following a community guide, and it kept working.

The second reason is the one catching people now. On 5 August 2026, the Element Call team removed well-known discovery from the client, and it shipped in v0.24.0 on 18 August. Here's how the current client finds your backend, straight from its source:

1. Ask the homeserver: GET /_matrix/client/unstable/org.matrix.msc4143/rtc/transports
2. If that returns nothing, use a livekit_service_url from Element Call's own config.json, which only exists in standalone deployments, and which the docs say is for debugging
3. Otherwise, fail with MISSING_MATRIX_RTC_TRANSPORT

.well-known isn't on the list. So a server whose only MatrixRTC config is the rtc_foci entry fails at step 3. The message users see is:

"Call is not supported. The server is not configured to work with Element Call. Please contact your server admin."

...with your domain and the error code on the end.

Element X bundles Element Call, so the break arrives whenever a user's app updates, not when you touch your server. That's why a bug report against Element X Android 26.09.1 called it a regression: the reporter's setup worked on 26.08.1 and stopped on the next update, with nothing changed server-side.

It's worth noting that Element Web/Desktop and Element X Android/iOS are being adapted to keep .well-known discovery as a fallback for a while longer. But the recommendation is clear: enable the MSC4519 endpoint to prepare for future changes.

How MatrixRTC fits together

A MatrixRTC call has four moving parts. Only the first one is a Matrix server in the usual sense.

That last point trips people up. If your users call from Element X or Element Web, you do not need to build or host the Element Call web app. You only need the backend: Synapse configured, plus LiveKit and lk-jwt-service. The standalone build is for people who want a Jitsi-style "open a link and join" page.

If you're weighing LiveKit against other SFUs more generally, our LiveKit vs Jitsi comparison covers where each one fits. For Matrix calls you don't get a choice, though: MatrixRTC's media transport is LiveKit.

What changed in 2026

If you set up MatrixRTC in 2025, every row below changes something you configured.

Notice the twist in the 19 August row. The day after clients stopped reading .well-known for the backend, lk-jwt-service started depending on .well-known to find your homeserver's API. So you can't delete /.well-known/matrix/client. It still has to serve a correct m.homeserver entry. The rtc_foci key inside it is what stopped mattering.

Current versions, for reference: Synapse 1.161.0, lk-jwt-service 0.7.0, LiveKit server 1.13.7, and Element Call 0.26.0.

Setting up the backend

This follows Element's self-hosting guide and the lk-jwt-service README, with the September changes folded in. The examples use example.com as the Matrix server name and matrix-rtc.example.com as a single hostname for both LiveKit and lk-jwt-service, which is what Element recommends.

Step 1: Configure Synapse

Add this to homeserver.yaml and restart Synapse:

experimental_features:
  # Room summary API, used for knocking into calls over federation
  msc3266_enabled: true
  # Enables the /rtc/transports endpoint clients now depend on
  msc4143_enabled: true
  # state_after in sync v2, so clients track call state correctly
  msc4222_enabled: true

# Delayed events (MSC4140). Without these, calls get stuck.
max_event_delay_duration: 24h

rc_message:
  per_second: 0.5
  burst_count: 30

rc_delayed_event_mgmt:
  per_second: 1
  burst_count: 20

matrix_rtc:
  transports:
    - type: livekit
      # Synapse 1.161+ only: the SFU's WebSocket URL
      url: wss://matrix-rtc.example.com/livekit/sfu
      # Deprecated, but current clients still use it. Keep it.
      livekit_service_url: https://matrix-rtc.example.com/livekit/jwt

Two things in there are easy to get wrong.

The msc4143_enabled flag name is historical. It turns on the transports endpoint that the newer MSC4519 defines, and without it the matrix_rtc block does nothing. And only add the url line on Synapse 1.161 or later. On older versions, use livekit_service_url alone.

Synapse also needs either a federation or an openid listener that lk-jwt-service can reach, because that's how the service checks a user's OpenID token. If you've disabled federation, add an openid resource to a listener. One GitHub issue documents an admin who spent a while in the source code before finding this.

Finally, check that https://example.com/.well-known/matrix/client returns your m.homeserver base URL. You can leave an existing rtc_foci entry in place for older clients.

Step 2: Configure LiveKit

A minimal livekit.yaml for Matrix calls:

port: 7880
rtc:
  tcp_port: 7881
  port_range_start: 50000
  port_range_end: 60000
  use_external_ip: true
room:
  # Required: let lk-jwt-service decide who can create rooms
  auto_create: false
keys:
  matrixrtc: <long-random-secret>
webhook:
  # Must be a key from the keys section above
  api_key: matrixrtc
  urls:
    - https://matrix-rtc.example.com/livekit/jwt/sfu_webhook

auto_create: false is the setting people skip. Without it, LiveKit creates a room for anyone holding a valid token, and the access control in lk-jwt-service has nothing to enforce. The webhook section is new with lk-jwt-service 0.6.0. It lets the service notice when a phone loses signal mid-call and post the leave event on the user's behalf. Without it you get ghost participants.

The firewall needs TCP 7881 and UDP 50000-60000 open to the world, plus 443 for the reverse proxy. Our guide to self-hosting LiveKit on AWS goes through the security group and the use_external_ip behaviour in detail, and none of that changes for Matrix.

Step 3: Run lk-jwt-service

docker run -d --name lk-jwt-service --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -e LIVEKIT_URL=wss://matrix-rtc.example.com/livekit/sfu \
  -e LIVEKIT_KEY=matrixrtc \
  -e LIVEKIT_SECRET=<long-random-secret> \
  -e LIVEKIT_FULL_ACCESS_HOMESERVERS=example.com \
  ghcr.io/element-hq/lk-jwt-service:0.7.0

LIVEKIT_FULL_ACCESS_HOMESERVERS takes your Matrix server name (example.com), not the hostname Synapse runs on. Users from listed servers can start calls on your SFU. Users from other servers can still join calls that your users started. You could set it to *, but then anyone on any homeserver can open rooms on your hardware.

Pin the image version rather than using latest. The service had two breaking changes this year, and you want to pick when you take the next one. If you want leave-event tracking to survive a restart, add LIVEKIT_REDIS_URL; otherwise that state lives in memory.

Step 4: Route both behind one hostname

server {
    listen 443 ssl;
    server_name matrix-rtc.example.com;
    # ssl_certificate / ssl_certificate_key here

    location ^~ /livekit/jwt/ {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://127.0.0.1:8080/;
    }

    location ^~ /livekit/sfu/ {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_buffering off;
        proxy_read_timeout 120;
        proxy_send_timeout 120;
        proxy_pass http://127.0.0.1:7880/;
    }
}

Then check each piece from outside the server:

# lk-jwt-service is up
curl -i https://matrix-rtc.example.com/livekit/jwt/healthz

# Synapse advertises the transport (needs a real access token)
curl -s -H "Authorization: Bearer <access-token>" \
  https://matrix.example.com/_matrix/client/unstable/org.matrix.msc4143/rtc/transports

The second command should return JSON with a livekit entry. If it returns an empty list or a 404, clients will fail with MISSING_MATRIX_RTC_TRANSPORT no matter what else is right. You can get an access token from Element Web under Settings, then Help & About.

Application service mode

Synapse 1.161's release notes are where the next change shows up. In the new model, clients stop talking to lk-jwt-service directly. They call endpoints on the homeserver under /rtc/livekit, and Synapse forwards those requests to lk-jwt-service, which is registered as a Matrix application service. The service no longer needs its own public URL or its own token validation, and LIVEKIT_FULL_ACCESS_HOMESERVERS is ignored because the homeserver already knows who is local.

It's a cleaner design. I'd still wait before switching.

lk-jwt-service 0.7.0's release notes describe the mode as "still experimental." It depends on two draft MSCs (4502 and 4512), both behind their own experimental flags in Synapse. And the client side isn't there yet: Element Call 0.26.0 still fetches its token through livekit_service_url. The only request it sends through the new homeserver path is the delayed-leave call. Right now the application service setup adds moving parts and buys you nothing.

What to do today is what Step 1 already does: set url and keep livekit_service_url. Clients that understand the new mode will use it when they ship, and everything else keeps working. When you do make the switch, the registration file lives in the lk-jwt-service README, and you'll also need msc4502_enabled and msc4512_enabled in Synapse.

Fixing common call errors

Most of these are in the GitHub issue trackers somewhere, spread across four repositories. Here they are in one place.

A tool worth knowing: testmatrix, a Matrix server sanity checker that the Element Call docs link to. It includes MatrixRTC checks, and it catches most of the configuration mistakes above faster than reading logs.

LiveKit ships its own TURN server, which covers most setups. If your users sit behind strict enterprise firewalls, a separate TURN server on its own IP and port 443 is often more reliable. Meetrix publishes a ready-to-run coturn image for exactly that case.

Related Articles

How to Self-Host LiveKit on AWS

Self-host LiveKit on AWS EC2 step by step: generate the config, open the right ports, size the instance, avoid ICE failures and compare cost with LiveKit Cloud.

By Shalomi Umeshika • Meetrix.io

LiveKit vs Jitsi: Which Open-Source WebRTC Platform Should You Self-Host in 2026?

LiveKit vs Jitsi compared honestly: a WebRTC SFU and agents framework for building custom apps, against a finished, self-hostable meeting room product, and which one to actually self-host in 2026.

By Shalomi Umeshika • Meetrix.io

STUN vs TURN vs ICE: WebRTC NAT Traversal Explained

STUN vs TURN vs ICE explained plainly: what each one actually does, why WebRTC calls fail behind NAT, and when you need your own TURN server.

By Binuka Ranatunga • Meetrix.io