This page summarizes the features that Kurento provides, with links to their own documentation page for the most important ones.
Kurento API, Clients, and Protocol¶
If you prefer a different programming language, it’s possible to write a custom client library by following the specification of the Kurento Protocol, based on WebSocket and JSON-RPC.
The picture below shows how to use Kurento Clients in three scenarios:
- Using the Kurento Java Client in a Java EE Application Server.
Complete examples for these three technologies is described in the Tutorials section.
The Kurento Client API is based on the concept of Media Elements. A Media Element holds a specific media capability. For example, the media element called WebRtcEndpoint holds the capability of sending and receiving WebRTC media streams; the media element called RecorderEndpoint has the capability of recording into the file system any media streams it receives; the FaceOverlayFilter detects faces on the exchanged video streams and adds a specific overlaid image on top of them, etc. Kurento exposes a rich toolbox of media elements as part of its APIs.
To better understand theses concepts it is recommended to take a look to the sections Kurento API and Kurento Protocol. You can also take a look at the Reference Documentation of the API implementations that are currently provided: Kurento Client.
Kurento has been designed as a pluggable framework. Kurento Media Server uses several modules by default, named kms-core, kms-elements and kms-filters.
In addition, there are others built-in modules to enhance the capabilities provided by the Kurento Media Server. These modules are named kms-crowddetector, kms-pointerdetector, kms-chroma, and kms-platedetector.
Finally, Kurento Media Server can be expanded with new custom modules.
For more information, read the section Kurento Modules.
Besides WebRTC connections, Kurento Media Server is able to manage standard RTP streams, allowing to connect an instance of KMS to a wide variety of devices.
There are two topics to note when dealing with RTP connections: the automatic congestion control algorithms that KMS implements (see Congestion Control (REMB)), and the NAT traversal capabilities (see NAT Traversal).
Congestion Control (REMB)¶
Kurento implements the Google Congestion Control algorithm, so it is able to generate and parse both
abs-send-time RTP headers and REMB RTCP messages.
It is enabled by by passing the media-level attribute
goog-remb in the SDP Offer. For example:
v=0 o=- 0 0 IN IP4 127.0.0.1 s=- c=IN IP4 127.0.0.1 t=0 0 m=video 5004 RTP/AVPF 103 a=rtpmap:103 H264/90000 a=rtcp-fb:103 goog-remb a=sendonly a=ssrc:112233 cname:firstname.lastname@example.org
a=rtcp-fb is an RTCP Feedback Capability Attribute, as defined in RFC 4585.
Also it is important to note that KMS implements REMB propagation between the sender and receiver legs of a connection. This means that when KMS is used as a proxy between a video sender and one or more video receivers, the smallest REMB value from the receivers will be relayed to the sender. This allows the sender to choose a lower bitrate that will accommodate all of the receivers connected to KMS at the other side.
For more context about what is REMB and how it fits in the greater project of RMCAT, please read our Knowledge Base document: Congestion Control (RMCAT).