Reflexive test is unacceptably misleading and should be removed or reworked

[brucek2]

If I am informed correctly, for a typical consumer to see a green pass for the reflexive connectivity test, they will need a router that supports NAT loopback. This is objectionable because:

1. Many perfectly fine modems/routers do not and will not support that.

2. Failure to support this extreme edge case has nothing to do with the much more common case of wanting to connect two clients that are not on the same physical device. No user is trying to video chat with themselves on one device.

3. The framing of the existing output as a condition yellow "warning" falsely implies there is a problem, and the warning text falsely implies there is something about the user's home environment or configuration that can be improved, when in reality there is nothing to improve: they'd have to buy one of only a handful of modems/routers that can do this and even after having done so, would see no positive improvement in their video calls or other applications.

4. Because this test fails almost everybody over a needless complication, it can not serve its primary goal of identifying actual reflexive connectivity issues that the user could/should fix (i.e., double NAT), for their own benefit and that of those who provide these services.

IMO the ideal fix would be for test.webrtc.org to actually provide a partner to connect to, so the user could get a real answer as to whether reflexive connections were working for them. I understand that's not trivial to arrange, although given the stakes for webRTC members who run video conferencing services and would prefer not to provide relays it also seems like a small investment for high payback. Better to provide a small amount of bandwidth once for this test, vs. having to provide it on an ongoing basis for relays.

Failing that, I would change the output to not include any positioning of yellow/warning/problem, and if there is no way for test.webrtc.org to tell them if they can do reflexive connectivity in the real world, to just say that and perhaps suggest another way to test if there is one.

Issue 176 contains some related technical background.

(The existing case/message may have some use for developers only, letting them know that in their current environment they would need to do reflexive testing on pairs of two separate devices. This could be presented neutrally as a footnote vs. part of the primary test.)