googAvailableReceiveBandwidth / RTCIceCandidatePairStats.availableIncomingBitrate / Bandwidth Estimation (REMB/transport-cc)

[Jose Antonio Olivera Ortega]

Hi there!

Can transport-cc mechanism provide these (googAvailableReceiveBandwidth  / RTCIceCandidatePairStats.availableIncomingBitrate) stats?

When transport-cc is removed from SDPs (just keep goog-remb) these stats are provided. If both are present googAvailableReceiveBandwidth and RTCIceCandidatePairStats.availableIncomingBitrate are always 0.

It is a bit confusing which bandwidth stats can be provided depending on the bandwidth estimation mechanism being used. If these cannot be provided with transport-cc what's the alternative way to have info about bandwidth in the receiver side?

Thanks!

Cheers,
JAOO.

[Philipp Hancke]

that is a tough one. I'll try to explain in way too few lines

Make sure to read

https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc#section-5

https://datatracker.ietf.org/doc/html/draft-holmer-rmcat-transport-wide-cc-extensions-01#section-3

https://datatracker.ietf.org/doc/html/draft-alvestrand-rmcat-remb-03#section-3

In REMB the bandwidth is estimated at the receiver based on the abs-send-time and the receive timing and variations thereof. Hence you get the availableIncomingBitrate at the receiver and the sender gets the information via RTCP.

In transport-cc the receiver does not know the send times so can not calculate an available bitrate. Only the sender can do that. Hence you only get it at the sender.

--

---
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-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/76594eee-ee73-4f89-aa51-184b3d09e0afn%40googlegroups.com.

[Harald Alvestrand]

Short answer: No.

When using transport-cc, the estimation is done on the sender side, and the receiver knows nothing about what the estimate is.

When both are supported, Chrome will choose to use transport-cc and not use goog-remb.

The receiver can observe the actual receive rate, but has no information about how much more the sender thinks it can send.

If the stats return 0 when not using goog-remb, this is a bug; it should be undefined (see https://w3c.github.io/webrtc-stats/#dom-rtcicecandidatepairstats-availableincomingbitrate). Please file a bug on bugs.webrtc.org if this is the case.

As to alternate means: What do you need to know, why do you need it, and can you access this data on the sender side?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiKq55__X1CTVMKYTxQ8RU5iL5U1tgxbUMp95rrouxuLuQ%40mail.gmail.com.

[Jose Antonio Olivera Ortega]

Philipp, Harald; thanks for your answers.

I know how both bandwidth estimation mechanisms work (at a high level so will read more about it the links Philipp). The thing here is the fact that an existing stats value (VideoBwe.googAvailableReceiveBandwidth might
be 0) for some situations (whether using REMB or not) is a bit confusing. I just wanted to confirm that transport-cc just cannot provide these stats.

Harald; while RTCIceCandidatePairStats.availableIncomingBitrate is not part of the JSON string of a RTCStatsReport instance (I am using them) when transport-cc used (which can be considered correct)
I see googAvailableReceiveBandwidth being 0 when iterating over a webrtc::StatsReport instance. In any case I would not consider this a bug.

I just looking for a way to observe the actual receive rate. I needed to perform some kind of analysis. Yes, I have access to stats in both side.

Thanks!

Cheers,
JAOO.

[Harald Alvestrand]

Than availlableOutgoingBitrate (sender side) should be the number to look for!

The actual receive rate should be calculated using bytesReceived, of course.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/afd3c03d-8b1c-484a-88f3-08c1e2af2a10n%40googlegroups.com.

[Jose Antonio Olivera Ortega]

Hey,

Got it. Thanks.

I am looking through the code for the place where it is decided to do REMB or transport-cc (when both are supported). I am about to give up, I am blind. May I know where that is happening please? Thanks.

SDP munging is the way I am "forcing" REMB with but I wondering about any other existing way to force that through the native API. I had a look at https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/api/peer_connection_interface.h but could not find anything to let the engine to do REMB or transport-cc.

Cheers,

JAOO.

[Philipp Hancke]

I don't think there is an API to control rtcp-fb but if you use the fancy https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/rtp_transceiver_interface.cc;l=61;drc=570d2d089d1d822d8b29111ea92d7e2e12cce67b;bpv=1;bpt=1

you can remove the transportcc extension which should cause it not to be negotiated.

(or you munge, during signalling that is ok)

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/4acea074-0826-4cf3-988e-bf8d701c8ef4n%40googlegroups.com.