You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: proposals/4143-matrix-rtc.md
+22-13Lines changed: 22 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,20 +1,20 @@
1
1
# MSC4143: MatrixRTC
2
2
3
-
This MSC defines the modules with which the matrix real time system is build with.
3
+
This MSC defines the modules with which the matrix real time system is build.
4
4
5
5
The MatrixRTC specification is separated into different modules.
6
6
7
7
- The MatrixRTC room state that defines the state of the real time application.\
8
-
It is the source of truth for:
8
+
It is the source of truth for:
9
9
- Who is part of a session
10
10
- Who is connected via what technology/backend
11
11
- Metadata per device used by other participants to decide whether the streams
12
-
from this source are of interest / need to be subscribed.
12
+
from this source are of interest / need to be subscribed.
13
13
- The RTC backend.
14
14
- It defines how to connect the participating peers.
15
15
- Livekit is the standard for this as of writing.
16
16
- Defines how to connect to a server/other peers, how to update the connection,
17
-
how to subscribe to different streams...
17
+
how to subscribe to different streams...
18
18
- Another planned backend is a full mesh implementation based on MSC3401.
19
19
- The RTCSession types (application) have their own per application spec.
20
20
- Calls can be done with an application of type `m.call` see (TODO: link call msc)
@@ -57,6 +57,13 @@ A complete `m.rtc.member` state event looks like this:
57
57
}
58
58
```
59
59
60
+
> [!NOTE]
61
+
> This relies on [MSC3757](https://github.com/matrix-org/matrix-spec-proposals/pull/3757).
62
+
> We need to have one state event per device, hence multiple "non-overwritable" state
63
+
> events per user.
64
+
>
65
+
> More specifically this uses the approach outlined in this [comment](https://github.com/matrix-org/matrix-spec-proposals/pull/3757#issuecomment-2099010555).
66
+
60
67
giving us the information, that user: `@user:matrix.domain` with device `DEVICEID`
61
68
is part of an RTCSession of type `m.call` in the scope/sub-session `""` (empty
62
69
string as call id) connected over `FOCUS_A`. This is all information that is needed
@@ -75,8 +82,8 @@ Based on the value of `m.application`, the event might include additional parame
75
82
required to provide additional session parameters.
76
83
77
84
> A thirdRoom like experience could include the information of an approximate position
78
-
on the map, so that clients can omit connecting to participants that are not in their
79
-
area of interest.
85
+
> on the map, so that clients can omit connecting to participants that are not in their
86
+
> area of interest.
80
87
81
88
#### Historic sessions
82
89
@@ -86,12 +93,12 @@ historic sessions need to be computed and most likely cached on the client.
0 commit comments