This page covers the ingest protocols supported by RMS - RTMP, SRT, and RTSP, and explains how each affects your encoder setup, ingest URL structure, and streaming capabilities.

Ingest protocols

How ingest works

The input protocol (inputProtocol) defines how your encoder sends the live feed to RMS. It is set at creation and cannot be changed while the event is running. If you need a different protocol, create a separate live event.

Once the live event is created, RMS returns a protocol-specific ingest URL. The URL structure depends on the selected protocol - this page breaks down what each URL contains and what to expect from each ingest type.

Protocol options

Get ingest URL

Once the live event is created, RMS returns a response containing the ingest endpoints[] array. Each entry includes:

• protocol - identifies the ingest protocol for this endpoint (RTMP, SRT, or RTSP).

• url - the full ingest address to configure in your encoder. The URL structure is protocol-defined.

• accessToken - value serves as your stream key. For SRT and RTSP, it is embedded directly in the URL; for RTMP, it is entered separately in the encoder.

For the complete request and response schema, see the Live events - Create API reference. If the encoder does not connect after entering these values, see Troubleshooting live events for startup failure scenarios, including invalid ingest URLs and stream key errors.

Protocol capabilities

Legend:

✓ - Supported.

✗ - Not supported.

🔒- Encrypted.

— - Not applicable.

RTMP

Real-Time Messaging Protocol (RTMP) is the most widely supported ingest protocol and the default choice for most production workflows. It uses a persistent TCP connection, which makes it reliable on stable networks and compatible with most professional encoders.

RTMPS adds TLS 1.2+ encryption for transport security - use it when streaming over public networks or when your infrastructure requires encrypted ingest.

RTMP ingest URL format

rtmp://liveingest.{endpointId}.ravnur.net:1935/live

rtmps://liveingest.{endpointId}.ravnur.net:1936/live

Where:

• rtmp:// uses an unencrypted connection, while rtmps:// uses TLS encryption for secure transport.

• {endpointId} - system-generated identifier for the RMS deployment resources in Azure.

• 1935 - RTMP port.

• 1936 - RTMPS (TLS) port.

If your network uses a firewall, ensure outbound TCP is allowed on port 1935 for RTMP and port 1936 for RTMPS.

SRT

Secure Reliable Transport (SRT) is a UDP-based protocol designed for streaming over unpredictable networks. Its built-in packet recovery makes it the better choice for long-distance contribution or environments where packet loss is a concern.

SRT connections operate in caller mode - your encoder initiates the connection to RMS. Encryption is handled at the protocol level using AES, configured through parameters embedded directly in the ingest URL.

SRT ingest URL format

srt://liveingest.{endpointId}.ravnur.net:9710?
    streamid={unique-input-id}
    &passphrase={passphrase}
    &mode=caller
    &latency=1000
    &pbkeylen=16

Where:

• {endpointId} - RMS-assigned ingest hostname for the event.

• 9710 - SRT ingest port.

• unique-input-id - a unique identifier generated for this live event input. Includes accessToken value, which is a stream key.

• passphrase - automatically generated encryption key for SRT input.

Compared to the URL, the response additionally includes three SRT-specific values: srtStreamId and srtPassphrase, which are embedded in the ingest URL, and srtNodePassphrase, which secures the internal relay leg between the ingest edge node and the processing node. All three are auto-generated. See the LiveEvent SRT Protocol API reference for the full schema.

• mode=caller - your encoder initiates the connection to RMS. The only supported mode.

• latency=1000 -buffer time (milliseconds) for stabilizing the SRT link; default is 1000 ms.

srtLatency (1000 ms) and srtMaxBW (50000000 kbps) values are pre-configured by Ravnur and optimized for reliable streaming.

• pbkeylen=16 - parameter for AES key length (industry-standard 128-bit setting).

Limitation: DVR functionality is not available with MPEG-DASH output when using SRT. If you need a DVR with this ingest type, use HLS.

RTSP

Real-Time Streaming Protocol (RTSP) is supported in two modes:

• RTSPPush, where your encoder connects to RMS and sends the stream,

• RTSPPull, where RMS connects to your source and retrieves the stream.

RTSP is primarily a camera-oriented protocol and is more fragile than RTMP or SRT in production environments. It does not support ABR encoding or low-latency mode.

RTSPPull parameters

In RTSPPull mode, RMS connects to your source and retrieves the stream. You configure this using the following parameters at live event creation:

Note: These parameters go in the tags object of the request body, not in properties.input. The tags field is typically used for resource metadata, so this placement is easy to miss. If you put these values under properties.input instead, the event will be created without error but RMS will not pull from your source.

RTSP Push ingest URL format

rtsp://liveingest.{endpointId}.ravnur.net:554/rmpproxy/{stream-id}?publishsign={signature}

Where:

• {endpointId} - RMS-assigned ingest hostname for the event.

• 554 - the RTSP ingest port assigned by RMS.

• {stream-id} - the unique stream identifier generated in the accessToken. Value functions as the stream key.

• {signature} - the RMS-generated authorization signature required for RTSP ingest.

See more: