Mute Yourself

[erikzenker]

Currently it is only possible to mute other conference participants. It would be nice to provide a self mute button.

[thammi]

Calling toggleMute() on LocalPeer should work. It sends silence/black.

For not sending anything we need to call replaceTrack(null) on the corresponding RTCRtpSender (which is not distinguishable from connection problems) or we have to set direction to recvonly on the corresponding RTCRtpTransceiver (which requires renegotiation).

[janlelis]

I agree, this is an urgently needed feature.

Related front-end issue: palavatv/palava-web#9

This API also looks promising:

• https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack/enabled
• Examples: https://stackoverflow.com/questions/34469618/how-to-add-audio-video-mute-unmute-buttons-in-webrtc-video-chat

Also, we need to decide if this should be implemented in the front-end or in the client-library

[erikzenker]

Also, we need to decide if this should be implemented in the front-end or in the client-library

What does make sense to you?

IMHO providing the feature in the client-library make sense to me.

[thammi]

Muting tracks using enabled, as described in the links, is implemented in palava-client. It is available as toggleMute() on LocalPeer as mentioned above.

[janlelis]

Muting tracks using enabled, as described in the links, is implemented in palava-client. It is available as toggleMute() on LocalPeer as mentioned above.

Awesome, didn't notice this was possible already! Should work in the same way for video tracks, too, shouldn't it?

For not sending anything

Could you elaborate a little, what anything means here? Something in the direction of only a null value is sent instead of not sending anything?

[thammi]

enabled makes video tracks send (and display) black and audio tracks send (and play) silence. This is not reversible by remote peers and does not consume much bandwidth. It is not possible to distinguish between this and a normal track on the remote peer though afaik. I was assuming toggleMute() could handle both already, but that is easy to extend.

Not sending anything means either just stopping to send the track using replaceTrack(null) (which sets mute on the remote track and triggers associated events and is not distinguishable from losing the network packages) or setting the direction to recvonly and renegotiating which stops the remote track and removes it from the remote stream.

Both methods would require a way to get the transceiver/sender of the track which would require some new concepts in palava-client or some rather hacky workarounds. rtc-lib has the ability to add custom transceivers while adding a stream to support these use cases for example. A workaround could be searching the corresponding sender for a track in the PeerConnection.