Skip to content

RTSP

RTSP (Real-Time Streaming Protocol) is the protocol most IP cameras, network video recorders and streaming appliances use to set up and control live audio and video streams. When you point a viewer at a camera, whether it's VLC, a security-camera app, or an NVR pulling feeds, RTSP is usually what negotiates the stream.

For anyone monitoring a network, RTSP is worth understanding because it is extremely common on the kinds of devices that matter for security: cameras, DVRs, intercoms and other appliances that are often deployed with weak or missing authentication. RTSP negotiations happen in clear text, so Nzyme can observe them passively and surface exactly what is being streamed, from where, to whom, and how well it is protected.

You can find all recorded RTSP streams on the RTSP tab under Streams in the sidebar of your Nzyme web interface.

See also: WebRTC

Another, similar protocol parsed by Nzyme is WebRTC.

A short primer for analysts

You don't need to know RTSP in depth to make sense of the data, but a little background helps.

How an RTSP stream is set up

An RTSP session has two parts, and Nzyme tracks both:

  • The control connection. A TCP connection on which the client sends RTSP commands (OPTIONS, DESCRIBE, SETUP, PLAY) and the server (the camera) responds. This is where the stream is negotiated: which media is available, on what transport, and whether authentication is required.
  • The media flow. The actual audio and video, carried as RTP. Depending on how the stream is set up, the media either travels on a separate UDP flow (the common case) or is muxed into the same TCP control connection (interleaved). Nzyme links the media flow back to the control connection so you see them as one stream.

Client and server

Unlike peer-to-peer protocols, RTSP has clear roles: the client is the device that initiates the session (the viewer, NVR or app pulling the stream), and the server is the camera or appliance providing it. Nzyme uses these roles throughout. The client is the one that started the control connection, the server is the one it connected to.

What Nzyme reports

Each RTSP stream includes:

  • The client and server endpoints, with MAC and asset context where available.
  • The state of the negotiation (see below).
  • The request URI, the stream path the client asked for (e.g. rtsp://camera/live).
  • The client software (from the client's User-Agent) and server/camera identity (from the server's Server header), often enough to identify the exact camera model or streaming software.
  • The authentication posture (see below).
  • A media description parsed from the stream's SDP: whether it carries audio and/or video, the codecs in use, and sometimes the resolution.
  • The media locator, how the media is transported (UDP, interleaved, or multicast).
  • Bytes exchanged, duration, and whether the stream is currently active.
  • A set of flags highlighting noteworthy conditions (see below).

Stream state

Each stream is assigned a negotiation state, which only ever advances (a late keep-alive can't drag it backwards):

State Meaning
Probing The client is querying the server (e.g. OPTIONS) but hasn't yet described or set up media.
Describing The client has requested a description of the available media (DESCRIBE).
Establishing The client is setting up a media transport (SETUP).
Started Media is playing (PLAY). This implies setup succeeded, even if Nzyme didn't observe it.

Authentication posture

This is one of the most useful signals for a security analyst, because cameras are frequently deployed unauthenticated or with weak authentication. Nzyme classifies each stream's posture:

Posture Meaning
None The stream is unauthenticated. The client was never challenged and sent no credentials.
Basic HTTP Basic authentication. Credentials are sent in (trivially reversible) clear text.
Digest Digest authentication. Credentials are not sent in clear text.
Unknown Nzyme could not determine the posture from the observed exchange.

An unauthenticated camera stream (posture None) is a common and important finding. It means anyone who can reach the camera on the network can pull its feed. A Basic posture is nearly as concerning, because the credentials are effectively in the clear.

Flags

Streams can carry flags that call out specific conditions worth attention:

Flag Meaning
UnauthenticatedStream The stream was set up without authentication.
BasicAuthCleartext Basic authentication was used, so credentials are effectively in clear text.
AuthFailures One or more authentication failures (401) were observed.
PublishAttempt The client attempted to publish to the server (ANNOUNCE/RECORD) rather than just view.
MediaRedirect The media was directed to a different address than the control client, worth understanding.
UnusualTransport The media transport didn't match a recognised pattern.

Media transport (the media locator)

How the media is carried tells you where to look for the actual video:

Transport Meaning
UDP Media travels on a separate UDP flow, on ports negotiated during SETUP. The common case.
Interleaved Media is muxed into the same TCP control connection. Common when firewalls block separate UDP.
Multicast Media is sent to a multicast group; multiple receivers can consume the same stream.

Analyzing RTSP activity

The RTSP view and its charts help answer common questions:

  • Which cameras are being watched, and by whom? The stream list shows each client/server pair. Sorting or filtering reveals the busiest cameras and the most active viewers.
  • Are any camera streams unauthenticated? Filter or scan for the UnauthenticatedStream flag or the None posture. These are streams anyone on the network could pull.
  • Is anyone using clear-text (Basic) credentials? The BasicAuthCleartext flag surfaces streams whose credentials are effectively exposed.
  • When was streaming happening? The activity chart shows how many RTSP sessions were concurrently active over time, and stays readable even on networks with many parallel streams.
  • Which servers and clients move the most data? The top-servers and top-clients views rank endpoints by the number of streams and the total bytes exchanged, useful for spotting the heaviest camera feeds and the busiest viewers.
  • Is someone publishing rather than viewing? The PublishAttempt flag catches clients pushing media to a server (e.g. a device configured to record to an NVR), which may or may not be expected.

A note on RTSPS (RTSP over TLS)

Some deployments use RTSPS, which wraps the RTSP control channel in TLS. Because the control messages are then encrypted, Nzyme cannot parse them. The request URI, codecs, authentication posture and other detail all rely on reading the clear-text RTSP exchange, which TLS hides. RTSPS is uncommon in practice (most cameras and NVRs use plain RTSP), so this is rarely a limitation, but it is worth knowing that an RTSPS will not appear as a parsed stream in Nzyme.

Configuration

RTSP detection is part of Nzyme's TCP analysis and requires no separate configuration beyond having Ethernet monitoring enabled on the relevant interface. See the Ethernet overview for interface configuration.

Additionally, you can tune pipeline performance, but this is rarely required for STUN:

[protocols.rtsp]
pipeline_size = 256