1501456 - ICE fails with Chrome/Safari with server reflexive candidates only

Status: NEW

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

Description

[Nils Ohlmeier [:drno]]

Attachment: nICEr log from Firefox <-> Chrome with srv flx only candidates

I learned last week that ICE interop with Safari and Chrome is broken if the other side only provides server reflexive candidates (no TURN, no host candidates).

From looking at Firefox ICE logs (attached) it looks like Firefox is sending a STUN binding request. But when it receives the binding response message from Safari or Chrome the STUN transaction ID doesn't match the ID from the request. Firefox then keeps retransmitting it's binding requests, but every single STUN answer from Chrome/Safari come back with a new different transaction ID. So Firefox keeps ignoring the responses because they don't match pending STUN transaction.

I have no idea if or how this works Chrome <-> Chrome. Maybe they ignore STUN transaction IDs if the ufrag/pwd match?

Comment 1

[Philipp Hancke [:fippo]]

I'd love to see more debug from the chrome side. I think starting it with --enable-logging=1 --v=4 should give us enough.
The debug I am looking for should be easily grep-able by searching for "STUN ping":
https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/base/port.cc?sq=package:chromium&dr=CSs&g=0&l=1270

This looks bad:
  // If this is an authenticated STUN request, then signal unknown address and
  // send back a proper binding response.

Also a pcap would be good for the trial :-)

Comment 2

[Justin Uberti]

We have to compare transaction IDs or else we'll get lots of messed-up stuff when there are multiple interfaces. Unless this is a recent regression, this seems hard to believe.

Regarding fippo's comment, that code is for handling pings from unknown remote candidates, and will create a new prflx remote candidate accordingly. Seems unrelated.