3

Let's assume two devices are behind symmetric NATs.

  1. Device_1 ONLY gathers HOST and REFLEXIVE candidates. It sends them to Device_2 in an SDP OFFER.

  2. Device_2 gathers HOST, REFLEXIVE and RELAY candidates. It sends them to Device_1 in an SDP ANSWER.

  3. During ICE connectivity checks, Device_2 will install a permission into its TURN server. This will be the REFLEXIVE candidate of Device_1.

  4. At some point, a STUN indication will be sent from Device_1 (reflexive) to Device_2 (relay). If Device_2 has created a permission for reflexive address of Device_1, the UDP packet should hit the TURN server, get wrapped in a STUN message, and then arrive at Device_2. This connectivity check should pass, and therefore bidirectional traffic should flow.

Is this understanding correct?

          RESTRICTED_NAT                         RESTRICTED_NAT
                |                                      |
Device_1 <----> | <--UDP--> [Device_2_TURN] <--SEND--> | <----> Device_2
Peer            |                                      |        Client

Host                                                            Host
Reflexive                                                       Reflexive
                                                                Relay

I asked a similar question a while ago Will ICE negotiations between peers behind two symmetric NAT's result in requiring two TURN servers?, but now im having doubts that two TURN servers are required for two peers behind symmetric NATs. The reason being, the permission that is created on the TURN server only includes an IP address.

https://datatracker.ietf.org/doc/html/rfc5766#section-9.1

   When forming a CreatePermission request, the client MUST include at
   least one XOR-PEER-ADDRESS attribute, and MAY include more than one
   such attribute.  The IP address portion of each XOR-PEER-ADDRESS
   attribute contains the IP address for which a permission should be
   installed or refreshed.  The port portion of each XOR-PEER-ADDRESS
   attribute will be ignored and can be any arbitrary value.  The
   various XOR-PEER-ADDRESS attributes can appear in any order.

That means that as long as the same server reflexive IP sends a UDP message to the relayed transport address, it should go through. Meaning, only one TURN server should be used.

Mmm Donuts
  • 9,551
  • 6
  • 27
  • 49

2 Answers2

2

This depends on how well the turn server software that you use has implemented the RFC. You'll need to check it.

The port is part of the xor-peer-address that gets sent to the TURN server so the natural assumption would be that any lookups happen against the full address.

But in the case of the other side being behind a symmetric NAT the port (and sometimes the IP but that is rare) used will be different. Which is likely the reason for the specific requirement in the RFC.

Philipp Hancke
  • 15,855
  • 2
  • 23
  • 31
  • 1
    Would I be right to assume here though that if the permission is solely the `xor-peer-address` with the port ignored, data should be able to reach both (even if they are behind symmetric NATs) by solely one side providing a TURN relay? Of course, Ill check coTURN to be sure. – Mmm Donuts Jul 16 '21 at 12:46
  • 1
    `rfc-5766-turn-server` at the very least, ignores the port in the permission check. – Mmm Donuts Jul 16 '21 at 13:37
2

Yes Philipp is right, it depends on the implementation details.

But the other criteria you did not specify is your list of assumptions is if the NAT's in front of Device_1 and Device_2 does let UDP pass through or not.

The most evil/problematic scenario is if Device_1 and Device_2 can't use UDP to connect to the Internet. In that case they both will have to use TCP to connect to each of their TURN relays. Since most (?) TURN servers today only hand our UDP candidates in this scenario Device_1 uses TCP to connect Device_1_TURN. The same applies to Device_2. But since both hand out UDP candidates now TURN server needs to connect to TURN server.

Device_1 <--TCP--> Device_1_TURN <--UDP--> Device_2_TURN <--TCP--> Device_2

In this case you can't get away with just one TURN relay, since Device_1 can't connect via UDP to the UDP based relay candidates of Device_2.

You could reduce this scenario to one TURN server again if the TURN server and Device_2 both implement support for TURN TCP candidates. And then Device_1 needs to have support for ICE TCP and connect via TCP to the TURN server:

Device_1 <--TCP--> Device_2_TURN <--TCP--> Device_2
Nils Ohlmeier
  • 1,061
  • 7
  • 8
  • I wish I could give you both checkmarks. We do hand out TCP, along with UDP credentials. This is interesting. If I understand the topology correctly, localActive (relay) and remoteActive (reflexive) means that data moves in directions through the relay. One side is sending/receiving through a ChannelBind, while the other is sending/receiving through UDP. If we have TCP enabled, what scenario would force `relay-relay`? Also would this mean a relay server is sending to another relay server? (`D1 <-> TURN_1 <-> TURN_2 <-> D2`) – Mmm Donuts Jul 19 '21 at 14:07
  • When D1 receives candidates from D2 it will send binding requests also through it's own TURN_1 relay. The binding requests send directly from D1 will fail, because it's NAT/FW blocks all UDP. Thus the only binding requests which will succeed are the once going through its relay. Since D2's NAT/FW also blocks UDP TURN1 can't reach D2 directly either. So the only successful binding request is going to be TURN_1 to TURN_2 (or vice versa). And TURN_2 forwards these to D2 over its TCP connection. So yes in this case you have trapezoid where traffic goes through both relays. – Nils Ohlmeier Jul 20 '21 at 00:09
  • AHHHHH okay I see. Since on the `relayed-transport-address` side, there is only UDP. That makes total sense. – Mmm Donuts Jul 20 '21 at 13:28