add note about this relying on MSC3757

proposals/4143-matrix-rtc.md

@@ -1,6 +1,6 @@
 # MSC4143: MatrixRTC
 
-This MSC defines the modules with which the matrix real time system is build with.
+This MSC defines the modules with which the matrix real time system is build.
 
 The MatrixRTC specification is separated into different modules.
 
@@ -57,6 +57,13 @@ A complete `m.rtc.member` state event looks like this:
 }
 ```
 
+> [!NOTE]  
+> This relies on [MSC3757](https://github.com/matrix-org/matrix-spec-proposals/pull/3757).
+> We need to have one state event per device, hence multiple "non-overwritable" state
+> events per user.
+>
+> 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`
 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
@@ -75,8 +82,8 @@ Based on the value of `m.application`, the event might include additional parame
 required to provide additional session parameters.
 
 > A thirdRoom like experience could include the information of an approximate position
-on the map, so that clients can omit connecting to participants that are not in their
-area of interest.
+> on the map, so that clients can omit connecting to participants that are not in their
+> area of interest.
 
 #### Historic sessions
 
@@ -146,5 +153,7 @@ defined:
 - [`m.call`](www.example.com) TODO: create `m.call` MSC and add link here.
 
 ## Potential issues
+
 ## Alternatives
+
 ## Security considerations