MSC4143: MatrixRTC by toger5 · Pull Request #4143 · matrix-org/matrix-spec-proposals

toger5 · 2024-05-10T10:32:49Z

Rendered

To-do:

discovery and negotiation of available applications
how do you support early media? see MSC3635: Early Media for VoIP #3635 for example

Pull Request Checklist

Pull request includes a sign off
Update the title and file name of your proposal to match this PR's number (after opening).
Pull request includes a 'Rendered' link above.
Your MSC adheres to each point in the MSC Checklist.
Ask in
#matrix-spec:matrix.org to
get feedback on this PR.

Signed-off-by: Timo K <toger5@hotmail.de>

proposals/4143-MatrixRTC.md

Signed-off-by: Timo K <toger5@hotmail.de>

ara4n · 2024-11-25T09:07:15Z

proposals/4143-matrix-rtc.md

+## Unstable prefix
+
+The state events and the well_known key introduced in this MSC use the unstable prefix
+`org.matrix.msc4143.` instead of `m.` as used in the text.


empirically we seem to be using org.matrix.msc3401.call.member rather than org.matrix.msc4143.rtc.member in Element?

The current implementation is still using the msc3401 prefix. That is wrong and will be addressed. There is still the open topic of how exactly we want to do the state keys and the event ownership and on top of that we have plans for how to index rtc member events in a better way.
The reason we changed it to (...call... ->) ...rtc... is, that we need the call namespace for the particular video call matrixRTC application (session type) of calling over MatrixRTC. Using that word for both. Matrix rtc sessions in general and calls will be confusing in the long run.

Pinging this topic.
Is this high temp? Can we close the thread, or are there arguments to reconsider going back to call again?

ara4n · 2024-11-25T09:11:50Z

proposals/4143-matrix-rtc.md

+`created_ts()`+`device_id`. This is why the `m.rtc.member` events deliberately do NOT include a `membership_id`.
+
+Other then the membership sessions, there is **no event** to represent a rtc session (containing all members).
+Such an event would include shared information, and deciding who has authority over that is not trivial.


I continue to trip over whether it is wise to force clients to read all possible m.rtc.member events to figure out if a call is happening, and who created it.

I /think/ that a better reason for not having an m.rtc state event describing the existence of an RTC session is that you'd have to handle disconnection semantics on it similar to delayed-events for m.rtc.member... at which point, why not leverage the membership events?

However, it still feels REALLY weird to not have something in state telling you whether semantically a call is intended to be happening now (and what that sort of call is, when it began, and who initiated it) - versus having to infer it.

Alternatively, if the thought experiment is "what if two users both create an m.rtc state event on different forks of the DAG at the same time?" ... is that really so bad? and does aggregating m.rtc.member state actually make it better? if so, how?

In other words, we actually need to justify the lack of m.rtc state event much better here, imo. In particular, having somewhere to store the metadata about the call at the point of creation (its name, its ID, whether it's intended to be a voice/video room or a group call or a conference, etc)

There is a large list of reasons and I 100% support the idea to go into detail in the MSC to justify this approach.

As for this comment I will just give a couple of short examples/arguments:

The security and "trolling" surface is huge. If we have one state event we either limit who can create a call or we allow everyone to mess with the event. This can go from smaller issues like ending the call for fun to larger issues like changing where the call is happening without the members noticing it. (in a LK world at least)

But even if everyone plays fair, a call can be stopped by a delayed event because the creator failed to send the refresh event. This now disconnects everyone from the call.
Independent how we make things behave, if we have a public/shared event controlling the experience for everyone we switch from:

If there is a client with issues (or user that actively introduces issues) that user has a degraded experience

If there is a client with issues (or user that actively introduces issues) everyone experience can be broken.

In the context of matrix where there is no central entity controlling the clients the seconds seems to be the only valid option.

The slot state events seem to be a great balance between the two positions brought up in this thread.

Do we feel comfortable closing this thread?

ara4n · 2024-11-25T09:12:59Z

proposals/4143-matrix-rtc.md

+
+- [`m.call`](www.example.com) TODO: create `m.call` MSC and add link here.
+
+## Potential issues


The fact we don't reference how to tell users that a call is happening (i.e. m.call.notify) is very disorienting here.

The notification/ring process is call specific so it should not be part of the base MatrixRTC MSC.

proposals/4143-matrix-rtc.md

@frastefanini

Deployments that make use of the [synapse-s3-storage-provider](https://github.com/matrix-org/synapse-s3-storage-provider) module must upgrade to [v1.6.0](https://github.com/matrix-org/synapse-s3-storage-provider/releases/tag/v1.6.0). Using older versions of the module with this release of Synapse will prevent users from being able to upload or download media. No significant changes since 1.140.0rc1. - Add [a new Media Query by ID Admin API](https://element-hq.github.io/synapse/v1.140/admin_api/media_admin_api.html#query-a-piece-of-media-by-id) that allows server admins to query and investigate the metadata of local or cached remote media via the `origin/media_id` identifier found in a [Matrix Content URI](https://spec.matrix.org/v1.14/client-server-api/#matrix-content-mxc-uris). ([\element-hq#18911](element-hq#18911)) - Add [a new Fetch Event Admin API](https://element-hq.github.io/synapse/v1.140/admin_api/fetch_event.html) to fetch an event by ID. ([\element-hq#18963](element-hq#18963)) - Update [MSC4284: Policy Servers](matrix-org/matrix-spec-proposals#4284) implementation to support signatures when available. ([\element-hq#18934](element-hq#18934)) - Add experimental implementation of the `GET /_matrix/client/v1/rtc/transports` endpoint for the latest draft of [MSC4143: MatrixRTC](matrix-org/matrix-spec-proposals#4143). ([\element-hq#18967](element-hq#18967)) - Expose a `defer_to_threadpool` function in the Synapse Module API that allows modules to run a function on a separate thread in a custom threadpool. ([\element-hq#19032](element-hq#19032)) - Fix room upgrade `room_config` argument and documentation for `user_may_create_room` spam-checker callback. ([\element-hq#18721](element-hq#18721)) - Compute a user's last seen timestamp from their devices' last seen timestamps instead of IPs, because the latter are automatically cleared according to `user_ips_max_age`. ([\element-hq#18948](element-hq#18948)) - Fix bug where ephemeral events were not filtered by room ID. Contributed by @frastefanini. ([\element-hq#19002](element-hq#19002)) - Update Synapse main process version string to include git info. ([\element-hq#19011](element-hq#19011)) - Explain how `Deferred` callbacks interact with logcontexts. ([\element-hq#18914](element-hq#18914)) - Fix documentation for `rc_room_creation` and `rc_reports` to clarify that a `per_user` rate limit is not supported. ([\element-hq#18998](element-hq#18998)) - Remove deprecated `LoggingContext.set_current_context`/`LoggingContext.current_context` methods which already have equivalent bare methods in `synapse.logging.context`. ([\element-hq#18989](element-hq#18989)) - Drop support for unstable field names from the long-accepted [MSC2732](matrix-org/matrix-spec-proposals#2732) (Olm fallback keys) proposal. ([\element-hq#18996](element-hq#18996)) - Cleanly shutdown `SynapseHomeServer` object, allowing artifacts of embedded small hosts to be properly garbage collected. ([\element-hq#18828](element-hq#18828)) - Update OEmbed providers to use 'X' instead of 'Twitter' in URL previews, following a rebrand. Contributed by @HammyHavoc. ([\element-hq#18767](element-hq#18767)) - Fix `server_name` in logging context for multiple Synapse instances in one process. ([\element-hq#18868](element-hq#18868)) - Wrap the Rust HTTP client with `make_deferred_yieldable` so it follows Synapse logcontext rules. ([\element-hq#18903](element-hq#18903)) - Fix the GitHub Actions workflow that moves issues labeled "X-Needs-Info" to the "Needs info" column on the team's internal triage board. ([\element-hq#18913](element-hq#18913)) - Disconnect background process work from request trace. ([\element-hq#18932](element-hq#18932)) - Reduce overall number of calls to `_get_e2e_cross_signing_signatures_for_devices` by increasing the batch size of devices the query is called with, reducing DB load. ([\element-hq#18939](element-hq#18939)) - Update error code used when an appservice tries to masquerade as an unknown device using [MSC4326](matrix-org/matrix-spec-proposals#4326). Contributed by @tulir @ Beeper. ([\element-hq#18947](element-hq#18947)) - Fix `no active span when trying to log` tracing error on startup (when OpenTracing is enabled). ([\element-hq#18959](element-hq#18959)) - Fix `run_coroutine_in_background(...)` incorrectly handling logcontext. ([\element-hq#18964](element-hq#18964)) - Add debug logs wherever we change current logcontext. ([\element-hq#18966](element-hq#18966)) - Update dockerfile metadata to fix broken link; point to documentation website. ([\element-hq#18971](element-hq#18971)) - Note that the code is additionally licensed under the [Element Commercial license](https://github.com/element-hq/synapse/blob/develop/LICENSE-COMMERCIAL) in SPDX expression field configs. ([\element-hq#18973](element-hq#18973)) - Fix logcontext handling in `timeout_deferred` tests. ([\element-hq#18974](element-hq#18974)) - Remove internal `ReplicationUploadKeysForUserRestServlet` as a follow-up to the work in element-hq#18581 that moved device changes off the main process. ([\element-hq#18988](element-hq#18988)) - Switch task scheduler from raw logcontext manipulation to using the dedicated logcontext utils. ([\element-hq#18990](element-hq#18990)) - Remove `MockClock()` in tests. ([\element-hq#18992](element-hq#18992)) - Switch back to our own custom `LogContextScopeManager` instead of OpenTracing's `ContextVarsScopeManager` which was causing problems when using the experimental `SYNAPSE_ASYNC_IO_REACTOR` option with tracing enabled. ([\element-hq#19007](element-hq#19007)) - Remove `version_string` argument from `HomeServer` since it's always the same. ([\element-hq#19012](element-hq#19012)) - Remove duplicate call to `hs.start_background_tasks()` introduced from a bad merge. ([\element-hq#19013](element-hq#19013)) - Split homeserver creation (`create_homeserver`) and setup (`setup`). ([\element-hq#19015](element-hq#19015)) - Swap near-end-of-life `macos-13` GitHub Actions runner for the `macos-15-intel` variant. ([\element-hq#19025](element-hq#19025)) - Introduce `RootConfig.validate_config()` which can be subclassed in `HomeServerConfig` to do cross-config class validation. ([\element-hq#19027](element-hq#19027)) - Allow any command of the `release.py` script to accept a `--gh-token` argument. ([\element-hq#19035](element-hq#19035)) * Bump Swatinem/rust-cache from 2.8.0 to 2.8.1. ([\element-hq#18949](element-hq#18949)) * Bump actions/cache from 4.2.4 to 4.3.0. ([\element-hq#18983](element-hq#18983)) * Bump anyhow from 1.0.99 to 1.0.100. ([\element-hq#18950](element-hq#18950)) * Bump authlib from 1.6.3 to 1.6.4. ([\element-hq#18957](element-hq#18957)) * Bump authlib from 1.6.4 to 1.6.5. ([\element-hq#19019](element-hq#19019)) * Bump bcrypt from 4.3.0 to 5.0.0. ([\element-hq#18984](element-hq#18984)) * Bump docker/login-action from 3.5.0 to 3.6.0. ([\element-hq#18978](element-hq#18978)) * Bump lxml from 6.0.0 to 6.0.2. ([\element-hq#18979](element-hq#18979)) * Bump phonenumbers from 9.0.13 to 9.0.14. ([\element-hq#18954](element-hq#18954)) * Bump phonenumbers from 9.0.14 to 9.0.15. ([\element-hq#18991](element-hq#18991)) * Bump prometheus-client from 0.22.1 to 0.23.1. ([\element-hq#19016](element-hq#19016)) * Bump pydantic from 2.11.9 to 2.11.10. ([\element-hq#19017](element-hq#19017)) * Bump pygithub from 2.7.0 to 2.8.1. ([\element-hq#18952](element-hq#18952)) * Bump regex from 1.11.2 to 1.11.3. ([\element-hq#18981](element-hq#18981)) * Bump serde from 1.0.224 to 1.0.226. ([\element-hq#18953](element-hq#18953)) * Bump serde from 1.0.226 to 1.0.228. ([\element-hq#18982](element-hq#18982)) * Bump setuptools-rust from 1.11.1 to 1.12.0. ([\element-hq#18980](element-hq#18980)) * Bump twine from 6.1.0 to 6.2.0. ([\element-hq#18985](element-hq#18985)) * Bump types-pyyaml from 6.0.12.20250809 to 6.0.12.20250915. ([\element-hq#19018](element-hq#19018)) * Bump types-requests from 2.32.4.20250809 to 2.32.4.20250913. ([\element-hq#18951](element-hq#18951)) * Bump typing-extensions from 4.14.1 to 4.15.0. ([\element-hq#18956](element-hq#18956))

Half-Shot · 2025-10-23T13:09:59Z

proposals/4143-matrix-rtc.md

+  "application": {
+    "type": "m.call",
+    // optional: app specific slot metadata
+    "m.call.id": UUID,           // Note your application must handle rollback due to state resolution


zecakeh · 2025-11-24T15:14:32Z

proposals/4143-matrix-rtc.md

+The exact procedures for subscribing to and publishing real-time data are defined in the dedicated
+MSCs for each transport type.
+
+#### Discovery of RTC Transports


This section doesn't say whether the endpoint should be rate-limited, and whether it requires authentication.

Currently the implementation in Synapse requires authentication.

I think it's expected to require auth so we should update this section. Also, I'm assuming we would want guests to be able to access it.

I don't think this needs special ratelimiting guidance, it's only returning configuration.

Half-Shot · 2025-12-11T14:01:15Z

proposals/4143-matrix-rtc.md

@@ -0,0 +1,1170 @@
+# MSC4143: MatrixRTC


I can't find the usual @turt2live magic implementations thread, but I'm sure that will happen at some point. Anyway:

Client implementation of backend endpoint: Support MSC4143 RTC Transport endpoint element-hq/element-call#3629

Server implementation of backend endpoint: Add MatrixRTC backend/services discovery endpoint element-hq/synapse#18967

Looks like this is implmented in https://github.com/element-hq/element-call/releases/tag/v0.17.0-rc.1

areny6 · 2026-01-08T04:25:54Z

Any plans to make MSC4143 discovery work for non-FQDN servers, or a workaround?

Half-Shot · 2026-01-08T09:28:47Z

Any plans to make MSC4143 discovery work for non-FQDN servers, or a workaround?

Can you comment this as a thread on the relevant part of the MSC please :)

richvdh · 2026-02-03T16:10:54Z

Early feedback: this can't enter FCP until (a) most of the the open threads are resolved; (b) dependency MSCs (MSC4354 and MSC4140 in this case) are, if not in FCP, at least well on the way.

turt2live · 2026-02-10T03:04:30Z

This is currently blocked on comment thread resolution and dependency clearing. I believe we might be able to "safely" send this through to proposed-FCP once its dependencies have entered FCP.

toger5 marked this pull request as draft May 10, 2024 10:33

toger5 force-pushed the toger5/matrixRTC branch 2 times, most recently from d717c0b to cff8291 Compare May 10, 2024 10:34

draft

9cbe448

Signed-off-by: Timo K <toger5@hotmail.de>

toger5 force-pushed the toger5/matrixRTC branch from cff8291 to 9cbe448 Compare May 10, 2024 10:35

turt2live changed the title ~~MatrixRTC (draft)~~ MSC4143: MatrixRTC May 10, 2024

turt2live reviewed May 10, 2024

View reviewed changes

proposals/4143-MatrixRTC.md Outdated Show resolved Hide resolved

turt2live added voip proposal A matrix spec change proposal kind:core MSC which is critical to the protocol's success needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels May 10, 2024

lowercase filename

b2b4e5e

Signed-off-by: Timo K <toger5@hotmail.de>

toger5 force-pushed the toger5/matrixRTC branch from b0aa20b to b2b4e5e Compare May 14, 2024 09:24

add note about this relying on MSC3757

8c1340a

toger5 force-pushed the toger5/matrixRTC branch from 728f6cd to 8c1340a Compare May 15, 2024 10:04

td-famedly mentioned this pull request May 16, 2024

refactor: make voip.calls and voip.groupCalls simpler famedly/matrix-dart-sdk#1796

Closed

toger5 added 8 commits May 17, 2024 15:37

remove the m.prefix from fields.

8c800a6

update

1dcbfce

add foci_preferred well known section

813a21a

update to reference to msc [MSC4158](#4158)

d65e42e

add a "Reliability requirements for the room state" section

4ab679a

use current state key format

6d84256

add expires_after

d68e942

add section about send order (delayed leave event -> join event)

3b19b49

hughns mentioned this pull request Oct 2, 2024

Fix MatrixRTC sender key wrapping matrix-org/matrix-js-sdk#4441

Merged

4 tasks

language fixes

a278ff8

ara4n reviewed Nov 25, 2024

View reviewed changes

proposals/4143-matrix-rtc.md Outdated Show resolved Hide resolved

fkwp marked this pull request as ready for review October 14, 2025 13:16

fix grammar & link the MSC

680ef7d

Half-Shot reviewed Oct 23, 2025

View reviewed changes

zecakeh reviewed Nov 24, 2025

View reviewed changes

This was referenced Nov 24, 2025

client-api: Add unstable support for RTC transports discovery endpoint ruma/ruma#2298

Merged

refactor(sdk): Split supported versions and well-known cache matrix-org/matrix-rust-sdk#5910

Merged

Half-Shot reviewed Dec 11, 2025

View reviewed changes

fkwp added 2 commits December 12, 2025 17:11

more informatino on the purpose of member.id

b62f75b

markdown cleanup

50f8331

fkwp force-pushed the toger5/matrixRTC branch from 6120351 to 50f8331 Compare December 12, 2025 16:15

anoadragon453 mentioned this pull request Jan 6, 2026

Add installation instruction to the manual for MatrixRTC element-hq/synapse#18321

Open

HarHarLinks mentioned this pull request Jan 16, 2026

Nothing implements: 100% Matrix standard + stable free stack + mobile VoIP matrix-org/matrix.org#3160

Closed

robintown and others added 3 commits January 23, 2026 15:41

Remove stray . from slot ID

d53175b

cleanup field description for to-device message

dc605bf

minor changes to the m.rtc.encryption_key to-device format

7907635

turt2live added 00-weekly-pings Tracking for weekly pings in the SCT office. 00 to make it first in the labels list. and removed needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Jan 30, 2026

turt2live moved this from Tracking for review to Ready for FCP ticks in Spec Core Team Workflow Jan 30, 2026

turt2live moved this from Ready for FCP ticks to Proposed for FCP readiness in Spec Core Team Workflow Jan 30, 2026

turt2live added blocked Something needs to be done before action can be taken on this PR/issue. and removed 00-weekly-pings Tracking for weekly pings in the SCT office. 00 to make it first in the labels list. labels Feb 10, 2026

eris-ths mentioned this pull request Feb 20, 2026

MatrixRTC vs Photon Engine — 分散型リアルタイム通信は商用ゲームネットワーキングを食えるか？ eris-ths/research-notes#33

Open

deepbluev7 mentioned this pull request Mar 10, 2026

VoIP on OSX (metal implementation) Nheko-Reborn/nheko#2027

Open

Update transport type to match latest MSC4195 revision

c032f03

escix mentioned this pull request Apr 4, 2026

Synapse 1.150.0 does not expose MatrixRTC transports endpoint despite msc4143_enabled=true element-hq/synapse#19652

Open


		- [`m.call`](www.example.com) TODO: create `m.call` MSC and add link here.

		## Potential issues

Conversation

toger5 commented May 10, 2024 • edited by hughns Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request Checklist

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Half-Shot Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

areny6 commented Jan 8, 2026

Uh oh!

Half-Shot commented Jan 8, 2026

Uh oh!

richvdh commented Feb 3, 2026

Uh oh!

turt2live commented Feb 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants

toger5 commented May 10, 2024 •

edited by hughns

Loading

Half-Shot Dec 11, 2025 •

edited

Loading