> -----Original Message----- > From: Jerry Yin [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 24, 2008 10:54 AM > To: Dan Wing > Cc: 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer > > > > > > > TURN client STUN server NAT TURN server > > | | | | > > 1. |------give me a TURN address------->|----->| > > 2. | |<--STUN Request--------| > > 3. | |-STUN Response->|----->| > > 4. |<-----here is your TURN address------------| > > > > > > Messages 2-3 are normal STUN request/response messages, and > > tell the TURN server a publicly-routable IP address and UDP > > port. The IP address and UDP port returned in in the STUN > > Response (message 3) is the TURN server's publicly-routable > > transport address, and is given to the TURN client in message > > 4. > > > > > > Does the "p2p-friendly" mean the NAT allows the STUN messages > pass through? > How does the message 1 (STUN) go through the NAT?
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. > I guess the TURN server has to send STUN keep alive messages > to keep the NAT > hole open before the TURN request expire? Yes, the p2p-sip TURN server would be responsible for keeping open all of the pinholes necessary for the p2p-sip TURN server to operate. -d _______________________________________________ P2PSIP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
