"checkPeerMedia" unmutes audio and video when a connection is established

When the MCU is used checkPeerMedia is used to unmute audio and video when some bytes were received according to the media track stats. However, it seems that in some cases this could lead to a peer being wrongly unmuted (in the receiving end; the original peer is still muted); for example, when joining a call in which a participant is muted.

Besides that I have also noticed that when a screen is shared the peer that receives the screen wrongly marks the video as available too; this is caused by the bytes received in the video track of the screen, which triggers an unmute event of video type and causes the normal video to be set as available.

@fancycode The screen sharing case can be fixed simply by not calling startCheckPeerMedia if the peer is a screen peer, because shared screens are not expected to be muted (in the sense of making the video not available, not audio muting), but I have no idea about why it happens for the microphone nor how it can be fixed in that case.

Note that the steps in scenario 1 sometimes work as expected, but it is caused by the audio off information sent when the connection is completed arriving after checkMediaPeer already unmuted the audio.

Steps to reproduce (Scenario 1)

• Setup Talk to use the MCU
• As user A, start a call
• As user A, disable microphone in the Talk UI
• As user B, join the call

Expected behaviour

User A is muted, and user B sees an indicator that user A is muted.

Actual behaviour

User A is muted, but user B does not see an indicator that user A is muted.

Steps to reproduce (Scenario 2)

• Setup Talk to use the MCU
• As user A, start a call with a camera available
• As user B, join the call
• As user A, disable camera in the Talk UI
• As user A, share local screen

Expected behaviour

User A video is disabled, and user B sees the avatar of user A.

Actual behaviour

User A video is disabled, but user B does not see the avatar of user A (a black video is shown instead) and user B sees an indicator that video of user A is enabled.

Start in js/webrtc.js at checkPeerMedia, startCheckPeerMedia, and the screen-peer handling around the linked lines. Reproduce both MCU scenarios to trace how received media-track bytes affect mute and video availability, including the connection-completion audio-off message. Done means muted audio and video remain unavailable to the receiver while screen sharing does not mark the normal video as available.