From 1dcbfce23a6d6b4e99fc338a19d2489c50c15f14 Mon Sep 17 00:00:00 2001 From: Timo Date: Wed, 5 Jun 2024 15:59:48 +0200 Subject: [PATCH] update --- proposals/4143-matrix-rtc.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/proposals/4143-matrix-rtc.md b/proposals/4143-matrix-rtc.md index b0bce4779..1fa274987 100644 --- a/proposals/4143-matrix-rtc.md +++ b/proposals/4143-matrix-rtc.md @@ -44,7 +44,7 @@ require one event type. A complete `m.rtc.member` state event looks like this: ```json -// event type: m.rtc.member +// event type: "m.rtc.member" // event key: ["@user:matrix.domain", "DEVICEID"] { "application": "m.my_session_type", @@ -66,7 +66,7 @@ A complete `m.rtc.member` state event looks like this: > > More specifically this uses the approach outlined in this [comment](https://github.com/matrix-org/matrix-spec-proposals/pull/3757#issuecomment-2099010555). -giving us the information, that user: `@user:matrix.domain` with device `DEVICEID` +This gives us the information, that user: `@user:matrix.domain` with device `DEVICEID` is part of an RTCSession of type `m.call` in the scope/sub-session `""` (empty string as call id) connected over `FOCUS_A`. This is all information that is needed for another room member to detect the running session and join it. @@ -77,10 +77,18 @@ be the second element of the state key array. `created_ts` is an optional property that caches the time of creation. It is not required for an event that, has not yet been updated, there the `origin_server_ts` is used. + +> [!NOTE] +> We introduce `created_ts()` as the notation for `created_ts ?? origin_server_ts` + Once the event gets updated the origin_server_ts needs to be copied into the `created_ts` field. +An existing `created_ts` field implies that this is a state event updating the current session +and a missing `created_ts` field implies that it is a join state event. +All membership events that belong to one member session can be grouped with the index +`created_ts()`+`device_id`. This is why the `m.rtc.member` events deliberately do NOT include a `membership_id`. -There is **no event** to represent a session. This event would include shared -information where it is not trivial to decide who has authority over it. +Other then the membership sessions, there is **no event** to represent a rtc session (containing all members). +This event would include shared information where it is not trivial to decide who has authority over it. Instead the session is a computed value based on `m.rtc.member` events. The list of events with the same `application` and `m.call_id` represent one session. This array allows to compute fields like participant count, start time ...