> -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: Saturday, February 02, 2008 00:32 > To: Audet, Francois (SC100:3055); 'Cullen Jennings'; 'Bruce Lowekamp' > Cc: 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer > > 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.
And? That doesn't seem so bad to me. When a peers goes live (attempts to connect), it would then try to find a working STUN/TURN server. After a few attempts, it is likely to find a working one. A success of 87.5% after 2 tries seems very good to me. Also, the alternative is that the servers themselves do a lot of self-assestment which takes some time. I'm also thinking that if somehow we could make the process of being a STUN/TURN server and discovering others/joining the overlap mandatory, then we wouldn't have the problem that everybody would opt out of being used as a STUN or TURN server. (By mandatory, I don't mean "the spec says it's mandatory: I mean the procedures would be intertwined enough that it would not be possible, or at least very difficult, to disable the STUN and TURN server). Just thinking out loud... _______________________________________________ P2PSIP mailing list [email protected] http://www.ietf.org/mailman/listinfo/p2psip
