> On Feb 2, 2008, at 12:32 AM, Dan Wing wrote: > > > Reports indicate that roughly 25% of NATs would block such > > incoming packets. > > Which reports are you thinking of here ?
Google uses a pre-standard version of ICE for their user-to-user connections, and according to http://code.google.com/apis/talk/libjingle/important_concepts.html, 8% of those user-to-connections connections require a relay. For this to be a problem 8% of the time that two peers cannot establish a direct connection, about 28% (28%*28%=7.84%) of NATs have a property (port-specific filtering or port assignment) that would also break a TURN server trying to run behind that NAT. This brings me back to thinking about Bruce's idea that a TURN server be triggered via a message sent through the overlay. In <http://www.ietf.org/mail-archive/web/p2psip/current/msg03814.html>, I said I didn't think it would work. However, on further reflection, there is an advantage to communicating to the TURN server using the overlay and also sending it TURN messages directly (i.e., not through the overlay). This combination with the TURN client communicating to the TURN server using the overlay and using a normal TURN request means that a TURN server that is behind an address-filtering NAT could still be a viable and usable TURN server. This would increase the number of TURN servers available to p2p-sip. This works because the TURN client would have already learned its public IP address via STUN (although its port would be wrong, or its port would be filtered), and the TURN client can communicate that IP address and UDP port through the overlay to the TURN server. When the TURN server receives that communication (containing the TURN client's public IP address and UDP port) through the overlay, the TURN server can send packets towards it; due to p2p-unfriendlyness of the NAT in front of the TURN client, though, those packets would be dropped by the TURN client's NAT. However, those messages cause the TURN server's NAT to open a permission towards the TURN client's IP address. The next retranmission by the TURN client will then make it through the TURN server's NAT, to the TURN server, and the response will make it back to the TURN client. Here is a diagram, with "-" showing peer-to-peer messages, and "=" showing messages sent through the p2p-sip overlay: TURN client NAT STUN Server NAT TURN server | | | | | 1. |--STUN request--->| | | 2. |--a.b.c.d/12345---| | | | | | | | 3. |--TURN request (1st xmit)-->X(dropped) | 4. |====my address=a.b.c.d/12345===========>| 5. | X<---TURN indication-----------| 6. |--TURN request (2nd xmit)-->|---------->| 7. |<--------|<---TURN response-------------| | | | | | * Message 3 is dropped because the TURN Server's NAT filters incoming packets based on their source address -- the TURN server has never sent a packet to a.b.c.d, so the NAT drops the incoming packet. * Message 4 is the p2psip overlay message. * Message 5 is mostly to mollify the TURN server's NAT. Once the TURN server's NAT sees message 5, it adds a permission for traffic from a.b.c.d/*. (remember: the TURN server's NAT has address filtering behavior, which is what we're trying to get a TURN Server working with by adding this p2psip overlay message (4)). Message 5 is dropped by the TURN client's NAT. * Message 6 is a normal retransmission of the TURN client's message. With the functionality to trigger to the TURN server through the overlay, we can run a TURN server even behind an address-filtering NAT (but not a port-restricting NAT or a symmetric NAT). Without the functionality to trigger the TURN server, we cannot run behind an address-filtering NAT. I don't know what (pre-standard) version of ICE that Google implemented, nor do I recall which version of ICE added the ability to communicate directly even with address-restricted NATs. The standard version of ICE does something vaguely like the above: it sends a message through the overlay (the Offer/Answer exchange, using SIP), and that message causes both peers to try to communicate with each other, which allows two peers with address-filtering NATs to communicate directly with each other (without a relay). The ability to communicate through the p2p-sip overlay to the TURN server provides a similar capability so that a TURN server can be behind an address-filtering NAT. -d _______________________________________________ P2PSIP mailing list [email protected] http://www.ietf.org/mailman/listinfo/p2psip
