Does the TURN server support multiplexing?

[David C]

I'm wondering if the TURN server supports multiplexing capabilities through single port? Because in an enterprise setting, it doesn't seem feasible in opening a new UDP port for every peer connection.

[Oleg Moskalenko]

The relay multiplexing is impossible in the TURN communications. The only multiplexing is happening at the TURN Server client-side socket. 

An Enterprise TURN Server that is intended for the external communications must be located at the "edge" of the network. There must be two network interfaces in the TURN server box. One interface must be located "outside", in the public network, and that interface must be configured for the relay endpoints (and, optionally, the listening endpoint(s),.too). Another interface must be "inside", in the private network. That interface must have the listening endpoint configured.

Of course, many interfaces can be configured, not just two.

This TURN server allows that kind configuration. The listening IP addresses and the relay IP addresses can be configured separately.

Oleg

On Fri, Jun 27, 2014 at 4:44 PM, David C <ksb...@gmail.com> wrote:

I'm wondering if the TURN server supports multiplexing capabilities through single port? Because in an enterprise setting, it doesn't seem feasible in opening a new UDP port for every peer connection.

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

[David C]

I mean for like in the situation, for example, when peer A behind a NAT attempts to communicate with peer B who is outside through the TURN server, then peer A will be sending data to one port on the TURN which relays to peer B on a relay port. But then if another peer C behind the NAT attempts to communicate with peer D, then peer C send towards a different port on the TURN and relay to another relay port for peer D. 

I guess what I'm asking is that if there's an implementation or feature on the TURN server so that it can multiplex/demultiplex the data receiving from behind the NAT and send to the peers outside instead of opening a new port each time a new peer connects, like having a table of IP:Port of the peers outside the NAT and relay the data using that.

But from what it sounds like this is not possible?

On Friday, June 27, 2014 10:29:02 PM UTC-7, Oleg Moskalenko wrote:

The relay multiplexing is impossible in the TURN communications. The only multiplexing is happening at the TURN Server client-side socket. 

An Enterprise TURN Server that is intended for the external communications must be located at the "edge" of the network. There must be two network interfaces in the TURN server box. One interface must be located "outside", in the public network, and that interface must be configured for the relay endpoints (and, optionally, the listening endpoint(s),.too). Another interface must be "inside", in the private network. That interface must have the listening endpoint configured.

Of course, many interfaces can be configured, not just two.

This TURN server allows that kind configuration. The listening IP addresses and the relay IP addresses can be configured separately.

Oleg

On Fri, Jun 27, 2014 at 4:44 PM, David C <ksb...@gmail.com> wrote:

I'm wondering if the TURN server supports multiplexing capabilities through single port? Because in an enterprise setting, it doesn't seem feasible in opening a new UDP port for every peer connection.

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

[Oleg Moskalenko]

This makes no sense. But definition, a "peer" in TURN sense cannot be behind a NAT. Only "client" can be behind a NAT. Try to draw some network diagrams to straight this out - what exactly you would like to achieve. Honestly, after reading your email, I have no idea what you are talking about.

Regards,

Oleg

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.

[David C]

Sorry for the confusion, I use the term peer because I'm implementing the TURN for WebRTC which has no server/client, just peers.

So basically my question is if there are 10 "clients" that are connect to the TURN, does that mean the TURN has 10 ports opened externally?

[Oleg Moskalenko]

TURN opens a new relay port/IP combination for every session. If all the 10 clients will communicate only within their "community" then those ports will not have to be "opened" to the external world - the communications will be short-circuited within the TURN Server. But if they are using external peers then those ports have to be opened to the outside.

As I said before, that must be not a problem - because an enterprise TURN server, ideally, must have its relay interface(s) located beyond (outside of) the firewall/NAT. You must not place the TURN server  within the private network, unless you want to communicate only within that private network.

Oleg

On Saturday, June 28, 2014 1:06:22 AM UTC-7, David C wrote:

Sorry for the confusion, I use the term peer because I'm implementing the TURN for WebRTC which has no server/client, just peers.

So basically my question is if there are 10 "clients" that are connect to the TURN, does that mean the TURN has 10 ports opened externally?

On Sat, Jun 28, 2014 at 12:12 AM, Oleg Moskalenko <mom0...@gmail.com> wrote:

This makes no sense. But definition, a "peer" in TURN sense cannot be behind a NAT. Only "client" can be behind a NAT. Try to draw some network diagrams to straight this out - what exactly you would like to achieve. Honestly, after reading your email, I have no idea what you are talking about.

Regards,

Oleg

On Fri, Jun 27, 2014 at 11:21 PM, David C <ksb...@gmail.com> wrote:

I mean for like in the situation, for example, when peer A behind a NAT attempts to communicate with peer B who is outside through the TURN server, then peer A will be sending data to one port on the TURN which relays to peer B on a relay port. But then if another peer C behind the NAT attempts to communicate with peer D, then peer C send towards a different port on the TURN and relay to another relay port for peer D. 

I guess what I'm asking is that if there's an implementation or feature on the TURN server so that it can multiplex/demultiplex the data receiving from behind the NAT and send to the peers outside instead of opening a new port each time a new peer connects, like having a table of IP:Port of the peers outside the NAT and relay the data using that.

But from what it sounds like this is not possible?

On Friday, June 27, 2014 10:29:02 PM UTC-7, Oleg Moskalenko wrote:

The relay multiplexing is impossible in the TURN communications. The only multiplexing is happening at the TURN Server client-side socket. 

An Enterprise TURN Server that is intended for the external communications must be located at the "edge" of the network. There must be two network interfaces in the TURN server box. One interface must be located "outside", in the public network, and that interface must be configured for the relay endpoints (and, optionally, the listening endpoint(s),.too). Another interface must be "inside", in the private network. That interface must have the listening endpoint configured.

Of course, many interfaces can be configured, not just two.

This TURN server allows that kind configuration. The listening IP addresses and the relay IP addresses can be configured separately.

Oleg

On Fri, Jun 27, 2014 at 4:44 PM, David C <ksb...@gmail.com> wrote:

I'm wondering if the TURN server supports multiplexing capabilities through single port? Because in an enterprise setting, it doesn't seem feasible in opening a new UDP port for every peer connection.

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.

To post to this group, send email to turn-server-project-rfc5766-turn-s...@googlegroups.com.

Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

[Oleg Moskalenko]

If you still have questions, then simply open the RFC 5766 document and read how the TURN communications are designed, from the network topology point of view. If you have 10 clients all behind a NAT/firewall, and an external TURN server, then all you have to open in your firewall is 1 single TURN server port.

Oleg

[David C]

Thank you for your help.

You received this message because you are subscribed to a topic in the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/turn-server-project-rfc5766-turn-server/iJ4LJOQD1cc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.