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

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
  • Internet Explorer 11


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