webrtcturnice

Is a single TURN server sufficient for two devices behind restricted NAT configurations?

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.

Solution

  • 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