1332031 - TIAS cancels bitrate limiting when additional m-sections appears

Status: RESOLVED INCOMPLETE

(Core :: WebRTC: Networking, defect, P3)

Description

[Alexander Abagian]

Attachment: charts.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.92 Safari/537.36 Vivaldi/1.6.689.34

Steps to reproduce:

Chrome and Firefox webrtc clients entered the conference via SFU.
Firefox has m=TIAS:500000 at every video m-section.

Chrome statisics shows incoming 500 kbps from Firefox.

Then another Chrome webrtc client entered the conference.
Firefox has got additional two m-sections; video one has the same m=TIAS:500000.
Chrome statisics shows that Firefox bitrate arises to ~1800 kbps.

The second Chrome leaved the conference. Firefox high stays 1800 kbps.




Actual results:

Firefox webrtc client arises output bitrate as the TIAS hasn't been in use.


Expected results:

Firefox webrtc client should keep output bitrate at 500 kbps.

Comment 1

[Alexander Abagian]

Attachment: 2 participants.txt

Comment 2

[Alexander Abagian]

Attachment: 3 participants.txt

Comment 3

[Alexander Abagian]

Reproduceable at developer FF 52.0a2 (2017-01-18) and current release 50.1.0.

Comment 4

[Alexander Abagian]

You can try it here :

http://go.videomost.com/service/wjoin/?confid=moz&confpass=moz

(This is not a release version, problems with entering the conference could exist).

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Nils, can you help triage this?

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Can you try this with Firefox 53 (or 54)?  Since I don't think an Aurora 53 has gone out yet, use Nightly/54.  This code changed dramatically in 53 due to landing a major update to the underlying code.

Comment 7

[Alexander Abagian]

I've tried with Nightly 54.0a1 (2017-01-25) (64-bit).

It does not not show video at all. Another side too. If I change to Aurora 52.0a2 (2017-01-23) (32-bit), the video is OK.

Comment 8

[Alexander Abagian]

The same problem with 54.0a1 (2017-01-25) (32-bit).

Comment 9

[Nils Ohlmeier [:drno]]

I can't get any version of Firefox connect to the bundled video transport on port 9000. Firefox keeps sending STUN requests but never gets an answer. On port 8000 for the audio it works.

If you manage to repro the original problem when everything connects can you get us NSPR log files https://wiki.mozilla.org/Media/WebRTC/Logging#Signaling_.28SDP_offer.2Fanswer_handling.29 but with the following NSPR_LOG_MODULES string instead:
  NSPR_LOG_MODULES=timestamp,signaling:5,mtransport:5,jsep:5,mediapipeline:5,MediaManager:5,MediaPipelineFactory:5

Comment 10

[Alexander Abagian]

Attachment: nspr.zip

firefox nspr.log with NSPR_LOG_MODULES=timestamp,signaling:5,mtransport:5,jsep:5,mediapipeline:5,MediaManager:5,MediaPipelineFactory:5

Comment 11

[Alexander Abagian]

Nils,

Logged the scenary : 
- Chrome 1 webrtc (192.168.125.39) entered the conference
- Firefox 50.1.0 webrtc (192.168.125.138) entered the conference
- Chrome 2 webrtc (192.168.125.138) entered the conference

The server ip is 212.158.160.167

FF bitrate increases exactly as I described.

BTW I've seen you when you tried it.

Comment 12

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 13

[Byron Campen [:bwc]]

Our TIAS code has changed some since bug 1342727 landed; is this still broken?