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

[Huioqy]

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]

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

@Huioqy

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?

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.

@Huioqy

Is it still possible to configure environment variables to KMS through the Media Node Controlloer docker contianer?

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.

@Huioqy

For the PRO version, when I checked the docker-compose file for Coturn, actually it sitll sets MIN_PORT=57001 , MAX_PORT=65535

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.

@Huioqy

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?

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.

@Huioqy

are all these port ranges actually independent among the KMS and Coturn?

just to confirm: yes, they are independent.

@Huioqy

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 […]

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:

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

• 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]

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?