Hi, Bruce: Sorry for late response. See inline.
-- Jiang XingFeng > -----Original Message----- > > > > > > > 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------------| > > > > > If we allow a TURN server to be behind a NAT, then the only change I > would see necessary would that 1 and 4 would have to be routed over > the overlay (a reload tunnel, for example). 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 as long as the two voice endpoints support ICE; > the connectivity checks should take care of any form of filtering the > NAT uses. While TURN client in question gets its relayed address from the TURN server, it will exchange them with its peer, say B. According to the connectivity check in ICE, B and ICE will send message to try to find direct connection. So if B send the message destined to the relayed address first, it will be filtered by the TURN server. Then TURN client sends a message destined to the B's candidate, it will send the message through the TURN server. But in the message 1 reached the TURN server in a hop-by-hop way, if the message is sent directly to the TURN server, it will be filtered. If the message is sent in a hop-by-hop way through the overlay, the immediate peer to the STUN server may change over time, so the message may also be filtered. Am I missing something? Regards! JiangXingFeng _______________________________________________ P2PSIP mailing list [email protected] http://www.ietf.org/mailman/listinfo/p2psip
