Summary

  • RTSP's successful SETUP created a server-side control context and returned a Session identifier; an SDP description or an open TCP connection did neither.
  • The context could survive replacement of its control connection, but the identifier did not replace the correct URI, method state, authentication or a working media path.
  • RTSP kept state only while the server still held it and received acceptable liveness evidence. TEARDOWN, timeout or another terminal action could make the next command answer 454 Session Not Found.

The remote control did not need a permanent cord

The first RTSP specification arrived in 1998 with an architectural contradiction built into its purpose. A viewer wanted VCR-like controls—set up a stream, play it, pause it, seek it and stop it—yet the continuous media normally travelled somewhere other than the channel carrying those commands. The control protocol looked like HTTP, but a media server had to remember far more than an isolated request.

RFC 2326 resolved the contradiction with an unusually direct sentence: there was no notion of an RTSP connection. The server maintained a session marked by an identifier, and that session was not tied to a transport-level connection such as TCP. A client could open and close several reliable connections while one viewing context continued.

That did not make TCP irrelevant. Commands still needed a path to the server, responses needed a return path, and interleaved media could even share the control stream. The design made a narrower claim: the lifetime of the remembered operation was not identical to the lifetime of the socket on which one command happened to arrive.

This was the difference between a remote control and its cord. Pulling out the cord prevented the next button press. It did not, by itself, tell the machine to forget the selected movie, negotiated transport, current state or grouped streams.

A description could point to a session without creating one

Before a client asked for server state, it often obtained a presentation description. RFC 4566 defined SDP as a representation of media types, formats, transport addresses and other session metadata. It was deliberately only a format; it did not carry or execute the control protocol.

The distinction is easy to lose because both vocabularies use the word session. An SDP document can describe audio and video, provide control references and tell software what might be available. It does not prove that a server has reserved ports, accepted a transport, allocated buffers or created a particular viewer's RTSP state.

RTSP crossed that boundary with SETUP. The client named a media resource and offered the transport parameters under which it could receive delivery. A successful server selected an acceptable alternative, stored the relevant parameters and returned them. In RFC 7826, the 2016 RTSP 2.0 replacement, this is stated as creation of an RTSP session context.

The response also carried a server-created value in the Session header. Description answered, “What presentation and control resources exist?” SETUP answered, “What state has this server accepted for this delivery?” The two facts could not be substituted for one another.

The second address named remembered state

A media URI identified something that could be controlled. The Session identifier distinguished one accepted delivery context from another. That mattered when one client created two sessions for the same URI, or when audio and video resources were assembled under common control.

RTSP 1.0 made the identifier an opaque random string at least eight octets long. RTSP 2.0 constrained it to 8–128 characters, required cryptographically random generation and recommended roughly 128 bits of entropy. Its reference to RFC 4086 addressed guess resistance: identifiers drawn from a weak or predictable process are easier for an outsider to discover.

The stronger randomness did not turn the string into a complete security system. RFC 7826 immediately warns that the identifier offers no defence against session hijacking unless the client, server and trusted proxies keep it confidential. Entropy can make a value hard to predict. It cannot decide whether the presenter is entitled to the movie, whether an account remains active or whether the command is allowed by current policy.

RTSP used the HTTP authentication framework for that separate problem. A mechanism such as Digest, specified in RFC 7616, challenges credentials and carries its own nonce and replay controls. A Session value and an authentication response could appear in the same request because they answered different questions: which stored context, and which requester under what protection space?

A known Session value still needed the right object

Once a client learned the identifier, commands related to that context carried the Session header. PLAY, PAUSE and TEARDOWN could therefore reach the remembered state even if they arrived on a later TCP connection. But the header did not erase the request URI.

An aggregated session makes that boundary visible. Several media streams can share a timeline so one PLAY starts audio and video together. A SETUP that cites an existing context can ask to add another resource. Even then, RFC 7826 requires an aggregate control URI for aggregate operations. The URI helps a proxy route the command, tells the server which resource is being operated on and preserves useful logging scope.

The identifier may be enough to locate an internal record. It is not permission to apply every method to every URI associated with that record. RTSP defined separate errors for a missing session, a method invalid in the present state, and aggregate operations attempted at the wrong scope. This prevented a convenient lookup key from becoming an excuse to collapse resource identity, state-machine authority and command validity into one field.

It also bounded failed growth. If a SETUP tried to add a resource to an existing context and failed, RTSP 2.0 required the earlier session and transport state to remain as if the failed request had not arrived. A partial attempt could not silently rewrite the already accepted control surface.

One session could change connections, and one connection could carry many sessions

RTSP 2.0 retained the separation while making the connection rules more explicit. Servers had to support both persistent TCP connections and transient ones. A client might send SETUP and PLAY, close the connection, then establish another when it later wanted PAUSE. A pair supporting transient connections could survive a TCP loss caused, for example, by a NAT timeout.

The inverse arrangement was also valid: one persistent connection could carry commands for several RTSP sessions. The socket therefore did not identify the viewing context. At a given moment, RTSP 2.0 limited an agent to one connection in use for a particular session, so that the server knew where to send server-initiated requests. That operational restriction did not reattach the session lifetime to that connection; it selected the current channel for control traffic.

The media path remained another layer. RTP could use UDP ports negotiated in SETUP, or media could be interleaved with control. NAT and firewall traversal still required actual reachability evidence. RFC 7825 adapted ICE to RTSP-controlled datagram media precisely because a valid control context could coexist with unusable media candidates. The Session header said which state to manipulate, not whether packets could cross the network.

Continued memory had to be earned by signs of life

A server could not retain abandoned state forever. The Session response could announce how long it would wait between commands or other acceptable signs of life; absent another value, the default was 60 seconds. RTSP 2.0 made the timeout parameter response-only and forbade changing its length during an established session.

Any RTSP request that referenced the context could demonstrate liveness. For a pure keep-alive, RTSP 2.0 preferred an empty SET_PARAMETER request. RTP deployments could also use RTCP traffic. RFC 3550 defined sender and receiver reports for media-source and reception evidence; RFC 7826 allowed reports associated with the server's sources and the relevant network tuple to count as evidence that the client side remained present.

That evidence was deliberately probabilistic. RTCP reports can be lost and arrive according to a reporting schedule. A server can make the chance of a false timeout very small without turning a report into proof that a person watched, a frame decoded, a PLAY command committed or a subscriber remained authorized. Liveness justified retaining protocol state. It was not a receipt for the media experience.

The number could remain while the state disappeared

Normal termination used TEARDOWN. At aggregate scope it could stop the grouped delivery and destroy the context; a permitted media-level TEARDOWN could remove one component, with the final removal ending the session. A server could also time out the context, redirect it toward termination or end it after an unrecoverable failure.

After that boundary, repeating the old identifier did not resurrect anything. RTSP's 454 response—Session Not Found—covered a missing, invalid or timed-out Session identifier. The same bytes could be perfectly remembered by the client and still refer to no live server state.

This is the mechanism's durable lesson. The identifier did not contain the session. It addressed a revocable record controlled by the server. Connection continuity, token possession, URI scope, authentication, media reachability and liveness all contributed evidence, but no one of them could impersonate the others.