Is that the correct Chrome version?

no... tested in 72.0.3611.0 but filed with 70.

Ok, just making sure, but it was Windows, right?

yes. Copying from the crash bug:
Chrome Version: 72.0.3610.2
Operating System: Windows NT 10.0.17763

Can you reproduce this?

Can you include a webrtc-internals dump?

I'll try to repro on Windows.

re-attaching from https://bugs.chromium.org/p/chromium/issues/detail?id=905597#c1
-- import on http://fippo.github.io/webrtc-dump-importer/ unless you like reading JSON.

Chrome seems to be sending pings but never receiving. I do not think this is windows-specific. You should probably try on two different machines and get wireshark captures on each one.
Have not yet looked closely at the firefox side of things but pinged mozillas drno and bwc

Deleted: webrtc_internals_dump Appear.in.txt 202 KB

webrtc_internals_dump Appear.in.txt 202 KB View Download

Confirmed I can repro and I agree this should fall back to other candidates.

Quoting from RFC https://tools.ietf.org/html/rfc5245#section-15.1

"<rel-addr> and <rel-port> MUST be present for server reflexive, peer reflexive, and relayed candidates."

So the problem is caused by the new Chrome setting.

this does sound familiar: https://bugs.chromium.org/p/webrtc/issues/detail?id=1202
Good old bug... :-)

Regarding #9, I can confirm this issue repros on Linux.

https://cs.chromium.org/chromium/src/third_party/webrtc/pc/webrtcsdp.cc?q=webrtcsdp.cc&sq=package:chromium&dr&l=1909
-- check here if relatedaddress is nil. This probably does not get set because of checks that bail out on seeing a non-ip.

Good catch, should be zeroing raddr instead of removing it

Quoting from RFC https://tools.ietf.org/html/rfc8445#section-5.3

Related Address and Port:  The related IP address and port of the
         candidate.  These MAY be omitted or set to invalid values if
         the agent does not want to reveal them, e.g., for privacy
         reasons.

This is a critical part of the mDNS obfuscation feature. Sending the <rel-addr> and <rel-port> for srflx and relay candidates would defeat its purpose.

Sorry, race condition with #14. I agree that's likely causing the issue at hand.

check what is done when icetransportpolicy is set to relay -- i think its 0.0.0.0 and port 9 with the same rationale.

Justin: can you make sure the draft covers this?

Feature on:

a=candidate:2815163385 1 udp 2122262783 11487acc-e38c-4dad-a74a-2e616717ffc4.local 55977 typ host generation 1 ufrag gXK+ network-id 2
a=candidate:838548752 1 udp 2122194687 9647e65c-f1ad-445a-b2b8-00564341b26b.local 34056 typ host generation 1 ufrag gXK+ network-id 1
a=candidate:4252369539 1 udp 1685987071 104.132.51.71 43458 typ srflx generation 1 ufrag gXK+ network-id 1
a=candidate:3913811721 1 tcp 1518283007 11487acc-e38c-4dad-a74a-2e616717ffc4.local 9 typ host tcptype active generation 0 ufrag W7At network-id 2
a=candidate:3913811721 1 tcp 1518283007 11487acc-e38c-4dad-a74a-2e616717ffc4.local 9 typ host tcptype active generation 1 ufrag gXK+ network-id 2
a=candidate:2138620384 1 tcp 1518214911 9647e65c-f1ad-445a-b2b8-00564341b26b.local 9 typ host tcptype active generation 1 ufrag gXK+ network-id 1
a=candidate:2153973402 1 udp 41820415 18.224.63.33 50134 typ relay generation 1 ufrag gXK+ network-id 1

Feature off:

a=candidate:2815163385 1 udp 2122262783 2620:15c:17:10:c46b:c53a:c257:db45 38643 typ host generation 0 ufrag aES/ network-id 2
a=candidate:838548752 1 udp 2122194687 100.119.181.71 35861 typ host generation 0 ufrag aES/ network-id 1
a=candidate:3913811721 1 tcp 1518283007 2620:15c:17:10:c46b:c53a:c257:db45 9 typ host tcptype active generation 0 ufrag aES/ network-id 2
a=candidate:2138620384 1 tcp 1518214911 100.119.181.71 9 typ host tcptype active generation 0 ufrag aES/ network-id 1
a=candidate:4252369539 1 udp 1685987071 104.132.51.71 40467 typ srflx raddr 100.119.181.71 rport 35861 generation 0 ufrag aES/ network-id 1
a=candidate:2603517170 1 udp 41820415 46.4.60.18 64753 typ relay raddr 104.132.51.71 rport 40467 generation 0 ufrag aES/ network-id 1

The draft already mandates using 0.0.0.0:0 for rel-addr, which I agree is required, per 5245 and ice-sip-sdp:

   Any server-reflexive candidates generated from an mDNS local
   candidate MUST have their raddr field set to 0.0.0.0 and their rport
   field set to 0.

Seems a bit draconian to reject all candidates based on one bad one though.

well, raddr/rport is missing on *all* candidates. Its a bit surprising that the relay candidate is affected by this as well, it should just point back to to the srflx one.

And there should have been tests ensuring that srflx/relay candidates always have raddr/rport.

yeah, relay candidate should not have been affected.

Still, should have been possible to get a working connection using the FF local IP, if both browsers are running on the same machine.

yeah. Looking at firefox about:webrtc there are no candidate pair.
(ice/WARNING) ICE(PC:1542350637975000 (id=2147483652 url=https://appear.in/foppi)): Error parsing attribute: candidate:25531464 1 udp 2122260223 a0389767-bbc0-42a9-9b4b-2b3881fe6daf.local 56232 typ host generation 0 ufrag YR79 network-id 1 network-cost 10

-- not sure why that happens but I think we need to move to bugzilla for this one. Even without any remote candidate I would have expected Firefox to come up with prflx ones once Chrome sends binding requests.

yeah, my thoughts exactly.

filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1507700 -- Nils seems to have some ideas.

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

commit 72d2ddd36fec38e6aea31a0558232df7e2815f4b
Author: Jeroen de Borst <jeroendb@webrtc.org>
Date: Wed Nov 28 00:13:23 2018

Fix raddr on srflx and relay candidates

Bug:  chromium:905690 
Change-Id: Ic16d21672db5d456d7a9727ea5194ec26338c9d0
Reviewed-on: https://webrtc-review.googlesource.com/c/111441
Commit-Queue: Jeroen de Borst <jeroendb@webrtc.org>
Reviewed-by: Justin Uberti <juberti@webrtc.org>
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25810}
[modify] https://crrev.com/72d2ddd36fec38e6aea31a0558232df7e2815f4b/p2p/base/port.cc
[modify] https://crrev.com/72d2ddd36fec38e6aea31a0558232df7e2815f4b/p2p/base/port.h
[modify] https://crrev.com/72d2ddd36fec38e6aea31a0558232df7e2815f4b/p2p/client/basicportallocator.cc
[modify] https://crrev.com/72d2ddd36fec38e6aea31a0558232df7e2815f4b/p2p/client/basicportallocator.h
[modify] https://crrev.com/72d2ddd36fec38e6aea31a0558232df7e2815f4b/p2p/client/basicportallocator_unittest.cc

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

commit c3f9b27fbe6ff3ef5bf6fe209698d2741476b253
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Wed Nov 28 06:34:08 2018

Roll src/third_party/webrtc 59cfd3543875..0d007d7c4f11 (10 commits)

https://webrtc.googlesource.com/src.git/+log/59cfd3543875..0d007d7c4f11


git log 59cfd3543875..0d007d7c4f11 --date=short --no-merges --format='%ad %ae %s'
2018-11-28 chromium-webrtc-autoroll@webrtc-ci.iam.gserviceaccount.com Roll chromium_revision aed902039c..b04e513f82 (611312:611432)
2018-11-28 jeroendb@webrtc.org Fix raddr on srflx and relay candidates
2018-11-27 qingsi@webrtc.org Revert "Delay call to Destroy until after SignalDone has finished firing."
2018-11-27 chromium-webrtc-autoroll@webrtc-ci.iam.gserviceaccount.com Roll chromium_revision 81c26a093b..aed902039c (611047:611312)
2018-11-27 zstein@webrtc.org Delay call to Destroy until after SignalDone has finished firing.
2018-11-27 peah@webrtc.org AEC3: Add metrics for API call jitter
2018-11-27 jakobi@webrtc.org Add PeerConnection option to configure minimum audio jitter buffer delay.
2018-11-27 artit@webrtc.org Fix webrtc-internal configs to run perf tests on separate bots
2018-11-27 terelius@webrtc.org Batch RTC event log output if using the new wire format.
2018-11-27 jakobi@webrtc.org Expose delayed packet outage as a cumulative metric of samples in the new getStats API.


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

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:None,chromium:905690,chromium:905542,chromium:None,chromium:905542,chromium:907234
TBR=webrtc-chromium-sheriffs-robots@google.com

Change-Id: I956aed4c208a54a3ab6446e9ab8780d9f08669f2
Reviewed-on: https://chromium-review.googlesource.com/c/1352608
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@{#611578}
[modify] https://crrev.com/c3f9b27fbe6ff3ef5bf6fe209698d2741476b253/DEPS