OpenVidu 2.11.0: Webhook service and first version of scalability
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.
