> -----Original Message----- > From: JiangXingFeng [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 24, 2008 6:12 PM > To: 'Dan Wing'; 'Jerry Yin' > Cc: 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer > > > The p2p-sip TURN server, prior to those messages above, > > determined its publicly-routable IP address and publicly- > > routable UDP port. It may have determined that via STUN > > (or, if there is only one level of NAT, it might have > > determined that via UPnP or NAT-PMP). > > > > The p2p-sip TURN server also determines that it can receive > > STUN requests from arbitrary STUN clients via that port; Bruce > > I believe has written up how a TURN server makes that > > determination. Once the TURN server has made that determination, > > it would register itself as a TURN server in the p2p overlay > > network. > > How do you assume the filtering behavior of the NAT which is > in the front of the TURN server?
You can test it, and hope your test accurately reflects the NAT's filtering behavior when real traffic is attempting to traverse the NAT. I am not aware of a better technique, unless you know you are behind only one NAT (in which case you can use UPnP or NAT-PMP, both of which require no filtering on the NAT). > If it is not end-point independent > filtering, how could the > TURN client's request reach the TURN peer behind the NAT? It wouldn't. The p2p-sip TURN server needs to determine if it's behind that kind of NAT prior to declaring, to the p2p-sip network, that it is a TURN server. That is part of the qualification procedure the p2p-sip TURN server needs to do. -d _______________________________________________ P2PSIP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
