Understanding RTP Chrome's replaceTrack() for audio muting

[Juan Navarro]

Hi,
I'm working on reducing the wasted bandwidth that gets used after muting the audio during an audio-only call; the ideal, unrealistic goal would be 0 packets sent when the audio is muted, but in practice anything below the current 5 KB/s is already an improvement. For simplicity's sake, I'm focusing only on a one-way call, i.e. one `sendonly` peer sending audio to a `recvonly` peer. Lastly, the mute/unmute operation is expected to work as a push-to-talk (kind of a walkie-talkie), so the audio should start as close to "instantly" as possible; for this reason, I'd rather avoid any renegotiation or fully stopping the streams.

I've tested what happens when the sender calls `RTCRtpSender.replaceTrack(null)`, which works fine since Chrome 65, and it is very promising. This reduces the bandwidth wastage from 5 KB/s to around 300 B/s, and a big part of those are due to my receiver, which keeps sending a lot of RTCP Receiver Reports.

After the call to `RTCRtpSender.replaceTrack(null)`, Chrome stops sending both RTP packets and RTCP Sender Reports. That's OK. But if I change my receiver to force stop sending Receiver Reports during mute periods, then something strange happens: Chrome becomes "crazy" and starts sending a lot of RTCP Receiver Reports (yes, Receiver), and also lots of STUN Binding Requests. We're talking about a rate of around one per second of each, maybe a bit less.

I guess that Chrome must be identifying the lack of RTCP RRs as a symptom of bad network, and for that reason it raises the rate of those STUN Binging Requests; but my receiver does reply correctly to each one of those, so I thought Chrome should be able to know that there is no networking problem. I'd like to know a bit more about this topic from someone who is more familiar with how Chrome is expected to work in this situation.

About the RTCP Receiver Reports that Chrome starts sending, I've no idea why.

Could someone offer a bit of help on this?

Thanks,
Juan

[Taylor Brandstetter]

I'm not sure about the RTCP receiver reports, but I believe sending one STUN binding request per second is normal. They're used as connectivity checks, causing the ICE state to change to "disconnected" if they fail repeatedly. They also function as a "consent" mechanism (see this spec), though that document only recommends sending them every 5 seconds, not every 1 second.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/501fc53e-6e27-423d-8e80-59cf233b93b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Juan Navarro]

Hi, thanks for the info!

I've reviewed the behavior of both peers and realized that Chrome does not actually increase the rate of messages when the audio mute is in place; it is already higher than I expected even while the audio is streaming.

I was already familiar with the keepalive packets that are used by ICE to maintain connectivity between peers (i.e. sending regular STUN Binding Requests in order to refresh all intermediate NAT bindings). However I expected that these packages would be sent at a pace of around 1 packet each 15 seconds. RFC 5245 states so in section 10. Keepalives (https://tools.ietf.org/html/rfc5245#section-10):
   

   If there has been no packet sent on the candidate pair ICE is using
   for a media component for Tr seconds (where packets include those
   defined for the component (RTP or RTCP) and previous keepalives), an
   agent MUST generate a keepalive on that pair.  Tr SHOULD be
   configurable and SHOULD have a default of 15 seconds.  Tr MUST NOT be
   configured to less than 15 seconds.

However, after careful inspection with Wireshark, Chrome is sending STUN Binding Requests at an average rate of 0.5 per second, i.e. once each 2 seconds. Meanwhile, it also sends RTCP Sender & Receiver Reports while the audio stream is flowing, and keeps sending RTCP Receiver Reports when the audio stream is stopped.

I'm now headed to check on that consent mechanism in the spec you linked, so thank you for the link. Will see is I can somehow control the rate at which Chrome is sending all those status packets.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.