> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Francois Audet > Sent: Friday, February 01, 2008 4:14 PM > To: Cullen Jennings; Bruce Lowekamp > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer > > I'm sure this is an incredibly dumb question: but why does a > peer need to > think of being a TURN server (by presumably "testing" if it > is behind a NAT)? > > Wouldn't it work if all peer always try to be TURN/STUN servers? > A peer would advertize a TURN server for the any public IP addresses > it has. That includes both local public IP addresses as well as > self-discovered IP addresses (gathered through STUN using > other peers). > > If it happens that the peer is behind a NAT that does not have an > endpoint independent mapping, then it just won't receive any > TURN/STUN packets. > > The algorithm could work something like this, upon connecting > to the network: > > - If local IP address is public then advertize it (both STUN and TURN) > - Then, when another peer STUN server is discovered, discover > if you have another public IP address > binding (that would occur for example if you have NATing of > public IP addresses) > - Then advertize new IP address (both for STUN and TURN > server) on discovered IP address and port > - And so on > > You just won't get any incoming STUN/TURN destined to your > local IP:port if you are NATed (public to > public). Similarly, you won't get any incoming STUN/TURN > destined to your discovered IP:port if the > NAT is not endpoint-independent.
Reports indicate that roughly 25% of NATs would block such incoming packets. This means that a TURN client, trying to use a random TURN server's transport address that is published into the p2p overlay, would get a 75% success rate. If the TURN client tried two TURN servers it would get a success rate of 87.5%, and so on, up to trying 11 TURN servers to get a success rate of 99.9%. Those success rates include no calculations about TURN servers that have crashed, had their p2p-TURN application terminated, had their NATs crash or otherwise lose state, etc. -d > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Cullen Jennings > > Sent: Thursday, January 31, 2008 20:44 > > To: Bruce Lowekamp > > Cc: P2PSIP Mailing List > > Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer > > > > > > On Jan 28, 2008, at 8:01 AM, Bruce Lowekamp wrote: > > > > > But otherwise, the TURN > > > protocol seems to work as is. For the purposes of a TURN > server, a > > > NAT having endpoint independent mapping seems to be the only real > > > requirement on the NAT > > > > Agree on that but ... > > I think the hard part we have not fully solved yet is how a > > peer that is thinking of being a TURN server is going to > > detect if this is the case or not. > > _______________________________________________ > > P2PSIP mailing list > > [email protected] > > http://www.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > [email protected] > http://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] http://www.ietf.org/mailman/listinfo/p2psip
