BitTorrent does not need to connect to any particular member in a swarm, it’s not a p2p chat protocol where two specific end points want to talk to each other. All it cares about is that the connection graph of the swarm has a sufficiently high connectivity degree.
In other words, getting clients behind a NATs to talk to each other is somewhat desirable, but not to the point where major resources, such as traffic forwarding, would be expended on that goal. On the individual node level failure is an option.
Thus it does not use sip/turn/etc.
Of course on the aggregate swarm level performance will still degrade with an increasing fraction of non-reachable nodes. If nobody can accept incoming connections then BitTorrent doesn’t work.
Various clients use some combination of the following approaches to improve connectivity for the bulk transport connections:
- PCP, NAT-PMP or UPnP-IGD negotiation with the gateway to forward a port as long as the application is running.
- For TCP one can use source port binding (outgoing connections) and port reuse (listen + outgoing) socket options to use the same local port for all connections to exploit end-point independent (EIM) NAT mappings (also known as full cone NAT).
- Similarly for UDP one should use a single socket in combination with sendto/recvfrom or equivalent APIs to multiplex all application-level connections over a single port instead of creating one socket per peer.
- the
largely undocumentedut_holepunch extensionthat uses mutually reachable swarm members in place of stun servers. - an optional UDP-based transport protocol (µTP) that can be used in combination with the previous points. generally nat traversal is easier to achieve with udp
- IPv6 capability signalling, which in principle allows clients to upgrade their connections and then gossip about v6 peers via PEX/DHT.
- prompting the user to perform manual port forwarding
In the case of the DHT only the first two points (gateway negotiation and port reuse) are used. The overhead of attempting nat traversal for a single request-reply cycle would be >100% and is not worth it.