If the question is whether a TURN server can bind to a specific 2-tuple {ip, port} and communicate with TURN clients in a connection oriented way using a full 4-tuple {source ip, source port, destination ip, destination port}, the answer is yes. As you suggested, this is how some WebRTC media servers operate.

Unlike WebRTC media servers, TURN server also has to send packets to and receive packets from a third party since it acts as a UDP proxy for the TURN client. It needs a UDP socket in a connected state with a 4-tuple associated with the TURN client and a UDP socket with a 2-tuple to listen for packets from the third party. The 4-tuple and the 2-tuple forms a TURN "allocation". The ip, port for the third party peer is not part of this because this would make the TURN server more like a NAT, where it can't accept packets from unknown third parties.

So let's imagine we use a single 2-tuple for both TURN client <> TURN server and TURN server <> third party communication. When the TURN server receives a new UDP packet, it needs to tell apart:

A datagram from the TURN client (which one?)
A datagram from a third party (for which TURN client?)
Random internet junk like port scanning

The TURN protocol allows the Server to deal with (1) but not (2) or (3), so the TURN server is required to use a unique 2-tuple to communicate with third parties for every allocation. Because of this the section about allocations, the RFC8656 says:

The relayed transport address MUST be unique across all allocations so it can be used to uniquely identify the allocation

So the answer is no, you can't use a single port for every part of a TURN server.

The RFC is a little bit confusing as it also says this:

Since SIP supports forking, TURN supports multiple peers per relayed transport address; a feature not supported by other approaches (e.g., SOCKS [RFC1928]).

"multiple peer per relayed transport address" here refers to the fact that a TURN client can re-use the same relayed IP address to talk to multiple third parties, provided that it's same TURN client doing this. This is because all TURN server cares about is that this traffic is destined for the same TURN client.

That being said, if you're alright with ignoring the RFC, maybe you could keep track of the ICE connectivity check STUN packets over the TURN server and somehow tie the third party peer into the mix. This might work well if you also have access to the server reflexive address of third parties the TURN client is sending packets to.

Single port mode? #284

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions