Clarify each source is responsible for specifying mute/unmute/ended and constraints behavior

[jan-ivar]

From w3c/webrtc-pc#2915 (comment):

From yesterday's meeting I heard agreement that webrtc-pc should explicitly specify all causes of PeerConnection-sourced tracks being muted or unmuted, but some disagreement over what those causes are.

Since we have agreement we need to list causes here for event firing to be interoperable, the next steps I see are:

1. Open separate issue/PR on mediacapture-main to clarify each source is responsible for specifying its mute behavior.

Different sources (e.g. RTCPeerConnections or canvas) have different mute/unmute needs. Other specs need a clean slate to specify only what "MUST/MAY" happen (not what "MUST NOT" happen) which is generally considered a more extensible way of writing specs. Spelling this out should help readers, implementers, and interoperability.

Strangely, 17. Extensibility has no section for "Defining new sources of MediaStreams and MediaStreamTracks". That's probably where this should go.

Mediacapture-main could be also be clearer about when it's talking about microphone and camera sources, since these have unique mute/unmute needs tied to privacy features of the microphone and camera in the OS or UA to protect the end-user's privacy.

[dontcallmedom-bot]

This issue was discussed in WebRTC March 26 2024 meeting – 26 March 2024 (Clarify each source is responsible for specifying mute/unmute/ended and constraints behavior)