Releases

• 2.32.0
• 2.31.0
• 2.30.0
• 2.29.0
• 2.28.0
• 2.27.0
• 2.26.0
• 2.25.0
• 2.24.0
• 2.23.0
• 2.22.0
• 2.21.0
• 2.20.0
• 2.19.0
• 2.18.0
• 2.17.0
• 2.16.0
• 2.15.0
• 2.14.0
• 2.13.0
• 2.12.0
• 2.11.0
• 2.10.0
• 2.9.0
• 2.8.0
• 2.7.0
• 2.6.0
• 2.5.0
• 2.4.0
• 2.3.0
• 2.2.0
• 2.1.0
• 2.0.0
• 1.9.0-beta-1

2.32.0 🔗

Artifacts 🔗

Release Notes 🔗

This is a maintenance release with important updates to internal dependencies and bug fixes. Upgrading OpenVidu applications from 2.31.x to 2.32.x is a straightforward process.

• Latest updates in all internal dependencies, fixing multiple CVEs and improving stability and performance across OpenVidu platform. This includes:
  • Node version and NPM depencies in openvidu-browser and openvidu-node-client.
  • Java version and Java dependencies in openvidu-java-client.
  • Spring framework and other Java dependencies in openvidu-server.
  • Versions of nginx, redis and coturn in production deployments.
  • For AWS deployments: OpenVidu AWS AMIs are now based on latest Ubuntu 24.04.
  • ELK observability stack updates:
    • Elasticsearch from 7.8.0 to 7.17.29
    • Kibana from 7.8.0 to 7.17.29
    • Metricbeat from 7.8.0 to 7.12.1
    • Filebeat from 7.8.0 to 7.12.1
• Latest kurento-media-server version (7.3.0).
• Latest mediasoup version (3.19.12) for OpenVidu Enterprise, bringing two years of fixes and improvements to the SFU inside Media Nodes.
• Fix possible crash in kurento-media-server Docker container for resource exhaustion in available file descriptors when the system is under heavy load.
• Speech-to-text: improved English language model in vosk STT service. Added russian language to default vosk service.

BREAKING CHANGES 🔗

• openvidu-browser: removed support for es5 (minimum es2015). This means that applications using openvidu-browser must now support at least es2015. This affects mainly applications supporting very old browsers (like Internet Explorer 11). All modern browsers already support es2015.
• openvidu-java-client: now requires Java 17 or higher.

PATCH VERSIONS 🔗

2.32.2 🔗

• Update Coturn to 4.9.0:
  • Fix CVE-2026-27624: bypass localhost and IP range block using IPv4-mapped IPv6.
  • Fix old STUN RFC 3489 needed by Kurento (submitted PR waiting for approval (https://github.com/coturn/coturn/pull/1839))
  • Only allow peer relay udp

2.32.1 🔗

• CVEs fixes in openvidu/openvidu-server Docker container (commit 5921eef).

2.31.0 🔗

Artifacts 🔗

Release Notes 🔗

Kurento 7.1.1 🔗

• Kurento Media Server has been updated to version 7.1.1. Which includes the following feautures:
  • Update to Ubuntu 24.04. Base OS system has been updated to latest stabe version noble (24.04). This includes several base packages updates, including GStreamer, libnice and libsoup.
  • Update to GStreamer 1.24.2, GStreamer is updated to 1.24.04 which benefits the stability and performance of all the underying system. This includes some annoying bug recording H264 from iOS and safari
  • Update to libnice 0.1.21
  • Update to libSoup 3.4.4,
  • Added DTLS state, On WebRTCEndpoint, now DTLS state is reflected on a status property and changes are communicated to application throough Kurento events
  • Added VP9 support, Thanks to the update to GStreamer we hae been able to add VP9 support to Kurento, including WebRTC VP9 support
  • Initial AV1 support, Initial AV1 support has been added to Kurento, however it is ot yet functional for WebRTC

Update internal dependencies 🔗

There has been numerous updates to keep dependencies up to date and without vulnerabilities. This includes:

• openvidu-browser and openvidu-node-client dependencies.
• openvidu-server: Update some patches and dependencies.
• Versions of nginx, redis and coturn for production deployments.
• For AWS deployments: OpenVidu AWS AMIs are now based on Ubuntu 24.04

2.30.0 🔗

Artifacts 🔗

Release Notes 🔗

Virtual Background bug fix when losing tab focus 🔗

The use of requestAnimationFrame as the callback to update the virtual background frames on video elements was a problem. When the browser tab lost focus, the callback stopped its execution and the video froze. This is now fixed by using directly setTimeout instead.

OpenVidu Call and OpenVidu Components missing thumnbail in Safari iOS 🔗

When muting a video, the thumbnail of OpenVidu Call and OpenVidu Components (consisting of the user initial) was not displayed in Safari iOS due to some problems with CSS styles. This is now fixed.

OpenVidu Components updated to Angular 17 🔗

OpenVidu Components library was fixed to Angular 14. It has now been updated and is possible to use it with up to Angular 17.

Update internal dependencies 🔗

There has been numerous updates to keep dependencies up to date and without vulnerabilities. This includes:

• openvidu-browser and openvidu-node-client dependencies.
• openvidu-server: latest patch update of Spring dependency.
• Versions of nginx, redis and coturn for production deployments.
• For AWS deployments: OpenVidu AWS AMIs are now based on Ubuntu 22.04 and IMDSv2 is enforcecd over IMDSv1.

2.29.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Share the screen audio in screen-sharing publishers 🔗

Now you can share the screen audio when initializaing a screen sharing Publisher. Check it our here.

New directives in OpenVidu Components 🔗

Including:

• Added simulcast directive.
• Added stream resolution directive to allow configuring a custom video resolution value.
• Added stream frame rate directive to allow configuring the frames per second of each stream.

BUG FIXES 🔗

• An annoying bug was causing issues after a random network drop in the client side. Some participants may remain in a "ghost" state, appearing to be still connected to the session when in fact there was no longer any connection between the client and the server. This in the end was causing affected Sessions to not being properly closed. The problem has now been addressed and any ghost participant is evicted from the session as soon as it is detected. Related issue (756).

2.28.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

OpenVidu Enterprise HA on premises 🔗

It is now possible to deploy OpenVidu Enterprise High Availability in your own servers! Since OpenVidu 2.20.0 we have offered the High Availability deployment option for high demanding environments which require full scalability and fault tolerance. But this option was only available as an AWS deployment. Up until now.

This new deployment option has also brought a brand new architectural solution. This has been done in order to simplify the management of the OpenVidu nodes, the decission on how many Master Nodes (for signaling) and Media Nodes (for video/audio streams) you should launch, and to prepare the ground for future native deployments on Kubernetes. OpenVidu Enterprise HA on premises deployments is now based on a single Node, which includes in a single machine all the components that were splitted between two different machines (a Master Node and a Media Node) before.

You can follow the instructions to deploy an OpenVidu Enterprise HA cluster on premises right here.

OpenVidu Components improvements related to language management 🔗

Including:

• A new event (onLangChanged) is emitted by VideoconferenceComponent when the application language has changed, so you can act upon a user selecting a different language. See the event here.
• A new directive (langOptions) is added to customize the language options available in the application. See here.

COTURN update to latest release 4.6.2 🔗

See all changelogs since previous version (which was 4.5.2) here.

BUG FIXES 🔗

• openvidu-node-client: it wasn't catching errors on "fetch()" request which could potentially affect the application's error handling
• openvidu-browser: custom screenshare tracks were not detected as screen. Now they are. Related Issues and PRs: Issue 808, PR 809.
• Recording: in OpenVidu PRO and OpenVidu ENTEPRISE, in very rare occasions the recording service could return a 404 error when stopping an active recording, instead of the expected 200. This could affect the ongoing session and future recordings for that session. This is now fixed.
• openvidu-java-client: global configuration paremeter OPENVIDU_WEBRTC_ICE_SERVERS was being overridden by openvidu-java-client when not configuring custom ICE servers, setting an empty array. This made OPENVIDU_WEBRTC_ICE_SERVERS configuration parameter to be ignored. Now this is fixed, and the global parameter will be used if Connection parameter for a custom ICE server is empty.
• OpenVidu Components: on fullscreen mode, the settings menu (3 dots) was not displayed. Now it is.
• OpenVidu Components: switching the camera in Android devices was not working properly. This is now fixed.
• OpenVidu Components: audiomuted and videomuted properties of the components were ignored if local storage values were present. This is fixed now.

2.27.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Kurento 7 🔗

The new major version of Kurento has been recently released, and it is now the default version used in OpenVidu. This new version of the media server focuses on upgrading the internal dependencies to recent official versions, compared to the old versions and custom forks used in Kurento 6. This brings improvements in terms of security and stability. You can read the release notes of Kurento 7 here.

openvidu-ruby sample application server now available 🔗

We have added a new sample application server in Ruby. If you plan to build your OpenVidu application server in Ruby, you can use it as a starting point. You can find it here: openvidu-basic-ruby.

Audio-only broadcasts now available 🔗

It is now possible to broadcast an OpenVidu Session as only-audio. Visit Broadcasting to learn how.

BUG FIXES 🔗

• openvidu-browser: calling Publisher.publishVideo(false, true) before publishing the Publisher to a Session was causing the audio track to not play on the Subscriber side. If the Publisher called the method after publishing to the Session, the audio played correctly. Now audio also plays correctly even in the case the Publisher stopped its video track before publishing to the Session. Related forum discussion: 4514. Related PR: 797
• Broadcasting: broadcasting to AWS Media Live was not possible. Now it is.
• Broadcasting: a failure in the startup process of a broadcast could end on some occasions with the Media Node being disconnected from the OpenVidu cluster. This is now fixed.
• Broadcasting & Speech To Text: a fatal error was preventing these services to start normally in very specific cases:
  • If a custom Speech To Text module was based on an outdated version of the base Speech To Text module.
  • If a custom layout with an outdated version of openvidu-browser was being used to broadcast. This is now fixed and the fatal error is now a warn/error message in openvidu-server-pro logs.
• OpenVidu Components: in a session with two participants and one of them using iPhone, if the other participant mutes the video, the iPhone participant was not able to see the video poster (instead the last frame was shown). This is now fixed.
• OpenVidu Components: if a Session was recorded, that recording was then deleted and the Session was recorded again, the recording service was showing the oldest deleted video due to the browser caching the request to the resource. This is now fixed.
• Openvidu Components: non-moderator participants didn't update their recording list because they didn't know when a recording had been deleted. Now all standard participants know the recording activity status. New onActivitiesPanelForceRecordingUpdate event is emitted when the participants need to update their recording list.
• OpenVidu Call: the application updates the recording list from the backend listening to onActivitiesPanelForceRecordingUpdate event.
• OpenVidu Call: fixed issue with participants name using Java Backend. Nicknames were not synchronized with other participants.
• OpenVidu Call: fixed a security bug with recording access. This is now fixed.

2.26.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Broadcasting to YouTube, Twitch or any other RTMP ingestion service 🔗

Do you want to stream your OpenVidu Sessions to thousands of users? You can now easily broadcast them to YouTube Live, Twitch or any other live ingestion service that supports RTMP protocol. This feature is seamlessly integrated in OpenVidu REST API, openvidu-java-client SDK and openvidu-node-client SDK. And you can fully customize the broadcasting layout with HTML/JS/CSS.

Check out the official documentation here.

The broadcasting feature is included in the OpenVidu Components library (so currently available in openvidu-angular) and in the OpenVidu Call application

openvidu-java-client SDK allows advanced configuration of its internal HTTP client 🔗

openvidu-java-client SDK offers now more flexibility when configuring its internal HTTP client. Now you may provide a custom HTTP client builder in the constructor of OpenVidu object. This may be interesting for many reasons, including adding custom HTTP headers, adding proxy configuration, modifying the default connection timeouts, setting up a cookie store, and other things. Check out the new constructors in JavaDoc.

openvidu-node-client SDK production mode to hide info logging level 🔗

openvidu-node-client SDK has a new method for production environments to silent logs of level DEBUG and INFO. Only WARNING and ERROR logs will be written to the output. Check out this new method in TypeDoc.

openvidu-ios now uses the latest WebRTC library 🔗

openvidu-ios sample application is now using the latest WebRTC version available for iOS. Previous version was from 2020, current version is the latest one available (Jan 2023). This brings all the improvements of the WebRTC standard updates to iOS.

BUG FIXES 🔗

• Speech To Text: when using AWS as STT engine, two equal SpeechToTextEvent could be triggered with reason recognized in a row. This behavior is not contemplated and is now fixed.
• OpenVidu Pro/Enterprise deployments: new configuration property OPENVIDU_PRO_ELASTICSEARCH allows launching OpenVidu Pro/Enterprise without an Elasticsearch. Before it was supposed to be possible to launch an OpenVidu Pro/Enterprise without an Elasticsearch by setting configuration property OPENVIDU_PRO_ELASTICSEARCH_HOST to an empty string, but this resulted in failed deployments. Now this is fixed with the new property. Of course, launching your OpenVidu Pro/Enterprise deployment without Elasticsearch will result in a complete absence of observability and history data.

2.25.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Speech to Text support for AWS and Vosk 🔗

The Speech to Text service introduced in release 2.24.0 has been extended with support for more engines. Now you can use:

• Azure: available since OpenVidu 2.24.0, it uses Speech to Text service from Azure stack.
• AWS: using Amazon Transcribe service from AWS stack.
• Vosk: using Vosk engine, the open source alternative with no extra cost compared to cloud providers.

Check out Speech to Text documentation to learn more about all of these alternatives.

Native support for private Docker registries 🔗

New configuration property OPENVIDU_PRO_DOCKER_REGISTRIES allows you to configure private Docker registries to be used in your Media Nodes. Your custom images of OpenVidu services can now be private but easily accessible by your nodes at the same time. The actual services that can take advantage of this feature are kurento-media-server (configured with property KMS_IMAGE) and speech-to-text-service (configured with property OPENVIDU_PRO_SPEECH_TO_TEXT_IMAGE).

OpenVidu Components new Speech to Text features 🔗

• Speech to Text capabilities of OpenVidu Components now includes automatic reconnection to the service in case of failure. See Reconnecting to Speech to Text module in the case of a crash.
• A new directive captionsLangOptions has been addded, which allows overriding the default Speech to Text language options. This allows you configuring your own custom languages in the case you are using Vosk as Speech to Text engine.

BUG FIXES 🔗

• OpenVidu Components : Fixed typo with recordingActivity directive that prevented it from working as expected.

2.24.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Speech to Text 🔗

The new Speech to Text service allows transcribing in real time the audio tracks of an OpenVidu Session. It makes very easy to include captions in your video calls, no matter what language your users speak!

This feature, available in OpenVidu Pro and Enterprise editions, is designed to support different transcription engines in the background. For now we have released Speech to Text with Azure support, but others are coming very soon (including a self-hosted open source alternative for no extra cost). You can read the Speech to Text documentation here.

Support for HTTP IP cameras 🔗

IP cameras API is now compatible with cameras publishing to http and https URIs (these are generally in .mjpeg format). These are without a doubt the most common IP cameras URIs, so this support opens up new possibilities of use.

OpenVidu Components features 🔗

• In case of a node crash in your OpenVidu Deployment, OpenVidu Components emits a new event onNodeCrashed. This allows the application to implement fault tolerance in case of a node crash. See Fault Tolerance.
• Update to Angular 14.

OpenVidu Call features 🔗

• Speech to Text integration. Enable live captions in your OpenVidu Call sessions.
• Added Basic Auth to securize the access to the application. Now by default there is a login page requesting for credentials before accessing a session (this can be disabled). New env vars: CALL_PRIVATE_ACCESS, CALL_USER, CALL_SECRET
• Adds support for fault tolerance and automatic reconnection to the session without user intervention in case of a node crash. See Fault Tolerance.
• Minor UI improvements.

BUG FIXES 🔗

• OpenVidu Call : users with no webcam or microphone were shown a blank screen when loading OpenVidu Call landing page. OpenVidu Call now allows connecting users with no input devices available.
• IP cameras : if option onlyPlayWithSubscribers was enabled, there was a bug preventing the camera feed to automatically reactivate once a new Subscriber requested the camera's Stream. Hence, the camera's feed appeared frozen and the only way to fix it was unpublishing and publishing the IP camera again. Now this is fixed.
• Recording : COMPOSED recordings now use some new internal configurations that should help reducing the launch time of the recording module.
• S3 recording : when using non-AWS S3 buckets, there could be access denied errors if the S3 endpoint was a domain name and not an IP. Now configuration property OPENVIDU_PRO_AWS_S3_WITH_PATH_STYLE_ACCESS allows forcing path style requests in the internal S3 client, which gets rid of this problem.
• openvidu-browser : calling Publisher.replaceTrack was triggering a wrong StreamPropertyChanged event, which resulted in a wrong modification of audioActive or videoActive Stream properties. Now new StreamPropertyChangedEvent.changedProperty values have been added: videoTrack and audioTrack. You can use these new values to know when a remote user has called replaceTrack on its Publisher object.

BREAKING CHANGES 🔗

• Only if using OpenVidu Call application: environment variables ADMIN_SECRET and RECORDING have changed their name to CALL_ADMIN_SECRET and CALL_RECORDING respectively.

2.23.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Renewed documentation and tutorials 🔗

We have made a complete revision of our documentation to make it clearer, more precise and easier to use. We have also updated all our tutorials to use a more production-ready approach than before. These are the main improvements of the new documentation:

• There is now an introductory section explaining the basic concepts of OpenVidu and how it fits in your application's stack: Developing your video app.

• There are now basic application server samples for multiple languages. These applications are minimal functional backends ready to work against OpenVidu. Every tutorial is now prepared to work with any of these application servers. You can take any of them as a starting point of your backend. Check out new section Application Server.

• For the Application Client of your OpenVidu app, we have divided the documentation into three different sections, from the most straightforward to the most customizable: Ready-to-use component, OpenVidu Components and Full control of the UI. Everyone of them with their own guided tutorials. And all of them are prepared to work against any of the application servers mentioned in the previous point.

New features in OpenVidu Call 🔗

Our flagship application OpenVidu Call continues to improve with the addition of some new useful features:

• Recording: from now on it will be very easy to record your video meetings in OpenVidu Call. Just open the "Recording" side panel to manage the recording of your session. The first user connecting to the session will be considered its administrator and will be granted permission to manage the recording process.
• Change your camera and microphone on the fly: now you can change your input devices during the call. Before, the device selection was restricted to the pre-join page.
• Languages support: OpenVidu Call now supports a wide range of languages. Just select the desired language and all the text elements of the interface will adapt accordingly.

Advanced TURN support in native Android/iOS apps 🔗

We have updated the native applications for Android and iOS to support the different TURN configurations offered by OpenVidu. This means unifying the operation of these applications with respect to those using the openvidu-browser.js SDK: now they are able to use the OpenVidu TURN server or an external TURN server. Connecting your users from secure networks will be easier with the new versions of these mobile apps.

OpenVidu Ionic now supports native desktop applications with Electron integration 🔗

OpenVidu Ionic has always been a good option to build your OpenVidu mobile application. And now you can use it also to build native desktop applications for Windows, MacOS and Linux using the same source code. Visit this section of the documentation to learn how.

RTMP and SIP support 🔗

We have included in the renewed documentation two new sections offering commercial support for RTMP streaming (you can stream OpenVidu sessions to services such as YouTube or Twitch) and SIP integration (add phone calls as participants in an OpenVidu session). Both services are offered as external modules that to be acquired will require contact with OpenVidu team through commercial@openvidu.io.

You can read the official documentation about these new features here:

• Streaming to YouTube/Twitch
• Phone calls integration

BUG FIXES 🔗

• OpenVidu Pro/Enterprise: there was a race condition when manually launching multiple Media Nodes at the same time that could end with some of them not being properly added to the cluster. This is now fixed.
• OpenVidu Enterprise HA: fixed HTTP status on some REST API endpoints that were overriding the real status with 500.
• openvidu-browser: method Publisher.replaceTrack produced an echo effect when replacing the audio track. Now this is fixed with commit 17ff910. Related issues 642 and PR 700.
• openvidu-browser: when calling method Publisher.replaceTrack with an audio track, that was deactivating events publisherStartSpeaking, publisherStopSpeaking and streamAudioVolumeChange. This is fixed now.
• openvidu-browser: the recordingStarted event wasn't being fired for new participants of a session, if they joined it after the recording was started. Now the event is always triggered for new users if the session is being recorded.
• openvidu-components: device labels were not shown in iOS. Now they are.

BREAKING CHANGES 🔗

• Configuration property OPENVIDU_DOMAIN_OR_PUBLIC_IP has been finally removed. More than two years ago OpenVidu 2.14.0 deprecated it in favor of DOMAIN_OR_PUBLIC_IP https://docs.openvidu.io/en/2.14.0/reference-docs/openvidu-config/.
• Configuration property SUPPORT_DEPRECATED_API is now false by default. It still exists, so you can turn it back to true if necessary. But it is absolutely advisable to migrate to the new API endpoints (introduced in OpenVidu 2.16.0, Nov 2020). See 2.16.0 release notes. An upcoming release will completely remove support for old API endpoints.
• Although this is not really a breaking change, the Ionic tutorial of OpenVidu now uses Capacitor by default as hybrid runtime, instead of using Cordova. The reasoning behind this change is pretty obvious: for quite some time now the Ionic team has considered Capacitor their primary choice over Cordova, even if they still support both of them. The Capacitor-based tutorial can now be found at openvidu-ionic, and you can still check out the Cordova-based tutorial at openvidu-ionic-cordova.

2.22.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Virtual Background 🔗

Virtual Background allows you to apply a filter to a video stream, such as a blurring effect or a background image. In this way you may cut out the person from the background, giving a more professional look to your video calls. Check out the documentation for further information.

OpenVidu Components 🔗

OpenVidu Components is a new frontend framework built for making videoconferencing applications for OpenVidu in the simplest possible way. It is an npm library (currently available for Angular) that provides the developer powerful and complete videoconferencing components. These components can be adapted, extended and replaced very easily to suit your application's needs. Visit the documentation page for extended information and guided tutorials.

Fault tolerance improvements 🔗

OpenVidu Pro and OpenVidu Enterprise improve their fault tolerance capabilities. There are two new additions:

• New configuration property OPENVIDU_PRO_CLUSTER_RECONNECTION_TIMEOUT allows you to customize the reconnection timeout in case a Media Node undergoes an unexpected disconnection from the cluster. Before this property, an OpenVidu cluster did not provide any time window for Media Node reconnections (they were simply removed from the cluster, and you would have to manually add them through REST API after their recovery). Now, depending on the deployment environment, the OpenVidu cluster will actually try to recover the connection with the crashed Media Node. This is especially useful in On Premises deployments, where Media Nodes have fixed IPs.
• New WebHook event nodeRecovered will be triggered after a Media Node is successfully reconnected to the OpenVidu cluster.

Check out Fault Tolerance documentation for further information.

Turn off webcam light when disabling video 🔗

Method Publisher.publishVideo has been extended in openvidu-browser library to support the forced release of hardware resources. This allows webcam lights to turn off.

TURN server can now be configured in Media nodes 🔗

For OpenVidu Pro and OpenVidu Enterprise clusters, the default TURN server can now be deployed in Media Nodes instead of in the Master Node. This is nothing more than the natural evolution for OpenVidu deployments: TURN is in charge of relaying media streams when necessary, so it makes sense to host the service in Media Nodes. This brings to major advantages:

• The TURN server becomes a scalable service, as it can now be replicated in multiple Media Nodes.
• Networking performance improves, as video stream data flows directly between TURN server and media server in the same node. This means no unexpected extra charges due to data transfer between your servers.

Hosting TURN server in Media Nodes is considered an experimental feature, so right now the default location is still the Master Node. To test the new location inside Media Nodes you just need to open port 443 TCP/UDP in your Media Nodes and set configuration property OPENVIDU_PRO_COTURN_IN_MEDIA_NODES to true.

Easier configuration for OpenVidu Enterprise HA 🔗

OpenVidu Enterprise HA provides now a very easy way for updating configuration properties. Simply modify the S3 configuration file, and all Master Nodes will automatically restart to apply the new configuration! No need to connect to your machines to manually restart OpenVidu services. This behavior is enabled by default, using property OPENVIDU_ENTERPRISE_S3_CONFIG_AUTORESTART=true.

BUG FIXES 🔗

• openvidu-server: a race condition could arise after a Media Node crash if the application performed a great amount of petitions to restore a crashed session. This could cause some unexpected 500 errors that could only be overcome by retrying the request. This is now fixed.
• openvidu-browser : muting a screen-sharing Publisher (calling Publisher.publishVideo(false)) would generate infinite streamPropertyChanged events with changedProperty "videoDimensions", reason "screenResized" and same oldValue and newValue ({width: 0, height: 0}). This is now fixed.
• openvidu-browser : Connections with role SUBSCRIBER were logging some errors in the browser's console when subscribing to a Publisher's stream. These errors were harmless, but still unpleasant. This is now fixed.
• openvidu-browser : now method Publisher.publishVideo returns a Promise, so you can subscribe to it to directly know when the video has been really muted.
• PR https://github.com/OpenVidu/openvidu/pull/689

2.21.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

OpenVidu Enterprise general availability 🔗

OpenVidu Enterprise edition has gone from beta to production-ready. OpenVidu Enterprise brings the best performance, improved media quality and better scalability for high-demand environments. Any OpenVidu CE or OpenVidu Pro application will be compatible out-of-the-box with it. Take a look at what OpenVidu Enterprise has to offer: Documentation.

The transition from Beta to General Availability means the following limitations in OpenVidu Enterprise are now overcome:

• Recording now available for High Availability deployments
• OpenVidu Inspector is now available
• Full support for Simulcast. Check Simulcast documentation section to learn more.
• VP9 support thanks to mediasoup. Check our new Media Codecs documentation section to learn more.

Support for any S3 provider for storing recordings 🔗

If you want OpenVidu to automatically store your recordings in a separate storage service, now you are not limited to AWS S3. Any S3-compatible provider can be used. See documentation.

IP cameras now support RTSP over SSL 🔗

You can now publish IP cameras with rtsps protocol. See documentation.

More flexible ICE configuration 🔗

Now it is very easy to configure external TURN servers in the client-side. You can:

• Configure globally any TURN server. See configuration property OPENVIDU_WEBRTC_ICE_SERVERS.
• Set TURN credentials user by user from you application's server. See parameter customIceServers when creating a Connection.

Before, this was only possible using the client-side library openvidu-browser (with OpenViduAdvancedConfiguration.iceServers property), which always required more work on the developer side and had some limitations.

Allow users behind strict firewalls 🔗

In some occasions users may be located behind strict firewalls that only allow connections though port 443 (for example, in restricted corporate networks). Now OpenVidu may be configured with external TURN servers to overcome these situations. You can use our brand new TURN server appliance that can be deployed externally, or use a third-party TURN SaaS. See documentation here.

Strictly typed openvidu-browser events for TypeScript projects 🔗

Event objects of openvidu-browser client library are now strictly typed in TypeScript. This has also greatly improved openvidu-browser documentation, centralizing all of the available events in interfaces. Now you have now a complete description of all events in one place:

• Session events
• StreamManager events
• Publisher events

BUG FIXES 🔗

• openvidu-browser : LocalRecorder better management for long recordings.
• Monitoring - Elastic stack: summary objects were lacking property media_node_id, that is used to identify the Media Node in which the object lived. This is now fixed and the property do actually exist.

BREAKING CHANGES 🔗

There is a small breaking change affecting recording IDs. These IDs (and recording default names) are different for consecutive recordings of the same session. Before, they where built with the session ID, plus a hyphen (-) and a number. For example, for three consecutive recordings of session ses_ABCD, the recording IDs would be: ses_ABCD, ses_ABCD-1, ses_ABCD-2. Now the hyphen has been replaced by a tilde (~) due to new restrictions that have arisen. Now the recording IDs would be: ses_ABCD, ses_ABCD~1, ses_ABCD~2. This should not really affect your application, unless you are explicitly assuming the existence of a hyphen in your own logic.

2.20.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

OpenVidu Enterprise High Availability beta 🔗

OpenVidu Enterprise edition comes with beta support for a High Availability deployment, with replication of all nodes and load balancing for clients. All functionality of OpenVidu Enterprise remains in beta during version 2.20.0 of OpenVidu, so it is still free of charge, just as it was for version 2.19.0.

Individual recording for OpenVidu Enterprise with mediasoup 🔗

One of the limitations of using mediasoup with OpenVidu Enterprise is now fixed: INDIVIDUAL recording is already possible when using mediasoup.

New property "ip" for the Connection object 🔗

The Connection object now has an ip property with the IP of the client, just as OpenVidu Server sees it. This can help further identifying your final users. Of course, this property is also available in the official server SDKs openvidu-java-client and openvidu-node-client.

BUG FIXES 🔗

• Recording : for OpenVidu deployments in AWS, the first time a COMPOSED recording was initialized inside a node, it could take a long time to return. The operation usually finished with an error. This has to do with the EBS volumes from the AMIs which are pulled down from S3 when data is read for the first time. Now the content is cached before the node starts, so the problem is fixed and the first recording starts as fast as any other.

2.19.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Beta support for mediasoup 🔗

OpenVidu Enterprise edition is available in beta, free of charge for a limited time. It includes mediasoup support as Media Server, which includes a great boost in performance and quality. To test it you need an OpenVidu Pro license. Visit OpenVidu Enterprise documentation to learn how to enable it.

New supported browsers in iOS 🔗

Safari was the only supported browser in iOS until 2.19.0. Now latest versions of Chrome, Firefox, Microsoft Edge and Opera are also supported in iPhones and iPads.

New Timeline View in OpenVidu Inspector 🔗

OpenVidu Inspector brings the Timeline View for your sessions. It provides a quick and visual way to review the events and actions that took place in a session, ordered in time. You can also filter by user or event type.

BUG FIXES 🔗

• OpenVidu Pro : fix for autoscaling event. Property system.status.avgLoad had an invalid JSON value when numNodes was 0.
• COMPOSED recordings: characters of non-european fonts could not be properly displayed in the recording layout. Lack of fonts in the recording module made these chars to show up like ?. Now they will be displayed fine for the following language groups: Western Europe, Eastern/Central Europe, Baltic, Cyrillic, Greek, Turkish, Arabic, Simplified and Traditional Chinese, Hebrew, Japanese, Korean, Thai. Note that special versions of these chars (bold, italic....) could still be problematic to be shown in the recording layout.
• COMPOSED recordings: an annoying Chrome translate banner could appear on the recording file if the layout was recognized in a language different than English. Now this banner won't show up.

BREAKING CHANGES 🔗

WebHook/CDR event sessionCreated is triggered earlier in time, and for all sessions. Before, it was only launched after the first user joined the session. Now it is launched after successfully initializing a session through REST API or server SDKs. This also means that sessionDestroyed event wasn't being launched before for sessions that haven't had any user connected to it. Now it is. We consider this to be a more predictable and more consistent behavior.

2.18.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Recording improvements 🔗

Recording API has been extended in this release. The two main new features are:

• You can now set the desired frame rate of your COMPOSED recording.
• You can set default values for all recording properties when initializing a Session.

This second point is the result of a small but significant refactoring of the Session object. Before, Session objects had custom attributes for defining default values for its recordings:

{
  "defaultOutputMode": "COMPOSED",
  "defaultRecordingLayout": "CUSTOM",
  "defaultCustomLayout": "mySimpleLayout"
}

Now it has a single attribute defaultRecordingProperties that is an actual RecordingProperties object, containing all of the available attributes to customize recordings:

{
  "defaultRecordingProperties": {
    "name": "MyRecording",
    "hasAudio": true,
    "hasVideo": true,
    "outputMode": "COMPOSED",
    "recordingLayout": "CUSTOM",
    "customLayout": "mySimpleLayout",
    "resolution": "1280x720",
    "frameRate": 25,
    "shmSize": 536870912,
    "mediaNode": "media_i-po39jr3e10rkjsdfj"
    }
}

In this way, for example, it is now possible to record Sessions set to recording mode ALWAYS with only audio or only video. Before the lack of custom default recording properties for in the Session object made this impossible.

This refactoring introduces small breaking changes that must be addressed if your application initializes Session objects with any default recording property (defaultOutputMode, defaultRecordingLayout, defaultCustomLayout). This is all carefully detailed in the Breaking changes section of these release notes.

New openvidu-browser SDK features 🔗

openvidu-browser SDK has been improved in many ways. The most important points are listed below:

• PublisherSpeakingEvents are now available also for Publisher objects. Before, they were restricted to Subscriber objects, so it wasn't easy to know when the local user started or stopped speaking.
• Methods Session.unpublish and Session.unsubscribe are now properly Promisified. You can subscribe to the Promise returned by them to know when the operation has successfully taken place or has failed. This allows avoiding inconvenient errors when trying to call publish/unpublish or subscribe/unsubscribe operations in a row.
• New Stream.reconnect method. This method allows you to manually recreate the media connection with the server. openvidu-browser does this for you automatically whenever it detects some unrecoverable error, but now you can actively call this method to restore any media connection (for any Publisher or Subscriber) if your application encounters any kind of unforeseen error.
• New ExceptionEvent event for the Session object: session.on('exception', exception => {}). This event alerts of different problems that may appear when establishing media connections. You can take a look to the different types of error on ExceptionEventName attribute.

New nodeCrashed WebHook event 🔗

There is a brand new CDR/WebHook event available in OpenVidu Pro. The new nodeCrashed event allows you to relocate any Session hosted at a Media Node that crashed into a different healthy Media Node. Take a look to its documentation here.

Client logs can now be sent to Elasticsearch 🔗

We keep improving the monitoring features of OpenVidu Pro. A very important aspect when analyzing wrong behaviors and possible bugs in your OpenVidu applications is the logging on the client side. Now with OpenVidu Pro you can enable configuration property OPENVIDU_BROWSER_LOGS (disabled by default) to make openvidu-browser automatically send its logs to Elasticsearch.

Only the openvidu-browser's own logs are sent (your application's own logs are not). You can inspect them from OpenVidu Inspector session history view.

New analysis features for OpenVidu Inspector session history 🔗

In your OpenVidu Inspector session history view you will see now a new land page showing the percentage of successful and problematic sessions. Problematic sessions now show a new "Troubleshooting" section with the list of detected anomalies.

Improved reconnection capabilities under the hood 🔗

Previously the reconnection capabilities were based only on the health of the client-server signaling plane. But the media plane can break on its own, without affecting the signaling plane. And up to this point, the application was completely blind when facing these conditions: the media could simply freeze and nobody would be alerted. But now these situations are also taken into account and media connections will be restored automatically.

Take a look to the revamped section Automatic reconnection to learn more.

BUG FIXES 🔗

• openvidu-browser : Network Quality API wasn't enabled for Microsoft Edge Mobile. Now it is.
• openvidu-browser : StreamPropertyChangedEvent had a wrong typed property when triggered by a Filter in the local Stream. The options attribute of the Filter (being set at newValue property of the event) was a string instead of an object. This only affected the local event (the user that triggered the event), remote events were not affected by this bug (those receiving the event from a different user).
• openvidu-browser : method Publisher.replaceTrack misbehaved when applied to a muted audio or video track. In this case it was unmuting it, leaving the Publisher object in an inconsistent state. Related to 449. This is now fixed.
• Recording : time response improved when managing a huge amount of recordings in S3. Before when tens of thousands of recordings were being stored in the S3 bucket, the response time when listing or starting recordings could be very high. This is now fixed and these operations have a fast response time, within the normal range.
• OpenVidu Pro : improved the clean-up process of possible stranded threads when enabling configuration property OPENVIDU_PRO_STATS_WEBRTC_INTERVAL.
• OpenVidu Inspector : sessions with the same customSessionId could be interchanged when retrieving their information. Now they don't.
• Text encodings updated to UTF-8 in the server side. Previously special characters could result in wrong symbols depending on the encoder used to decode HTTP messages (such as the WebHook ones). Now using UTF-8 everywhere guarantees a better support for special chars.
• WebHook is now more resilient. Upon connection failure, it will retry up to 5 times before throwing an error. This may help overcome transient networking issues.
• Coturn server of OpenVidu stack has been updated to the latest release. This fixes some security issues that could potentially affect past versions.

BREAKING CHANGES 🔗

There is a breaking change for the Recording API. We have consolidated the RecordingProperties object so it can be equally used when configuring the default recording properties of a session or when manually starting the recording of a session. This affects the operation of initializing a Session. Depending on whether you are consuming the REST API, openvidu-java-client SDK or openvidu-node-client SDK:

For REST API 🔗

Before when initializing a Session:

curl --header "Content-Type: application/json" \
     --request POST \
     --data '{"defaultOutputMode":"COMPOSED","defaultRecordingLayout":"BEST_FIT","defaultCustomLayout":"CUSTOM_LAYOUT"}' \
     https://your.openvidu.ip/openvidu/api/sessions

Now:

curl --header "Content-Type: application/json" \
     --request POST \
     --data '{"defaultRecordingProperties":{"outputMode":"COMPOSED","recordingLayout":"BEST_FIT","customLayout":"CUSTOM_LAYOUT"}' \
     https://your.openvidu.ip/openvidu/api/sessions

For openvidu-java-client 🔗

Before when creating a Session:

OpenVidu openvidu = new OpenVidu(OPENVIDU_URL, OPENVIDU_SECRET);
SessionProperties properties = new SessionProperties.Builder()
  .defaultOutputMode(Recording.OutputMode.COMPOSED)
  .defaultRecordingLayout(RecordingLayout.CUSTOM)
  .defaultCustomLayout("mySpecialLayout")
  .build();
Session session = openVidu.createSession(properties);

Now:

OpenVidu openvidu = new OpenVidu(OPENVIDU_URL, OPENVIDU_SECRET);
RecordingProperties recordingProperties = new RecordingProperties.Builder()
  .outputMode(Recording.OutputMode.COMPOSED)
  .recordingLayout(RecordingLayout.CUSTOM)
  .customLayout("mySpecialLayout")
  .build();
SessionProperties sessionProperties = new SessionProperties.Builder()
  .defaultRecordingProperties(recordingProperties)
  .build();
Session session = openVidu.createSession(sessionProperties);

For openvidu-node-client 🔗

Before when creating a Session:

var openVidu = new OpenVidu(OPENVIDU_URL, OPENVIDU_SECRET);
var properties = {
  defaultOutputMode: "COMPOSED",
  defaultRecordingLayout: "CUSTOM",
  defaultCustomLayout: "mySpecialLayout"
};
openVidu.createSession(properties).then(session => { ... });

Now:

var openVidu = new OpenVidu(OPENVIDU_URL, OPENVIDU_SECRET);
var properties = {
  defaultRecordingProperties: {
    outputMode: "COMPOSED",
    recordingLayout: "CUSTOM",
    customLayout: "mySpecialLayout"
  }
};
openVidu.createSession(properties).then(session => { ... });

2.17.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Scalable COMPOSED recordings (OpenVidu Pro) 🔗

OpenVidu Pro has always been focused on offering scalability features upon OpenVidu CE, and there was still one very important limitation: COMPOSED recording were not scalable, as they were being performed in the OpenVidu Server Pro Node. Until today: from 2.17.0, recording modules will be launched in Media Nodes. Since Media Nodes are infinitely scalable, the limit of simultaneous COMPOSED recordings has been effectively eliminated, and the load on your OpenVidu Server Pro node should remain much lower and stable. This is great news!

Force the video codec in OpenVidu Sessions 🔗

Until now OpenVidu always honored the preferred video codec requested by each client. This had a very important consequence: whenever 2 clients negotiated 2 different codecs, OpenVidu had to perform transcoding between them, which resulted in much more intensive CPU usage and poorer media quality. With 2.17.0 codecs are managed in a much better way:

• First of all, OpenVidu automatically sets VP8 video codec to be used by all clients by default, as this is the most widespread video codec among all types of clients. This definitely improves the overall performance of the platform, avoiding useless transcodings when clients has different orders of preference in their list of supported codecs (for example, this was the case between Chrome and Firefox).
• But you can also set H264 as the default video codec, or leave the previous behavior if your use case may benefit of it. And you can configure this as the default setup for all of your OpenVidu Pro cluster, or even session by session.

Improving the performance and compatibility of your OpenVidu app has never been easier!

New signalSent event 🔗

This has been a very requested feature. You can now receive in your backend side all the signals sent to your OpenVidu Sessions. They will be received by your WebHook and registered in your CDR. Take a look at this new useful event here.

Microsoft Edge now supports screen sharing 🔗

Just as it sounds. Now Microsoft's browser is also able to screen share in OpenVidu!

Choose the instance type when launching new Media Nodes on AWS (OpenVidu Pro) 🔗

When deploying OpenVidu Pro on AWS now you are not forced to set a default size for all your Media Node. Simply indicate the EC2 instance type that you want as a parameter in the operation to add a new Media Node:

curl -u OPENVIDUAPP:YOUR_SECRET \
  --request POST  \
  --header "Content-Type: application/json" \
  --data '{"instanceType":"c5.2xlarge","volume":200}' \
https://your-openvidu-ip/openvidu/api/media-nodes

More powerful S3 recording upload (OpenVidu Pro) 🔗

There is a new configuration property OPENVIDU_PRO_AWS_S3_HEADERS that allows defining any HTTP header value that the internal S3 client may require to upload recordings to the bucket. The internal S3 client also better manages expired credentials and tries to automatically renew them if necessary. Check out S3 recording upload here.

Programmatic restart of OpenVidu Pro greatly speeded up (OpenVidu Pro) 🔗

The REST operation to restart OpenVidu Pro and apply new configurations is now much quicker. Internal improvements have accelerated the process by several seconds.

OpenVidu Pro monitoring completely revamped (OpenVidu Pro) 🔗

There is now more information and better displayed in Kibana. This includes things like:

• New low-level metrics registered at application level such as number of petitions, number of threads, number of HTTP errors…
• Better WebRTC debugging events for Kibana with SDP and munging information.
• New high-level events relating OpenVidu entities to performance over time, such as number of sessions, participants, streams and recordings.

Check out the new monitoring section of the documentation.

BUG FIXES 🔗

• OpenVidu Pro : fixed NetworkQuality API exception when applied to mirrored publishers-
• openvidu-java-client / openvidu-node-client : RecordingProperty shmSize wasn't being properly sent. Now it is.
• openvidu-node-client : server side data could sometimes remain undefined. This is now fixed.
• openvidu-node-client : new ConnectionProperties attributes from release 2.16.0 were not being sent to openvidu-server when calling Session.createConnection. This affected the creation of IPCAM connections when using the Node SDK. This is now fixed.
• openvidu-browser: the newest version of Microsoft Edge wasn't supported in desktop platforms and Android. Now it is.
• openvidu-browser: better error description when trying to publish more than one Publisher for the same Connection at the same time.
• COMPOSED recordings: possible concurrent exception fixed. This could affect sessions with multiple recordings starting at once.

BREAKING CHANGES 🔗

• OpenVidu Pro Elasticsearch event monitoringStats no longer exists. New Metricbeat event instead. This unifies the monitoring metrics collected from all nodes in the cluster.
• Old Elasticsearch data won't be compatible with 2.17.0.

2.16.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Network quality API (OpenVidu Pro) 🔗

One of the most important elements in real-time WebRTC connections is the network. It can have a huge impact in the quality of the media streams being transmitted. Usually we have control over the quality of the server-side network, but we don’t have any guarantee about the network of the clients. For that reason, it is especially important to monitor and to be able to warn about network problems to our end users.

This is why OpenVidu Pro now offers the Network Quality API. Now you can listen for network quality change events in your application’s client. Use it to display a network indicator to inform your users about the quality of their connections, as well as those of other users. This can help reduce customer frustration to a great extent when having a bad experience, as they have a reasonable explanation about their own and others’ network conditions.

S3 recording storage (OpenVidu Pro) 🔗

OpenVidu Pro can be configured to upload recordings to an Amazon Web Services S3 bucket instead of storing them in local storage. This brings multiple advantages:

• You can terminate clusters without worrying losing your recordings, as long as they are properly uploaded to the bucket.
• Launching an OpenVidu Pro cluster configured to use an already populated S3 bucket will make the existing recordings accessible and manageable from the new cluster.
• You can upload to the same S3 bucket from different OpenVidu Pro clusters.

Take a look to the official documentation: Uploading recordings to S3.

Improved REST API for managing participant roles 🔗

Token API has been replaced with Connection API. This helps harmonizing and unifying the server entities of OpenVidu, as you can see in the renovated REST API documentation. This change also brings many new functionalities:

• Now you can invalidate non-used tokens. With the new REST API, you can delete a Connection object before it has been taken by a final user.
• In OpenVidu Pro you can also modify the properties of an existing Connection object. This means that you can change on the fly the role of a participant (from SUBSCRIBER to PUBLISHER, for example) and you can also manage fine-grained INDIVIDUAL recording (see next point).
• Now OpenVidu Java Client and OpenVidu Node Client can also be used to publish IP cameras.

Manual allocation of sessions in your Media Nodes (OpenVidu Pro) 🔗

For some particular use cases, the automatic session distribution algorithm based on CPU load of Media Nodes may not be enough. Now you can force the specific Media Node where a session must be allocated. This gives you much more control. Check it out here.

Selecting streams to be recorded (OpenVidu Pro) 🔗

Let’s assume the following scenario: your application offers webinar-type video meetings, where a main speaker addresses an audience that can intervene from time to time. And you are recording these sessions. So far, any video stream published into the session would be recorded, so you couldn’t specify to record only the main speaker. Now in OpenVidu Pro you can choose which specific participants must be recorded. See how here. Not only that, with this new feature you can also start and stop the recording of one stream as many times as you want, for the very same session recording process! In our example, the main speaker could be the only participant recorded, and also only at certain specific times.

This applies only to INDIVIDUAL recording, as in COMPOSED recording with custom layouts there is total freedom to record as you wish.

Health check (OpenVidu Pro) 🔗

OpenVidu Pro offers a new health check REST API endpoint. Check it out in the documentation: GET openvidu/api/health.

New monitoring dashboards (OpenVidu Pro) 🔗

We have substantially improved the collection of information from OpenVidu Pro clusters, and there are available new Kibana dashboards to help you monitor and analyse your deployments:

• Monitoring OpenVidu Server Pro Node
• Monitoring Media Nodes
• NGINX

Support for external Elastic stacks (OpenVidu Pro) 🔗

Now you can tell OpenVidu Pro to send all of the monitoring information to your own Elasticsearch service. This is in fact the recommended option for a production OpenVidu Pro deployment. If you combine it with S3 recording (in case your product uses the recording feature), you can turn your cluster on and off at will, without worrying about data persistence. See how here: Configuring an external stack.

Kibana security integration (OpenVidu Pro) 🔗

We have improved the Kibana access, which is now secured with the Elastic user management system. This is the most natural and logical way of dealing with Kibana users, of course. Learn how to add new users to your Elastic stack here: Create a fine-grained user.

Automatic deletion of Elastic documents (OpenVidu Pro) 🔗

Some users have reported unexpected failures and strange behaviors in OpenVidu Pro clusters that eventually turned out to be caused by nearly full hard drives. OpenVidu Pro clusters are constantly generating data, and after some weeks disks can be filled up to dangerous points. Now by default any data older than 15 days will be automatically cleaned up, so these problems never arise. You can of course change this property in your .env configuration file to any number of days to accommodate it to your specific use case (OPENVIDU_PRO_ELASTICSEARCH_MAX_DAYS_DELETE=15). And this is also compatible with the new external Elastic stack option!

New configuration parameter for IP cameras 🔗

IP cameras can now be further configured with parameter networkCache. This allows changing the default buffer size that will be used when receiving from remote RTSP streams. The default 2000 ms can be to restrictive for certain use cases, and latency can be greatly improved if the conditions allow it. Check this new parameter here.

Change environment variables of Media Nodes (OpenVidu Pro) 🔗

Now you can update any environment variable of your Media Nodes directly from the .env configuration file of your OpenVidu Server Pro Node. This configuration will be broadcasted to all Media Nodes on startup. For example, changing the log level of Kurento in your Media Nodes is now as easy as this.

OpenVidu iOS native application 🔗

OpenVidu has offered support for mobile platforms for a long time. First we focused on the most popular cross-platform frameworks, first with Ionic and then with React Native. Finally in Android we implemented a sample tutorial to be used as a template for your own custom Android app. Now we are happy to introduce the same concept for iOS: openvidu-ios. These are the features of this application:

• Latest iOS versions (tested with iOS 14.0)
• Implementing OpenVidu RPC protocol
• Mute / Unmute video
• Mute / Unmute audio
• Toggle speaker / headset
• Subscribe / unsubscribe stream

OpenVidu Call improvements 🔗

Our flagship OpenVidu application keeps getting better. Here is the list of all improvements in 2.16.0:

• OpenVidu call app has been updated to Angular 10.
• Joining sessions with no input devices is now possible. Besides, if the video device is already in use, it will be disabled and the user will be able to connect to the session only by using the microphone.
• Muted participants are now present. Users with video muted disappeared from the layout making it difficult to know who is in the room. Now they will show with small black video.
• Automatic chat scroll when new messages are received.
• Video icons have been replaced by a unique icon which it will show an action menu.
• The chat notification did not appear in fullscreen mode. This is fixed now.
• Removed jQuery with the aim of decreasing the bundle size (200KBs). The awesome animation layout is now a simple plain CSS effect.
• Some capture avatar bugs have been fixed.
• If you are using the WebComponent you can hide the footer with a new field of ovSettings object (see footer property).

New documented tutorials 🔗

Take a look to the documentation of our new tutorials:

• openvidu-iframe: learn how to embed an OpenVidu web app inside another application using iframe technology.
• openvidu-ipcameras: do you want to publish an IP camera into an OpenVidu session? Then check out this tutorial.

Kurento 6.15.0 release 🔗

OpenVidu 2.16.0 uses under the hood the brand new Kurento 6.15.0. This version of the media server brings lots of new features, improvements and bug and security fixes. You can read all of them in Kurento Release Notes.

BUG FIXES 🔗

• openvidu-browser : bundled size cut almost in half! From 626 KB to 361 KB (488).
• openvidu-browser : fixed iPad Pro and Ionic devices support bug.
• openvidu-java-client: fixed possible NullPointer exception when fetching Session information when IP cameras are present.
• openvidu-react-native: updated internal react-native-webrtc to version 1.84.0
• openvidu-react-native: crash initializing an only audio publisher, fixed now.
• Recording: setting recording names with slashes and other special characters could result in unexpected errors. Now recording names must be alphanumeric strings or an error is returned.
• Recording: fixed rare exception when starting and stopping multiple recordings for the same session in a row.
• Recording: fixed exception when stopping COMPOSED_QUICK_START recordings in heavy loaded systems.
• Recording: fixed recordingStatusChanged event to started, that sometimes could be fired too soon, breaking the following rule of documentation: This means the associated video(s) already exists and its size is greater than 0. This is now fixed.
• IP cameras: IP Cameras with user info IPs (those IPs with Basic Auth formatted in the URL as rtsp://user:pass@domain.com) where being assigned an ID including the credentials. This is now fixed.
• OpenVidu Server CE: OpenVidu Secret property (OPENVIDU_SECRET) could introduce critical failures in COMPOSED recording and in the internal RedisDB for TURN server if special characters were being used (such as #, ?, /, …). Now OPENVIDU_SECRET must comply with an alphanumeric format that easily prevents these failures.
• OpenVidu Server CE: some TURN connections were not being successfully established under some restrictive network conditions in CE deployments. Now they do.
• OpenVidu Server Pro: some threads were not being properly closed on programmatic restart, causing duplicated calls in certain processes such as session garbage collector. This is now fixed.

Breaking changes 🔗

Consider the following points when upgrading to OpenVidu 2.16.0:

1. If your OPENVIDU_SECRET had any kind of special character: you must change it to a simple alphanumeric string (plus characters - and _). This helps preventing some important bugs caused by secrets with special chars not working fine in some internal services.
   
   
2. If you were publishing IP cameras: now in REST API method POST /api/sessions/<SESSION_ID>/connection, the default value of body request property type has changed from IPCAM to WEBRTC. If you were publishing an IP camera and not providing “type” property, now you must explicitly do so, with value “IPCAM”.
   
   
3. For OpenVidu Pro, the Elastic stack credential parameters have been renamed: from KIBANA_USER and KIBANA_PASSWORD to ELASTICSEARCH_USERNAME and ELASTICSEARCH_PASSWORD. You must transfer the values from the old .env configuration file to the new one, from the old parameters to the new ones. This is also noted in the official upgrading instructions.
   
   
4. If you are using REST API to control openvidu-server (no Java or Node clients): REST API paths have been updated to unify all of them under the same parent path. Now every OpenVidu REST API operation will be located under path /openvidu/. For example, what before was: POST /api/sessions/<SESSION_ID>/connection now is POST /openvidu/api/sessions<SESSION_ID>/connection. This is very good news: now OpenVidu has a single entrypoint from a single base path, greatly simplifying the configuration of API Gateways. New REST API is well documented in here.

Old API is considered now deprecated, but of course is still supported. When you are ready, you can make sure your migration has been done right by adding this property to your OpenVidu Server: SUPPORT_DEPRECATED_API=false

If that property is set to false (by default it is true), old API will no longer by accepted by OpenVidu Server, so you can test everything still works smoothly after updating your app to use the new REST API.

2.15.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Autoscaling 🔗

OpenVidu Pro has always had scalability as one of its main features. But until now, the responsibility for the management of the cluster fell on the users themselves, who had to actively monitor the status of their OpenVidu Pro clusters to add or remove nodes manually. In fact, we've observed that many users simply launch a new OpenVidu CE monolithic deployment whenever they need more capacity for more sessions, as this can be currently more convenient than managing an OpenVidu Pro cluster with REST API.

Of course this is not ideal. For that reason, with OpenVidu 2.15.0 we're pleased to introduced OpenVidu Pro Autoscaling. Now you can let OpenVidu Pro decide when should the cluster grow or shrink according to CPU load. This way you can forget about overloading your system and you can also have the price to pay at any moment adjusted in the most optimal way.

We have added a new Autoscaling section to OpenVidu Pro documentation. We invite you to take a look to it: Autoscaling

Screen sharing in Safari 13 🔗

Now Safari users can share their screen as long as they are using Safari ≥ 13. This is great news for lots of people! Available for both OpenVidu CE and OpenVidu Pro.

Vue.js tutorial 🔗

OpenVidu tutorials have a new member in their family. Thanks to @Ninjak now you have available a simple Vue.js tutorial.

Composed quick start recording 🔗

OpenVidu recording service has always offered 2 different modes of recording:

• INDIVIDUAL: media streams are recorded individually in their own files.
• COMPOSED: media streams are recorded together in the same file in a grid layout. Users can build their own custom layouts with HTML and JS.

INDIVIDUAL recording is very efficient, but lacks the potential of building the recorded files in real time using custom designs. Can be done later in a different process, but of course this is extra work. COMPOSED mode is very powerful, as you can immediately obtain the final desired result just after stopping the recording. But this requires more CPU power per active recording.

Besides, COMPOSED recording requires OpenVidu to launch, manage and drop a recording module during the lifecycle of each recording. This process can make starting COMPOSED recordings a process with a somewhat slow response time. This is where the brand new COMPOSED_QUICK_START mode comes into play: some use cases may benefit of configuring OpenVidu Sessions with this recording mode if they need the recordings to start as quickly as possible, paying as a price a higher CPU usage during the whole lifecycle of the session.

COMPOSED_QUICK_START recording mode is available for both OpenVidu CE and OpenVidu Pro. You have further information in OpenVidu Docs: Composed quick start recording.

New OpenVidu deployment commands 🔗

You can now run the following commands in your OpenVidu (CE or PRO) installation folder:

• ./openvidu version : will print out in the terminal all of the installation details of your deployment.
• ./openvidu report : will log in a file a complete report of the status of your deployment. This file can be very useful to quickly gather all of the information of your deployment in a single place.

Better Elastic stack integration 🔗

There are 2 major changes in the way OpenVidu Pro takes advantage of its Elastic stack:

• Logging: now you can directly review the logs of many of OpenVidu processes from the Kibana dashboard itself, using the "Logs" view. Including redis, coturn, openvidu-server and kms logs.
• New OpenVidu Clustering dashboard: the new autoscaling feature has brought the need to be able to review the behavior of the cluster and its load over time. For now you can quickly check the CPU load of any Media Node over time.

BUG FIXES 🔗

• OpenVidu deployment: if the ports of the machine hosting OpenVidu Server weren't properly closed, the internal Redis database could be easily attacked, allowing external connections that hackers exploited for crypto mining. Some users reported that the CPU usage of the machine was higher than expected, and this was finally identified as the proble. Now the databse is by default password-protected with your OpenVidu secret, so even in the case of forgetting closing non-necessary ports, your Redis database will be secure.
• Recording: possible concurrent exception for recordings configured with ALWAYS and INDIVIDUAL properties when users published very close in time, resulting in some streams not being recorded. Fixed now. Issue 479.
• Recording: cancelation of automatic stop of recordings wasn't working for ALWAYS recordings. Recording would stop even if the conditions to keep the recording alive were met. Now recordings started by ALWAYS mode are only automatically stopped when expected.
• Webhook: OpenVidu Webhook by default will work in background. Slow endpoints won't now affect OpenVidu Server responsiveness, which was being delayed when the configured endpoint didn't respond immediately.
• Kurento 100% CPU usage: a critical bug was found in the past version of Kurento (the internal media server used by OpenVidu). This may cause a spike of CPU when closing many media endpoints at the same time (for example closing a session with lots of participants), which could leave the CPU hanging at 100% usage level and not being able to recover. This was fixed in Kurento release 6.14.0, the one being used by OpenVidu 2.15.0. You can check out Kurento 6.14.0 release notes.
• Autorenewal of OpenVidu certificates: when using the Let's Encrypt deployment option, the automatic renewal of auto-generated certificates could fail due to a misconfiguration. Now it doesn't.
• openvidu-browser: Subscriber object wasn't changing the Stream object audioActive and videoActive status when calling subscribeToAudio or subscribeToVideo (PR 443).
• openvidu-browser: Samsung Internet support fix. Some installations of the browser were treated as non-supported. Ironically the browser was being successfully supported in non-Samsung devices, but when the browser run on Samsung phones or tablets, openvidu-browser treated them as non-supported. This is now fixed.
• openvidu-browser: iPad Pro support. Some users reported problems when using openvidu-browser library on iPad Pro devices (490). This has been addressed.
• Ionic iOS: ionic iOS: openvidu-browser has been updated to match the new iosrct release (6.0.12) which included the fix of the issue 442. Ionic iOS can now use the modern WebRTC API for adding tracks. Updating iosrtc to 6.0.12 is required with openvidu-browsers 2.15.0.
• openvidu-angular: good practice with BrowserModule and BrowserAnimationModule. Now these import must be in the main app (1086).
• openvidu-node-client: didn't allow configuring an OpenVidu Server hostname with plain HTTP protocol (was always forcing HTTPS). For a Node application deployed in the same host as OpenVidu, plain HTTP can be a valid option to connect openvidu-node-client to OpenVidu Server. Now with 2.15.0 this is possible.
• OpenVidu Pro: property OPENVIDU_RECORDING_PATH now can be changed. Before 2.15.0 a limitation was forcing this property to remain with its default value.
• OpenVidu Pro: emtpy recording folders in Media Nodes were being accumulated. Now they are properly cleaned up after the recorded files have been downloaded by OpenVidu Server Pro Node.
• OpenVidu Pro: a critical bug when deleting session history entries in OpenVidu Inspector has been fixed. Before, if Sessions where being initialized with the same customSessionId repeatedly over time, deleting the history entry of one of them would delete also the rest of entries belonging to different Sessions with the same customSessionId. Now this doesn't happen.
• OpenVidu React Native support: many dependencies have been updated, fixing important bugs. Including react-native-webrtc to latest version (1.75.3), React version in openvidu-react-native tutorial (from 16.8.6 to 16.13.1) and React Native version also in openvidu-react-native tutorial (from 0.60.5 to 0.62.0).

2.14.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

OpenVidu Call complete overhaul 🔗

OpenVidu Call is our flagship demo application. It is an example of a common use case of videoconferencing application, built with love and available for everyone with its open source license.

People liked it so much that we decided to integrate it by default in OpenVidu 2.13.0 official deployments. Now, when deploying OpenVidu in production, OpenVidu Call is automatically added to the stack and you can start using it right away. But OpenVidu Call had some limitations that must be addressed. This is the complete changelog of OpenVidu Call in 2.14.0 release:

• Node backend added to make the app secure: OpenVidu Call didn't have a backend, so OpenVidu secret needed to be included in the frontend code, making the app unsafe and not really prepared for a real production environment. Now OpenVidu Call has a simple Node backend, so any protected operation is now safely done in the server side.
• Renewed landing page: the calling card of the application is its home page, and it has been redesigned with a better look-and-feel. Besides, now a random session name will be automatically generated for you to use it if you want.
• Join a session without media devices: OpenVidu Call didn't allow users join a session if they didn't have a working camera and microphone. This proved to be too restrictive, so now users without media devices can still join a session to at least see and hear other participants.
• Zoom in and zoom out in specific videos: users can now press a specific button available at the bottom right corner of each video to make it bigger or smaller in the layout. They can also full screen any video, or full screen the entire application if they want. All of this to ensure users focus their attention on what they prefer at all times.
• Active speaker layout: a new option allows changing the main video to the active speaker automatically. This way the layout dynamically transforms to focus on the participant speaking, changing between participants as they take the floor. If any screen is being shared, this feature is disabled so as not to interfere with it.
• Muted videos now won't appear in the layout: users can mute their video whenever they want. Before, users would see a black square where the video used to be, which was inconvenient because some of the limited and valuable space was lost. Now any muted video will disappear from the layout.
• New footer bar showing remote participants: at the bottom of the page users can see at a glance what other participants are connected to the session. This is especially useful now that users without a camera may join a session, as well as muted videos not showing up in the layout.
• Chat messages notification: we noticed that many times chat messages went unnoticed without a proper notification. Now a subtle notification will be shown when a new chat message is received.
• Reconnection alerts: OpenVidu 2.12.0 introduced automatic reconnection features for users losing their network connection while connected to a session. Now OpenVidu Call takes advantage of reconnection events and will warn the user in case they experience a network drop.
• Smooth track replace when screen sharing: OpenVidu Call now uses the replaceTrack feature to provide a quicker and smoother transition whenever a user changes the screen being shared.

Change the port where OpenVidu is deployed 🔗

You can now easily change the port where your OpenVidu deployment listens with a simple configuration property change. Set HTTPS_PORT property to the desired value to seamlessly change all of the services exposed by OpenVidu from default 443 to any other port you want. This has been a heavily requested feature, as many developers prefer using 443 port for serving their own services in the same server hosting OpenVidu.

Besides this, OpenVidu also allows configuring with property HTTP_PORT an HTTP port (non-secure) to automatically redirect to whatever port has been defined in HTTPS_PORT. To sum up, by default URLs https://your.domain.com and http://your.domain.com will provide access to your OpenVidu deployment, as HTTPS_PORT is 443 by default and HTTP_PORT is 80. But you can now easily change these two values to whatever you prefer.

Limit connections to OpenVidu admin services to specific IPs 🔗

Another very demanded feature was having the ability to limit the IPs able to consume the administration services of OpenVidu. By administration services we mean: A) the frontend web page served by OpenVidu and B) OpenVidu REST API.

You can do this with config properties:

• A) ALLOWED_ACCESS_TO_DASHBOARD: limits the ability to connect to OpenVidu CE dashboard and to OpenVidu Pro Inspector.
• B) ALLOWED_ACCESS_TO_RESTAPI: limits the ability to consume OpenVidu REST API (both CE and PRO).

You can limit to a single IP, a single IP range, multiple IPs or multiple IP ranges. So total freedom in this regard:

ALLOWED_ACCESS_TO_DASHBOARD=198.51.100.1
# or ALLOWED_ACCESS_TO_DASHBOARD=198.51.100.0/24
# or ALLOWED_ACCESS_TO_DASHBOARD=198.51.100.1, 198.51.100.0/24

New automated upgrade process 🔗

Now upgrading your OpenVidu deployment will be a very easy guided process. We have included migration guides to upgrade to 2.14.0 for bot OpenVidu CE and OpenVidu Pro. Take a look at them!

Upgrading OpenVidu CE and Upgrading OpenVidu Pro

Samsung Internet Browser supported in Android 🔗

A new platform has been added to OpenVidu family. Now Samsung browser for Android is officially supported by OpenVidu. Not one of the most widespread browsers, but still with a small market share.

New region for OpenVidu AWS deployments 🔗

AWS Africa (Cape Town) af-south-1 region is available now for deploying OpenVidu on AWS, both OpenVidu CE and OpenVidu Pro tiers. By using our CloudFormation template, you will have your OpenVidu deployment up and running in just a few minutes.

Deploying OpenVidu CE on AWS and deploying OpenVidu Pro on AWS

New Kurento 6.13.2 🔗

OpenVidu 2.14.0 brings all the goodness of Kurento 6.13.2 release. It includes many fixes (especially in libnice library) that will enhance the stability of OpenVidu.

Read Kurento 6.13.2 release notes

BUG FIXES 🔗

• openvidu-server: possible avoidable exception when adding IceCandidates to recently created Subscriber WebRTC endpoints, for which sometimes an IceCandidate could arrive before the WebRtcEndpoint object is available for the Java code. Now accumulated IceCandidates are always added after the WebRtcEndpoint object is defined and available (issue 455).
• openvidu-server: recordings bigger than 2.1 GB were throwing an exception when generating their metadata during their stop process. Now they don't.
• openvidu-browser: there was a memory leak in entities inheriting from interface EventDispatcher. This is fixed now (PR 437).
• openvidu-browser: OpenVidu.enableProdMode was disabling all logging of browser. Now only disables openvidu-browser library log (issue 440).
• openvidu-browser: fix when providing MediaStreamTracks as audioSource or videoSource when calling OpenVidu.initPublisher. Where being used when calling OpenVidu.getUserMedia, but not for OpenVidu.initPublisher (issue 456).
• OpenVidu Pro: restarting OpenVidu Pro from Inspector or REST API may failed for AWS deployments due to a problem with system path. Now it doesn't.
• Installation process: more checks have been added to the production deployment script and the logging of the process has been improved to facilitate the correct installation and handling of possible errors when deploying OpenVidu.

2.13.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES IN OPENVIDU CE 🔗

Docker-based deployment of OpenVidu 🔗

OpenVidu 2.13.0 introduces a brand new Docker-based deployment. It uses docker-compose to manage all of the necessary services. Why did we make the decision of migrating to Docker after 2.12.0 release? It was a mix of two reasons:

First reason: OpenVidu users have always asked for a Docker-based deployment. OpenVidu users are clever. Docker is the first thing an OpenVidu user will encounter when going through any of our tutorials, as we recommend to use a special OpenVidu dev container to quickly run them. And of course, Docker greatly simplifies the management of the services for those administrating them. Just look at this beauty: now you can restart your whole OpenVidu deployment with this command (and we mean all of its services, which are 6 in total for an OpenVidu CE deployment): ./openvidu restart

Second reason: OpenVidu developers (that's us :) have always had problems helping users of the platform due to the lack of homogeneity in OpenVidu deployments out there. The reality is that there's an astounding variety of cloud providers, virtual machines, OS flavours and other stuff that may influence how an OpenVidu installation behaves. Docker fixes this. Now every OpenVidu deployment will be basically the same to the other ones, so we will be able to reproduce any problem, and the proper fix for the affected user will generally apply to all OpenVidu installations. Isn't that awesome?

Visit Deploying OpenVidu CE on premises and Deploying OpenVidu Pro on premises to see for yourself how easy it is now to deploy OpenVidu.

Microsoft Edge support 🔗

The new version of Microsoft Edge has joined the list of supported platforms by OpenVidu. Both the desktop Windows version and the Android version are now supported (of course, totally compatible with all other supported platforms).

Garbage collector for OpenVidu Sessions 🔗

OpenVidu sessions are initialized through the REST API or with any supported server SDK (see here). And they are automatically closed once the last user connected to it leaves the session. But sessions initialized through the REST API that have no connected users remained in memory forever. Now this has been addressed with a garbage collector that will periodically clean up all those non-active sessions.

BUG FIXES 🔗

• openvidu-browser: fixes for Publishers which have called Publisher.subscribeToRemote. If they called Publisher.publishAudio, Publisher.publishVideo and Publisher.replaceTrack, those where not taking effect. Now they do. And now they also properly stop their media stream tracks when disposing the Publisher object so the camera light of devices shuts down.
• openvidu-browser: Publisher.replaceTrack method now can be used on unpublished Publishers. These are Publishers that have not been called with Session.publish or that have been called Session.unpublish after being published.
• openvidu-server: critical concurrency bug fix. Subscription and unpublishing operations could interfere with each other with some bad luck, possibly causing ghost sessions and server events to have erroneous data. This is now fixed.
• openvidu-server-pro: programmatic reset failed if openvidu.pro.cluster.mode was manual. Now it doesn't.
• openvidu-server-pro: stats gathering threads for media endpoints could get stranded forever, consuming valuable CPU. Now they don't.
• openvidu-server-pro: important fixes on the connection status between OpenVidu Server Pro Node and Media Nodes. Upon an unexpected broken connection between OpenVidu Server Pro Node and a Media Node, the affected Media Node could still be selected in some cases to initialize new Sessions, failing in the process. Now it doesn't. Besides this, the connection status returned by the REST API could remain as "disconnected" even after a successful reconnection. Now it doesn't.
• OpenVidu Inspector: bug fixes in Session History page: 1) Sessions with same customSessionId could be missplaced when gathering their information. 2) Pagination position and size remembered when coming back from session detail. 3) Better click behavior for the selection checkboxes.

BREAKING CHANGES 🔗

The new Docker deployment stack requires OpenVidu to manage its configuration properties following the standard environment variable syntax rules. For that reason, all of OpenVidu configuration properties have been renamed from this.is.my-property=VALUE to THIS_IS_MY_PROPERTY=VALUE

OpenVidu configuration docs are of course updated to this new syntax. As production deployments of OpenVidu 2.13.0 will requires users to re-install all of the services, new installations will already bring the new syntax by default. The official [OpenVidu development container] should also use now the new syntax for its configuration properties.

2.12.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES IN OPENVIDU CE 🔗

IP cameras support 🔗

You can now publish IP cameras into an OpenVidu Session!. You users will be able to receive it as they receive any other regular webcam stream. With this new feature you can for example implement surveillance systems in the blink of an eye. How about receiving your IP camera video in your mobile app? And what about building a web dashboard where you can observe all of your security cameras footage in real-time? So many possibilities…

You can check out IP cameras section of OpenVidu official documentation to learn more

Send signals from your backend 🔗

You are now able to send messages to the participants of an OpenVidu Session from your application’s backend with method POST /api/signal. This feature brings the power of client side messaging to your server side.

Record your webapp with COMPOSITE layout 🔗

You can now use custom recording layouts deployed outside of OpenVidu Server host. Before it was mandatory to build an HTML/CSS layout and upload it to OpenVidu Server host before you could use it as a custom recording layout. But now you can record any webpage hosted anywhere. More information here.

New CDR/Webhook event filterEventDispatched 🔗

You can now register filterEventDispatched events in OpenVidu CDR and OpenVidu Webhook services. This way you can know when a voice or video filter has emitted an event from your application’s server side (once you add an event listener to a filter).

New data in CDR/Webhook event participantJoined and participantLeft 🔗

Both participantJoined and participantLeft CDR/Webhook events include now clientData and serverData properties. This allows you to better identify your users from your application’s server side.

Automatic reconnection when connection is lost 🔗

Now your clients can listen to brand new reconnection events triggered by Session object: reconnecting and reconnected events. reconnecting event is triggered when a client connected to a Session loses its network connection with OpenVidu. Automatically openvidu-browser tries to reconnect to the Session with an endless polling. Once the client recovers its network connection, openvidu-browser will automatically try to reset the user state in the session. If it is too late and OpenVidu has already evicted the user due to inactivity, then a SessionDisconnectedEvent with reason networkDisconnect will be triggered. If the user reconnected on time, everything’s back to normal, event reconnected will be dispatched by the Session object and media connections will be automatically re-established if necessary (see Media freeze bug in BUG FIXES).

You can check out Automatic reconnection section of OpenVidu official documentation to learn more

Switch from camera to screenshare instantly 🔗

You can use new Publisher.replaceTrack() method available in openvidu-browser to change the audio or video tracks of a Publisher object on the fly, without unpublishing and re-publishing again (so, no need of WebRTC renegotiation!). This also helps changing the video track (front camera for back camera, webcam for screenshare…) keeping your audio connection at all times.

You can check out Switch camera section of OpenVidu official documentation to learn more

Change publisherSpeakingEvents configuration on the fly in your clients 🔗

New method StreamManager.updatePublisherSpeakingEventsOptions() allows you to dynamically change the threshold for audio events in openvidu-browser. Affected events are publisherStartSpeaking, publisherStopSpeaking and streamAudioVolumeChange. This way you can adjust in real time the limits and frequency of audio stream polling in the browser to make better use of these events.

All the goodnes from Kurento 6.12.0 and 6.13.0 releases 🔗

OpenVidu 2.12.0 is now using the latest 6.13.0 version of Kurento. There are lots of improvements in both Kurento 6.12.0 and 6.13.0, including some several critical bug fixes. You can take a look to all of them here:

• Kurento 6.12.0 Release Notes
• Kurento 6.13.0 Release Notes

NEW FEATURES IN OPENVIDU PRO 🔗

New payment method 🔗

This is possibly the biggest change for this release. The number of customers of our OpenVidu Pro tier has increased considerably in recent times, and we needed to facilitate the process of subscribing to OpenVidu Pro. We have introduced a new license key system for deploying OpenVidu Pro. Now anyone can create an OpenVidu account, and in just a few clicks you will be able to purchase an OpenVidu Pro license to launch as many OpenVidu Pro clusters as you want.

Visit Pricing section to learn more about the new OpenVidu Pro subscription model. You have a 15-day free trial period when registering as an OpenVidu user!

Simplified pricing 🔗

Related to previous point, we have now removed the minimum 10$ per month fee and users receive a 15-day free trial period when they register as OpenVidu users. Check it out now for free!

Dynamic scalability 🔗

OpenVidu Pro 2.11.0 allowed you to initialize your OpenVidu Pro cluster with a fixed number of Media Nodes. Now you can add and remove as many Media Nodes as you want on the fly from OpenVidu Inspector or through OpenVidu Pro REST API. Visit Scalability section to learn more.

OpenVidu Inspector big upgrade 🔗

OpenVidu Inspector has undergone a major upgrade to support the new clustering features of OpenVidu Pro 2.12.0. You can now manage your cluster directly from OpenVidu Inspector. Besides, it is now built with Angular 9, which makes it even more efficient and less heavy!

Detailed session monitoring improved 🔗

OpenVidu Pro is now using the latest Elasticsearch and Kibana version. And every new event and important piece of information generated by 2.12.0 is of course stored and processed for later use. Visit Detailed session monitoring section to learn more.

BUG FIXES 🔗

• Media freeze bug: media connections are now automatically re-negotiated under the hood if they remain freezed after a user is successfully reconnected following a network failure. This happens when a user loses its Internet connection and manages to reconnect to OpenVidu before it was automatically evicted from the Session, but its media streams are broken. This is so because media connections flow through their own plane, separated from Client-OpenViduServer signaling plane.
• openvidu-server: race condition fixed for same final user establishing more than one connection to a session at the same time. This might be related to some sessions getting stuck even when no participants are connected to it.
• openvidu-server: concurrency problems when closing a session being recorded in COMPOSED video mode (fix for issue 364). Other possible concurrency problems of the same nature have also been addressed, so stability of OpenVidu Server should have improved for these kind of corner cases.
• openvidu-server: configuration parameter openvidu.recording.public-access could not take effect when set to false. Now it always does.
• openvidu-browser: LocalRecorder was broken for recent versions of Firefox. Now LocalRecorder.record() method has an optional string parameter to indicate the desired mimeType. If none is provided, then default browser codecs wil be used to record media streams in the browser.
• openvidu-browser: method OpenVidu.getUserMedia() was broken when requesting screen sharing. Now it works just fine.
• openvidu-browser: setting a listener for streamAudioVolumeChange event just after initializing a Publisher or Subscriber object could trigger an Exception. Now it doesn’t.
• openvidu-browser: Session.signal() wrong to array now does not trigger a fatal error.
• openvidu-node-client: OpenVidu entrypoint object would throw an error if initialized with a URL with no port. Now you can use your openvidu-server domain name without a port (default 443) to initialized it.
• OpenVidu Inspector: thumbnails of recording files were sometimes asking for the secret in order to be loaded. Now they don’t.

2.11.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES IN OPENVIDU COMMUNITY 🔗

OpenVidu Webhook service 🔗

You are now able to receive OpenVidu events in your application server by using the brand new Webhook service. This is a feature that has been requested for a long time, and you can start using it right now.

You have all the information in the official documentation: OpenVidu Server Webhook

Externalizing configuration of OpenVidu Server 🔗

Are you tired of having to write all the configuration parameters in openvidu-server launch command? Well, now you can externalize all your configuration into a separate file. You just need to use property spring.config.additional-location like this:

java -Dspring.config.additional-location=/path/to/application.properties -jar openvidu-server.jar

Then all configuration parameters listed in that file will be used.

You have all the information in the official documentation: Externalizing configuration

NEW FEATURES IN OPENVIDU PRO 🔗

First version of scalability 🔗

Finally OpenVidu brings the possibility of deploying a cluster with multiple Media Nodes. OpenVidu Pro will distribute your sessions among all available Media Nodes based on their current load. Take a look to the official OpenVidu Pro tier documentation to learn more: Scalability

Persistent configuration when restarting OpenVidu Server Pro 🔗

Whenever you restart OpenVidu Server Pro by using the REST API, the new parameters you provide will be saved to disk. This way you will be able to stop the service or even the host without losing the last configuration you provided when restarting OpenVidu Server Pro through REST API.

BUG FIXES 🔗

• openvidu-browser: when sharing the entire screen in Electron, no Publisher was being initalized. Now it does.
• openvidu-browser: mobile devices where sending a streamPropertyChanged event when rotating the phone even when the Publisher wasn't being published to the session (error on the websocket connection). Now they don't.
• openvidu-server: when KMS crashed and was rebooted, sometimes the first user republishing a Stream would get an error. Now it doesn't.
• openvidu-pro: restarting OpenVidu Pro from Inspector and enabling CDR failed. Now it doesn't.
• openvidu-pro: Kibana failed returning documents before running a session. Now it doesn't.
• openvidu-pro: Inspector loggin process may failed when connecting through Firefox. Now it doesn't.

OTHER NOTEWORTHY CHANGES 🔗

Although this is not a visible feature for OpenVidu final users, we would like to mention that we have updated OpenVidu Server to Spring Boot 2. OpenVidu Server core has been based on Spring Boot 1 since the beginning of the project, but we decided to invest some time to upgrade it to the latest stable version to take advantage of its many new improvements. This should translate in better performance, stability and security.

BREAKING CHANGES 🔗

OpenVidu CDR events recordingStarted and recordingStopped are now deprecated in favour of recordingStatusChanged event. Check this new event here. Besides, event recordingStopped now won't provide the final values of the recording (specifically its duration and size properties, that will be 0). You will have to listen to recordingStatusChanged with status ready to get them.

2.10.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

This release brings support to more and more clients, so you can expand your OpenVidu client-side range. Of course, they are all compatible with each other and with every other platform already supported.

Electron support 🔗

OpenVidu has supported most popular browsers since its inception, and past releases brought official support to Android and iOS through Ionic. But there was still a gap regarding desktop applications. With 2.10.0 we are happy to announce that you are now able to implement your Windows, OSX and Linux native app with OpenVidu through Electron.

What is Electron? It is great framework for building native desktop applications with classic web technologies (simple, good old HTML, CSS and JS).

Electron is to desktop operating systems what Ionic is to mobile operating systems. Some examples of great applications built with Electron are Slack, Skype, Atom or Visual Studio Code Using Electron means that the same codebase you are already using for your web and mobile application can be used to build a desktop app that will work on Windows, OSX and Linux. Take a look to our brand new openvidu-electron tutorial, and you will have a desktop OpenVidu app working in minutes. It even brings screen-sharing!

React Native support 🔗

You’re not convinced by Ionic? Now you can choose React Native framework for developing your OpenVidu mobile app. React Native is rather similar to Ionic from the developers perspective, but at the same time its nature is very different. Essentially, it really uses native Android and iOS UI components under the hood while Ionic is based on WebView (in a nutshell, it runs on the browser).

React Native support is not part of the open source stack of OpenVidu platform. Please, contact us through Commercial page to ask for React Native support. You can then use openvidu-react-native tutorial to quickly get started

Internet Explorer support 🔗

Yes, it’s 2019. But there’s still a lot of companies out there that provide/require IE support and need videoconferencing systems to work in this browser relic. So that’s why we have brought OpenVidu support to IE through Temasys plugin. Only IE 11 is supported (going further back was too much of a pain).

Internet Explorer support is not part of the open source stack of OpenVidu platform. Please, contact us through Commercial page to ask for React Native support. You can then use openvidu-internet-explorer tutorial to quickly get started

BUG FIXES 🔗

• openvidu-angular and openvidu-webcomponent were failing when screen sharing. Now they don’t.
• openvidu-browser: screen-sharing streams are not mirrored in the local videos now by default.
• openvidu-browser: event streamPlaying was being triggered anormally when calling StreamManager.addVideoElement method. Now it doesn’t.
• openvidu-node-client and openvidu-java-client: removed static methods and properties from OpenVidu object. Now it is possible to keep a collection of OpenVidu objects from same Node or Java app by using SDK clients, which allows to manage multiple OpenVidu Servers from the same application.
• openvidu-browser now checks version compatibility with openvidu-server. If version numbers are not equal, an error will be printed in the browser’s console when calling Session.connect method, so developers know they must use same version number on both sides. This gives devs very useful information about a very common mistake that usually leads to bugs that can be very difficult to trace but have a really simple solution, which is simply upgrading openvidu-browser library version. This new verification is not really a bug fix, but for sure will help avoiding future bugs.

2.9.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Ubuntu 18.04 bionic support 🔗

Our team has released Kurento 6.10.0, which can now be installed in Ubuntu 18.04 systems. This is a milestone we've been working on for quite some time, and we finally believe we're ready to launch official support for the newest Ubuntu LTS version. Deployment section in OpenVidu Docs is properly updated to inform about this.

We still consider Ubuntu Bionic to be in a preliminary support state, and some bugs may appear. In fact, we know for sure there's one limitation: no OpenCV filters will work in Ubuntu 18.04 at this moment. OpenVidu has supported audio and video filters for a long time now, and it is a cool feature that allows developers to implement some advanced audio and video real-time processing in the server side. But unfortunately Kurento has not been updated yet to support it in Bionic, so no FaceOverlayFilter or ChromaFilter will work in new Ubuntu version. But you can still use GStreamer filters!

OpenVidu Server boot process greatly improved 🔗

OpenVidu Server now checks all required conditions at boot time, which helps solving misconfiguration problems when deploying on Ubuntu. This includes every requirement related to permissions and installed software. If something is missing, wrong or there are not enough permissions in certain path, the OpenVidu Server process immediately exits with a clear description about what happened and a possible solution to fix it.

In our experience, this makes the process of installing OpenVidu Server directly in Ubuntu so much easier and manageable.

OpenVidu reconnection to Kurento Media Server 🔗

If OpenVidu Server loses its connection to Kurento Media Server, now it will try to reconnect automatically. When it does so, if it is a new instance of Kurento, every stream of every previously active session will be destroyed with reason mediaServerDisconnect and every active recording will be stopped with same reason, but your users will not be disconnected from your sessions. This way you can directly re-publish and re-subscribe any desired stream right away.

This may help in case Kurento crashes: your users will have lost their media connections, but they will still be connected to their OpenVidu sessions and will only have to re-establish streams once OpenVidu Server is connected to a new Kurento instance.

OpenVidu upgrade process 🔗

Do you want to upgrade your OpenVidu deployment? Now you have a section entirely dedicated to it in the documentation. If you have deployed OpenVidu in AWS, it's as easy as launching a single command. If you have chosen Ubuntu deployment, then you will have to manually run some commands. Either way, you have available proper instructions now.

Native screen-sharing for Chrome 🔗

OpenVidu has supported native screen-sharing for Firefox since its inception, but Google decided to have Chrome require an extension to allow screen-sharing. Finally they changed their mind and brought Chrome up to the standard, supporting getDisplayMedia API.

So, our client library openvidu-browser now supports native screen-sharing for Chrome≥72. No extension needed for these browsers!

OpenVidu Call improvements 🔗

Our best demo application has been updated with some exciting new features:

• Users can now share their webcam and their screen at the same time.
• The chat is better integrated now.
• You can enlarge as many videos as you want, not just one. Available space will be automatically managed by the application for best fit.
• Preview window for camera and mic selection has undergone many necessary fixes. Now it works fine in every OS and client supported by OpenVidu. openvidu-call-ionic (Ionic version of OpenVidu Call for mobile devices) now supports Ionic 4 and works fine in iOS.ready to

BUG FIXES 🔗

• For COMPOSED recording with video, when multiple screen sharing streams were being published it crashed. Now it doesn't.
• For COMPOSED recordings with video, when stopping them immediatley after started, sometimes the generated video file would not be playable. Now in this cases failed status is set to this recordings, so you can take care of them properly.
• After manually stopping ALWAYS recordings (sessions that are automatically recorded once first publisher starts) in an ongoing session, now publishing a stream when no publishers are active in the session won't start automatically a new recording.
• Active sessions retrieval now returns sessions created with REST API or server SDKs that have not received any client connection (before this fix they would not be returned until some user had connected to it)
• Call Detail Record: recordingStopped event for INDIVIDUAL recordings wasn't updating their duration and size values (both properties had value 0)
• streamPropertyChanged event was firing an exception in the browser for streams for which a user wasn't subscribed to.
• Avoid 500 error when sending no body on POST operations of the REST API, such as POST /api/sessions
• Minor bug fixes in openvidu-java-client.

OPENVIDU PRO 🔗

We are excited to announce OpenVidu Pro: a commercial tier for OpenVidu platform. Check it out here.

2.8.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Individual stream recording 🔗

Finally individual stream recording is available in OpenVidu. When recording a session you can now configure it to store each published stream in its own file.

This, on the one hand, gives developers lots of freedom to compose any kind of layout and achieve any kind of result once the recording has stopped, by using some post-processing video tool. On the other hand, this type of recording has proven to be 4x more efficient in comparison with previous grid recording in our first tests, allowing a better quality and a higher number of streams per recording, and more simultaneous recordings.

We have entirely rewritten Recording documentation explaining all these new features. Take a look at it!

Audio-only and video-only recording 🔗

Configure your recordings to be audio-only or video-only. This is available for both COMPOSED and INDIVIDUAL recordings. It is worth mentioning that audio-only COMPOSED recordings takes advantage of the new recording capabilities introduced in this release to make it an extremley efficient process. Check out the full documentation on this subject.

Other improvements 🔗

• New property resolution when starting recordings. With it you can set the width and height in pixels of the recorded file. This is only available for COMPOSED recordings. INDIVIDUAL recordings will always record the video files with the native resolution of each video stream
• Automatic stop of recordings is greatly improved. Check it out here
• New property Stream.creationTime in OpenVidu Browser. This is the time when a stream was created in OpenVidu Server. Reflects the real starting time of the media stream transmission on the server side.
• OpenVidu Server now destroys any stranded recording container left on the host on start up. This allows keeping the host machine clean when restarting the service
• New REST method available in OpenVidu Server: GET /config. You can consult OpenVidu Server version and all active configuration properties with it. Check it out here.

BUG FIXES 🔗

• Fixed a problem that was causing unexpected websocket disconnections from OpenVidu Server due to HttpSessions expiring after half an hour. It has been fixed by adding real reconnection capailities to websockets established from clients. This also fixes a problem with recordings longer than 30 minutes sometimes failing. Issue #146
• Recording layout improved: default BEST_FIT layout used in COMPOSED recordings was including small black bars in the upper and left margins of the layout, that were visible in the final video file. This is now fixed.
• openvidu-browser: property Connection.creationTime now has real value (brought from OpenVidu Server) instead of a local value. Now it reflects the real time some user connected to the Session. Issue #170
• openvidu-call: now when setting a screen-share stream in full-screen mode, aspect ratio is preserved to avoid loss of information

BREAKING CHANGES 🔗

Even though this is not a major update with incompatibility changes according to semver, there are in fact a couple of changes that are worth mentioning:

• Recorded files folder structure has changed: each recording is stored now in its own folder, named after the unique recording id. This doesn't affect the recordings management through REST API, openvidu-java-client or openvidu-node-client. But if you were locally managing the recordings, then a new folder structure is expected now.
• openvidu-node-client: Recording properties Recording.hasAudio, Recording.hasVideo and Recording.name have been included into new Recording.properties attribute: Recording.properties.hasAudio, Recording.properties.hasVideo and Recording.properties.name

2.7.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Safari support 🔗

OpenVidu finally brings Safari to its collection of supported platforms. Two things to take into account when developing a Safari compatible application:

• If there are gonna be other types of clients rather than Safari connecting to the same session, then transcoding will be necessary in OpenVidu Server. This will bring up CPU load significantly. This behavior is due to Safari not supporting any other codec than H264, when rest of platforms usually prefer VP8. Good news is this is a problem that will soon fix on its own: Safari will support VP8 in the near future (see Release 68 Notes)
• A little hack is needed in your app if your Safari users are gonna have SUBSCRIBER role (only receiving video, without accessing their microphone or camera). Learn more here

Ionic support for iOS 🔗

Apple support is completed with Ionic platform for iOS. Now you can implement an Ionic app that will compile OK into an iOS native application. Our openvidu-ionic tutorial is now fully compatible with iPhones and iPads. We recommend to use it as a starting point for your Android/iOS application, but in openvidu-ionic tutorial you also have everything you need to integrate OpenVidu in any Ionic app. Take a look at it!

New event streamAudioVolumeChange 🔗

You can now listen to volume changes in any Publisher or Subscriber object. You can, for example, add a real-time audio wave or perform some action when certain level of noise or silence is reached. More details here.

BUG FIXES 🔗

• Recording layout now internally hides cursor (no need of styling the layout with cursor:none). Issue #138
• Recording stopping process reinforced to terminate and gracefully generate video files for failed recording containers (those that do not receive any video from the session caused by a misconfiguration or a wrong custom recording layout). This will help getting rid off dead containers and keeping OpenVidu Server clean. Issue #148
• Mirroring local video fix: when changing to screen-share, local video is now un-mirrored, and viceversa. Issue #13
• Sessions configured with Recording.MANUAL now automatically stop their recording if last participant left the session and no user published to the same session in 2 minutes. Issue #149
• Publisher.publishAudio and Publisher.publishVideo may be called without having initialized a Session or having called Session.publish(Publisher)

2.6.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Ionic support 🔗

There's a complete tutorial in OpenVidu Docs to get a native Android app working with OpenVidu in just a few steps. You can just clone and use our sample application as a starting point or maybe you want to add OpenVidu to your existing Ionic app. Here you have the necessary configuration steps to do so (basically Android permissions stuff).

We are currently working on making OpenVidu work on iOS with Ionic.

New types of filters supported 🔗

OpenVidu 2.5.0 brought a fantastic and a differentiating element: real time audio and video filters. Now we have extended this capability to support new GStreamer based filters such as textoverlay, timeoverlay or clockoverlay.

You can embed any text, the timestamp of the video or the current time, easily customizing its position and format. Check these filters in GStreamer section of filters documentation.

Recording service now generates a thumbnail when stopping the recording 🔗

Whenever you stop the recording of a session, OpenVidu will automatically generate a thumbnail for the video, getting it from the middle of the video timeline. You can access it from https://OPENVIDU_SERVER_IP:4443/recordings/RECORDING_NAME.jpg

Do not worry about their lifecycle: they are linked to the video file itself. If you decide to delete the recording, thumbnail will also be deleted.

BUG FIXES 🔗

Important fix for increasing success rate in establishing media connections 🔗

Time ago we ran into a pretty ugly bug that was causing some problems during WebRTC negotiation, resulting in some clients located in complex networks (like a company's internal network) not being able to connect to OpenVidu Server. What developers perceived was that in certain scenarios some users simply couldn't receive or send any media connection.

This bug has been completely solved in OpenVidu 2.6.0. Now media connections will work fine in almost every client network configuration.

2.5.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

Kurento filters support 🔗

OpenVidu API offers a simple way of applying filters to video and audio streams in the server side by making use of Kurento Media Server capabilities. See Voice and video filters section to learn more.

Individual user configuration for maximum/minimum bandwidth 🔗

In version 2.3.0 we introduced 4 new configuration parameters for OpenVidu Server that allow the limitation of the video bandwidth both sent and received to/from OpenVidu Server, affecting all video streams in a global manner. Now it is possible to specifically configure certain input and output bandwidth for every user connected to a session. This way you can customize the bandwidth for each Publisher and Subscriber object of each Connection object. Users with no specific configuration will use the global values.

You can set custom bandwidths by using REST API, openvidu-java-client or openvidu-node-client:

• REST API: in POST /api/tokens append a property in the json body like this

  "kurentoOptions": {
    "videoMaxRecvBandwidth": 1000,
    "videoMinRecvBandwidth": 1000,
    "videoMaxSendBandwidth": 1000,
    "videoMinSendBandwidth": 1000
  }
  

• openvidu-java-client: build your tokens like this

  KurentoOptions kurentoOptions = new KurentoOptions.Builder()
    .videoMaxRecvBandwidth(1000)
    .videoMinRecvBandwidth(1000)
    .videoMaxSendBandwidth(1000)
    .videoMinSendBandwidth(1000)
    .build();
  TokenOptions tokenOptions = new TokenOptions.Builder()
    .data("User data")
    .role(OpenViduRole.PUBLISHER)
    .kurentoOptions(kurentoOptions)
    .build();
  String myToken = mySession.generateToken(tokenOptions);
  

• openvidu-node-client: build your tokens like this

  var tokenOptions = {
      data: "User data",
      role: OpenViduRole.PUBLISHER,
      kurentoOptions: {
        videoMaxRecvBandwidth: 1000,
        videoMinRecvBandwidth: 1000,
        videoMaxSendBandwidth: 1000,
        videoMinSendBandwidth: 1000
      }
  };
  mySession.generateToken(tokenOptions).then(token => { ... } );
  

REST API and Server SDKs improvements 🔗

• Connection objects have a brand new property very useful for session analysis: platform. It carries a complete description of the platform used by the client to connect to your session. For example: "Chrome 69.0.3497.81 on OS X 10.13.6 64-bit" or "Firefox Mobile 62.0 on Mobile (Android 8.1.0)"

  You can get this information by retrieving session information with the REST api (GET /api/sessions or GET /api/sessions/SESSION_ID) or inspecting openvidu-java-client and openvidu-node-client Session objects: calling Session.fetch() or OpenVidu.fetch() will update the status of their activeConnections property. Then you can check it out in openvidu-node-client (property Session.activeConnections) or openvidu-java-client (method Session.getActiveConnections())

• Session, Connection and Publisher objects now have createdAt property, indicating when these objects where initialized in OpenVidu Server. This property has been integrated to maintain consistency with OpenVidu Server Call Detail Record, which has already been storing it in previous versions (check "timestamp" property of every CDR entry).

OpenVidu Browser improvements 🔗

• New method OpenVidu.checkScreenSharingCapabilities(). It allows developers to know if the client platform supports screen sharing (see its declaration in OpenVidu Documentation)

New OpenVidu Angular and OpenVidu React libraries 🔗

We introduced OpenVidu Web Component in release 2.3.0. Now we offer native libraries for both Angular and React (latest versions) to insert the same powerful component in your applications by making use of each framework capabilities. You can check a tutorial for OpenVidu Angular (openvidu-library-angular) and for OpenVidu React (openvidu-library-react) right now.

Of course you can keep using OpenVidu Browser library instead of these components in any frontend framework. These tutorials show a basic use of OpenVidu Browser in an Angular app (openvidu-angular) and in a React app (openvidu-react).

BUG FIXES 🔗

• Local tracks now are not stopped on stream disposal if property PublisherProperties.videoSource was of type MediaStreamTrack (custom stream got with OpenVidu.getUserMedia()). Issue #107, PR #108
• Deprecated RTCPeerConnection.getRemoteStreams and RTCPeerConnection.getLocalStreams to RTCPeerConnection.getReceivers and RTCPeerConnection.getSenders. Issue #54
• Allow full screen sharing in Firefox. Issue #103, PR #105
• Fixed duplicated camera permissions in Firefox if PublisherProperties.videoSource/audioSource are provided as MediaStreamTracks. PR #109
• openvidu-node-client now rejects with Error object upon OpenVidu Server unreachable. Issue #116, PR #117

2.4.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

OpenVidu Java Client and OpenVidu Node Client REST API support for v2.3.0 🔗

Backend clients are now compatible with REST API 2.3.0, adding methods:

• Session.close(): close a Session from your backend
• Session.forceDisconnect(): force some user to leave a Session
• Session.forceUnpublish(): force some user to unpublish a Publisher from a Session
• Session.fetch(): bring Session information from OpenVidu Server
• OpenVidu.fetch(): bring information from every active Session from OpenVidu Server

You can call methods Session.fetch() and OpenVidu.fetch() to bring the current status of sessions from OpenVidu Server. You can consult now directly from OpenVidu Java Client / OpenVidu Node Client all the active sessions with OpenVidu.getActiveSessions() / OpenVidu.activeSessions and the active connections of a session with Session.getActiveConnections() / Session.activeConnections.

OpenVidu CDR extended 🔗

Event recordingStopped event now has reason property. Can be:

• "recordingStoppedByServer": the recording was stopped by the application (using REST API, OpenVidu Java Client or OpenVidu Node Client)
• "lastParticipantLeft": if the Session was configured for automatic recording (RecordingMode.ALWAYS, check OpenVidu Node Client docs for more info), then it stopped because the last participant left the session
• "sessionClosedByServer": the recording stopped because the session was forcibly closed by the application (using REST API, OpenVidu Java Client or OpenVidu Node Client)
• "openviduServerStopped": the recording stopped because OpenVidu Server process unexpectedly stopped (cannot be guaranteed)

OpenVidu WebComponent improvements 🔗

• Added a generic fullscreen button which will set as fullscreen element the entire component
• Local video toolbar shown on fullscreen
• User's nickname update process is now less intrusive (pop-up removed, simple text input instead)
• Updated every dialog: now they appear inside of the component (center position), instead of appended to DOM body
• The chat component is integrated in the layout for a better experience
• New close chat button (top right corner)
• New send button (bottom right corner)
• New avatar user in each message. A new snapshot image will be displayed with each new message

BUG FIXES 🔗

• OpenVidu Server dashboard test could sometimes fail because of a misuse of TURN server
• OpenVidu Java Client: pending requests bug fixed
• Remote Stream status properties are now properly updated when calling Session.publish, Session.unpublish and Session.publish for the same Publisher object (having unpublished audio or video in between the calls)

2.3.0 🔗

Artifacts 🔗

Release Notes 🔗

OPENVIDU WEB COMPONENT 🔗

OpenVidu platform now offers an easier way to get started: just include our new Web Component into your web and start enjoying video call capabilities with just 3 new lines of code:

Add to your index.html OpenVidu Web Component files:

<link rel="stylesheet" href="openvidu-webcomponent.css" />
<script src="openvidu-webcomponent.js"></script>

And add your video-call element wherever you want in your application:

<openvidu-webcomponent session-config='{"user":"NICKNAME", "token":"TOKEN"}' theme="dark"></openvidu-webcomponent>

Being NICKNAME the user's name during the call and TOKEN one token generated in OpenVidu Server. Of course, if you want to connect users to the same session, the tokens should be generated for the same session. Attribute theme can be dark or light. Use the one that better fits your application.

OpenVidu Web Component supports a reasonable amount of different dimensions, and every video displayed inside of it will be automatically relocated and resized for its optimal position upon window resizing. You can set the position, width and height of the component by styling it like this:

1. Setting its property position to absolute or fixed, depending on your web layout and the desired behavior you want the component to have.
2. Playing with values:
   • width
   • height
   • top or bottom
   • right or left

For example, the following CSS rule would position the upper OpenVidu Web Component in the bottom-right corner of your web, taking up half of the height of the page and a third of its width.

openvidu-webcomponent {
  position: absolute;
  bottom: 0;
  right: 0;
  width: 33vw;
  height: 50vh;
}

If you give enough width to the component (at least 700px), users can communicate through an integrated chat.

To see some images of OpenVidu Web Component in action, check this post on Medium. If you want to learn more about OpenVidu Web Component, visit Tutorials section

NEW FEATURES 🔗

StreamPropertyChangedEvent (See here) 🔗

OpenVidu Browser now lets users connected to a Session know when any Stream they are subscribed to undergoes any possible change in its properties. Every Session object will dispatch this new event (you can subscribe to it to every Publisher or Subscriber object too). This event can refer to the following Stream properties:

• Stream.audioActive: this property may change if the user publishing the Stream calls Publisher.pusblishAudio(bool).
• Stream.videoActive: this property may change if the user publishing the Stream calls Publisher.publishVideo(bool).
• Stream.videoDimensions: this property may change if...
  • ...the user publishing the stream is screen-sharing and the shared window changes its dimensions.
  • ...the user is publishing from a mobile device and it is rotated (every camera from a phone will invert the resolution in the output video when rotated).

So, for example, now you can do:

var OV = new OpenVidu();
var session = OV.initSession();
session.on('streamPropertyChanged', event => {
    if (event.changedProperty === 'audioActive') {
        console.log('The state of the audio of the publisher has changed. Is enabled? -> ' + event.newValue);
    } else if (event.changedProperty === 'videoActive') {
        console.log('The state of the video of the publisher has changed. Is enabled? -> ' + event.newValue);
    } else if (event.changedProperty === 'videoDimensions') {
        console.log('The video dimensions of the publisher has changed. New dimensions: ' + event.newValue);
    }
});

This way you can react more easily upon this variations in the published streams and update your application's layout accordingly.

Session.capabilities (See here) 🔗

You can check capabilities property of Session object to know which methods are able to invoke each one of your clients, depending on their role. Also, if a client tries to call a method for which he has no permissions, now an OpenViduError is thrown with property name being OPENVIDU_PERMISSION_DENIED.

New MODERATOR role 🔗

At last developers have available the new role that has been in our roadmap for a long time. Users connecting to a session with a token configured with MODERATOR role can call every method granted for SUBSCRIBER and PUBLISHER roles, but also:

• Session.forceDisconnect: you can evict any user from the Session (force the method Session.disconnect)
• Session.forceUnpublish: you can stop the Publisher of any user publishing in the Session (force the method Session.unpublish)

REST API extended 🔗

5 new methods join the REST API of OpenVidu Server:

• Retrieve active session info: GET /api/sessions/<SESSION_ID>
• Retrieve all active sessions info: GET /api/sessions
• Close a session: DELETE /api/sessions/<SESSION_ID>
• Force the disconnection of a user from a session: DELETE /api/sessions/<SESSION_ID>/connection/<CONNECTION_ID>
• Force the unpublishing of a user's stream from a session: DELETE /api/sessions/<SESSION_ID>/stream/<STREAM_ID>

Future iterations will add this capabilities to openvidu-java-client and openvidu-node-client libraries

Configure global bandwidth for your WebRTC connections 🔗

We have included a first way to set the maximum and minimum bandwidths for the media connections established between browsers and OpenVidu Server. You can configure it with the following system properties, as stated in OpenVidu Server configuration sections:

• openvidu.streams.video.max-recv-bandwidth: Maximum video bandwidth sent from clients to OpenVidu Server, in kbps. 0 means unconstrained (default 1000)
• openvidu.streams.video.min-recv-bandwidth: Minimum video bandwidth sent from clients to OpenVidu Server, in kbps. 0 means unconstrained (default 300)
• openvidu.streams.video.max-send-bandwidth: Maximum video bandwidth sent from OpenVidu Server to clients, in kbps. 0 means unconstrained (default 1000)
• openvidu.streams.video.min-send-bandwidth: Minimum video bandwidth sent from OpenVidu Server to clients, in kbps. 0 means unconstrained (default 300)

Future iterations will study the possibility of configuring this same parameters for each session individually or even for each incoming or outgoing WebRTC connection (maybe as part of PublisherProperties or SubscriberProperties)

2.2.0 🔗

Artifacts 🔗

Release Notes 🔗

OpenVidu now offers integrated and automated support for TURN server. We encourage developers to check out our post on Medium to learn more about it.

The platform now integrates by default a COTURN server as part of its ecosystem. This means that media connections will work OK even when clients are located on restricted networks. When deploying OpenVidu Server in Amazon Web Services with our Cloud Formation template no changes are required at all. If you are deploying OpenVidu Server on your own in an Ubuntu machine, installation instructions have changed a little bit. You have them properly updated here.

2.1.0 🔗

Artifacts 🔗

Release Notes 🔗

NEW FEATURES 🔗

OpenVidu Browser support for video management

We have implemented a new class in OpenVidu Browser aimed to better support declarative frontend frameworks such as Angular, React or Vue.js.

Now Publisher and Subscriber objects both inherit from StreamManager, which provides 2 different methods to tell OpenVidu what DOM video players should display each specific stream (addVideoElement and createVideoElement). This allows us to let OpenVidu take control of the video elements (even if our framework dynamically creates them) and do not worry about its internals. This is all explained in detail in Manage video players section.

If you want to check out a real example of this behavior, explore our renovated OpenVidu Angular tutorial.

2.0.0 🔗

Artifacts 🔗

Release Notes 🔗

This is the first breaking change update for OpenVidu, which brings in lots of new features and internal improvements.

NEW FEATURES 🔗

• OpenVidu Browser new methods

  • Session.publish(): now returns a Promise so you can tell if the method was successful or not.
  • Session.signal(): now returns a Promise so you can tell if the method was successful or not.
  • Subcriber.subscribeToAudio() and Subscriber.subscribeToVideo(): new methods that allows you to mute the audio or video tracks of a remote stream.

  • OpenVidu.initPublisher(): now expects properties as interface PublisherProperties. They include:

    {
        audioSource: undefined, // The source of audio. If undefined default audio input
        videoSource: undefined, // The source of video. If undefined default video input
        publishAudio: true,     // Whether you want to start publishing with your audio unmuted or muted
        publishVideo: true,     // Whether you want to start publishing with your video enabled or not
        resolution: '640x480',  // The resolution of your video
        frameRate: 30,          // The frame rate of your video
        insertMode: 'APPEND',   // How the video will be inserted in the target element
        mirror: false           // Whether to mirror your local video or not
    }
    

  • Session.subscribe(): now expects properties as interface SubscriberProperties. They include:

    {
        insertMode: 'APPEND',   // How the video will be inserted in the target element
        subscribeToAudio: true, // Whether to initially subscribe to the stream's audio track or not
        subscribeToVideo: true  // Whether to initially subscribe to the stream's video track or not
    }
    

  • OpenVidu.getDevices(): now you can use certain video or audio input device when calling OpenVidu.initPublisher(), thanks to properties audioSource or videoSource of PublisherProperties object. Just set these variables to the property deviceId of any of the devices returned by this method.

  • OpenVidu.getUserMedia(): method improved. Now devs can customize a MediaStream object before calling OpenVidu.initPublisher() method, setting property audioSource or videoSource to a MediaStreamTrack object (see docs for further information)
    
    

• OpenVidu Browser new properties

  • Stream.frameRate: new property defining the frame rate of video streams. This property will only have value if the Publisher owning the stream has set property frameRate of PublisherProperties when calling OpenVidu.initPublisher()
    
    

• OpenVidu Browser events

  • New events accessDialogOpened and accessDialogClosed: dispatched by Publisher objects when the browser asks the user to grant permissions to camera or michrophone by opening a pop-up. You can use them to warn your users about it.
  • New events recordingStarted and recordingStopped: dispatched by Session object when the recording of a Session starts and stops. You can customize which clients will receive this event thanks to new property openvidu.recording.notification (see OpenVidu Server configuration)
  • Events publisherStartSpeaking and publisherStopSpeaking improved: more customizable thanks to OpenVidu.setAdvancedConfiguration() and better overall performance.
  • Events streamDestroyed, connectionDestroyed and sessionDisconnected have new property reason. This gives more information about why the events have been dispatched so you can take specific actions depending on the context: maybe a stream has been destroyed because the user publishing has deliberately diposed it or maybe the network connection has unexpectedly closed (see docs for StreamEvent, ConnectionEvent and SessionDisconnectedEvent)
    
    

• Other improvements in OpenVidu Browser

  • Support for custom screen sharing extensions for Chrome
  • Support for custom STUN and TURN servers in openvidu-browser. Use OpenVidu.setAdvancedConfiguration()
  • Library size decreased in almost 30% (openvidu-browser.min.js from 300 KB to 216 KB)
    
    

• OpenVidu Server new features

  • New property name for recordings: you can now specify which name should OpenVidu Server give to each one of your recording files. You can do it by using the REST API (by setting body parameter "name" in POST /api/recordings/start), openvidu-java-client (by using RecordingProperties.Builder.name()) or openvidu-node-client (by setting property RecordingProperties.name)
  • Now support for initializing sessions with a custom sessionId. You can take advantage of this new property to facilitate the mapping between OpenVidu Server 'session' entities and your own 'session' entities. You can set it by using the REST API (by setting body parameter "customSessionId" in POST /api/sessions), openvidu-java-client (by using SessionProperties.Builder.customSessionId()) or openvidu-node-client (by setting property SessionProperties.customSessionId)
  • Call Detail Record extended: new events recordingStarted and recordingStopped, property reason for events sessionDestroyed, participantLeft and webrtcConnectionDestroyed.

BUG FIXES 🔗

• Now when any participant unexpectedly disconnects from a session (for example, due to a network failure), connectionDestroyed event is sent to the rest of participants with property reason set to networkDisconnect.
• When OpenVidu Server is stopped, it will try to gracefully finish every in progress session and recording. This way no recording file will end corrupted upon OpenVidu Server termination (this cannot be granted if the process crashes or is forcibly terminated)
• Now both STUN and TURN OpenVidu Server configuration parameters can be set up at the same time with no overwritings.
• Tons of small fixes and code refactoring that makes OpenVidu more stable and easy to test and develop

BREAKING CHANGES 🔗

• OpenVidu Browser

  • OpenVidu.initSession now doesn't receive any input parameter.
  • OpenVidu.initPublisher input parameters have changed. Now properties parameter must match PublisherProperties interface.
  • Session.connect method has been promisified. Change the last mandatory callback parameter for a Promise implementation: session.connect(token, (error) => { ... }) to session.connect(token).then(() => {...}).catch(error => {...});
    
    

• OpenVidu Java Client

  • All Archive entities are now called Recording. This includes: class Archive to Recording, class ArchiveMode to RecordingMode, class ArchiveLayout to RecordingLayout, method SessionProperties.archiveLayout() to SessionProperties.recordingLayout(), method SessionProperties.archiveMode() to SessionProperties.recordingMode(), method SessionProperties.Builder.archiveLayout() to SessionProperties.Builder.recordingLayout(), method SessionProperties.Builder.archiveMode() to SessionProperties.Builder.recordingMode()
  • RecordingLayout property in SessionProperties.Builder is now configured calling method defaultRecordingLayout() instead of recordingLayout(). This means that if one Session is gonna be recorded more than once, each recording layout may be customize with RecordingProperties.Builder.recordingLayout(), which will overwrite the default one globally configured in SessionProperties object.
    
    

• OpenVidu Node Client

  • We have removed the builder pattern in all openvidu-node-client classes. Now objects are used instead, which includes classes TokenOptions, SessionProperties and RecordingProperties. For example, instead of getting a TokenOptions object like this: var tokenOptions = new TokenOptions.Builder().data(serverData).role(role).build() now it must be like this: var tokenOptions = {data: serverData, role: role}
  • There has been a simple change in certain asynchronous call. Method Session.getSessionId() is now synchronous, but method OpenVidu.createSession() is now asynchronous (the reason is pretty simple: now method createSession implements the behavior that getSessionId was providing the first time it was called for certain Session object).
  • All callback methods have been promisified. This includes method Session.generateToken(tokenOptions?, callback): void (now Session.generateToken(tokenOptions?): Promise<string>) and method Session.getSessionId(callback): void (now OpenVidu.createSession(): Promise<Session>, take also into account that the async call has changed from one method to the other as stated in the previous point).
  • All Archive entities are now called Recording. This includes: object Archive to Recording, object ArchiveMode to RecordingMode, object ArchiveLayout to RecordingLayout, method SessionProperties.archiveLayout() to SessionProperties.recordingLayout(), method SessionProperties.archiveMode() to SessionProperties.recordingMode(), method SessionProperties.Builder.archiveLayout() to SessionProperties.Builder.recordingLayout(), method SessionProperties.Builder.archiveMode() to SessionProperties.Builder.recordingMode()
  • recordingLayout property in SessionProperties has changed to defaultRecordingLayout. This means that if one Session is gonna be recorded more than once, each recording layout may be customize with recordingLayout property (of RecordingProperties interface, which will overwrite the default one globally configured in SessionProperties object.
    
    

• REST API

  • All Archive entities are now called Recording in API REST. For example: {"archiveMode": "ARCHIVE_MODE", "archiveLayout": "ARCHIVE_LAYOUT", "mediaMode": "MEDIA_MODE"} now is {"recordingMode": "RECORDING_MODE", "recordingLayout": "RECORDING_LAYOUT", "mediaMode": "MEDIA_MODE"}.
  • Field recordingLayout is now called defaultRecordingLayout in operation POST /api/sessions. This means that if one Session is gonna be recorded more than once, each recording layout may be customize adding a new field recordingLayout in the call to POST /api/recordings/start of the API REST, which will overwrite the default one globally configured during POST /api/sessions
    
    

• Other breaking changes

  • OpenVidu Server default port from 8443 to 4443
  • OpenVidu Server configuration property openvidu.recording.free-access is now openvidu.recording.public-access

1.9.0-beta-1 🔗

Artifacts 🔗

Release Notes 🔗

• Safari support: now OpenVidu is compatible with the most recent versions of Safari in Mac and iOS. It is necessary to use Kurento Media Server 6.7.0:
  
  
  • openvidu/openvidu-server-kms:1.9.0-beta-1 Docker image already incorporates KMS 6.7.0
  • openvidu/openvidu-server:1.9.0-beta-1 Docker image and openvidu-server-1.9.0-beta-1.jar need KMS 6.7.0. To install it, first be sure to completely uninstall and clean any previous version of KMS and then:

# In first command: xenial for Ubuntu 16.04, trusty for Ubuntu 14.04
sudo echo "deb http://ubuntu.openvidu.io/6.7.0 xenial kms6" | sudo tee /etc/apt/sources.list.d/kurento.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 5AFA7A83
sudo apt-get update
sudo apt-get -y dist-upgrade
sudo apt-get -y install kurento-media-server
sudo apt-get -y install openh264-gst-plugins-bad-1.5

To start and stop KMS 6.7.0:

sudo service kurento-media-server start
sudo service kurento-media-server stop