Menu
I am developing a P2P application, and I need to use STUN and/or TURN for NAT traversal. I have looked into the issues that an arise when using STUN only (basically it will not always work because it is UDP based and some firewalls won't like that - the reason is not that interesting as per my question), and I keep seeing recommendations about using STUN and TURN for fallback (the ICE scheme).
But everywhere I look I just see people STUN as "unlikely to always work". What I am looking for is some concrete numbers / stats. I might try to generate them myself but I don't have enough clients for a significant sample.
So I was wondering if anyone could shed some light on stats around the success rate of using STUN for NAT traversal. How many peers would not be able to connect if I fail to use TURN as fallback?
525
STUN provides the mechanism to communicate with users behind a network address translation (NAT) firewall, which keeps their IP addresses private within the local network (LAN). The initiating party sends a request to the STUN server, which maintains the IP addresses of the phone or computer (for video).
STUN does not work with symmetric NAT (also known as bi-directional NAT) which is often found in the networks of large companies. Since the IP address of the STUN server is different from that of the endpoint, in the symmetric NAT case, the NAT mapping will be different for the STUN server than for an endpoint.
The STUN server allows clients to find out their public address, the type of NAT they are behind and the Internet side port associated by the NAT with a particular local port. This information is used to set up UDP communication between the client and the VoIP provider to establish a call.
To build the list of ICE candidates, Alice's browser makes a series of requests to a STUN server. The server returns the public IP address and port pair that originated the request.
Depending on who your customers are, where they are, and the types of devices they use (PCs vs Mobile), the results can vary.
In practice (based on my experience), ICE connectivity with STUN alone is about 85% successful for desktop and laptop PCs. But if it works once for a particular pair of endpoints, it will be even more likely for subsequent connections for these same hosts (assuming network topologies have not changed). Things are a bit different for mobile devices.
Here are some factors that influence getting a successful "connection" (either UDP based or TCP) for P2P.
NAT type. If both endpoints are behind well behaved "port restricted" NATs or better, then chances are high for success with STUN. This is the usual case for home NATs with a good ISP such as those in the US. But mobile carriers and enterprise firewalls typically implement "symmetric NAT" as a result of having multiple layers of NATs and network configurations. This basically means that port mappings are not consistent - and are harder for a P2P algorithm like ICE to establish a connection with.
Firewalls or Enterprise configurations. Even if the firewall allows outbound UDP packets and accepts packets back, it is often a symmetric NAT configuration.
Mobile carriers. Are often (but not always) symmetric NAT types.
143
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
