1562281 - Interop: Chrome/Safari rejects the RTCIceCandidate (>=68) with the empty candidate string.

Status: RESOLVED WORKSFORME

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

Description

[Manjesh Malavalli]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36

Steps to reproduce:

1. Open https://jsfiddle.net/fjyzakdm/ in a Firefox 68 tab.
2. Click the "Copy" button.
3. Open https://jsfiddle.net/fjyzakdm/ in a Chrome/Safari.
4. Click the "Apply" button.
5. Open the JavaScript console.

Actual results:

Chrome/Safari rejects the RTCIceCandidate with the empty candidate string.

Expected results:

All the RTCIcecandidates generated by Firefox 68 should be successfully added by Chrome/Safari.

Comment 1

[Nils Ohlmeier [:drno]]

Thanks for the report.

Firefox implements the spec compliant behavior as far as I can tell https://www.w3.org/TR/webrtc/#dom-rtcicecandidate-candidate

There is Chrome bug to support the spec compliant behavior which currently has been assigned https://bugs.chromium.org/p/chromium/issues/detail?id=978582

Additionally this doesn't affect the end-to-end functionality as ICE connection can still get established. Chrome/Safari will only miss that Firefox is not going to send more candidates for this ICE transport.

Lastly if the console errors from rejecting the candidates should be concerning it should be pretty trivial to re-write the Firefox ICE candidates from empty string to null candidates to make them accepted by Chrome and Safari.

Expecting to withhold spec compliant behavior on the Firefox side because Chrome hasn't gotten around to support such a small change is asking a lot in such case which doesn't really affect the real functionality.

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

This WFM now in Chrome. I only have an older Safari (Release 142, Safari 15.4) which still fails on candidate: "", but I think this is enough progress to close this on our end.