> > > > > As Bruce suggested that message 1 and 4 will be routed > > > > > through the overlay. > > > > > > > > I don't believe that will work; part of what causes TURN to > > > > be an effective NAT relay is that the TURN client sends > > > > a packet directly to the TURN server's publicly-routable > > > > transport address. The side effect of the TURN client > > > > doing that is that the TURN client's (evil, nasty) NAT > > > > opens pinholes to communicate bi-directionally with the > > > > TURN server's transport address. > > > > > > I agree with you. So I think we should also consider > > > NAT's filtering > > > behavior while we choose a peer to be a TURN server. > > > > The TURN client's NAT filtering behavior?? > > No, the NAT which the TURN server is behind.
Yes, I agree that needs to be tested. Some sort of qualification procedure is needed before a TURN server advertises its transport address to the overlay. -d _______________________________________________ P2PSIP mailing list [email protected] http://www.ietf.org/mailman/listinfo/p2psip
