1742337 - A server-reflexive candidate is discarded when the host IPv4 address is public and obfuscated by using mDNS

Status: RESOLVED FIXED

(Core :: WebRTC: Networking, defect)

Description

[Kyutae Lee [:gorisanson]]

Attachment: The result of taking the steps to reproduce

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

1. Connect to the Internet directly with a public IP (behind no NAT)
2. Open the Trickle ICE sample page: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
3. Click "Gather candidates"

Actual results:

A server-reflexive candidate was not provided.

Expected results:

A server-reflexive candidate should be provided.

Comment 1

[Kyutae Lee [:gorisanson]]

A server-reflexive (srflx) candidate is discarded when the host IPv4 address is public and obfuscated by using mDNS.

According to https://www.rfc-editor.org/rfc/rfc8445#section-5.1.3, the srflx candidate is considered redundant and eliminated when the host address is public (and not obfuscated). In this case, WebRTC P2P connection can be achieved since the host address is public and the same as the srflx candidate address.

However, when the host address is both public and obfuscated by using mDNS, according to https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-mdns-ice-candidates-02#section-3.1.2.2, a srflx candidate MUST NOT be considered redundant and so must not be eliminated. But, it seems that Firefox eliminates the srflx candidate when the host address is both public and obfuscated.

Comment 2

[Kyutae Lee [:gorisanson]]

It seems that it is related to: https://bugzilla.mozilla.org/show_bug.cgi?id=1742009

And here is the related Stack Overflow question which I posted about one and a half years ago: https://stackoverflow.com/q/61629450/8581025

Comment 3

[Kyutae Lee [:gorisanson]]

It seems that Safari and Chrome have the same bug now.
For your information, the links of the bug reports are at the following.

Webkit: https://bugs.webkit.org/show_bug.cgi?id=233414
Chromium: https://bugs.chromium.org/p/webrtc/issues/detail?id=13426

Comment 4

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

Byron, can you help triage this?

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 6

[Kyutae Lee [:gorisanson]]

This bug is fixed by the patch in upstream:
https://webrtc.googlesource.com/src/+/7eea6672285f765599fd883a5737f5cae8d20917

And the patch begins to be applied on Chromium with version 110.0.5452.0.

Comment 7

[Kyutae Lee [:gorisanson]]

Attachment: Bug 1742337 - Fix discarding of srflx candidates r?#webrtc-reviewers

Fix so that srflx candidates are not discarded if host address
obfuscation is enabled.

Comment 8

[Byron Campen [:bwc]]

Try pushes:

https://treeherder.mozilla.org/jobs?repo=try&revision=315a38e458f7b3b919ee282ff30f9d221d8c1df3
https://treeherder.mozilla.org/jobs?repo=try&revision=accb3669926912f2b30d8ed4d269cf21a6deba20
https://treeherder.mozilla.org/jobs?repo=try&revision=89c9cb9cfdbcfe08cc0c9093ce9275a0dd928120

Comment 9

[Byron Campen [:bwc]]

Try looks normal.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/587eb0272431
Fix discarding of srflx candidates r=webrtc-reviewers,bwc

Comment 11

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/587eb0272431