zeroRtpOnPause vs DTX and header bytes

mediasoup libraries
1

I am trying to get away from using DTX as I have hit some edge case issues where OPUS can generate bad noise when transitioning to comfort noise as a result DTX. (This issue seems fixed in the OPUS repo but it has been years since a release).

Anyway, I am experimenting with zeroRtpOnPause and seeing it generate a lot more header bytes than when using DTX and I am wondering if this is expected behavior. I am testing w/ an audio only producer on mediasoup-client@3.6.82

With DTX=false, zeroRtpOnPause=true (the results are also the same with both = false)
producer example

image
image963×192 5.99 KB

consumer example
image
image954×189 7.4 KB

With DTX=true, zeroRtpOnPause=false
producer example

image
image963×179 8.53 KB

consumer example
image
image953×187 6.47 KB

So my primary question is again, is this expected behavior? It seems odd to me that sending no RTP packets would still generate so much header traffic. Second (and I know this is more general webrtc and not mediasoup), it feels like 12Kbps is a lot of header data. It’s been a while since I dug around in webrtc-internals so maybe it’s a Chrome change or I just never noticed, just wondering if anyone else has noticed this.

2

zeroRtpOnPause just means that no packets are sent while the producer in mediasoup-client is paused. It doesn’t mean that it doesn’t send packets when enabled and the user doesn’t speak.

3

Sorry I should have clarified. I am pausing the producer on the client side (but not server side). The spikes in bytes received / bytes sent are where the producer is un-paused. The pausing/unpausing mechanism is based on push-to-talk keypress.

What I think is interesting is while using zeroRtpOnPause we do see the bytesSent graph and bytesReceived graphs drop to 0 as expected, but headerBytes remains stable at a fairly high rate.

4

This is rather strange. Do you see a “transceiverModified” event with “direction: inactive” in the internals as a result of pausing the producer?

5

Well, I’m an idiot. Thanks for pointing out to check this. I was configuring the producer incorrectly…

this.ProduceAudio({
              track: audioTrack,
              paused: pauseMediaOnStart,
              codecOptions: {
                ...BaseAudioCodecOptions,
                opusMaxAverageBitrate: this.ChannelBitrate * 1000,
                opusDtx: false,
                // zeroRtpOnPause: true, // WRONG spot
              },
              zeroRtpOnPause: true, // RIGHT spot
            })

An oversight on my part by putting it into the codec options. Lesson learned: always share a code snippet when asking for help.

Thanks!