restrictOwnAudio is a constrainable property and setting for whether or not own audio restriction is applied, meaning:

When own audio restriction is applied, the user agent MUST attempt to remove any audio from the audio being captured that was produced by the document that performed getDisplayMedia. If the user agent is not able to remove the audio through processing it SHOULD remove the audio by excluding the document's audio from being captured. If this results in no audio being captured, the user agent MUST keep the track muted until it is able to capture audio again.

The original problem that we were trying to solve was if I am screensharing I may want to include the capture of audio, however if that audio contains the playout of remote RTCPeerConnection tracks, when I share this presentation back to the remote participants, they will hear themselves which would be maddening.

restrictOwnAudio attempts to solve this by saying to exclude audio that the application (i.e. document) is producing, but recognizing that all implementations may not be able to do this under all circumstances, there is some SHOULD language that is meant to convey that it's OK to capture less stuff than we ideally would want to as long as we can ensure that the document audio isn't included.

But there are a few issues with this:

• Saying you "MUST attempt to remove" else you "SHOULD" something else is not really testable.
• The vague choice of language may result in different browsers doing different things.
• This definition fails to capture (no pun intended) the most important thing about restrictOwnAudio, which is that we want to remove remote track audio. In some cases it may be more difficult to remove "document" than to remove "peer connection".

Proposal
Let's rephrase this to:

1. MUST remove audio produced by RTCPeerConnection remote tracks.
2. SHOULD remove document audio (but system-wide audio that includes "document audio w/o PC audio" is still better than no audio at all).
3. MAY cause muting if muting was the only way to achieve 1).

This would allow web developers to trust that restrictOwnAudio solves their use case and help browser implementors align on behavior by being more testable. @o1ka @guidou