1507700 - interop with chrome/mdns candidates is broken

Status: RESOLVED FIXED

(Core :: WebRTC: Networking, defect, P2)

Description

[Philipp Hancke [:fippo]]

from https://bugs.chromium.org/p/chromium/issues/detail?id=905690#c23

steps to reproduce:
1. in chrome canary (72+) go to chrome://flags and enable #enable-webrtc-hide-local-ips-with-mdns
2. join an appear.in room in chrome
3. join the same room in firefox

the ice connection fails. 

As Nils pointed out, Firefox rightly rejects the srflx/relay candidates due to the lack of raddr/rport (even though I wonder why they show up in the remote description on about:webrtc)

Firefox also does not like the mdns candidate:
(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

Even then, the local connection should be established because Chrome starts pinging the candidates from Firefox and those candidates should show up as prflx.

Comment 1

[Nils Ohlmeier [:drno]]

I modified the parent process filter code to allow incoming STUN requests, but that turned out not to be the problem.

One can actually repro the problem even within Firefox with two PeerConnection instances:
- if only PeerConnection 1 sends it's ICE candidates to PeerConnection 2
- drop all ICE candidates from PC2
- PC2 will start sending binding requests to PC1
- even though PC1 created the network sockets it doesn't start to listen on them
- this problem exists even without e10s active, which means it's not an e10s related problem

Comment 2

[Nils Ohlmeier [:drno]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d1635cc50b2cbde9cef170835a3ed7aadce0d1d0

Comment 3

[Nils Ohlmeier [:drno]]

Attachment: Bug 1507700: allow incoming STUN requests. r?bwc

Comment 4

[Nils Ohlmeier [:drno]]

So testing with appear.in through me off.

When testing with appr.tc the attached patch clearly resolves the problem. Firefox being the offerer and the answerer work and I get a connection every time.

But when testing with appear.in the patch only solves the problem for when Firefox is the offerer. When Firefox is the answerer there appears to be some kind of race condition. If I see no remote raw candidates at all on about:webrtc usually the connection doesn't get established. But when I see the broken candidates from Chromium in the remote raw candidates list it appears to work. Not sure if or why that matters.

Comment 5

[Nils Ohlmeier [:drno]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=edc608440fd50cc1044ceeb64978c19d0550445e

Comment 6

[Nils Ohlmeier [:drno]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b66d1a6094c5a6c898ab3237c83e08f557aad184

Comment 7

[Nils Ohlmeier [:drno]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=fcc57d2c45bcd743bc6ba5c7c2df1be8991460ac

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7d539c01dad8
allow incoming STUN requests. r=bwc

Comment 9

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/7d539c01dad8

Comment 10

[tapitman11]

I'm not sure what the current plan is, but I would like to request that the Firefox team not disable host candidates until all the major browsers have mDNS candidates working well and widely deployed. I'm currently developing a LAN game that depends on host candidates. It works great between Chrome and Firefox, but not at all on Safari (at least without getUserMedia, which doesn't make sense for my game) due to it being mDNS-only for host candidates, as far as I can tell.