Kurento is an Open Source Software WebRTC media server

6.16.0 (March 2021)

  • Mar 20, 2021
  • j1elo

 

 

To install Kurento Media Server: Installation Guide.

These Release Notes were originally published here.

 

Added

ICE-TCP setting

ICE-TCP is what allows WebRTC endpoints to exchange ICE candidates that use the TCP protocol; in other words, the feature of using TCP instead of UDP for WebRTC communications.

Kurento had this setting enabled and it was hardcoded, so users were not able to easily change whether TCP should be used or not for ICE candidate exchange (the part of WebRTC that finds connectivity between peers). Thanks to this addition, it is now possible to use the IceTcp setting and disable ICE-TCP when desired.

So when should you use this setting? Well, for the most majority of cases the previous default was the best choice, but if you have a well known scenario and you are 100% sure that UDP will work, then disabling TCP will provide for slightly faster times when establishing WebRTC sessions. I.e., with ICE-TCP disabled, the time between joining a call and actually seeing the video will be smaller.

Of course, if you cannot guarantee that UDP will work in your network, then you should leave this setting enabled; otherwise, UDP might fail and there would be no TCP fallback for WebRTC to work.

Thanks to @prlanzarin (Paulo Lanzarin) for Kurento/kms-elements#26 (Add niceAgentIceTcp configuration option and API methods for it).

Local install

  • Set value iceTcp to 1 (ON) or 0 (OFF) in /etc/kurento/modules/kurento/WebRtcEndpoint.conf.ini.

Docker

  • Set environment variable KMS_ICE_TCP to 1 (ON) or 0 (OFF).

Client API

 

Packet loss correction in Recorder

RecorderEndpoint has gained a new configuration file: /etc/kurento/modules/kurento/RecorderEndpoint.conf.ini, where static settings can be written in the same manner than for other modules, such as PlayerEndpoint or WebRtcEndpoint.

For now, this file contains a single parameter: gapsFix, allowing users to decide which of the packet loss correction techniques they want to use for the recordings. Packet loss causes gaps in the input streams, and this can happen for example when an RTP or WebRTC media flow suffers from network congestion and some packets don't arrive at the media server.

Currently there are two of such techniques implemented:

  • NONE: Do not fix gaps.

    Leave the stream as-is, and store it with any gaps that the stream might have. Some players are clever enough to adapt to this during playback, so that the gaps are reduced to a minimum and no problems are perceived by the user; other players are not so sophisticated, and will struggle trying to decode a file that contains gaps. For example, trying to play such a file directly with Chrome will cause lipsync issues (audio and video will fall out of sync).

    This is the best choice if you need consistent durations across multiple simultaneous recordings, or if you are anyway going to post-process the recordings (e.g. with an extra FFmpeg step).
     
  • GENPTS: Adjust timestamps to generate a smooth progression over all frames.

    This technique rewrites the timestamp of all frames, so that gaps are suppressed. It provides the best playback experience for recordings that need to be played as-is (i.e. they won't be post-processed). However, fixing timestamps might cause a change in the total duration of a file. So different recordings from the same session might end up with slightly different durations.

See the extended description of GapsFixMethod for more details about these settings.

Also have a look at Introduction to Kurento for an intro to all of the available Kurento modules.

 

Changed

ErrorEvent Type

Kurento Client API docs: Java, JavaScript.

The ErrorEvent can be emitted from any of the Kurento MediaElement objects (see Kurento Modules for more details). This Event has a Type string field that contains an error identifier, but until now it was mostly unused and all errors were identified as UNEXPECTED_ELEMENT_ERROR. On top of this, most errors were actually not being handled at all by the MediaElement where they occurred, so they would end up in the general handler of the MediaPipeline, with the Type identifier set to UNEXPECTED_PIPELINE_ERROR.

This now changes to provide better and more informational errors, so when possible the ErrorEvent will be emitted from the actual MediaElement where the error is taking place. Existing applications will continue to work, but the general recommendation holds that Applications should subscribe to the Error event from all of Kurento objects.

Some new Type identifiers have been added to the Error event:

  • RESOURCE_ERROR_OPEN: Indicates that there was a problem when trying to open a local file or resource. This will typically happen when, for example, the PlayerEndpoint tries to open a file for which it does not have read permissions from the filesystem.
  • RESOURCE_ERROR_WRITE: Similar to the previous one, this identifier marks an error writing to some file. This error could be seen when the RecorderEndpoint in Kurento lacks write permissions to the target path.
  • RESOURCE_ERROR_NO_SPACE_LEFT: This error will mostly happen when a RecorderEndpoint is writing a recording but the disk becomes full. This is a common thing to happen if you don't have additional free space monitoring on your servers, so you should listen for this error from the RecorderEndpoint if you use it in any of your applications.
  • STREAM_ERROR_DECODE: This error tends to happen when the sending side has transmitted an invalid encoded stream, and Kurento Media Server is trying to decode it but the underlying GStreamer library is unable to do so. This could happen, for example, when using a PlayerEndpoint (which by default decodes the input stream), or when Transcoding has been enabled due to incompatible codecs negotiated by different WebRtcEndpoints. When getting this error, you should review the settings of the sender, because there might be something wrong with its encoder configuration.
  • STREAM_ERROR_FAILED: A generic error that is originated from the underlying GStreamer library when any data flow issue occurs. KMS debug logs should be checked because chances are that more descriptive information has been printed in there.

 

Other changes

This list includes other changes and fixes contributed by users and/or fellow developers, who merit our sincere appreciation and thanks for sharing their work with the Kurento project:

kms-core

kurento-client-js