This looks like out of scope for TE, hence adding the respective label for it to  triage further.

I am attaching a test page that exhibits this issue. Press the three buttons in order to establish a local video+audio call. The renegotiate button simply starts another offer/answer handshake; no changes to the peer connection. After the renegotiation takes place, both remote videos will be capped 64kb/s when they should be capped at 2Mb/s.

Deleted: BandwidthTest.zip 40.3 KB

BandwidthTest.zip 40.3 KB Download

Just for the record, since Opera updated recently.
I tested the page in Opera 43:
-v43.0.2442.1144 (PGO)
-Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 OPR/43.0.2442.1144

and in Opera 44:
-44.0.2510.857 (PGO)
-Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36 OPR/44.0.2510.857

Opera v43 (Chrome 56) did not show the problem. I updated Opera to v44 (Chrome 57) and now it shows the problem.

Tested the issue on Win-7 and Win-10 using chrome reported version #58.0.3029.19.

Attaching screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Downloaded the BandwidthTest.zip and extracted it.
2. Opened the index.html in the chrome browser.
3. Observed that out of three buttons only one button was enabled and the other two were disabled.

xsvengolix@ - Could you please provide any other sample html file to test this issue.

Thanks...!!

Deleted: 703903.mp4 1023 KB

	703903.mp4 1023 KB View Download

krajshree@ - I modified my test page and added more logging to see what's happening. I think it failed to find a camera and didn't continue. I made a recording of my own just so you can see the problem in action, but I'm hoping to have you reproduce it yourself.

Here are the steps I took on a Windows 7 machine:
1. Plugged in a Logitech c615. This will provide both the video and microphone needed for this test.
2. Opened the index.html in the chrome browser
3. Clicked the "Start Local Video" button.
4. Clicked Allow for both camera and microphone usage. Made sure the local video is active for both client A and client B.
5. Clicked the "Start Call" button. Made sure the remote video is active for both client A and client B.
6. Opened chrome://webrtc-internals, clicked on one of the two tabs, opened the stats graph for bweforvideo, and observed that the googAvailableSendBandwidth was at 2.0M
7. Clicked the "Renegotiate" button.
8. Observed that the googAvailableSendBandwidth drops to 64Kb and the video quality drops in client A and client B remote video.

Hope this helps!

Deleted: BandwidthTest2.zip 40.3 KB

BandwidthTest2.zip 40.3 KB Download

Deleted: recording.mp4 8.6 MB

	recording.mp4 8.6 MB View Download

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on Windows 10, mac 10.12.3 and Ubuntu 14.04 using chrome reported version #58.0.3029.19 and latest canary #59.0.3050.0.

Bisect Information:
=====================
Good build: 57.0.2938.0   Revision(435514)

Bad Build : 57.0.2939.0   Revision(435817)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/df48f17f5512fa5a727e63290aded588bc776751..a3baa5f8c33d60a57fc98d211da1d168c093ae52

From the above change log suspecting below change

Review url: https://codereview.chromium.org/2545763002

hbos@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note: Adding label ReleaseBlock-Stable, as it seems to be a recent regression.

Thanks...!!

From the roll, +sprang's CL https://codereview.webrtc.org/2531383002/ looks suspicious. Can you take a look?

+hta for SDP goodness; is this unexpected behavior? b=AS bitrate limiting both audio and video...

cc +pthatcher, +deadbeef for network layers.

This is certainly a bug.

The definition is in https://tools.ietf.org/html/rfc4566#section-5.8 - AS means "the application's concept of bandwidth", and if it's a per-media entry, one m= section shouldn't affect other m= sections.

Severity seems to be a bit high, since (according to the description)
1) It only affects systems that add "b=as" to the SDP
2) It only affects cases of renegotiation
So number of affected users isn't going to be tremendously high, but the users affected will be quite affected (crappy video quality).

A workaround is to not add the "b=AS" line to the audio.

I believe the issue was introduced in this CL, FYI: https://codereview.webrtc.org/2534173002

+holmer for suspected https://codereview.webrtc.org/2534173002

Thank you everyone. We're planning to cut RC today for next week Stable refresh release. Please note M57 Stable has been out since 03/09 for small percentage of Win/Mac users and 100% Linux users. 

As number of affected users isn't going to be tremendously high, I'm leaning towards NOT to block M57 Stable release for this unless CL listed at #14 is super safe to revert. 

+ abdulsyed@ & + anantha@ to take their input as wel..

I agree that this is a regression. I think it's a bit unclear how this should work, since b=AS affects the max bitrate of the bandwidth estimator, and the two m= sections share the same bandwidth estimator in Chrome.

IMO the change needed to revert to old behavior is trivial, so I have uploaded a CL which does that here: https://codereview.webrtc.org/2774123002/

Verified the fix in a ToT Chrome build.

Thank you holmer@.
Could you please land the revert on trunk, verify it on Canary and then request a merge to M57 and M58?

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/1ccf73f830fd3f4ca75b0e4fd15adc784991edaa

commit 1ccf73f830fd3f4ca75b0e4fd15adc784991edaa
Author: stefan <stefan@webrtc.org>
Date: Mon Mar 27 10:51:18 2017

Fix issue with conflicting behavior if setting a max BW with b=AS on both audio and video.

This reverts to previous behavior where b=AS only affects the codec bitrate for audio streams, and not the max bandwidth estimate.

BUG= chromium:703903 

Review-Url: https://codereview.webrtc.org/2774123002
Cr-Commit-Position: refs/heads/master@{#17386}

[modify] https://crrev.com/1ccf73f830fd3f4ca75b0e4fd15adc784991edaa/webrtc/media/engine/webrtcvoiceengine.cc
[modify] https://crrev.com/1ccf73f830fd3f4ca75b0e4fd15adc784991edaa/webrtc/media/engine/webrtcvoiceengine.h
[modify] https://crrev.com/1ccf73f830fd3f4ca75b0e4fd15adc784991edaa/webrtc/media/engine/webrtcvoiceengine_unittest.cc

It's most likely possible to work around this issue by instead of using b=AS for the audio m section, use the Opus fmtp parameter "maxaveragebitrate" https://tools.ietf.org/html/rfc7587#section-6.1. 

Example:
a=rtpmap:101 opus/48000/2
a=fmtp:101 maxaveragebitrate=64000;

For other codecs (if there are any other ones that support setting a max bitrate), it can be worked around for now by simply removing b=AS for the audio m section. It's not the ideal solution, but should help avoiding bad video quality.

Based on this I think we should consider only merging this to M-58.

Note also that the fmtp parameter "maxaveragebitrate" is the recommended solution for setting a max bitrate for opus.

Based on comment #23, rejecting merge to M57.

Please update the bug with Canary result. If change looks good in Canary, we will approve merge to M58. Thank you.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Your change is approved for M58. Please ensure to verify the fix, if all looks good merge ASAP so that it will be picked up for next Beta Release, RC cut today (Tuesday-03/28) at 4.00 PM PST.

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/0e43e9d0d6a2f8472c4f47c6fead5415d5472bf1

commit 0e43e9d0d6a2f8472c4f47c6fead5415d5472bf1
Author: Stefan Holmer <stefan@webrtc.org>
Date: Tue Mar 28 20:26:45 2017

Fix issue with conflicting behavior if setting a max BW with b=AS on both audio and video.

This reverts to previous behavior where b=AS only affects the codec bitrate for audio streams, and not the max bandwidth estimate.

BUG= chromium:703903 
TBR=minyue@webrtc.org

Review-Url: https://codereview.webrtc.org/2774123002
Cr-Original-Commit-Position: refs/heads/master@{#17386}
Review-Url: https://codereview.webrtc.org/2780783004 .
Cr-Commit-Position: refs/branch-heads/58@{#9}
Cr-Branched-From: f31969a584bcafe9406c214a9d4c3afb49d19650-refs/heads/master@{#16937}

[modify] https://crrev.com/0e43e9d0d6a2f8472c4f47c6fead5415d5472bf1/webrtc/media/engine/webrtcvoiceengine.cc
[modify] https://crrev.com/0e43e9d0d6a2f8472c4f47c6fead5415d5472bf1/webrtc/media/engine/webrtcvoiceengine.h
[modify] https://crrev.com/0e43e9d0d6a2f8472c4f47c6fead5415d5472bf1/webrtc/media/engine/webrtcvoiceengine_unittest.cc

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot