Re: [P2PSIP] Choice of STUN peer or TURN peer

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 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: [e-mail] 
> > [mailto:[e-mail]] 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
> > [e-mail]
> > http://www.ietf.org/mailman/listinfo/p2psip
> > 
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/p2psip