OpenVidu 2.19.0: mediasoup beta support

2 min readJul 26, 2021


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.

You can learn more about mediasoup support in the following post. A new era for OpenVidu: better perfomance and media quality with mediasoup

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.

New Timeline View in OpenVidu Inspector. It has never been so easy to go through the lifecycle events and actions of your past sessions.


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


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.

Stay tuned for next iterations! You can follow us on Twitter and a Star in GitHub is always welcome :)