Tried testing the issue on chrome version# 71.0.3578.98 using Mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and installed Network Link Conditioner from Apple Developers Page
2) Installed Network Link Conditioner and from the dropdown selected "100% LOSS"
3) Tried navigating to random webpage, but unable to connect

@Reporter: Please find the above mentioned information and attached screencast for your reference, could you please let us know how to Establish a peer connection with Canary(as mentioned in steps to reproduce the problem in comment# 0), provide your feedback on it which help in further triaging it. If possible provide screencast of the issue which help in better understanding.

Thanks!

Deleted: 920188.mp4 2.4 MB

	920188.mp4 2.4 MB View Download

Hello,

Sorry for not being clear enough. I've attached a screencast demonstrating the issue with https://appr.tc/. The dark window is chrome stable, light window is canary.

As you can see in the video: stable detects the degraded network connection and reports
the ice states "disconnected" and "failed". Whereas canary doesn't.

Hope this clears it up.

Deleted: ice.mp4 3.1 MB

	ice.mp4 3.1 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

easier repro:
1) go to https://webrtc.github.io/samples/src/content/peerconnection/pc1/
2) make a call
3) call pc2.close()
In stable that makes pc1.iceConnectionState go to disconnected. In canary it doesn't. Probably the connectionState changes?

jonasolsson@ this is probably related to the recent changes, can you take a look when you're back?

Able to reproduce the issue on reported chrome reported version# 73.0.3666.0 and on latest chrome# 73.0.3667.0, same issue is not seen on Stable# 71.0.3578.98 and on Beta# 72.0.3626.53 using Mac 10.12.6 hence providing Bisect Info
Note: Issue is specific to Mac OS

Bisect Info:
================
Good build: 73.0.3644.0
Bad build: 73.0.3645.0

You are probably looking for a change made after 617475 (known good), but no later than 617476 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/f59e15e2eaaae59abacb8e93182137c64b4f1562..e902e08dc0c67fd7598a4a4e431177f89c00f350
Change-Id: I1e7c13f22e40b534e732ecd3fc103f617306f00a
Reviewed-on: https://chromium-review.googlesource.com/c/1371392

@Jonas Olsson: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable for M-73, feel free to remove it if not applicable.

Thanks!

I confirm this issue on Windows too => Impossible to detect a P2P disconnection since the exact relevant change: no RTCPeerConnection.oniceconnectionstatechange event or RTCPeerConnection.onconnectionstatechange, impossible to get disconnection information whatever the way used.

Yep, between M71 and M72 we completely switched the iceConnectionState implementation in order to better align with the standard, and that's where these changes come from.

The old implementation signaled "disconnected" when the underlying connection state reverted to "connecting" from "connected" or "completed": https://cs.chromium.org/chromium/src/third_party/webrtc/pc/peerconnection.cc?rcl=aaa99a93e288f0354b03b96588d0624ee910d2ed&l=5644

The new one expects the transports to report disconnects, but that part isn't implemented yet. I'll file a bug to implement that, and do something about it. I don't think this is a release blocker, as the new behavior is technically spec-compliant, but that's no excuse not to improve things.

if you break disconnected and failed, you will break ice restarts (which are triggered by those state changes). This is very common and would be a severe regression in UX for most applications.

Agreed, that's no good. I've written up a CL to handle disconnected/failed similar to how we used to, and will report back when it has landed.

With https://webrtc-review.googlesource.com/c/src/+/117565 landed the error signaling should be very similar to how it used to be.

Friendly ping to get an update on this as it is marked as RBS & stable release is coming soon.
Thanks..!

I'm gonna mark this as fixed. The CL in #14 should fix this, and even if it doesn't we've temporarily reverted to the old implementation while another bug is investigated.