turn
turn copied to clipboard
pion
Single port mode?
Within the TURN spec... can we support using pion's single udp port mode?
https://github.com/pion/webrtc/tree/master/examples/ice-single-port
Related https://github.com/pion/ice/issues/400
Within the TURN spec...
I dont see a single port mode explicitly mentioned in RFC8656. Do you have some more infos? E.g. other TURN implementations which support it?
As far as im aware @stv0g it should just work - I didnt mean to say that the turn spec has it... I was asking those who know more about the turn spec than me if it would be ok. I think it would be. But I hadnt seen that the upstream project only supports muxing on host candidates.
I agree @danjenkins,
according to the RFC it should be possible to implement it. pion/ice already supports muxing for Host and Srflx candidates. Muxing for Relay candidates is still on the todo list.
@danjenkins do you mean single port on the TURN Client <> TURN server or TURN server <> remote peer path?
@danjenkins do you mean single port on the TURN Client <> TURN server or TURN server <> remote peer path?
I meant multiplexing all turn traffic over one port - just like webrtc media servers do now, far easier to deploy to environments like kubernetes etc
You don't need single-port mode for Kubernetes per se, see here. You cannot expose a media server over a Kubernetes Service anyway since Services usually do random load-balancing over the endpoints.
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.