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,8 +49,7 @@ 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
@@ -72,8 +71,15 @@ Notify conditions depend on:\
   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,6 +145,13 @@ 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: