TURN client Peer X STUN server NAT TURN server
| | | | |
1. |-------------------->|---Give me a Turn Address
--------->|----------------->|
2. |<-----------------STUN Request----------|
3. |-------------------STUN Response------>|
4. |<--------------------|<---------here is your TURN
address-------------------|
Figure 1: message flow to get a TURN address
As Bruce suggested that message 1 and 4 will be routed through the overlay.
So here, we assume the Peer X is the neighbor peer to the TURN server.
Message 4 will return to TURN client by traversing Peer X or not. Here, we
assume the NAT has an address-dependent filtering behavior which most NATs
have.
When TURN servers receives message 1 through the overlay, it will set the
Internal Remote transport address as Peer X's transport address. Then send
message back to the Internal Remote transport address in its Internal
5-tuple. Then NAT will open a port for Peer X.
TURN client Peer Y Peer B NAT TURN server
| | | | |
5.|--------------------- ->|-------Send
Indication---------------------------->|
6. |----Binding Request------- | (filtered by
the NAT)
7.
8.
Figure 2 message flow for connectivity check in ICE
When TURN client wants to communicate with Peer B which is also behind the
NAT (the NAT in front of the Peer B is ignored in the Figure 2), it should
use overlay routing to exchange their candidates.
We assume the candidate pair from TURN client is {relayed candidate, server
reflexive candidate of Peer B}
So In message 5, TURN client will send a binding message which will be
encapsulate in the Send Indication and the message will be sent to TURN
server.
There are two ways which could be used to send the message:
1. directly, due to NAT has a address-dependent filtering behavior, NAT will
filter the message;
2. through the overlay. yes, the message could arrive at the TURN server.
But you know, overlay topology is changing and the immediate peer to TURN
server in message 5 may not be Peer X any more, may be other peer, such as
Peer Y. For TURN server, it will check its association, and find no matched
internal 5-tuple, because Internal Remoter Transport address has been
changed. It will be discarded by the TURN server.
On the other hand, Peer B will send a Binding request to TURN client's
relayed address, whose destination is TURN server. But it will also be
filtered by the NAT due to its filtering behavior.
To be honest, I am not very familiar with ICE. If there is something wrong,
please point it out. Thanks.
JiangXingFeng
_______________________________________________
P2PSIP mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/p2psip
