WebRtcHideLocalIpsWithMdns remove from Chrome://flags

[Shachar]

In M91 the "WebRtcHideLocalIpsWithMdns" flag was remove from chrome://flags.

We have some deployment relying on disabling the feature via the CLI arguments:

"--disable-features=WebRtcHideLocalIpsWithMdns"

The cli argument still seem to function - is the intention to keep it or remove that as well ?

Thanks in advance

[Harald Alvestrand]

Can you give some more info on your use case? We have been discussing how to deal with scenarios where mdns is problematic in the past, but none of the scenarios have been compelling enough to consider this an urgent matter.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/02a0130d-be45-4ee6-a2b3-f16abaa5dfaan%40googlegroups.com.

[Roman Shpount]

A peer-to-peer delivery network, which is designed to work inside the corporate environments would be one such use case.

[Harald Alvestrand]

The obvious use case is a peer to peer application in a routed network without an external uplink and without MDNS bridging (think Burning Man). In that case, mdns would be really unhelpful.

For the corporate case where there's enough capacity to the NAT unit, hairpinning STUN-derived addresses at the NAT may be workable.

But: I was specifically asking for Shachar's use case, because there's usually more things under the sun than what we've already discussed.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/1dceab3f-2b93-4a90-b9f3-7cfe4793dd70n%40googlegroups.com.

[Roman Shpount]

Shachar is working for Peer5. They are using datachannel peer-to-peer connections to stream large video events to corporate customers. During these events, they typically set the WebRtcHideLocalIpsWithMdns flag using enterprise policy to disable mDNS. The main reason is to minimize delays and reduce the load on the corporate routers. I think they described their use case in great detail when MDNS was originally proposed.

[Shachar]

Right,

The idea is to use this CLI flag in the enterprise use-case in order to remove the mDNS obfuscation and expose the IP. This way the peers can connect via host in a segmented network. 

p.s: hairpinning usually isn't supported.

[Shachar]

btw, we're also using it in tests

[Harald Alvestrand]

Guido, do you know if removing this from chrome://flags was deliberate?

Shachar, can you file a bug in crbug.com indicating a desire to have it back?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6d0c9775-0f22-4328-8c84-7cc8f7eb9698n%40googlegroups.com.

[Shachar]

Sure: https://bugs.chromium.org/p/chromium/issues/detail?id=1228030

[Philipp Hancke]

flags expire. I've just merged an extension until M100 to M92.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/a28a6dfd-28a3-4f73-9c80-c8f39a6c983dn%40googlegroups.com.

[Shachar]

Hi,

We've passed M100, the flag is still used in tests.

Can we extend it further or unexpire it ?

[Harald Alvestrand]

Fippo and I have extended it to 120.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/85c09e51-983f-4fbb-b9a1-4ebf04e2e173n%40googlegroups.com.