MSC3291: Muting in VoIP calls

proposals/3291-muting.md

@@ -27,18 +27,22 @@ has the common VoIP fields as specified in
 [MSC2746](https://github.com/matrix-org/matrix-doc/pull/2746) (`version`,
 `call_id`, `party_id`) and a `sdp_stream_metadata` object which is the same
 thing as `sdp_stream_metadata` in `m.call.negotiate`, `m.call.invite` and
-`m.call.answer`. The client sends this event the when `sdp_stream_metadata` has
+`m.call.answer`. The client sends this event when the `sdp_stream_metadata` has
 changed but no negotiation is required (e.g. the user mutes their
 camera/microphone).
 
 All tracks should be assumed unmuted unless specified otherwise.
 
-It is suggested `video_muted` (but not required) should determine if a user sees
-video but `audio_muted` only determines if a user is shown a mute indication
-rather than actually muting the audio track on the receiving side. This is
-suggested because if the track is muted using the WebRTC `disabled` property,
-there can be delay between the audio track getting unmuted and the client
-receiving the `m.call.sdp_stream_metadata_changed` event.
+Clients are recommended to not mute the audio of WebRTC tracks locally when a
+stream has the `audio_muted` field set to `false`. This is because when the
+other user unmutes themselves, there may be a slight delay between their client
+sending audio and the `m.call.sdp_stream_metadata_changed` event arriving. If
+`enabled` is set to `false`, then any audio sent in between those two events
+will not be heard. The other user will still stop transmitting audio once they
+mute on their side, so no audio is sent without the user's knowledge.
+
+The same suggestion does not apply to `video_muted` - there clients _should_
+mute video locally, so that the receiving side doesn't see black video.
 
 ### Example
 
@@ -75,8 +79,8 @@ which will waste bandwidth.
 
 ### Only disabling the corresponding track
 
-This is the solution that some clients (e.g. Element) use at the moment. While
-this is almost instantaneous, it doesn't allow the other side to know the
+This is the solution that some clients (e.g. Element Android) use at the moment.
+While this is almost instantaneous, it doesn't allow the other side to know the
 opponent's mute state. This leads to the opponent showing a black screen for a
 muted video track and not doing anything for a muted audio track which is bad
 for UX.