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
