Skip to main content

Crate rtsp_runtime

Crate rtsp_runtime 

Source
Expand description

Sans-IO RTSP 1.0 session engine — RFC 2326 (Real Time Streaming Protocol).

This crate fills the gap the ecosystem leaves: a driveable RTSP session engine, a client and a server. Message parse/serialize is delegated to the mature rtsp_types and sdp_types codecs; authentication (Basic/Digest/ Bearer) to the shared broadcast_auth crate (which itself wraps http-auth for Basic/Digest). What lives here is the part nothing else provides — the client and server session state machines (RFC 2326 Appendix A), CSeq correlation, Transport negotiation (§12.39), interleaved RTP/RTCP framing (§10.12), and RTSP’s auth wiring (§14).

§The sans-IO contract

No sockets live in the core. You drive the engine with bytes and read back bytes + typed events:

  • ClientSession — request-builder methods (options/describe/setup/ play/pause/teardown/get_parameter) return the outbound request bytes to write; ClientSession::handle_data consumes inbound bytes (responses and interleaved $ frames) and returns ClientEvents. It correlates CSeq, advances the state machine on 2xx, resets to Init on 3xx, transparently answers 401 challenges, and captures the Session id/timeout from the SETUP response.
  • ServerSessionServerSession::handle_request takes inbound request bytes and returns the response bytes plus ServerEvents, validating the method against the server state table (455 otherwise), allocating a session on SETUP, and negotiating Transport.

An optional tokio socket adapter (feature tokio) drives real connections over this same core: the io::AsyncRtspClient and io::AsyncRtspServer types own a tokio::net::TcpStream, move the bytes the session produces/consumes, and surface the same ClientEvent/ServerEvents. With the tls feature the adapter also speaks rtsps:// (RTSP over TLS, default port 322) by wrapping the stream in a tokio-rustls session before the RTSP exchange. Both are generic over the stream type, so identical logic runs over TCP and TLS.

§Module map

Methods, status codes, and their state effects are catalogued in docs/methods-and-status.md.

Re-exports§

pub use client::ClientEvent;
pub use client::ClientSession;
pub use error::Error;
pub use error::Result;
pub use interleaved::InterleavedFrame;
pub use io::AsyncRtspClient;
pub use io::AsyncRtspServer;
pub use io::RTSP_DEFAULT_PORT;
pub use io::RTSPS_DEFAULT_PORT;
pub use server::ServerEvent;
pub use server::ServerSession;
pub use state::SessionState;
pub use transport::Delivery;
pub use transport::LowerTransport;
pub use transport::Transport;
pub use transport::TransportSpec;

Modules§

auth
Authentication wiring — RFC 2326 §14 (RTSP reuses HTTP auth).
client
Client-side RTSP session engine — RFC 2326 Appendix A.1.
error
Error types for the RTSP session engine.
interleaved
Interleaved ($-framed) binary data — RFC 2326 §10.12.
io
Async real-socket IO adapter over the sans-IO engine — RFC 2326 transport.
server
Server-side RTSP session engine — RFC 2326 Appendix A.2.
state
RTSP session state machine — RFC 2326 Appendix A.
transport
Typed Transport header — RFC 2326 §12.39.

Structs§

Authenticator
Negotiates a challenge once, then answers every subsequent request in the session (RFC 7235 WWW-Authenticate/Authorization; RFC 2326 §14 for RTSP; RFC 6750 for Bearer).

Enums§

Credentials
Credentials for one of the supported auth schemes.
Method
RTSP method.
StatusCode
RTSP response status codes.

Constants§

RFC
The RFC this engine implements.