1694610 - Firefox <=> Chrome transport-cc issue after session renegotiation

Status: UNCONFIRMED

(Core :: WebRTC: Signaling, defect, P2)

Description

[fs]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36

Steps to reproduce:

A WebRTC session is established between Firefox and Chrome. Only Chrome sends a video track Firefox is receive only. Now Firefox ads a track as well (videos or audio) and the session is successfully renegotiated.

Actual results:

After a few seconds the quality of the video track send from Chrome to Firefox degrades, the framerate drops to 2-3 fps and the video starts to lag for a few seconds.

Expected results:

The video quality should remain the same as before the renegotiation.

This issue exists with all Firefox versions >= 80. It seems to be caused by transport-cc (https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01 ) which was enabled in Firefox 80. When i disable transport-cc in Firefox by setting media.navigator.video.use_transport_cc to "fals"e OR remove all transport-cc related lines from the SDP the issue does not appear.

The same renegotiation works fine with Firefox <=> Firefox and Chrome <=> Chrome.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Signaling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Nico Grunbaum [:ng, @chew:mozilla.org]]

fs, thanks for your bug report. Could you upload the contents of about:webrtc after letting the video run for a bit?

Comment 3

[fs]

Sure... can i share this somehow non publicly since it contains some sensitive information such as IP addresses and URLs?

Comment 4

[Nico Grunbaum [:ng, @chew:mozilla.org]]

(In reply to fs from comment #3)

Sure... can i share this somehow non publicly since it contains some sensitive information such as IP addresses and URLs?

Sure, you can send it to my email if you like.

Comment 5

[fs]

OK i just sent it to your email.

Comment 6

[fs]

This is a little test case to reproduce the issue:

• Open this URL in Firefox and Chrome https://w2g.tv/rooms/fftest-7g10fv6j7h4sn52li0
• In Chrome enable your webcam (Button at the bottom)
• Wait until the video appears in Firefox
• In Firefox enable your microphone
• Wait a few seconds you should see the quality of the video send from Chrome to Firefox decrease, fps drop and that the video starts to lag

If you set media.navigator.video.use_transport_cc to false this does not happen.

Comment 7

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Michael, do you think this could be related to some of the bandwidth limiter issues that you have been looking into? Transport-cc is supposed to give a transport wide view of congestion.

Comment 8

[Michael Froman [:mjf]]

(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #7)

Michael, do you think this could be related to some of the bandwidth limiter issues that you have been looking into? Transport-cc is supposed to give a transport wide view of congestion.

Yes, it seems so. I just ran my tests with some instrumentation in place, and having turned off transport-cc I no longer see the drop in bandwidth after multiple negotiations. Interesting find. I'm going to link these bugs. They may be a straight up duplicate, but I'll wait a bit to decide that.

Comment 9

[Nazar Mokrynskyi]

Same here, disabling transport-cc with any means helps with https://bugzilla.mozilla.org/show_bug.cgi?id=1690832 too, thanks for viable workaround!

Comment 10

[fs]

Any update on this?