UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce the problem:
1. Create a webrtc session with audio and video captures
2. Set a 2 Mpbs limit on the bandwidth using b=AS:2048 line in the sdp. I had set this as an attribute under the video media line.
3. Once the session is stable, add another track to the same stream and renegotiate the session through a new offer/answer. The usecase here is starting a screen capture during a video session
4. Observe the bandwidth usage

What is the expected behavior?
Even after the screen capture track is added, the overall bandwidth should be 2 Mpbs (not considering audio here)

What went wrong?
The bandwidth usage doubles on adding a new track to the session. Instead of splitting the available BW between the two tracks each track is allocated 2 Mbps.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 63.0.3239.132  Channel: stable
OS Version: OS X 10.12.4
Flash Version: 

The strange thing here is that, it works fine under the following conditions
1. In the process of adding the new track, if there is a change in the BW then it works fine. For example, in the second offer/answer that was initiated to signal the new track, if the answerer changes the BW from say 2048 to 2047, then the bandwidth gets equally split between the two tracks
2. If I disable transport-cc and other extensions that negotiates the sender side rate control and fallback to REMB and receiver side rate control the bandwidth gets split equally and the overall bandwidth usage stays within the limit specified by the b line.

In essence it appears to me that, chrome does behave the right way under certain conditions but misses out on a few. When a new track gets added to the stream or a track gets removed the bandwidth estimation probably has to be reset to take into account the change in number of media flows.