Audio-only calls should use bitrate adaptation when possible. A/V calls should adapt the audio bitrate down when the total number of bits gets "low", with a fair bit of hysteresis.

This will probably need some tweaks on debugging and to the algorithm for allocating audio bits, so there will be a followup, and I haven't run Trys yet. Note this patch requires the update_49 queue, so it's gated on that.

[Tracking Requested - why for this release]: the blocking bug landed in 53. Getting ready to finish cleanup and testing of this patch for 53

Tracking 53+ per Comment 2.

Hello! Is this still going to land in Firefox 52?

(In reply to Iulia Cristescu, QA [:IuliaC] from comment #4) > Hello! Is this still going to land in Firefox 52? No. I hope to land this in 53 (the blocking bug, webrtc.org 49 update, landed in 53)

Will need un-bitrotting, and testing/tests (though we don't have great (ok, any) ways to test actual bitrate adaptations)

(In reply to Randell Jesup [:jesup] from comment #6) > Will need un-bitrotting, and testing/tests (though we don't have great (ok, > any) ways to test actual bitrate adaptations) Are you referring to automation or for development? For development I would run a TURN server on a Linux machine and control the throughput through iptables or other tools. Or maybe you can even do it directly on the Linux dev machine? On Mac I installed Apple's "Network Link Conditioner", but I have to admit I never tried it for real.

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