0

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

user2139084
  • 275
  • 1
  • 4
  • 14

2 Answers2

4

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.

selbie
  • 100,020
  • 15
  • 103
  • 173
  • Thanks Selbie for the reply.I had some doubts.if both are behind port and address restricted NATs,both the Connectivity checks will fail.Then both will simultaneuosly send media to the remote party's RELAYED ADDRESS.So , the address to which we are sending media is different from the address from where we will receive media ?? then there needs to be a significant change in the Signalling also . – user2139084 Jan 27 '14 at 05:22
  • 1
    @user2139084 - If you use the ICE methodology, they should converge to the same TURN server. TURN server acts like an IP-restricted NAT. Client 1 will do a connectivity check to the public IP address of Client 2 through the TURN relay. Simultaneously, client 2 will do a connectivity check to the RELAY-ADDRESS of port 2. Eventually, both clients will be aware of each other. – selbie Jan 27 '14 at 05:40
  • Thank you Selbie for the help.I am still confused :) with certain issues.I will explain with an example.If A is behind NAT 1.1.1.1 and uses TURN server 1.2.3.4 and B is behind NAT 2.2.2.2 and uses TURN server 5.6.7.8. Now say both are behind Address and Port restricted NATs so Media relay is necessary .Now A will be sending and expecting data from 1.2.3.4 and B will be sending and expecting data from 5.6.7.8..Data transfer can take place only if the 2 turn servers have a connection in between. How is that handled ???? – user2139084 Jan 27 '14 at 05:56
  • How should they converge to the same TURN server? The TURN servers are configured in each client (see ICE RFC5245, 20.5 Endpoint configuration) and might by offered by their VoIP providers. And I don't see a mechanism specified on how they arrange to use the same TURN server. – Steffen Ullrich Jan 27 '14 at 06:01
  • My point of confusion is ,if both the devices support TURN, then to 1. where will A send data ?(A's TURN server or B's TURN server) 2. from where will B receive data ?(A's TURN server or B's TURN server) 3.Where will B send data ?(A's TURN server or B's TURN server) 4. from where will B receive data(A's TURN server or B's TURN server)..I think this will solve my doubt. – user2139084 Jan 27 '14 at 06:23
  • @SteffenUllrich - Start by reading some of Rosenberg's tutorials on ICE here: http://www.jdrosen.net/tutorials.html (Scroll down to the middle of the page for the two ICE tutorial slide sets). – selbie Jan 27 '14 at 07:05
  • @user2139084 - Same thing. Consider reading the ICE tutorials. Link the comment above this one. – selbie Jan 27 '14 at 07:06
  • @selbie - you are right. In the normal case they can talk using the same TURN server, only if they are behind some restricted firewall they need two TURN servers. I've adjusted my reply accordingly. – Steffen Ullrich Jan 27 '14 at 08:57
  • 1
    @SteffenUllrich - there are oddball cases where both TURN servers are used in a session. Such when both clients are behind an HTTP only firewall and the only connectivity they really have is to their own TURN server address. – selbie Jan 27 '14 at 10:23
  • Yes, like with WebRTC behind firewalls, where they try to use TURN through a CONNECT tunnel or with WebSockets. Scary stuff :) – Steffen Ullrich Jan 27 '14 at 10:57
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.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • Thanks Steffen Ullrich for the help.But in the solution which you gave, the IP address to which data will be sent and the IP address from where data will be received will be different.Is it not in contrast with the 'connection' field in the SIP ?Do we have to set 2 'connection' field with one for 'sendonly' and another for 'recvonly' ? – user2139084 Jan 27 '14 at 04:46
  • The connection field in the SDP body only specifies, where the peer should send its data to. This will be the external addresses provided by the TURN servers. That each of the client maintains a tunnel to its TURN server and the TURN server will forward the data to its client does not matter for the other side and thus needs not given in the SDP. – Steffen Ullrich Jan 27 '14 at 05:33
  • correction: the clients not only receive their data through the TURN server, they also send their data through it. Thus sending and receiving IP will be the same from the view of the peer. – Steffen Ullrich Jan 27 '14 at 05:43
  • Thanks Steffen for the help. If sending and receiving are the same IP, then there should also be a tunnel between the 2 turn servers ..for eg, if A uses 1.2.3.4 and B uses 5.6.7.8, then A will be sending and receiving data from 1.2.3.4 and B will be doing the same with 5.6.7.8.So there ought to be a tunnel between 1.2.3.4 and 5.6.7.8..Am i right ?? – user2139084 Jan 27 '14 at 05:51
  • I wouldn't call it a tunnel. Both TURN server exchange the data for their clients using public IPs, like the SIP clients itself would do it if they were not behind a NAT. – Steffen Ullrich Jan 27 '14 at 06:03
  • How does a TURN server know the existence of another TURN server to which it can exchange data ? How does it get the other servers IP address? – user2139084 Jan 27 '14 at 06:15
  • see step#3 and step#4 in my response - they both exchange the public addresses of the TURN servers in their SDP body, and not their private natted addresses. And client#1 instructs its turn#1 to send the data to turn#2 which address it received from client#2. – Steffen Ullrich Jan 27 '14 at 06:20
  • Oh :) got it.. The Client will create TURN permission for the remote party's TURN address and NOT remote party's SRV-REFLEXIVE ADDRESS. – user2139084 Jan 27 '14 at 06:37
  • We cannot configure both the end devices to use the same TURN servers as they are independent to choose (configurable). Now,if they use different servers,the local device needs to create Permissions in its TURN server. Should it create permissions for remote local IP,remote NATed IP and also to remote Relayed IP ? – user2139084 Jan 27 '14 at 09:09
  • they use different TURN servers during the discovery on how to connect to each other. But if client#1 succeeds in connecting directly to the TURN server of the peer (turn#2 at addr#2) it automatically establishes a back-tunnel through its NAT and in this case they both can use the same TURN server turn#2 – Steffen Ullrich Jan 27 '14 at 09:12
  • Thanks for the reply. If that's the case,then the client#2 should have created permissions for NAT#1 address. And is there any way that we could decide to use one of the TURN servers ?And do we need to create permissions to the addr#2(relayed address of client#2) at turn#1 ? – user2139084 Jan 27 '14 at 09:26
  • 1
    client#1 first sends a packet to turn#2 which will be denied but opens the back.tunnel through NAT#1. When client#2 sends a packet via turn#2 to client#1 this creates the permission for client#1 to send packets back through turn#2 and thus the connection is established. No permissions need to be created for turn#1 because no data pass through it. I don't know how it gets select which of the TURN servers will be used, but it should be defined in ICE and as long as each client can directly connect to the peers TURN server it should not matter. – Steffen Ullrich Jan 27 '14 at 10:00