rfc 5766 : Issue when Both devices support TURN

Question

I have been going through the TURN rfc 5766 and didn't find explanation to an issue.The rfc talks about ONLY 1 device(client) that supports TURN and the other device doesn't support TURN. I have certain doubts when both support TURN.I am using SIP protocol.It is assumed that both devices are behind bad NATs(i.e. address and port restricted NATs).

If both devices,say Device A and Device B supports TURN,

1.To which transport address will Device A send its application data? a.To its allocated RELAYED ADDRESS. b.To remote party's RELAYED ADDRESS.

1.From which Transport Address will Device A receive application data? a.From its allocated RELAYED ADDRESS. b.From remote party's RELAYED ADDRESS.

Thanks and regards

Answer 1

The RFC talks about a TURN server outside of NAT and a client behind NAT, which needs to talk to another client also behind NAT. The idea is, that each client connects to a TURN server (not necessary the same), gets an public address from the server and sends this address inside the SIP message (e.g. the SDP body) to the other client, e.g.

1. client#1 will connect to turn#1 and get public addr#1
2. client#2 will connect to turn#2 and get public addr#2
3. client#1 sends addr#1 to client#2
4. client#2 sends addr#2 to client#1

If client#1 can reach addr#2 directly (usually the case, unless you have a restrictive firewall and not a simple NAT) it will send a packet to addr#2 and thus dig a tunnel into its own NAT. Thus not only packets from client#1 to addr#2 are possible, but also packets from addr#2 to client#1. The result is the following communication scenario:

client#1 <---NAT#1---> turn#2 (addr#2) <---NAT#2---> client#2

Only if direct communication between client#1 and addr#2 (or client#2 to addr#1) is not possible (uncommon, only if both are behind restrictive firewalls) you need to use both TURN servers:

client#1 <--FW#1---> turn#1 (addr#1) <---> turn#2 (addr#2) <---FW#2---> client#2

Thanks to selbie@ for pointing out that usually a single TURN server is enough.

Answer 2

Let's assume there are two TURN servers. One used by client 1 with IP 1.2.3.4. The other used by client 2 at IP 5.6.7.8. Both TURN servers are listening on the standard listening port of 3478.

Let's saying during an ICE or ICE-like negotiation session, Client 1 allocated port 8888 on its TURN server. Client 2 allocated port 9999 on it's TURN server.

After ICE negation, assuming the clients couldn't connect direct, the flow of data between both clients will be ONE of the following

• Client 1 sends data packets (encapsulated inside a TURN message) from it's local port to it's TURN server's listening port (1.2.3.4:3478). The TURN server will unwrap this packet and forward the message from its relay port (8888) to the address of client 2. Data sent from client 2 will be sent as-is to the relay port on the TURN server allocated by client 1. (1.2.3.4:8888). When the TURN server receives datagrams from client 2 on the relay port, it will encapsulate the packet into a TURN message and forward it from port 3478 to the address of client 1.

OR

• Client 2 sends data packets (encapsulated inside a TURN message) from it's local port to it's TURN server's listening port (5.6.7.8:3478). The TURN server will unwrap this packet and forward the message from its relay port (9999) to the address of client 1. Data sent from client 1 will be sent as-is to the relay port on the TURN server allocated by client 2. (5.6.7.8:9999). When the TURN server receives datagrams from client 1 on the relay port, it will encapsulate the packet into a TURN message and forward it from port 3478 to the address of client 2.

In other words, if a TURN server was selected, one side will always send/receive data on the TURN port 3478 using the TURN protocol as encapsulate messages. The other side will always send/receive packets (not encapsulated) to the relay port allocated by the other client. How does it decide which TURN server to pick? It's not always deterministic in ICE.

In some rare cases, it can go "TURN to TURN". Both client's send/receive data from their respective TURN server's port 3478. The TURN servers forward the data to the other client's allocated relay address. This is uncommon, but can happen if all other candidate checks fail during ICE negotiation.