> -----Original Message----- > From: Henry Sinnreich [mailto:[EMAIL PROTECTED] > Sent: Friday, February 01, 2008 5:47 PM > To: Song Yongchao; Cullen Jennings; Bruce Lowekamp > Cc: P2PSIP Mailing List > Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer > > > > For the simplicity, I think we should only admit peers with public > addresses > > to be the TURN servers at the first step. > > This simplicity may be far too expensive in real deployments. > The effort to develop the protocol for TURN servers behind p2p friendly > NAT is fully justified IMHO.
I'm very glad to hear that, what I just said is about how a peer that is willing to be a TURN server to detect whether it is behind a P2P friendly NAT. Could you please provide some information about the justified detecting? > > Henry > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Song Yongchao > Sent: Friday, February 01, 2008 8:22 AM > To: 'Cullen Jennings'; 'Bruce Lowekamp' > Cc: 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer > > See inline > > 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. > > In that case,each peer that is willing to be the TURN server must dialog > with several STUN servers with public address to detect its NAT mapping > type, only peers with public addresses or behind endpoint independent > NATs > could be TURN servers. However, STUN servers may be behind NAT either, > in > the worst case, it may be behind the same outermost NAT with the peer, > and > these STUN servers response different reflexive addresses with the > public > STUN servers. So, in that case STUN servers must be classified in to > public > addressed and non-public addressed, and the peer willing to be the TURN > server must dialog with public addressed STUN servers to detect its NAT > mapping type. > > For the simplicity, I think we should only admit peers with public > addresses > to be the TURN servers at the first step. > > > _______________________________________________ > > 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
