Troubleshooting and FAQ
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 in Ubuntu 16.04. Check Deploying OpenVidu on Ubuntu 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
Ctrl + Shift + R
Share your app through your network to test with multiple devices
Making your app accessible to any device connected to your WiFi 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 openvidu.publicurl=https://192.168.0.107:4443/ openvidu/openvidu-server-kms:6.9.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
https://192.168.0.107:WHICHEVER_PORT_YOUR_APP_IS_LISTENING_THROUGH will be able to send and receive video.
3. I am using Windows to run the tutorials / develop my app. Anything I should know?
Yes, some little changes are needed because of the way Docker runs on Windows. In Linux/Mac, Docker containers are easily accesible through
localhost, but in Windows you will have to use the specific IP allocated to your container (usually
First of all, you must launch the developing Docker container of OpenVidu Server (openvidu/openvidu-server-kms) setting paramater
openvidu.publicurl 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.8.0
...in Windows is...
docker run -p 4443:4443 --rm -e openvidu.secret=MY_SECRET -e openvidu.publicurl=https://192.168.99.100:4443/ openvidu/openvidu-server-kms:2.8.0
Then, to let your applications know how to connect to OpenVidu Server:
Applications Client-Side Only
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 ...
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.100or the one that Docker picks up for you. To serve over https with
http-server, generate a self-signed certificate and run with
-Sflag 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
Applications Client-Side + Server-Side
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:
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
urlOpenViduServerthat our OpenVidu object from openvidu-java-client will receive in its constructor. This change is something related to these specific applications.
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
urlOpenViduServerthat 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?
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 deploy everything by yourself. To do so, check Deploying OpenVidu on Ubuntu 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 form 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 by your own, there are detailed instructions in the Deploying OpenVidu on Ubuntu section, which explains how to install, configure and run COTURN on Ubuntu.
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. Does OpenVidu support Android and iOS?
Since release 2.7.0 Android and iOS are supported through Ionic. You can try openvidu-ionic tutorial and you will have an OpenVidu native application compatible with both Android ang iOS working in minutes.
9. Which is the current status of OpenVidu on scalability and fault tolerance?
OpenVidu load testing process is described in detail in this Medium post. Results are the following for 7-to-7 sessions were 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.
That said, one of the most important features OpenVidu will offer is the possibility of automated scalability and fault tolerance. We intend to provide an easy-to-use service integrated with most popular cloud providers to allow the automated launching and shutdown of servers depending on the workload of your application.
10. I am getting an "Error accessing the camera" and I have already granted permissions on the browser
If you are using Chrome: you cannot access the camera or microphone from a
http URL if it is not
127.0.0.1. In a nutshell: in Chrome accessing the webcam on
http://127.0.0.1:8080 is perfectly OK. But, for example, on
http://172.17.0.1:8080 it will through an error saying "Only secure origins are allowed". If for any reason you want to serve your app locally on a custom URL, 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
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>