Troubleshooting and FAQ


  1. Everything looks alright, but I cannot see any remote video
  2. Any tips to make easier the development of my app with OpenVidu?
  3. I am using Windows to run the tutorials / develop my app. Anything I should know?
  4. Does my app need a server-side?
  5. The CloudFormation Stack is a nice option for Amazon, but I don't like it. I want more control
  6. What are STUN and TURN servers and why do I need them?
  7. What does OpenVidu not integrate regarding WebRTC and Kurento yet?
  8. What platforms are supported by OpenVidu?
  9. Which is the current status of OpenVidu regarding performance, scalability and fault tolerance?
  10. My local video is not showing up on the browser
  11. My Safari users with role SUBSCRIBER are not able to receive any remote video
  12. Videos are freezing on Safari for iOS
  13. Deploying OpenVidu in AWS is failing
  14. Deployment with Let's encrypt is not working
  15. Do I need to update Let's Encrypt certificates?
  16. My commercial certificate is not working, What can I do?

1. Everything looks alright, but I cannot see any remote video 🔗

You have an app that uses OpenVidu to stream some video user-to-user, and the process looks perfectly okey. No errors on the console and all the OpenVidu events you are subscribed to are correctly triggered. So what's happening?

99% of the time this is a problem related with OPENVIDU SERVER NOT HAVING A PUBLIC IP. To learn more about it, you can check this FAQ. The quickest solution to this problem is to deploy our ready-to-use OpenVidu Server in Amazon.

If you are a bit reluctant to this quick solution with Amazon CloudFormation, you can always deploy OpenVidu by yourself with Docker. Check Deploying OpenVidu on premises section to learn how to properly do it.

Besides that, these are the recommended steps to follow when videos are not received:

  • Access your OpenVidu dashboard (https://YOUR_OPENVIDU_IP:4443) to quickly test the video transmission (user: OPENVIDUAPP, pass: [your private secret])
  • Please be sure that your OpenVidu Server host meets the network requirements.

The other 1% of the time this can be an attempt of accessing the same camera from two different browsers at the same time. Remember that Chrome, Firefox, Opera and Safari are distinct processes which cannot generally access the same physical resource (as a webcam) at the same time on your computer. On the other hand, accessing the camera from different tabs of the same browser is tipically possible.


2. Any tips to make easier the development of my app with OpenVidu? 🔗

You can do some things to improve your efficiency while using OpenVidu:


Multiple tabs to test the video transmission 🔗

You can use multiple tabs in the same browser to test your video streams.

WARNING: you may have trouble for testing with tabs from different browsers at the same time, as they compete for the camera access.


Be very aware of the browser's console 🔗

There you can find logs reporting important stuff. Error messages can help you to solve many issues.

OpenVidu Browser is developed with both Chrome (first image) and Firefox (second image) in mind in terms of logging. By default the browser's console displays OpenVidu's high-level messages (that's when the option 'Info' is enabled, as seen in the images). This means logs about OpenVidu objects being created and destroyed and logs for each triggered event (only for those you are subscribed to).

Warn and Error messages are specifically reserved for unwanted situations, and you should check your code in case you spot one of them.

If you enable the lowest level of logging you can see all the messages concerning the WebRTC negotiation process (generally not very interesting for an OpenVidu user).


Remember the browser's cache 🔗

If you have changed your HTML, JavaScript or CSS code, refreshed the page and cannot see the changes on the browser, probably the cache is still serving the old files. To perform a hard reload of your page on the browser, press Ctrl + Shift + R


Share your app through your network to test with multiple devices 🔗

Making your app accessible to any device connected to your LAN network is very useful for quickly testing your app with different devices at the same time. To achieve this, you just have to indicate OpenVidu Server to use your dev machine LAN IP address as public url. For example, let's say that your machine has assigned ip 192.168.0.107 in your network:

docker run -p 4443:4443 -e DOMAIN_OR_PUBLIC_IP=192.168.0.107 openvidu/openvidu-server-kms:2.15.0

Then you just have to configure your app (REST API address / OpenVidu Java Client / OpenVidu Node Client) to connect to OpenVidu through https://192.168.0.107:4443/. Any user connecting to your app through in your LAN network will be able to send and receive video through this OpenVidu Server.


3. I am using Windows to run the tutorials / develop my app. Anything I should know? 🔗

Depending on how you are running Docker in your Windows system you may or may not require to do some changes. If you are using the modern and recommended Docker for Windows, everything should work fine out-of-the-box just as explained in tutorials. No changes required.

But if you are running Docker in Windows with the legacy Docker Toolbox, some little changes are needed just because you won't be able to use localhost as IP to connect to OpenVidu Server. You will have to use the specific IP allocated to your container. You can get it by running command docker-machine ip default (will output something similar to 192.168.99.100, but the IP can vary).

First of all, you must launch the developing Docker container of OpenVidu Server (openvidu/openvidu-server-kms) setting parameter DOMAIN_OR_PUBLIC_IP to the IP allocated for Docker in your Windows machine.

What in Linux/Mac is...

docker run -p 4443:4443 --rm -e OPENVIDU_SECRET=MY_SECRET openvidu/openvidu-server-kms:2.15.0

...in Windows with Docker Toolbox may be...

docker run -p 4443:4443 --rm -e OPENVIDU_SECRET=MY_SECRET -e DOMAIN_OR_PUBLIC_IP=192.168.99.100 openvidu/openvidu-server-kms:2.15.0

Then, to let your applications know how to connect to OpenVidu Server:

Applications Client-Side Only 🔗

(For example openvidu-hello-world, openvidu-insecure-js, openvidu-insecure-angular, openvidu-getaroom)

When consuming openvidu-server REST API, change location.hostname to the IP of the Docker container running openvidu-server (usually 192.168.99.100). For every one of the insecure tutorials listed above, the url where to send the REST operations ...

"https://" + location.hostname + ":4443/api/<OPERATION>"

... in Windows is ...

"https://192.168.99.100:4443/api/<OPERATION>"

Change this url in every insecure tutorial right here:

  • openvidu-hello-world: here
  • openvidu-insecure-js: here
  • openvidu-insecure-angular: here
  • openvidu-getaroom: here

Also you will need to serve your apps over https. Browsers only accept camera usage on http when the address is localhost, and here it will be 192.168.99.100 or the one that Docker picks up for you. To serve over https with http-server, generate a self-signed certificate and run with -S flag on the root path of your app:

Generate a selfsigned certificate (run in your Docker console)

openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -subj '//CN=www.mydom.com\O=My Company LTD.\C=US' -keyout key.pem -out cert.pem

Run with SSL flag

http-server -S

Applications Client-Side + Server-Side 🔗

(Tutorials openvidu-js-java, openvidu-mvc-java, openvidu-js-node, openvidu-mvc-node and demo openvidu-call).

You must let know your app/tutorial how to initialize openvidu-java-client or openvidu-node-client (or where to send your REST API operations in case you are not using any of these clients). For example:

  • Java tutorials (tutorials openvidu-js-java, openvidu-mvc-java): override the default value of the property openvidu.url:

    mvn package exec:java
    

    in Windows is...

    mvn -Dopenvidu.url=https://192.168.99.100:4443/ package exec:java
    

    With this change we are simply changing the param urlOpenViduServer that our OpenVidu object from openvidu-java-client will receive in its constructor. This change is something related to these specific applications.

  • Node tutorials (tutorials openvidu-js-node, openvidu-mvc-node): change the URL param passed on launch:

    node server.js https://localhost:4443/ MY_SECRET
    

    in Windows is...

    node server.js https://192.168.99.100:4443/ MY_SECRET
    

    With this change we are simply changing the param urlOpenViduServer that our OpenVidu object from openvidu-node-client will receive in its constructor. This change is something related to these specific applications.

    With this change we are simply changing the param urlOpenViduServer that our OpenVidu object from openvidu-node-client will receive in its constructor. This change is something related to these specific applications.


4. Does my app need a server-side? 🔗

First of all, let's differentiate between OpenVidu server-side and your application's server-side.

  • You will always need OpenVidu Server deployed at some place on the Internet (check the Deployment section to learn how to do it in 5 minutes). For now, OpenVidu doesn't support p2p direct connections between two users, so all the traffic must flow to OpenVidu Server or from OpenVidu Server.
  • You will generally want your application to have its own server-side. Why?

Well, it is really not necessary. You can have a pure client-side application if you want. Just check any of these tutorials:
openvidu-hello-world, openvidu-insecure-js, openvidu-getaroom

The problem here is pretty evident: if you don't have any kind of server side to control your users, anyone can use your app. In fact, you can respectively see here, here and here a comment warning about this matter in every insecure tutorial. Due to the lack of a server-side in these tutorials, we have no choice but to embed the REST API consumption methods in our JavaScript code, which includes hardcoding our secret in the JS client code.

IMPORTANT: Do NOT include your SECRET in your JavaScript or HTML files in a production environment!

First an OpenVidu app Client-Side Only.

Second an OpenVidu app Client-Side + Server-Side.

In production you will usually want the second option to avoid unwanted users.


5. The CloudFormation Stack is a nice option for Amazon, but I don't like it. I want more control 🔗

You can always easily deploy everything by yourself with Docker. To do so, check Deploying OpenVidu on premises section.


6. What are STUN and TURN servers and why do I need them? 🔗

If the user's devices don't have a public and reachable IP, WebRTC connections cannot be established and therefore, video streams cannot be sent or received. This occurs when the users are behind NAT's and Firewalls. In brief, when they are hidden under complex networks.

In order to support these circumstances, WebRTC relies on STUN and TURN servers:

  • STUN can easily provide to the user's devices their own public IP (the IP that other devices on the Internet use to connect to it), so they can tell OpenVidu where to send the video streams. Only with a STUN server, around 86% of the time the connection will be successful.
  • TURN is an extension of STUN, and covers the most extreme cases of complex networks (symmetric NATs). It acts as a gateway, passing all the media streams from one side to the other. This situation will occur with a probability of around 8%.

For all purposes, OpenVidu Server acts as a final user, and your connections may fail if it is hosted behind a complex network. To provide a a solid service you definitely need both STUN and TURN servers. There are many public, free-to-use STUN servers (STUN server list), but because TURN always faces a much larger load when coming into play, no one offers it free of charge. The good news is that it is very easy to install a COTURN server, which offers both STUN and TURN:

  • Our ready-to-use CloudFormation stack already includes a properly configured COTURN server.
  • If you are deploying OpenVidu Server on your own, instructions in the Deploying OpenVidu on premises section already include a COTURN server.

    You can test your COTURN server on this website: Trickle ICE. To do so, remove the default Google server from the list and add your own following this format: turn:YOUR_TURN_IP:YOUR_TURN_PORT (add your TURN username and password below)


7. What does OpenVidu not integrate regarding WebRTC and Kurento yet? 🔗

As the main goal OpenVidu has is to make as simple as possible the integration of video-call capabilities in applications, it would make little sense to support all the features provided by Kurento: why would most of developers want visual recognition or augmented reality capabilities when adding video-calls to their apps?

But there's also a bunch of features supported by Kurento or WebRTC that will be part of OpenVidu as well:

  • Video composing: right now OpenVidu streams are always sent and received without any processing in Kurento Media Server, so every subscription to a video stream in a video-session implies its own WebRTC connection. We intend to provide the possibility of configuring video-sessions to be processed and send as only one video, composed in a grid by all the published streams (MCU architecture).
  • Direct p2p connections between users: OpenVidu will offer the possibility of connecting users without having to use Kurento Media Server as central node. This can be very advantegeous for certain use-cases, as will reduce the need of infraestructure.

8. What platforms are supported by OpenVidu? 🔗

OpenVidu supports a wide range of platforms:


Desktop browsers 🔗
  • Chrome
  • Firefox
  • Opera
  • Safari
  • Microsoft Edge >= 80


Mobile browsers 🔗
  • For Android
    • Chrome
    • Firefox
    • Microsoft Edge
    • Opera
    • Samsung Internet Browser
  • For iOS
    • Safari (Safari is the only browser in iOS with WebRTC support)

IMPORTANT: In iOS versions less than 13 have been found several bugs (videos and audio frozen) with WebRTC in Safari! These bugs look solved in iOS 13.


Mobile native applications 🔗

Both Android and iOS are supported:

  • Since release 2.7.0 through Ionic. You can try openvidu-ionic tutorial and you will have an OpenVidu native mobile application compatible working in minutes.

  • Since release 2.10.0 through React Native. You can try openvidu-react-native tutorial and you will have an OpenVidu native mobile application working in minutes.


Desktop native applications 🔗
  • Windows, OSX and Linux are supported since release 2.10.0 through Electron. You can try openvidu-electron tutorial and you will have an OpenVidu native desktop application working in minutes.

9. Which is the current status of OpenVidu regarding performance, scalability and fault tolerance? 🔗

In terms of performance, OpenVidu load testing process is described in detail in this Medium post. Results are the following for 7-to-7 sessions where every participant sends one audio-video stream (540x360, 30 fps) and receives 6 remote streams (same video). The table states the maximum number of entities that can be established until CPU reaches 100% use.

About scalability, you can try OpenVidu Pro scalability features. With OpenVidu Pro you can deploy an OpenVidu cluster to make your application scalable and automatically scale-in and scale-out the number of Media Nodes depending on the workload of your application.


10. My local video is not showing up on the browser 🔗

You cannot access the camera or microphone from an http URL. It will only work without SSL if the domain is localhost or 127.0.0.1. Media devices and WebRTC APIs of any browser requires a secure site to be available. In a nutshell: accessing the webcam on http://localhost:8080 or http://127.0.0.1:8080 is perfectly OK (at least in Chrome). But, for example, on http://172.17.0.1:8080 you won't be able to access to them.

This means that when deploying your app on production, you MUST use an SSL certificate and serve your app over https.

This also means that when developing your app in local, if for any reason you want to locally serve your app on a custom URL different than localhost, the only solution is to serve it over https with a certificate. If you are making use of the web server we have strongly suggested over the documentation (npm install -g http-server), you can do this with the following commands on your application's root path:

  • Generate a selfsigned certificate with openssl

    openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -subj '/CN=www.mydom.com/O=My Company LTD./C=US' -keyout key.pem -out cert.pem
    
  • Run http-server with SSL flag

    http-server -S
    

11. My Safari users with role SUBSCRIBER are not able to receive any remote video 🔗

Safari needs a user gesture to allow videos to automatically start playing if they have audio. This applies to users with role SUBSCRIBER: that is, users that don't need to perform a call to OpenVidu.initPublisher. If a user access its camera or microphone, then there's no need of user gestures at all (as soon as they accept camera permissions, remote videos will automatically start playing).

So, in this particular case developers must show a button their SUBSCRIBER users must click (any other action that counts as user-gesture is also suitable), and the action executed upon click event should include a call to video.play(). The actual video element is completely irrelevant. It can be hidden and with no media attached at all. For example:

<!-- This can be placed anywhere in the DOM. For example, as last child of <body> element -->
<video id="hidden-video"></video>
// Javascript code run upon any user gesture
var video = document.getElementById("hidden-video").play();

After this JavaScript line has been executed any remote video will start playing. This process is not necessary for future subscribed videos, when there is already some audio being played in the DOM.


12. Videos are freezing on Safari for iOS 🔗

Again, Apple's browser has "special" needs when it comes to video playback. In iPhones and iPads, Safari doesn't support out of the box the playback of multiple videos at the same time if they have audio tracks. Here you have a link to a bug related to this behavior.

Possible solutions to this issue? Tweaking muted property on videos to have only one playing audio at a time. Maybe using user gestures to directly play videos can help too. Other users have reported that it usually works fine if dynamically adding audio tracks to the same MediaStream object. There is not a clear solution to this problem, and depending on the web application some workarounds can succeed and some may not. On our tests we have even seen different behaviors in video playback from one execution to another, breaking the supposed consistency of the browser. It is really a matter of testing different approaches until you find a good enough solution.

Due to these problems, any other WebRTC based service we have tested usually redirected to a native application when trying to connect through iOS Safari. You can implement your native OpenVidu app for both iOS and Android with Ionic or React Native.


13. Deploying OpenVidu in AWS is failing 🔗

If you are deploying OpenVidu CE or OpenVidu Pro in AWS and the CloudFormation reaches CREATE_FAILED status, then possibly you are missing a default VPC in that specific region.

You can inspect your default VPCs like this: https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#view-default-vpc
And you can create a default VPC like this: https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#create-default-vpc

If you are still experiencing problems while deploying OpenVidu on AWS, please check out this guide: AWS Deployment Troubleshooting

14. Deployment with Let's encrypt is not working 🔗

Sometimes OpenVidu Deployments are not working on premises because nginx container is not able to run. Most of this problems are related with ports not opened or other services running.

First of all, if you can't access OpenVidu after configuring the deployment to run with Let's Encrypt, you must check the nginx logs with the next command:

sudo docker-compose logs nginx

14.1 Ngnix error while binding ports 🔗

sudo docker-compose logs nginx
Attaching to openvidu_nginx_1
nginx_1            | 2020/05/01 12:37:44 [emerg] 15#15: bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx_1            | nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx_1            | 2020/05/01 12:37:44 [emerg] 15#15: bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx_1            | nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx_1            | 2020/05/01 12:37:44 [emerg] 15#15: bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx_1            | nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx_1            | 2020/05/01 12:37:44 [emerg] 15#15: bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx_1            | nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx_1            | 2020/05/01 12:37:44 [emerg] 15#15: bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx_1            | nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx_1            | 2020/05/01 12:37:44 [emerg] 15#15: still could not bind()
nginx_1            | nginx: [emerg] still could not bind()
nginx_1            | Domain name: <your-domain>
nginx_1            | Certificated: letsencrypt
nginx_1            | Letsencrypt Email: <configured-letsencrypt-email>
nginx_1            | Proxy mode: CE
nginx_1            | Demos mode: true
nginx_1            | ===Mode letsencrypt===
...

If you see in your logs this: bind() to 0.0.0.0:80 failed (98: Address already in use), or any other errors related with binding ports, your deployment is failing because Nginx service can not use this specified port. In most of the cases this error happens because of port 80 is being used by other services running in the same machine as OpenVidu. Port 80 is used by our Nginx container for https redirection and letsencrypt. Be sure to not run any services at ports used by OpenVidu. These ports are defined here (OpenVidu CE) and here (OpenVidu Pro).

14.2 Let's Encrypt challenges errors 🔗

...
nginx_1            | Saving debug log to /var/log/letsencrypt/letsencrypt.log
nginx_1            | Plugins selected: Authenticator webroot, Installer None
nginx_1            | Obtaining a new certificate
nginx_1            | Performing the following challenges:
nginx_1            | http-01 challenge for <your-domain>
nginx_1            | Using the webroot path /var/www/certbot for all unmatched domains.
nginx_1            | Waiting for verification...
nginx_1            | Challenge failed for domain <your-domain>
nginx_1            | http-01 challenge for <your-domain>
nginx_1            | Cleaning up challenges
nginx_1            | Some challenges have failed.
nginx_1            |     - Requesting LetsEncrypt certificate...IMPORTANT NOTES:
nginx_1            |  - The following errors were reported by the server:
nginx_1            |
nginx_1            |  ...
nginx_1            |
nginx_1            |    To fix these errors, please make sure that your domain name was
nginx_1            |    entered correctly and the DNS A/AAAA record(s) for that domain
nginx_1            |    contain(s) the right IP address.
nginx_1            |
nginx_1            |
...

These errors can happen because a lot of reasons. Most common scenarios are:

  • DNS A/AAAA record configured is not pointing to the right IP: This error depends a lot of your kind of network. The most common scenario is OpenVidu deployed behind a NAT which router is not mapping correctly to the local IP and ports used by the machine where the deployment was made.
  • Other services running at port 80 or 443: If you have another service running at this port, the path http://<your-domain>/acme-challenge>/... will not be accessible or it will return an invalid response to Let's Encrypt.

14.3 Other Nginx errors 🔗

If none of this errors is your problem, ensure that your deployment accomplish the next points:

  • Make sure to not run any services at port 80 or port 443. Let's Encrypt will not be able to make the challenges to validate your certificate
  • Try, if possible, to not run any other service (Nginx, Apache, Tomcat) in your OpenVidu machine.
  • Be sure that all ports documented here(OpenVidu CE) or here (OpenVidu PRO) are visible using your domain name and your public ip. Also ensure that all the documented ports are available and not used by other services.

If none of this works, you can try to remove /opt/openvidu/certificates folder and restart OpenVidu with:

sudo ./openvidu restart

15. Do I need to update Let's Encrypt certificates? 🔗

No, it is not necessary. The Nginx container is configured to renew automatically your certificates.

16. My commercial certificate is not working, What can I do? 🔗

Sometimes problems related with Commercial Certificates are due because of a wrong creation of the certificate.key and the certificate.cert in /opt/openvidu/owncert.

Be sure that your certificates follow this format:

  • certificate.key is the private key and must follow this format:
-----BEGIN PRIVATE KEY-----
<BASE64_PRIVATE_KEY>
-----END PRIVATE KEY-----
  • certificate.cert are the public keys and must follow this format:
-----BEGIN CERTIFICATE-----
<BASE64_PUBLIC_KEY>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<BASE64_PUBLIC_KEY>
-----END CERTIFICATE-----

...

Normally official certificates have a chain of public keys in the .cert file