Red5 Documentation

Server Release 12.4.0

The most recent version of Chrome/Chromium (=>124) now supports only DTLS Elliptical Curve Algorithms for WebRTC. This release includes an update to add WebRTC DTLS Elliptical Curve support. Updating to this version will ensure that WebRTC connection are established successfully with newer versions of Chrome/Chromium.

New Features

  • RTMP Pull


  • Updated Java Spring Library
  • WebRTC DTLS Elliptical Curve Support

Bug Fixes

  • Append recording for JSON metadata
  • Rare image freeze while recording

Updating Webapps from older versions

To update your webapps that worked with older versions of Red5 Pro, you will need to follow the steps below:

  • Add the dependency to your pom for red5pro-commons:
  • Add the import to your application class: import com.red5pro.server.IProScopeHandler;
  • Add implements for the handler type: public class Application extends MultiThreadedApplicationAdapter implements IProScopeHandler {
  • Add default implementations in your application for the handler interface:
     * Sets the stream name alias provider for this scope.
     * @return provider
    public void setStreamNameAliasProvider(IAliasProvider provider) {
        // nothing to do here unless you have an alias provider

     * Returns the stream name alias provider for this scope.
     * @return provider
    public IAliasProvider getStreamNameAliasProvider() {
        return null; // add your alias provder reference if used

     * Returns the webhook endpoint for this scope.
     * @return webhook endpoint
    public String getWebhookEndpoint() {
        return null; // replace with your webhook endpoint if used

     * Sets the webhook endpoint for this scope.
     * @param webhookEndpoint
    public void setWebhookEndpoint(String webhookEndpoint) {
        // nothing to do here unless you're using a webhook endpoint

Updating Logging

If you are updating from a Red5 version before 10.9, slf4j and logback libraries have been updated to address security vulnerabilities; in doing so, this broke the old code in Red5 open source logging that allowed the separation of logging into additional contexts such as those used by custom webapps and Red5 Pro cloudstorage. The symptom of which was difficult to catch since it just prevented logging without any indication. Currently, the only work-arounds are to replace the logger libraries with the older versions or replace every use of Red5LoggerFactory with the SLF4J default interface LoggerFactory; the SLF4J factory does not accept a context. Here is an example:

 * The recent updates for SLF4J prevents Red5 logger factory use of a context,
 * it does not work in the latest Red5 open source libraries. We suggest a 
 * replacement in the interim.

// previous logger style with context separation
//private static Logger log = Red5LoggerFactory.getLogger(Application.class, "chat");

// newer / work-around version using SLF4J
private static Logger log = LoggerFactory.getLogger(Application.class); 

Logging in this way requires the implementer to update the default server logback configuration in conf/logback.xml to expose their classes using the logger so they will appear in the logs/red5.log file.