>
> The TURN server is responsible for obtaining a publicly-routable
> address, and giving that address to the TURN client. The TURN
> specification, as currently written, expects the TURN server
> itself to be on a publicly-routable network ("on the Internet").
>
> If, however, the TURN server is behind a NAT, and we want the
> TURN server to still be responsible for obtaining a
> publicly-routable IP address, you could do that. Here is a
> new technique that could be used: the TURN server could use
> STUN (or NAT-PMP or UPnP, if there is only one NAT between
> the TURN server and the Internet), and obtain a publicly-
> routable mapping:
>
>
> 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.
>
> For the above message flow to work, the NAT has to be
> p2p-friendly, of course -- that is a requirement for a
> successful TURN server behind a NAT.
If the NAT is nested, the location of the STUN server may fail the above the
method. For example, if the STUN server is also behind the NAT and reflects
the inner NAT mapping, not outer most NAT mapping, to the TURN server, the
relayed address will not be used for the TURN client to contact with TURN
server. In order to avoid this kind of failure, stun server's location
should be learned by its clients. In china, due to the lack of the IPv4
address, nested NAT is not a rare situation.
Comments?
Regards!
JiangXingFeng
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
