review changes

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

proposals/4075-call-notify-event.md

@@ -22,9 +22,9 @@ This event contains the following fields by leveraging intentional mentions.
 ```
 {
   "content": {
-    "application": "m.call" | "m.other_matrix_session_type" | "...",
+    "application": "m.call | m.other_matrix_session_type | ...",
     "m.mentions": {"user_ids": [], "room": true | false},
-    "notify_type": "ring" | "notification",
+    "notify_type": "ring | notification",
     // Application specific data,
     // optional fields to disambiguate which session
     // this notify event belongs to:
@@ -49,31 +49,37 @@ This visual indication should be more than an unread indicator
 and similar to a notification banner.
 This is not enforced by the spec however and ultimately a client choice.
 
-Notify conditions depend on:\
-(here we use )
+Ringing (or notifying) should happen only if all these conditions apply:\
 
 - `m.call.notify` content:\
-   If the user is not part of the `m.mentions` section as defined in
+  If the user is not part of the `m.mentions` section as defined in
   [MSC3952](https://github.com/matrix-org/matrix-spec-proposals/pull/3952)
   this event can be ignored. (Push notifications are automatically filtered
   so this only is important for events received via a sync)
 - Local notification settings:\
-   If the room is set to silent, it will never play a ring sound. A `m.call.notify`
+  If the room is set to silent, it will never play a ring sound. A `m.call.notify`
   event will at most be used to mark the room as unread or update the rooms
   "has active **call** icon". (the exact behavior is up to the client)
 - Currently playing a ring sound (room timeline):\
-   If the user already received a ring event for this **call** and is playing
+  If the user already received a ring event for this **call** and is playing
   the ring sound any incoming `m.call.notify` for the same **call**
   should be ignored. If the user failed to pick up and a new `m.call.notify`
   arrives for the same room the device should ring again.
 - Current user is a member of the the **call** (room state):\
-   None of the devices should ring if they receive a `m.call.notify` if the
+  None of the devices should ring if they receive a `m.call.notify` if the
   rooms state `m.call.member` event of the user contains a membership for
   the **call** in the `m.call.notify` event.
   This includes stopping the current ring sound if the room state updates so
   this condition is true.
+- If a notify event is received in "real time":\
+  Notify events that are older then **10 seconds** are ignored (using the local
+  timestamp computed via `unsigned.age`).\
+  Otherwise a clients syncing for the first time would ring for outdated call events.
+  In general ringing only makes sense in "real time". A 10 second syncing latency
+  is allowed. Any client which is not able to receive the event in this period should
+  not ring to prohibit (annoying/misleading/irrelevant) outdated rings.
 
-Sending a `m.call.notify` should happen if all of these conditions apply:
+Sending a `m.call.notify` should happen only if all of these conditions apply:
 
 - If the user deliberately wants to send a new notify event
   (It is possible to send a `m.call.notify` for an ongoing call if that
@@ -122,6 +128,15 @@ Cons
   specific list of users to notify want to be specified.
 - It would not make it possible to ring without participating.
 
+### Explicitly unspecified conditions
+
+- The duration of the ring sound is a deliberately chosen
+ to be a clients decision.
+- The ring sound is a client choice as well. (It was considered to
+ add the ring sound to the notify event but how "ringing" actually should
+ look like is intentionally in control of the receiver. So that users can use
+ clients that suit them in terms of accessibility and personal taste.)
+
 ## Security considerations
 
 This is another timeline event where any room participant can send a push
@@ -130,11 +145,18 @@ effect on the receiver. Since ringing has to obey the mute settings, it is
 very easy for the targeted users to mitigate the "attack". It can be very
 much compared to spamming a room with "@room" messages.
 
+The default power level for `m.call.notify` is `50` and equivalent to the default
+power level required for `m.call.member` state events.
+
+Additional control is provided indirectly with the use of intentional mentions.
+Setting `"notifications":{"room":X}` allows to choose `X` for the power required
+level to ring the whole room.
+
 ## Unstable prefix
 
 While this MSC is not present in the spec, clients and widgets should:
 
-- Use `org.matrix.msc4075.` in place of `m.` in all new identifiers of this MSC. 
+- Use `org.matrix.msc4075.` in place of `m.` in all new identifiers of this MSC.
 (`m.call.notify`)
 
 ## Dependencies