Coturn question and higher resolution question

Request for enhancement
1

Hello,

I have 2 questions.

  1. When I do “docker ps”, I can see “openvidu_coturn_1”,
    My company wants to service the app globally. Do we need to create additional STUN+TURN server IPs for each continent?

  2. In video calls, How do I set their video call resolution to support higher 1440p than 1080p resolution?
    I use Node.js, React, React-Native, Electron.

2

I hope if somebody in OpenVidu could answer the question.

3

Sorry for the delay @Wann_Lee

  1. It is not only Coturn. OpenVidu does not support p2p communication yet, so all media goes through a media server running next to OpenVidu (in OpenVidu CE), and in any case where the connection can not be established directly to the media server, it will use TURN. So, if you want to have a deployment which works globally, you will need different OpenVidu deployments in each continent.

    But this will not solve your problem entirely, because each session will be created on different OpenVidu instances. For example, If you have a session between one Asian user and one American user, your app should have “enough intelligence” to create a session in an OpenVidu instance deployed at a region which should be the nearest place for both users (Maybe Europe).

    TLDR: You need to deploy multiple OpenVidu instances globally and place sessions on each OpenVidu instance depending on the location of your users in this session.

  2. In video calls, How do I set their video call resolution to support higher 1440p than 1080p resolution?
    It is currently in the openvidu-browser API:

    When you create a Publiser object by calling OpenVidu.initPublisher, you can setup a PublisherProperties object where you can define the resolution

5

If I add the IP addresses of the TURN servers of companies that support global TURN servers (eg Xirsys, Twilio, etc) to OpenVidu’s configuration file, will this help solve the problem of global users making video calls?

No, it will make ICE candidate discover maybe quicker, but this will not solve global user problems of latency and packet loss because of congestion.

Regards.

6

If I have OpenVidu servers for each continent, how should I configure them to share sessions?

7

That’s a really hard question to answer.

OpenVidu is designed to be deployed (at the current time of writing this message) in an unique region, where each session lives in a unique media node.

If you want to have sessions around the world using OpenVidu, there is not a “configuration” for this kind of situation, you need to develop your own logic for that. In such scenario you will need to develop your own distributed service and create a logic to manage your own Session “concept” over OpenVidu sessions which will require you to develop a service which works over OpenVidu logic and over multiple OpenVidu servers. TLDR: Such kind of deployment and session distribution is not supported yet with OpenVidu.

So OpenVidu does not have a solution yet for that kind of situation, but we’re still advacing through that route in the long term future.

8

All the things @cruizba mentioned are true. There is not an automated way of having shared sessions over multiple OpenVidu deployments. However, there are some optimizations you can do on top of your globally distributed OpenVidu deployments to ensure a good quality service on your video calls.
The summary is something like this:

  • You have 3 OpenVidu deployments on 3 different continents: 1 in North America, 1 in Europe and 1 in Asia.
  • You build a simple service in your application to geolocate your Session participants before they connect to a Session.
  • When you have all of the geolocation information of all of your session participants (or the majority of them), you can now take an educated guess on which of the three OpenVidu deployments you should initialize the session to provide the best service, with the lower latency for the majority of participants. For example, if all of them are in Europe, just provide them tokens from your Europe’s OpenVidu deployment. If one of them is in India and the other in Canada, you should also locate the session in Europe, half-way from both of them. And so on…

The good thing about this approach is that the OpenVidu token-based access logic for your clients carries all of the information about the deployment where to connect to. So whenever you have the best decission, you just need to make your application backend consume the OpenVidu REST API of the “winner” deployment, store that info in your app (so you know which sessions are located in each deployment) and pass the token to your application’s frontend. Your application’s backend should work just as a kind of simple proxy, redirecting the REST API petitions to the correct OpenVidu deployment.

9

They are seem to be very good guide.
I appreciate them.