Skip to content


SRT (Secure Reliable Transport) is an RTP-like UDP based video transport protocol that wraps MPEG-TS and adds retransmission to it.

Main features of SRT are:

  • UDP based protocol.
  • Retransmit with fixed delay is main way of packet loss compensation, but FEC (Forward Error Correction) is also possible.
  • Optional encryption with a fixed secret (passphrase) known for both parties. No modern secure technics like DTLS.
  • No support for TLS certificate checks.
  • Lack of metadata signalling: usually ports are used to distinguish between different streams.
  • Lack of redirect, retry and other features that are required to build a large scale system.
  • Zero compatibility with existing HTTP infrastructure: all balancers must be reimplemented.

Comparing to TCP-based protocols, it solves only head-of-line blocking problem and provides stable latency.

SRT protocol is derived from UDT—the protocol for Torrent file delivery, but means of live streaming assume that you do not need to deal with congestion control mechanisms: you have almost constant bitrate traffic and need to send everything. Not faster, not slower, just try to send every frame.

SRT in Flussonic

SRT doesn't have reliable mechanism to tell:

  • name of the stream will be sent in this connection
  • does client want to play or publish video

This is why Flussonic offers several ways to configure the SRT port:

  • One port for one stream (recommended) or a multiplexed port for many streams.
  • Port for playing/publishing only or "uni-directional" port for client to tell the mode.

SRT protocol offers sending only one string from client to server that can be read and interpreted on server. This string will be read only if passphrase matches, so it is assumed that you cannot have different passphrases for different streams (without funny tricks like guessing one of several good passphrases). Only one correct passphrase per port.

For some reasons SRT has its own standard for encoding this string: it is not a standard URL encoding like in other protocols, but a phrase like #!::r=my-stream,m=publish. That is, you put #!:: in the beginning and then goes the usual KEY=VALUE,KEY=VALUE.

Some of the keys have predefined values, see below.


Some clients still do not have support for passing this streamid string so you cannot rely on having stream name and mode. This is why we recommend to use separate ports with specified mode.

Cloud support for SRT

Lack of functionality for redirects, balancing, and modern security in SRT is a challenge when you have cluster with several dozens of servers that accept publications from clients.

You cannot give just one IP address to a client, because the server can be turned off for any reason. So you provide a hostname having a pool of servers behind it. Remember, that the same port must be reserved on all these servers for that one client.

Having in mind the problem with lack of standard way to signal whether a client wants to publish or play and the issues with passphrase, we have designed a balancing made on ports instead of stream names.

When client connects to SRT port, Flussonic can make an HTTP request to a configuration backend telling server IP address and server port. Backend knows that it should be Client N with stream S and will tell all port configuration details in the reply. So SRT port will be configured dynamically on first request. Learn more in the API schema.

SRT modes

SRT protocol offers three modes: Caller, Listener, and Rendezvous. Flussonic supports the following modes:

  • SRT publication. Flussonic acts as Listener while awaiting to get the stream from the Caller.
  • SRT ingest. Flussonic acts as Caller by initializing the connection and requesting the stream from the source.
  • SRT push. Flussonic acts as Caller because it is the source of the stream forcefully sent to another server.
  • SRT playback. Flussonic acts as Listener waiting for the request from the Caller to send the stream.

The mode is stated in the stream's URL using the streamid parameter.


Transmitting an SRT stream requires specifying the streamid parameter that is a string of maximum 512 characters set on the socket before the connection. This string is a part of a callback that is sent by the Caller and registered by the Listener. Based on this information the Listener can accept or reject the connection, select the desired data stream, or set an appropriate passphrase for the connection.

Its format is #!:: optionally followed by the parameters:

  • r= — stream name
  • m=mode expected for the connection: publish (if the Caller wants to send the stream data) or request (if the Caller wants to receive the stream)
  • password= — a password for the authorization in a publish session (not recommended, better use the passphrase URL parameter instead because it is expected by most of clients)

During SRT sessions between two Flussonics, the following parameters are automatically added to streamid:

  • s= — the identifier of a session
  • a=Flussonic version

Example: streamid="#!::r=my-stream,m=publish".

See also developer's guide.

SRT port

When ingesting or pushing over SRT, the port and streamid settings are set on the side of the client application which generates the stream URL. When setting up publishing and playing, the stream URL is defined by Flussonic, so it is important to choose the right way to specify the port for streams. Flussonic offers flexible configuration of SRT ports for transmitting and receiving video. The way you choose to specify the port will affect the form of streamid that you will need to use to receive or transmit streams. There are the following setting options:

  • Set a separate SRT port for each stream or group of streams (i.e. template). This is the best option supported by most third-party clients. You can use the srt option in the stream configuration if the same port will be used for playback and publishing, or srt_play and srt_publish if the ports for playback and publishing are different. Specifying the stream name in the r= parameter is optional, because it is already set in the configuration. If you use srt, be sure to specify the connection mode in the m= parameter of streamid.
  • Set a global port for all modes of receiving and transmitting all SRT streams on your server. This method is more suitable for testing purposes, as it is not supported by third-party clients. You can set the port at Config - Settings in the UI.

    SRT global port

    Corresponding global option in the configuration file is srt.

    You can also set separate global ports for playback srt_play and publishing srt_publish. This can only be done in the config file. This mode is also not supported by most clients.

    If you use srt, be sure to specify the connection mode in the m= parameter of streamid, while this option is not required when you use srt_play or srt_publish because the connection mode is already known for the specified port. Specifying the stream name in r= is mandatory because it is not clear which stream you want to access when using a global port.

  • Set the range of ports for publishing and playing streams in the listeners directive. This method is used in conjunction with config_external when it is necessary to determine the name of a stream from its SRT port. Learn more in the API schema.


If you set both global and local port settings simultaneously, the local port settings take precedence and are applied first.

A summary table of streamid values for different connection modes, depending on how the port is specified:

Local srt Local srt_play/srt_publish Global srt Global srt_play/srt_publish
Publishing* "#!::m=publish" streamid is not required "#!::r=stream_name,m=publish" "#!::r=stream_name"
Push "#!::m=publish" streamid is not required "#!::r=stream_name,m=publish" "#!::r=stream_name"
Playback "#!::m=request" streamid is not required "#!::r=stream_name,m=request" "#!::r=stream_name"
Ingest* "#!::m=request" streamid is not required "#!::r=stream_name,m=request" "#!::r=stream_name"


* streamid specifies the mode that characterize the source, so m=publish is specified for publishing even though Flussonic is in Listener mode, and m=request for capturing even though Flussonic acts as Caller.

SRT parameters

In any mode of receiving or transmitting streams via SRT Flussonic supports the following parameters:

Parameters Unit Description Example
minversion x.y.z The minimum SRT version that is required from the peer. minversion=1.1.0
version x.y.z Required SRT version. version=1.3.0
enforcedencryption boolean If set to true, both connection parties must have the same password set (including empty, in other words, with no encryption). If the password doesn’t match or only one side is unencrypted, the connection is rejected. Set to true by default. enforcedencryption=false
passphrase string Password for the encrypted transmission. Its length should be not less than 10 and not more than 79 characters. Default value is an empty string ("") passphrase=9876543210
timeout seconds If set to -1 then data transmission time is unlimited. Default behavior. timeout=1
linger seconds The time socket waits for the unsent data when closing. Set to 180 by default. linger=1
connect_timeout seconds Connection timeout. Equals to 0 by default. connect_timeout=2
latency milliseconds Packet delivery delay. Used to absorb bursts of missed packet retransmissions. Default value is set to 120. latency=100