Openvidu Pro & CE - Media Node+KMS+Coturn Configuration

Huioqy · September 17, 2020, 6:37am

Hi Openvidu Team!

First of all, thanks a lot for building up this great project.

Here are some questions related to the KMS & Coturn initial set up in the Openvidu On premise deployment with subnet segregation (only coturn and nginx proxy in DMZ zone wtih public internet access while the rest inSF zonewith limited intra VPC network access).

1.KMS docker container - environment variable settings

Docker Hub - kurento/kurento-media-server

STUN/TURN server: KMS_STUN_IP, KMS_STUN_PORT, KMS_TURN_URL
RTP port bindings: KMS_MIN_PORT, KMS_MAX_PORT

For the CE version, if I set up the above variables in docker-compose with VPC intra network settings (e.g., private IP Address instead of public IP address for Coturn server, changing the KMS port ranges & Coturn port ), will these variables be overwritten by the openvidu server when they are setting up the connections?

For the PRO version, I find that the KMS is controlled by the Media Node Controlloer. Is it still possible to configure environment variables to KMS through the Media Node Controlloer docker contianer? If not possible, any suggestions on how to pass environment variables to the KMS docker container? I am using the customerized KMS image from my team and also need to pass addtional environment variables.

2.KMS and Coturn - port range settings

2.1 From the Openvidu documents for on-premise deployment, there are differeces of the port ranges between CE and PRO.

CE
Coturn: 57001 - 65535 TCP+UDP
KMS: 40000 - 57000 TCP+UDP

PRO
OpenVidu Server Pro Node
Coturn: 40000 - 65535 TCP+UDP
Media Nodes
KMS: 40000 - 65535 TCP+UDP

For the PRO version, when I checked the docker-compose file for Coturn, actually it sitll sets MIN_PORT=57001, MAX_PORT=65535. Is it true that the port ranges settings for Coturn
and KMS are actually still the same as the CE version?

2.2 Port Range setting rules between KMS and Coturn
Kurento Doc 6.14.0 #frequently-asked-questions

According to the above information from Kurento Doc 6.14.0, is it really required that Coturn and KMS are using the same set of ports?
Any advice or attention points on how to change the point ranges of KMS and Coturn. For example, for coturn, 3478 stay untouched but port range changes to 57001 - 60000 TCP+UDP. Anything needs to be changed in the KMS or Openvidu server side to match up to the new Coturn port ranges? Or are all these port ranges actually independent among the KMS and Coturn?

3. Coturn port range’s protocol settings

For Openvidu On premise deployment with subnet segregation, only coturn and nginx proxy are in DMZ zone wtih public internet access while the rest are in the SF zonewith limited intra VPC network access.

Due to the security concern of exposing a wide range of TCP+UDP ports to public for Coturn, we are planning to make the following changes based on turnserver · coturn/coturn Wiki · GitHub.

Coturn with ssl certificate.
3478 DTLS + TLSV1_2; no tcp,udp,tls,tlsv1,tlsv1_1
57001 - 65535 UDP

Refering to Kurento’s WebRtcEndpoint.conf.ini, KMS is working on udp protocol by default for Media traffic. So, just want to double confirm with you guys that any potient concern or issue may occur with Openvidu Server and KMS if I only enable Coturn with above protocols.

j1elo · October 28, 2020, 11:44am

Hi, let me summarize here the replies to some of your questions, so other people can benefit too when searching the forum:

Yes, right now that is the case, and we’re having discussions about how to improve the server so it doesn’t overwrite STUN or TURN settings if the media server already has these.

Not right now, but with the upcoming release 2.16, it will be easy to pass env vars to all media nodes through the media node controller.

Yes, this is a “config bug”, and it will be resolved in 2.16. OpenVidu CE needs to split the port range between Coturn and KMS, because both processes live in the same machine. Actually I believe we could leave both to use the same port range, and when there is a collision, they would just try to select a different port. But for now we’ll just leave it as two separate port ranges.

Not really. This was written a while ago, because of a misunderstanding on how TURN and KMS operate; but this is going to be improved in both OpenVidu 2.16 and Kurento 6.15 releases.

just to confirm: yes, they are independent.

Coturn separates 2 network segments that cannot connect directly (otherwise, STUN and direct connections would be used). In order to allow for maximum probabilities of successful connection, both UDP and TCP protocols are enabled by default:

When a WebRTC participant is behind a strict NAT or firewall that requires relay, it becomes a TURN client, contacting Coturn on its client listening port (3478 either UDP or TCP), and requesting a TURN relay transport.
Coturn listens for client requests on both UDP and TCP ports, to maximize the chances that the client’s firewall will allow the connection.
The TURN relay transport, mentioned above, is a random port selected on the TURN port range of Coturn. This range, again, can be either UDP or TCP, to maximize the chances that remote peers are also able to send RTP data to Coturn.
When a remote WebRTC peer wants to send RTP data to the TURN client, it doesn’t send to it directly, instead it sends data towards the corresponding TURN relay transport of Coturn. Then Coturn will relay this data through its client port (3478) towards the actual TURN client.

(I’m adding this explanation to the new TURN documentation that will be added to Kurento docs :-))

Now, you are deploying your own Coturn instance in the DMZ, so you are free to configure it as needed. Please refer to this for the most up to date reference on the turnserver.conf file:

github.com

coturn/coturn/blob/master/examples/etc/turnserver.conf

# Coturn TURN SERVER configuration file
#
# Boolean values note: where a boolean value is supposed to be used,
# you can use '0', 'off', 'no', 'false', or 'f' as 'false',
# and you can use '1', 'on', 'yes', 'true', or 't' as 'true'
# If the value is missing, then it means 'true' by default.
#

# Listener interface device (optional, Linux only).
# NOT RECOMMENDED.
#
#listening-device=eth0

# TURN listener port for UDP and TCP (Default: 3478).
# Note: actually, TLS & DTLS sessions can connect to the
# "plain" TCP & UDP port(s), too - if allowed by configuration.
#
#listening-port=3478

# TURN listener port for TLS (Default: 5349).

This file has been truncated. show original

You can disable TCP for the TURN clients, by using no-tcp. Then you could close the port TCP 3478 on your firewall.
You can disable TCP for the TURN relay transports, by using no-tcp-relay. Then you could close the whole TCP TURN port range on your firewall.
Of course, you can disable TCP altogether by using no-tcp and no-tcp-relay at the same time. Then you will be able to close all TCP ports on the firewall.

Note, however, that if you disable TCP then if there is some remote WebRTC participant behind a strict firewall that only allows TCP, they will not be able to connect. However I agree that such strict firewalls only allowing TCP are not very common, but there is a small % of cases where this actually happens.

Huioqy · November 10, 2020, 3:32pm

Thanks Juan for the detailed reply!

Currently, we are doing the testing with the company intra net, and find out some issues. Hope you can give some advice on the coturn server setup.

For our testing scenario, there are two groups of people who will join the openvidu meetings.
One side is joining within the company intranetwork while the other joins from public network.

For the openvidu server domain name, we are using the same domain name for both intranetwork and public network. Inside the intranetwork, the domain name will be pointed to a intranetwork private ip for the nginx+coturn server. For the public facing, the domain name will be pointed to the public ip address of the WAF & loadbalancer which are in front of the nginx+coturn server.

The web page and websocket of the control plane for openvidu server are able to work for this domain name setup for both intra network and public network. However, both side can not see each other, as the video frame for the other side is not showing up.

I think the issue is related to the coturn server ip address. Inside the docker-compose.yml for the openvidu server, COTURN_IP is set only as the coturn server’s public ip address. But this public ip address is not reachable for the intranetwork.

coturn/coturn/blob/master/examples/etc/turnserver.conf

I read the “turnserver.conf”. So coturn actually supports to set up both <public-ip/private-ip>. So my question is related to the openvidu side. Is it possible if we pass more than one ip addresses for the COTURN_IP so that the client brower wants to join the session with the token, they are able to test with multiple coturn ip and find out the correct coturn ip address in the end?

Topic		Replies	Views
Openvidu support for Kubernetes Request for enhancement	7	1612	January 8, 2024
OPENVIDU KMS on premise deployment Issues developing apps	5	325	June 5, 2020
Is it possible to change the default port of coturn if yes how? Issues with deployment	3	253	August 11, 2020
CoTURN and KMS Ports Issues developing apps	5	645	November 25, 2020
SdpEndpoint.conf for Docker How to implement?	6	603	September 29, 2021

Openvidu Pro & CE - Media Node+KMS+Coturn Configuration

1.KMS docker container - environment variable settings

2.KMS and Coturn - port range settings

3. Coturn port range’s protocol settings

coturn/coturn/blob/master/examples/etc/turnserver.conf

Related Topics