OpenVidu 2.11.0: Webhook service and first version of scalability

OpenVidu
OpenVidu
Jul 29, 2019 · 4 min read

New features in OpenVidu Community Edition

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 server instances. OpenVidu Pro will distribute your sessions among all available media servers based on their current load.

OpenVidu Pro consists of different nodes that work together to offer OpenVidu services in a distributed, scalable way. Currently, OpenVidu Pro has two types of nodes:

  • OpenVidu Server Pro node: this is the control node. It runs openvidu-server-pro Java process, which manages the control plane of the stack. It takes care of OpenVidu sessions, forwarding events and messages to clients and distributing the load across the available Media Server nodes.
  • Media Server node: this is the node in charge of managing the media streams. For that reason, Media Server nodes are the actual bottleneck of the OpenVidu cluster and the ones that determine its capacity: more Media Server nodes means more concurrent OpenVidu sessions. Each OpenVidu session is currently hosted in one Media Server node. Each Media Server node can manage multiple OpenVidu sessions.

Of course, this first version of scalability has a lot of room for improvement. This is the (non-prioritized) list of features scheduled for OpenVidu Pro regarding scalability:

  • Adding and removing Media Server nodes on the fly: current release only allows to launch the cluster with a fixed number of Media Server nodes. In the near future it will be possible to change its number dynamically without restarting the service.
  • Remove composed recording module from OpenVidu Server Pro node: right now composed recordings are hosted in OpenVidu Server Pro node, which means that launching multiple simultaneous composed recordings may increase the load on this node to a dangerous point. So a necessary change to improve scalability for this particular use case is to get this module out of OpenVidu Server Pro node.
  • Elasticity: the automated scale-in and scale-out of Media Server nodes according to server load is an important feature that OpenVidu Pro will provide.
  • AWS S3 recording: instead of storing recording files into the cluster nodes, OpenVidu Pro will provide an easy way of uploading them to S3 buckets (in real-time when possible). This way the recording files persistance will be greatly improved: you will be able to drop your cluster nodes (or even manage multiple clusters) without worrying about your recordings.
  • Kubernetes support: we intend to provide a Kubernetes version of OpenVidu Pro cluster.

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 . 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.


OpenVidu

Written by

OpenVidu

Easy videoconference in your web or mobile app

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade