Closed Bug 1507700 Opened Last year Closed Last year

interop with chrome/mdns candidates is broken

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla65
Tracking Status
firefox65 --- fixed

People

(Reporter: fippo, Assigned: drno)

Details

Attachments

(1 file)

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.
Flags: needinfo?(drno)
Rank: 25
Priority: -- → P2
Rank: 25 → 15
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
Flags: needinfo?(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.
https://hg.mozilla.org/mozilla-central/rev/7d539c01dad8
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
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.
You need to log in before you can comment on or make changes to this bug.