0

I am implementing a TURN server and I am going to use TURN rfc5766 terminology in my question.

There is a part that I do not get. Lets say we have a client(A) who is connected to the TURN server and a peer(B) who is not connected to anything yet. We get peer(B)'s reflexive address from another mechanism and pass it to client (A) using SIP or email. Whatever the case maybe.

Next lets assume we created an allocation, permissions, and relay address for client(A)

It says that when client(A) sends a data indication for peer(B) to TURN server to relay, it attaches peer(B)'s server-reflexive address to the indication. Server then extracts the udp from the indication and the peer(B)'s reflective address and sends it to the peer(B) . What I don't get is that how can the server reach the peer(B) behind its NAT. Just knowing peer(B)'s server-reflexive address does not cut it right. If peer(B) has never communicated with the server, peer(B)'s NAT will never create a mapping from Peer(B) to client(A)'s relay-address on the TURN server.

And if server can reach the server-reflexive address of the peer(B) with out ip:port mapping so can client(A) (since client knows that server-reflexive address of the peer(B) too). And it would not need the turn server. It would just use STUN.

What is the point of TURN Server then ? What am I missing.

One can argue that Maybe peer(B) did a STUN binding request beforehand to the same server and that is how we got peer(B) server-reflexive address and that request created a NAT mapping on the peer(B)'s side. Well that works only for NATs which use Endpoint-Independent Mapping and Address-Dependent Mapping but not Address and Port-Dependent Mapping. Because relay-address of the client(A) is different than the address of the Turn server where STUN binding request is send. Ex: Turn Server Address: 121.121.121.121:8080 Clients relay address: 121.121.121.121:8081(on the same turn server different port. ). Since stun binding message goes to 121.121.121.121:8080 there is no mapping on Peer(B)'s NAT for 121.121.121.121:8081. Basically bridge is broken.

Thanks.

Mikko
  • 1,877
  • 1
  • 25
  • 37
Evren Bingøl
  • 1,306
  • 1
  • 20
  • 32

1 Answers1

0

The problem in your explanation is that the peer(B) would not be connecting to the TURN server before the messaging starts. This is not true.

For a WebRTC client the STUN and TURN server addresses will need to be configured. When the clients create the PeerConnections, they will both connect to the TURN server before the actual messaging begins. For this to work, both peers have to connect to the TURN server, and do the "hole punch" which then allows the traffic through the NAT.

When relaying the the traffic through a TURN server, the clients will not know each others IP addresses, just the TURN endpoints to communicate with.

Mikko
  • 1,877
  • 1
  • 25
  • 37