Kindly refer the Bisect Info:

OS: Windows (7,8,8.1,10),Linux (14.04 LTS),Mac OS X(10.12.6,10.13.1,10.13.4)

Good Build:66.0.3342.0(Revision:534888)

Bad Build:66.0.3343.0(Revision:535276)

You are probably looking for a change made after 535268 (known good), but no later than 535269 (first known bad).

CHANGE-LOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

https://chromium.googlesource.com/chromium/src/+log/c9ee8b32a9740805d519c57cef154c9d30b7db98..20f8faff76403f9e9353af778fd39617e784a599

Suspect:https://webrtc.googlesource.com/src.git/+/8b0ebb9484fb3b97514c0492407e20aca50b0908
(Got Auto-Roll group in bisect CL,Hence assigning it to the tommi)

@tommi: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.


Thank You!

Adding release blocker label for this issue.Please reduce priority or remove if not the case.

Thank You!

The roll contains these two CLs (looking now). Please let me know if there are other things I should be looking at:

6780c51 Use SRTP_AES128_CM_SHA1_80 by default instead of SRTP_AES128_CM_SHA1_32. by Joachim Bauch · 18 hours ago
8b0ebb9 Change FakePeriodicVideoCapturer to use a TaskQueue instead of Thread. by Tommi · 19 hours ago

Taylor - could it be that srtp change caused this?

https://webrtc-review.googlesource.com/c/src/+/41420

Just tested hangouts in canary myself and see this error in the console:

Uncaught (in promise) DOMException: Failed to set remote answer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to setup SRTP..

Adding jbauch@

Revert has landed in WebRTC:
https://webrtc-review.googlesource.com/c/src/+/49880

Now working through the bots and should land in Chromium soon.

thanks Tommi@ - can you please land the revert in today's Canary branch also, branch:3343? We'll use this for our dev candidate. 

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

commit 014a579d442696416fe5055ffdae8f81e6db26e3
Author: Taylor Brandstetter <deadbeef@chromium.org>
Date: Thu Feb 08 21:28:52 2018

Roll src/third_party/webrtc/ 8e545eee..6780c51b2 (9 commits)

https://webrtc.googlesource.com/src.git/+log/6780c51b2351..8e545eee1e72

$ git log 8e545eee..6780c51b2 --date=short --no-merges --format='%ad
%ae %s'

This includes a revert of "Use SRTP_AES128_CM_SHA1_80 by default
instead of SRTP_AES128_CM_SHA1_32", which caused a regression (see
linked bug).

Bug:  810292 
Change-Id: If1e433a7ca23237e6c77a316b16448af7d5df31a
Reviewed-on: https://chromium-review.googlesource.com/909568
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Cr-Commit-Position: refs/branch-heads/3343@{#3}
Cr-Branched-From: ceb89e8235ab8b934c9cbe424543ccdd160933d4-refs/heads/master@{#535276}
[modify] https://crrev.com/014a579d442696416fe5055ffdae8f81e6db26e3/DEPS

Sorry, that was the wrong DEPS file. Here's a CL that updates the right DEPS file, though I can't land it myself without an LGTM: https://chrome-internal-review.googlesource.com/c/chrome/tools/buildspec/+/566231

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/5ee27e23647bc2782a11cc293dde54751311d2d6

commit 5ee27e23647bc2782a11cc293dde54751311d2d6
Author: Taylor Brandstetter <deadbeef@google.com>
Date: Thu Feb 08 22:08:29 2018

Able to reproduce the issue on Chrome 66.0.3343.0/CrOS10386.0.0- kip

Should be fixed in the next build.

Rechecked the above issue on OS: 
Windows (7,8,8.1,10),Linux (14.04 LTS),Mac OS X(10.12.6,10.13.1,10.13.4) with chrome version:66.0.3343.3 and the issue works as intended.

Kindly refer attached screen cast for reference.


Thank you!

Deleted: Hangoutverified.mp4 1.2 MB

	Hangoutverified.mp4 1.2 MB View Download

Verified the fix on Chrome66.0.3344.0/CrOS10397.0.0 - Kip