high traffic even when video&audio are muted in both sides

[adbenitez]

in a Xiaomi test phone that display KB/s traffic in real time in the status bar:

• I see around 25KB/s traffic even when both sides have camera and microphone muted
• 28-30KB/s when both side have only audio enabled
• 450-500KB/s when audio and camera are enabled

the video is pretty high quality, half a megabyte per second I would say is too much and if the call is in relay mode we absolutely should avoid this and use much lower quality, can we lower that numbers some how?

and more concerning is why there is such already high traffic even when no video or audio is enabled???

[WofWca]

Addressing "garbage" traffic

I see around 25KB/s traffic even when both sides have camera and microphone muted

I confirm. With both audio and video muted with two localhost peers chrome://webrtc-internals/ shows that each peer sends ~60 000 bits / s, i.e. ~7 KB / s (14 KB / s for both directions). When I unmute the mic, the value climbs up to ~80 000 bits / s, i.e. ~9 KB / s (18 KB / s) for both directions.

When I instead call getUserMedia with video: false, audio: true, then it becomes ~20 000 with audio muted and ~45 000 bits / s with audio unmuted.

I would also expect that if everything is disabled, we'd see much lower traffic, but having both audio and video constantly muted is not something that people usually do when they're on a call.

I guess we can still investigate other, more proper ways to mute / disable video and audio, e.g. here is some article. Also the WebRTC browser spec mentions the "Hold" functionality where they replaceTrack(null), and do some extra stuff.

Following the advice from the article above, with the following hack I was able to achieve ~48 000 bits / s with camera disabled ("muted") i.e. roughly equivalent to when getUserMedia({ video: false, audio: true }); and ~18 000 bits / s with everything disabled.

diff --git a/src/lib/calls.ts b/src/lib/calls.ts
index 62f0727..318f10c 100644
--- a/src/lib/calls.ts
+++ b/src/lib/calls.ts
@@ -62,6 +62,25 @@ export class CallsManager {
   ) {
     this.peerConnection = new RTCPeerConnection(initialRtcConfiguration);
 
+    setInterval(() => {
+      for (const t of this.peerConnection.getTransceivers()) {
+        if (t.sender.track?.enabled === false) {
+          const originalTrack = t.sender.track;
+          t.sender.replaceTrack(null);
+          console.log('got muted, doing replaceTrack(null)')
+
+          const intervalId = setInterval(() => {
+            if (originalTrack.enabled !== true) {
+              return
+            }
+            console.log('restoring original track, replaceTrack')
+            t.sender.replaceTrack(originalTrack)
+            clearInterval(intervalId)
+          }, 100)
+        }
+      }
+    }, 1000);
+
     const setIceServers = (iceServers: RTCConfiguration["iceServers"]) => {
       this.peerConnection.setConfiguration({
         ...initialRtcConfiguration,

So I suppose traffic-wise this indeed seems like a more proper way to mute the media. Note that this does not require re-negotiation (which is good).

If newTrack was omitted or was null, replaceTrack() stops the sender. No negotiation is required in this case.

FYI Jitsi seems to be happy with just enabled = false:

https://github.com/jitsi/jitsi-meet/blob/23c831e9b0fd1701d9d8c056c8f6ca83a21d4cd3/react/features/stream-effects/audio-mixer/AudioMixerEffect.ts#L95-L103

They only use replaceTrack for some audio mixing stuff.

Edit: I posted a StackOverflow answer, with some better code: https://stackoverflow.com/questions/35512314/how-to-mute-unmute-mic-in-webrtc/79776960#79776960

About manually reducing audio / video quality

As discussed in private, if the concern is server costs / performance, then the server should be the one limiting bandwidth. Then the clients will use as much as they want, but no more than available.

But if the concern is "data saving", i.e. saving the quota, I think we are at a point where we're comparable to WhatsApp in terms of this, and the rest is some micro-optimization-level stuff which IMO is unlikely to bring us "orders of magnitude" results. 12 KB / s, total upload + download is pretty good IMO. ~0.7 MB per minute. According to some random articles on the internet, WhatsApp uses between 0.4 and 0.7 MB.
And to be clear: in a scenario where data saving is a concern I don't think it's worth talking about video. If you want to save data, you just disable video, instead of trying to make sense of 5 pixels that is the incoming video.

[WofWca]

BTW if one wants to more accurately measure how much traffic the calls use, see https://developer.mozilla.org/en-US/docs/Web/API/RTCStatsReport.

[adbenitez]

so you managed to improve/reduce the traffic usage when the video is disabled??? can you open a PR with your changes or is there a reason you abandoned the idea in the end?

[WofWca]

No particular reason. The traffic difference is just not that big for this to be of particular importance.
But I guess I can work on it, if you think that it actually is.

[adbenitez]

mmmh let's postpone it then after we see how the traffic goes on the server and are trying to optimize things, btw, the current TURN server software we have doesn't even support controlling bandwidth