RTSP Server Architecture: Sessions, RTP & Capacity | Callaba
More live video workflow notes and product updates.
An RTSP server is the control point for named media presentations. It describes available tracks, authenticates clients, negotiates RTP transport, starts and stops sessions, and releases resources when viewers leave. The media commonly travels as RTP and RTCP rather than inside the RTSP messages. A production design therefore needs both a reliable control plane and a measurable media plane.
One RTSP request creates several operational responsibilities
Callaba can consume and process RTSP without claiming a native RTSP server
Callaba Multiview can open an RTSP camera or media-server URL directly. Recording accepts RTSP URL inputs, while Restream can take RTSP and create a required SRT, RTMP, RIST or other supported output with optional media changes. Callaba does not currently document a module that accepts RTSP publishers, exposes RTSP resources to arbitrary clients or manages RTSP server sessions.
| Required job | Existing Callaba path | What still needs a separate system |
|---|---|---|
| Operator confidence view | Add the approved RTSP URL directly to Multiview | Callaba does not become the source RTSP server |
| Managed capture | Create a Recording from the verified RTSP input and inspect progress and files | The upstream server still owns client authentication and session availability |
| Protocol or media handoff | Use Restream only when the consumer needs another output or transformation | A downstream SRT or RTMP endpoint is not an RTSP publishing service |
A useful addition would be a managed RTSP Server with named publish and play resources, credential and network policy, RTP transport controls, session inventory, capacity limits and correlated diagnostics. Until that feature is documented, Callaba's direct RTSP monitoring, recording and conversion remain the available workflow.
Choose origin, proxy, publisher or playback roles explicitly
An origin can expose stored or generated presentations. A camera gateway may proxy many upstream devices behind stable names. A publishing server accepts media from encoders and makes it available to permitted readers. A playback server may only serve resources created elsewhere. These roles have different trust, state and capacity requirements.
Write one resource contract per path: who may publish, who may play, whether concurrent publishers are allowed, which tracks are expected, how replacement works, and what happens after a source disconnects. Do not let a second publisher silently inherit a trusted path merely because it knows the URL.
RTSP controls a presentation; RTP carries its timed media
RTSP 2.0 defines methods including DESCRIBE, SETUP, PLAY and TEARDOWN. The presentation description identifies tracks and payload mappings. Setup chooses the transport for each media stream, and the session identifier binds later requests to the allocated server state.
Track RTSP response codes and method timing separately from RTP packet arrival, sequence gaps, timestamps and RTCP reports. A client can authenticate and receive PLAY 200 while a firewall drops the UDP media. Interleaved TCP may cross that network, but head-of-line blocking changes failure behavior.
Capacity follows sessions, fan-out and media work
A relay that copies one upstream feed to many clients spends network bandwidth and per-session state even without transcoding. A proxy may also maintain upstream sessions, packet buffers and transport mappings. Recording adds disk I/O and retention. Transcoding changes the capacity model completely because decoded pixels, filters, codec presets and output count become dominant.
Size control connections, RTP egress, file writes and transformation workers independently. Limit sessions per tenant and resource, cap setup rate, expire abandoned state, reserve ports deliberately, and leave headroom for reconnect waves after a network or server restart.
Authentication does not replace network isolation
Use a per-client or narrowly shared credential policy supported by both server and client. Keep secrets out of URLs, command history and routine logs. Apply rate limits to authentication and session creation, and place camera-facing resources on networks that are not broadly reachable from the internet.
When both endpoints support protected RTSP over TLS, validate certificate name, trust chain and expiry. Encryption of the control connection does not automatically describe every RTP media path; verify the negotiated transport. The RTSP guide retains the protocol overview, while the server runbook must name its actual security properties.
Resource identity and lifecycle need deterministic rules
Normalize paths without collapsing distinct tenant or camera identities. Define whether path names are case-sensitive, how aliases resolve, how long a source can remain unavailable, and whether clients see a denial, an offline response or the last stored asset. Prevent users from enumerating resources through distinguishable error timing.
On shutdown, stop accepting new setup requests, drain or terminate sessions under a documented deadline, send the supported end signal, close files, and release UDP ports. On restart, restore configuration before advertising readiness and prove one complete setup-to-media cycle.
Example: every RTSP method succeeds, but clients render black
The server returns successful DESCRIBE, SETUP and PLAY responses, yet clients on a new subnet receive no frames. The first comparison is the negotiated transport and client ports beside packet capture and firewall counters. If RTP leaves the server but never reaches those ports while an interleaved-TCP test works, the root cause is the UDP media boundary—not resource authentication or codec selection.
Commission the server as a chain of evidence
- Prove resource policy. Test one authorized publisher or origin, one reader, one denied identity and a duplicate-publisher attempt.
- Exercise both planes. Capture control results, negotiated transport, first RTP packet, first decoded frame and RTCP evidence.
- Test transport choices. Use the supported UDP and interleaved modes from representative client networks.
- Measure fan-out. Add clients gradually and observe connection state, egress, packet continuity, CPU, memory and port use.
- Interrupt each dependency. Restart source, server and downstream consumer separately; record recovery and stale-session cleanup.
- Validate downstream jobs. Use Multiview, Recording or Restream only for the consumer job that is actually required.
RTSP server FAQ
Does an RTSP server send media inside RTSP messages?
Usually no. RTSP controls the presentation, while RTP and RTCP carry media and reports through the transport negotiated during setup. Interleaving can frame RTP on the RTSP connection.
Can one RTSP server handle cameras and publishers?
Software may support both, but the roles should have separate resource, authentication and lifecycle contracts. Do not assume a playback proxy safely accepts arbitrary publishers.
Is interleaved TCP always better than RTP over UDP?
No. It can pass restrictive networks, but delayed TCP data holds later media behind it. Test both supported modes against the actual network and latency requirement.
Does Callaba currently expose a managed RTSP Server module?
Callaba documents direct RTSP inputs for monitoring, recording and conversion. It does not currently document a general RTSP publishing and playback server, so treat that as a separate product boundary.