You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
jan-ivar
changed the title
Clarify each source is responsible for specifying mute/unmute behavior
Clarify each source is responsible for specifying mute/unmute/ended behavior
Feb 20, 2024
jan-ivar
changed the title
Clarify each source is responsible for specifying mute/unmute/ended behavior
Clarify each source is responsible for specifying mute/unmute/ended and constraints behavior
Feb 20, 2024
From w3c/webrtc-pc#2915 (comment):
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.
The text was updated successfully, but these errors were encountered: