All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=906533

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=57943e7835982222ca15d2fb63046caa09213f3fb24f1c045edfdf963422b109


Bot(s) for this bug's original alert(s):

chromium-webrtc-rel-mac

Can you please have a look whether https://webrtc-review.googlesource.com/c/110622 is the cause for these changes and verify if it is expected.

asapersson@ can you tell me how to run this test?

(it is possible that that changed caused it).

(there is a behavior change that before you set local description & create media track you won't get available BWE).

I would need to check if that's the cause, and if so, it's expected. I can either change the test if that's the case, or I can revert the behavior to match the previous one.

I am willing to say that this is expected in "RunsOneWayCall60SecsAndLogsInternalMetricsDefault"

When you run one-way call there is no BWE estimation. The 300kbps that you are seeing in those graphs are hardcoded, and the hardcoded value can be changed. 

The two-way scenarios (or one-way with outgoing streams) still reports correct values from GoogCC.

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/b27578801673769f8a1393c2bd11b8c2fd7fb850

commit b27578801673769f8a1393c2bd11b8c2fd7fb850
Author: Piotr (Peter) Slatala <psla@webrtc.org>
Date: Wed Dec 19 21:19:01 2018

Register stat callbacks after rate observer is registered.

Currently the stats callback is registered too early.
For now we ignore media transport for these callbacks (it was ignored
already), and we will introduce changes to media transport in the
future.

Bug: webrtc:9719
Bug:  chromium:906998 
Bug:  chromium:906533 
Change-Id: I24c0265d46ec2eb35743de6cd96a11d8c41fefbe
Reviewed-on: https://webrtc-review.googlesource.com/c/114904
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26062}
[modify] https://crrev.com/b27578801673769f8a1393c2bd11b8c2fd7fb850/call/call.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5dc073b965af6b98b556d7941d665cba3fd09904

commit 5dc073b965af6b98b556d7941d665cba3fd09904
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Thu Dec 20 02:43:45 2018

Roll src/third_party/webrtc e92035179825..b27578801673 (2 commits)

https://webrtc.googlesource.com/src.git/+log/e92035179825..b27578801673


git log e92035179825..b27578801673 --date=short --no-merges --format='%ad %ae %s'
2018-12-19 Peter) Slatala Register stat callbacks after rate observer is registered.
2018-12-19 chromium-webrtc-autoroll@webrtc-ci.iam.gserviceaccount.com Roll chromium_revision 7ebbeeebe7..bdf260ef72 (617780:617896)


Created with:
  gclient setdep -r src/third_party/webrtc@b27578801673

The AutoRoll server is located here: https://autoroll.skia.org/r/webrtc-chromium-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux_chromium_archive_rel_ng;luci.chromium.try:mac_chromium_archive_rel_ng

BUG= chromium:906998 , chromium:906533 ,chromium:None
TBR=webrtc-chromium-sheriffs-robots@google.com

Change-Id: I076149b9302b111693c4692a5295268fe19b99b7
Reviewed-on: https://chromium-review.googlesource.com/c/1385566
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#618084}
[modify] https://crrev.com/5dc073b965af6b98b556d7941d665cba3fd09904/DEPS

This value shouldn't be dependent upon, but the metric is now back to the original value. Essentially, before the connection starts, the bitrate estimate is a 'starting bitrate' and has no relation to the actual bitrate.