> -----Original Message----- > From: JiangXingFeng [mailto:[EMAIL PROTECTED] > Sent: Friday, January 25, 2008 1:17 AM > To: 'Dan Wing'; 'Bruce Lowekamp' > Cc: 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer > > Hi, > > I'd like to see your proposed method works, because it could > make full use > of decentralized resource in the overlay to serve each other.
It seems useful to phase this for p2p-sip: initially, just have p2p-sip nodes advertise their TURN servers if the p2p-sip node is not behind a NAT. Once we know how to have p2p-sip TURN servers qualify their NAT's p2p-friendlyness, then can have p2p-sip nodes advertise those TURN servers, too. If we make fast progress on a document that describes the qualification procedure, and running code that shows it works, we should be good to go. No? > Regards! > > JiangXingFeng > > > > > Yep. That is part of the qualification a p2p-sip TURN server > > would have to do before it declares itself a TURN server. > > > I'm just worried about that rare end-point independent > filtering NAT exists > according the data in the paper > http://saikat.guha.cc/pub/imc05-tcpnat.pdf. > It said the proportion of the end-point independent filtering > NAT is about 5.8% That paper is for TCP. I thought the primary concern here, for TURN, was UDP? -d _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/p2psip
