Bisecting gave:
python .\bisect-builds.py -a win64 -g 470437 -b 471639 --use-local-cache -- --user-data-dir=C:\Users\<user>
 
You are probably looking for a change made after 470988 (known good), but no later than 471003 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/ad1eaa6c4fd1c53f6e4be4da087a8c13a1e84058..362df6f9c79116139df5f89867599d4e0f61bbb9
 

magjed@ can you help with triage?

I can investigate from here. This is an issue that (as you mention) has popped up in various places, but this is the most reliable method I've seen of reproducing it. So hopefully I can get to the bottom of it this week.

I narrowed down the issue to MediaPermission::HasPermission being called, but no callback being called in return. This affects the FilteringNetworkManager class which is used to filter ICE candidates based on media permissions.

This CL appeared to introduce the issue: https://codereview.chromium.org/2842013002/

Specifically, it looks like CloseBindings in DidFinishNavigation is an issue, I assume because DidFinishNavigation isn't a case where the renderer side of the pipe is closed after all.

reillyg@, what do you think? Do you know what to do about this?

I need to dig into this further because I am not familiar with MediaPermissionDispatcher but my theory is that MediaPermissionDispatcher instances outlive navigations and so we need to put in logic to reconnect to the Permissions service when the connection is closed due to a navigation.

The other option is that DidFinishNavigation is not a case where we should be closing the pipe. This may be true because (I believe) navigations do not change the origin that renderer represents and so we do not need to close connections for security isolation purposes.

It looks like the MediaPermissionDispatcher is owned by the RenderFrameImpl (created in RenderFrameImpl::GetMediaPermission()) and so it will survive navigation as long as the RenderFrameImpl is reused.

If we add a connection error handler that resets permission_service_ then that should fix this issue because MediaPermissionDispatcher will automatically reconnect. There's a possibility of a race because early permission requests may be issued before the connection close signal is received and so the request will be caught up on the old connection. To avoid this issue we may want to explicitly close the old connection on navigation in the renderer.

This issue is also observed on Chrome OS with M60 60.0.3105.0 / 9578.0.0 dev

I have a patch which fixes this issue by handling the connection close on the renderer side.

https://chromium-review.googlesource.com/513387

I get the same behaviour from a data-channel-only Peer-connection (no audio or video and no permissions needed) . Reloading the page results in zero local candidates - closing the window or tab and then loading the page again works. 

This is version 60.0.3109.0 (Official Build) canary (64-bit) on Macos 10.12.5 

It does not happen on version 60.0.3096.4 on android.

tim: a datachannel-only thing might nonetheless check permissions to figure out if it is allowed to use the full set of local candidates.

 Issue 726116  has been merged into this issue.

Same probl. here with chrome 60 - macOS.
ICE works only for the first Webrtc session of the browser life.

 Issue 727489  has been merged into this issue.

Any updates on this?

Waiting for a review from nick@ so I can land the fix.

There's no updates on the CL for a week... Can we get it landed asap since the fix needs to be merged back to M60?

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

commit 355be367c161e11c42991b47f13ba4a915c9e283
Author: Reilly Grant <reillyg@chromium.org>
Date: Tue Jun 06 19:15:50 2017

Recreate MediaPermissionDispatcher's service connection on navigation

In r470992 we started closing PermissionService connections on
navigation however the lifetime of a MediaPermissionDispatcher is that
of the frame it is attached to. Since frames can be navigated the
service connection must be re-established after it is closed.

To prevent a race between the browser-side close and the navigation
committing in the renderer we close the connection from that side as
well.

Bug:  725038 
Change-Id: Id5d9d03537c7b7ee0997d77da4bafed055686521
Reviewed-on: https://chromium-review.googlesource.com/513387
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Nick Carter <nick@chromium.org>
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#477363}
[modify] https://crrev.com/355be367c161e11c42991b47f13ba4a915c9e283/content/renderer/media/media_permission_dispatcher.cc
[modify] https://crrev.com/355be367c161e11c42991b47f13ba4a915c9e283/content/renderer/media/media_permission_dispatcher.h
[modify] https://crrev.com/355be367c161e11c42991b47f13ba4a915c9e283/content/renderer/render_frame_impl.cc

I will request a merge to branch 3112 once this change has baked in a Canary release.

Fix works in Canary (61.0.3123.0) on Win10, Linux & Mac

confirmed fix seems ok in data channel only case on canary  61.0.3123.0 on mac. 
Thanks.

Thank you for verifying.

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

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

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

commit 4d2aa441f353f892cda7029b5bbd908777536010
Author: Reilly Grant <reillyg@chromium.org>
Date: Wed Jun 07 19:58:15 2017

Recreate MediaPermissionDispatcher's service connection on navigation

In r470992 we started closing PermissionService connections on
navigation however the lifetime of a MediaPermissionDispatcher is that
of the frame it is attached to. Since frames can be navigated the
service connection must be re-established after it is closed.

To prevent a race between the browser-side close and the navigation
committing in the renderer we close the connection from that side as
well.

Bug:  725038 
Change-Id: Id5d9d03537c7b7ee0997d77da4bafed055686521
Reviewed-on: https://chromium-review.googlesource.com/513387
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Nick Carter <nick@chromium.org>
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#477363}
Review-Url: https://codereview.chromium.org/2931513003 .
Cr-Commit-Position: refs/branch-heads/3112@{#231}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}

[modify] https://crrev.com/4d2aa441f353f892cda7029b5bbd908777536010/content/renderer/media/media_permission_dispatcher.cc
[modify] https://crrev.com/4d2aa441f353f892cda7029b5bbd908777536010/content/renderer/media/media_permission_dispatcher.h
[modify] https://crrev.com/4d2aa441f353f892cda7029b5bbd908777536010/content/renderer/render_frame_impl.cc

Tested the issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.5 using chrome latest Beta M60-60.0.3112.24 by following steps mentioned in the original comment. Observed that Sound is heard and No JavaScript console errors and working as expected. Hence adding TE-Verified label.

Please find the screen cast for reference.

Thank you!

Deleted: 725038.mp4 5.9 MB

	725038.mp4 5.9 MB View Download

 Issue webrtc:7770  has been merged into this issue.

 Issue 727393  has been merged into this issue.

Verified this issue on Chrome OS with M60 60.0.3112.80 / 9592.71.0 beta using the steps mentioned in the initial bug report. Audio is heard after leaving the current call and rejoining the same call/joining a new call.