Great! The overlay could be thought of as a rendezvous point and could be used to exchange candidates. Further, the TURN client and the TURN server could use ICE with the help of the rendezvous point to get a direct connection. (It will exist if the NAT in front of the STUN server has end-point independent mapping behavior.) And then TURN client could use the TURN server to communicate with other peers.
-- Jiang XingFeng > -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 03, 2008 1:37 PM > To: 'Cullen Jennings' > Cc: 'Francois Audet'; 'Bruce Lowekamp'; 'P2PSIP Mailing List'; 'JiangXingFeng' > Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer > > > 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
