Skip to main content

RTSP(S) and (S)RTP transport

The devices use RTSP(S), (S)RTP, RTCP, and SDP to stream data to the client:

  • RTSP(S) (Real Time Streaming Protocol) sets up and controls the data transfer of the RTP stream.
  • (S)RTP (Real-time Transport Protocol) transmits data streams.
  • RTCP (RTP Control Protocol) sends control messages about the RTP stream.
  • SDP (Session Description Protocol) describes the media streams when RTSP receives a DESCRIBE request.

The devices support both unicast and multicast when streaming RTP with UDP. They also support streaming RTP with TCP by tunneling the RTP stream over RTSP. RTP over RTSP only supports unicast. The devices also support streaming RTSP over HTTP and encrypted RTP traffic through Secure Real-time Transport Protocol (SRTP), see Secure streaming with SRTP and RTSPS below.

We recommend unicast UDP when streaming to only one client, since it has less latency than streaming over TCP. If you need to stream to multiple clients, we recommend multicast UDP since it reduces bandwidth usage. If a firewall causes problems, RTP over RTSP or RTSP over HTTP can solve the problem. If you need an encrypted stream, we recommend SRTP.

For more information about streaming over RTSP, see Video streaming over RTSP.

RTSP session lifecycle​

To start a session, the client sends a SETUP request to the server. The request specifies how to transport the data, for example, what protocols and ports to use. If the server accepts the request, it responds with a session identifier. The client then uses this identifier when sending commands for the session.

To start playing the stream, the client sends a PLAY request. The client can then pause the stream by sending a PAUSE request. When the stream is paused, the client can resume it by sending another PLAY request. If it's a live stream, playback resumes from the current time, not from the time when it was paused.

When the client wants to stop streaming, it can close the session by sending the TEARDOWN command.

The client can request information about the available streams on the URL without starting a session. To do this, the client sends a DESCRIBE request for an SDP description, and the server responds with it.

The client can also ask the server what RTSP commands it supports by sending the OPTIONS command. The server responds with a list of available commands.

The following state diagram shows how the different commands affect the session and playing state. Note that OPTIONS and DESCRIBE aren't included in the diagram since they don't change the playing state or affect whether a session is open or not.

State diagram

The following sequence diagram shows how a client could interact with the server. The client first requests a list of supported commands with the OPTIONS command. Next, it requests an SDP description with the DESCRIBE command. It then starts a session with a specific transport configuration by sending the SETUP command. Once the session is set up, it starts playing the stream with the PLAY command. After a while, the client pauses the stream by sending the PAUSE command. Later, it resumes the stream by sending another PLAY command to the server. When the client is done, it closes the session by sending the TEARDOWN command.

Sequence diagram

Secure streaming with SRTP and RTSPS​

SRTP and RTSPS are security extensions that protect real-time audio/video streaming.

SRTP (Secure Real-time Transport Protocol) secures media streams by encrypting and authenticating RTP traffic. It provides confidentiality, integrity, and replay protection for audio and video data while keeping latency low — which is critical for real-time media.

RTSPS is the secure version of RTSP, where TLS encrypts RTSP signaling (similar to HTTPS for HTTP). It protects control-plane information such as stream URLs, session setup and control messages, credentials, and parameters from eavesdropping or tampering.

When to use SRTP and RTSPS​

Low-latency secure unicast streaming​

In unicast deployments, use RTSPS together with SRTP to transport media over RTP/UDP rather than over HTTPS/TCP. This avoids TCP retransmissions and head-of-line blocking, which results in:

  • Lower end-to-end latency
  • More predictable timing under packet loss
  • Better suitability for live video

Multicast streaming​

In multicast scenarios, multiple receivers subscribe to the same stream:

  • Use SRTP because multicast traffic is visible to anyone on the network segment. Encryption ensures only authorized receivers can decode the media.
  • Use RTSPS for secure session setup and key exchange, while the media itself is distributed efficiently via multicast.

RTSPS secures control and signaling, while SRTP secures media. Together, they provide strong end-to-end protection for RTSP-based streaming while preserving low latency.

For the Axis-specific implementation details and key management, see Secure streaming. For a step-by-step setup guide, see Set up an encrypted SRTP stream.