The one place for your designs
To enable design management, you'll need to meet the requirements. If you need help, reach out to our support team for assistance.
Why discover relay and server reflexive candidates from *all* local interfaces ?
Even if it's clearly stated in the RFC (*), I cannot imagine a real-world example, where it makes sense to discover our server-reflexive address by sending an stun request from all our local addresses, and to obtain a relay address from a turn server, by sending discovery requests from all our local addresses too.
In a setup with a single stun server and a single turn server, we can expect to discover a unique server-reflexive address, from whatever local interface we send the stun request from. The same applies for the turn server. These stun requests are all supposed to go out the host by the default route. The local network interface used to send the packet shouldn't matter a lot. I can imagine a setup with several default routes, but the metric should prefer one, and all stun request should use that one ?
What I observe from my tests is always the same server-reflexive address added N-times as a different local candidate: the same server-reflexive address, with a different base for each local IP address available on the host. The same candidates duplication applies to relay candidates. This causes a lot of resources waste, and pairing all these similar local candidates to remotes ones also amplify the problem.
Ignoring some local (virtual) interfaces is a possibility, but I think it doesn't handle the root of the problem.
Would it make sense to stop the discovery process after the first server-reflexive candidate is obtained, and after the first relayed candidate ? Would we miss pairs combinations that would be the only possibility to establish a connection ?
(*) Section B.2 of RFC-8445 "Candidates with Multiple Bases" gives an example of a network topology, where it makes sense to keep candidates with same transport address and different base. But from this example, I have difficulty to see how the stun server on the B:net10 network can be reached from the initiator, because outgoing packets for this network should normally go to the c:net10 instead: the net10 network directly reachable from the initiator.