WebRTC does not work in the modern browsers when a peer is not behind a NAT because of the obfuscating host address

While troubleshooting my web app, I found draft-mdns-ice-candidates, which is about obfuscating addresses in host candidates by using mDNS.

And I found that when the two peer (agent L, agent R) is in a topology as in the Figure 7 below, the WebRTC peer connection fails because the host address of agent R is obfuscated and the srflx address of agent R is discarded since agent R is not behind a NAT. The relevant expressions in rfc8445 about discarding the srflx address of agent R are below.

5.1.3. Eliminating Redundant Candidates

Next, the ICE agents (initiating and responding) eliminate redundant candidates. Two candidates can have the same transport address yet different bases, and these would not be considered redundant. Frequently, a server-reflexive candidate and a host candidate will be redundant when the agent is not behind a NAT. A candidate is redundant if and only if its transport address and base equal those of another candidate. The agent SHOULD eliminate the redundant candidate with the lower priority. - section 5.1.3 of rfc8445

(Figure 7 is from section 15.1 of rfc8445)

And in section 5 of draft-mdns-ice-candidates, I found no explanation about the case of Figure 7. When I tested the recent version of Chrome, Firefox, and Safari, the WebRTC peer connection failed in all of the browsers in the case of Figure 7, because of the reason I wrote above — the host address of agent R was obfuscated and the srflx address of agent R was discarded.

When turning off obfuscating local addresses by changing the browser setting (the obfuscating is done by default), the WebRTC peer connection is successfully established. (I tested this successful connection on Chrome, and FireFox. In Chrome, by disabling Anonymize local IPs exposed by WebRTC in "about:flags" page. In Firefox, by setting false media.peerconnection.ice.obfuscate_host_addresses in "about:config" page.)

Is this a problem of the IETF’s WebRTC spec? (Maybe a collision between draft-mdns-ice-candidates and rfc8445?) Or a problem of the implementations of the modern browsers? Is there a way to establish WebRTC peer connection in the case of Figure 7 without turning off the obfuscating host address? I want to know.

From draft-ietf-mmusic-mdns-ice-candidates-02, Section 3.1.2.2:

Regardless of the result, a server-reflexive candidate will be generated; the transport address of this candidate is an IP address and therefore distinct from the hostname transport address of the associated mDNS candidate, and as such MUST NOT be considered redundant per the guidance in [RFC8445], Section 5.1.3. To avoid accidental IP address disclosure, this server-reflexive candidate MUST have its raddr field set to "0.0.0.0"/"::" and its rport field set to "9", as discussed in [ICESDP], Section 9.1.

Omitting a SRFLX candidate because its server-reflexive IP address matches an IP address used to produce a local obfuscated candidate appears to be explicitly nonconforming.