> -----Original Message----- > From: Henry Sinnreich [mailto:[EMAIL PROTECTED] > Sent: Friday, February 01, 2008 3:06 AM > To: Song Yongchao; Cullen Jennings; Bruce Lowekamp > Cc: P2PSIP Mailing List; Dan Wing > Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer > > > 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 > > Two excellent papers deal with NAT discovery: > > < draft-ietf-behave-nat-behavior-discovery-02> > <draft-wing-behave-nat-control-stun-usage-05>
The second paper, draft-wing-behave-nat-control-stun-usage, resulted in a BoF at the last IETF in Vancouver. The consensus at that BoF was that IETF would not be successful building such a protocol. Minutes of the BoF are at http://www.ietf.org/proceedings/07dec/safe.html and audio is available at http://videolab.uoregon.edu/events/ietf/. A mailing list, SAFE, was created to discuss it. Archives are at http://www.ietf.org/mail-archive/web/safe/current/index.html If there is interest in pursuing SAFE or the NAT Control STUN Usage, please email [EMAIL PROTECTED] or email me off-list. -d > These are powerful tools not only to detect the NAT behavior > but also to > determine the position in multi-level NAT-ed networks. > > Deployment on the net may yet reveal some more work is > required for fine > tuning, > but the above are the best I know of today and seem to be the right > approach. > > My apology if I have missed some other recent relevant work. > > Henry > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Song Yongchao > Sent: Friday, February 01, 2008 11:00 AM > To: Henry Sinnreich; 'Cullen Jennings'; 'Bruce Lowekamp' > Cc: 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer > > > -----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 _______________________________________________ P2PSIP mailing list [email protected] http://www.ietf.org/mailman/listinfo/p2psip
