The Accept request-header field can be used to specify certain presentation description content types which are acceptable for the response.

The Allow response header field lists the methods supported by the resource identified by the request-URI. The purpose of this field is to strictly inform the recipient of valid methods associated with the resource. An Allow header field must be present in a 405 (Method not allowed) response.

Provides Basic and Digest authentication.

Abstract base class for all RTSP headers.

Abstract base class for all RTSP messages. Messages contain headers (standardized and generic) and content (SDP or custom).

A collection of Transaction objects.

The Cache-Control general header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain.
Cache directives must be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives may be applicable to all recipients along the request/response chain. It is not possible to specify a cache- directive for a specific cache.

Represents the Content-Base Header in an RTSP message.

Represents the Content-Length Header in an RTSP message. This field contains the length of the content of the method. Unlike HTTP, it MUST be included in all messages that carry content beyond the header portion of the message. If it is missing, a default value of zero is assumed.

Represents the Content-Location Header in an RTSP message.

Represents the Content-Type Header in an RTSP message.

Content type declaration.

Represents the CSeq header in an RTSP message. The CSeq field specifies the sequence number for an RTSP request- response pair. This field MUST be present in all requests and responses. For every RTSP request containing the given sequence number, there will be a corresponding response having the same number. Any retransmitted request must contain the same sequence number as the original (i.e. the sequence number is not incremented for retransmissions of the same request).

Represents the Date Header in an RTSP message.

eos-reason (draft-ietf-mmusic-rtsp-announce-01)

Event-Type header (draft-ietf-mmusic-rtsp-announce-01)

The Expires entity-header field gives a date and time after which the description or media-stream should be considered stale. The interpretation depends on the method:
Describe response: The Expires header indicates a date and time after which the description should be considered stale.
A stale cache entry may not normally be returned by a cache (either a proxy cache or an user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the entity). See section 13 for further discussion of the expiration model.
The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
To mark a response as "already expired," an origin server should use an Expires date that is equal to the Date header value. To mark a response as "never expires," an origin server should use an Expires date approximately one year from the time the response is sent. RTSP/1.0 servers should not send Expires dates more than one year in the future.
The presence of an Expires header field with a date value of some time in the future on a media stream that otherwise would by default be non-cacheable indicates that the media stream is cacheable, unless indicated otherwise by a Cache-Control header field.

Represents a generic header. Generic headers are headers with names that are not defined in the protocol standard. They allow for proprietary information to be transported. A generic header can have an arbitrary name and value.

The If-Modified-Since request-header field is used with the Describe and Setup methods to make them conditional. If the requested variant has not been modified since the time specified in this field, a description will not be returned from the server (Describe) or a stream will not be set up (Setup). Instead, a 304 (not modified) response will be returned without any message-body.

Extracts data from an RTSP interleave stream and saves them in a queue. Usage: Use AddBuffer to add data to the internal buffer. Then call ParseData as long as return value is true, to create InterleaveSlices. After that call GetSlice to retrieve the individual slices containing the payloads.

Represents a data unit sent to a specific channel using RTSP interleave mode. This class may produce 2 distinct types of data: InterleaveContentType.Signaling and InterleaveContentType.Payload. Signaling is used to represent RTSP an message or Payload is used to represent RTP/RTCP packets.

The Last-Modified entity-header field indicates the date and time at which the origin server believes the presentation description or media stream was last modified. See [H14.29]. For the methods Describe or Announce, the header field indicates the last modification date and time of the description, for Setup that of the media stream.

Represents the Location Header in an RTSP message.

RTSP parser helper class.

Represents the Public Header in an RTSP message.

This request and response header field specifies a range of time. The range can be specified in a number of units.
Ranges are half-open intervals, including the lower point, but excluding the upper point. In other words, a range of a-b starts exactly at time a, but stops just before b. Only the start time of a media unit such as a video or audio frame is relevant. As an example, assume that video frames are generated every 40 ms. A range of 10.0- 10.1 would include a video frame starting at 10.0 or later time and would include a video frame starting at 10.08, even though it lasted beyond the interval. A range of 10.0-10.08, on the other hand, would exclude the frame at 10.08.

Range parameters.

Represents the header part of a request message.

The Require header is used by clients to query the server about options that it may or may not support. The server MUST respond to this header by using the Unsupported header to negatively acknowledge those options which are NOT supported.
This is to make sure that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the case above). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes state ambiguity when the client requires features that the server does not understand.

Represents the response header of a response message.

This field is used to set RTP-specific parameters in the Play response.
A mapping from RTP timestamps to NTP timestamps (wall clock) is available via RTCP. However, this information is not sufficient to generate a mapping from RTP timestamps to NPT. Furthermore, in order to ensure that this information is available at the necessary time (immediately at startup or after a seek), and that it is delivered reliably, this mapping is placed in the RTSP control channel.
In order to compensate for drift for long, uninterrupted presentations, RTSP clients should additionally map NPT to NTP, using initial RTCP sender reports to do the mapping, and later reports to check drift against the mapping.

Makes up the inputStream-URL part of RTP-Info Header, containing track information, RTP base timestamp and sequence number.

The Announce method serves two purposes:
When sent from client to server, Announce posts the description of a presentation or media object identified by the request URL to a server. When sent from server to client, Announce updates the session description in real-time.
If a new media stream is added to a presentation (e.g., during a live presentation), the whole presentation description should be sent again, rather than just the additional components, so that components can be deleted.

RtspConstants.

The Describe method retrieves the description of a presentation or media object identified by the request URL from a server. It may use the Accept header to specify the description formats that the client understands. The server responds with a description of the requested resource. The Describe reply-response pair constitutes the media initialization phase of RTSP.

A GetParameter request may be issued at any time, e.g., if the client is about to try a nonstandard request. It does not influence server state.

RTSPManager is the base class for RTSP related activity.

RTSP message encapsulates both request and response as well as interleaved messages.

An Options request may be issued at any time, e.g., if the client is about to try a nonstandard request. It does not influence server state.

The Pause request causes the stream delivery to be interrupted (halted) temporarily. If the request URL names a stream, only playback and recording of that stream is halted. For example, for audio, this is equivalent to muting. If the request URL names a presentation or group of streams, delivery of all currently active streams within the presentation or group is halted. After resuming playback or recording, synchronization of the tracks MUST be maintained. Any server resources are kept, though servers MAY close the session and free resources after being paused for the duration specified with the timeout parameter of the Session header in the Setup message.
The Pause request may contain a Range header specifying when the stream or presentation is to be halted. We refer to this point as the "pause point". The header must contain exactly one value rather than a time range. The normal play time for the stream is set to the pause point. The pause request becomes effective the first time the server is encountering the time point specified in any of the currently pending Play requests. If the Range header specifies a time outside any currently pending Play requests, the error "457 Invalid Range" is returned. If a media unit (such as an audio or video frame) starts presentation at exactly the pause point, it is not played or recorded. If the Range header is missing, stream delivery is interrupted immediately on receipt of the message and the pause point is set to the current normal play time.
A Pause request discards all queued Play requests. However, the pause point in the media stream MUST be maintained. A subsequent Play request without Range header resumes from the pause point.

The Play method tells the server to start sending data via the mechanism specified in Setup. A client MUST NOT issue a Play request until any outstanding Setup requests have been acknowledged as successful.
The Play request positions the normal play time to the beginning of the range specified and delivers stream data until the end of the range is reached. Play requests may be pipelined (queued); a server MUST queue Play requests to be executed in order. That is, a Play request arriving while a previous Play request is still active is delayed until the first has been completed.

This method initiates recording a range of media data according to the presentation description. The timestamp reflects start and end time (UTC). If no time range is given, use the start or end time provided in the presentation description. If the session has already started, commence recording immediately.
The server decides whether to store the recorded data under the request-URI or another URI. If the server does not use the request- URI, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.

A redirect request informs the client that it must connect to another server location. It contains the mandatory header Location, which indicates that the client should issue requests for that URL. It may contain the parameter Range, which indicates when the redirection takes effect. If the client wants to continue to send or receive media for this URI, the client MUST issue a Teardown request for the current session and a Setup for the new session at the designated host.

Represents an RTSP request.

Represents an RTSP response.

Contains session information about on ongoing RTSP session.

The Setup request for a URI specifies the transport mechanism to be used for the streamed media. A client can issue a Setup request for a stream that is already playing to change transport parameters, which a server MAY allow. If it does not allow this, it MUST respond with error "455 Method Not Valid In This State". For the benefit of any intervening firewalls, a client must indicate the transport parameters even if it has no influence over these parameters, for example, where the server advertises a fixed multicast address.
Since Setup includes all transport initialization information, firewalls and other intermediate network devices (which need this information) are spared the more arduous task of parsing the Describe response, which has been reserved for media initialization.

The Teardown request stops the stream delivery for the given URI, freeing the resources associated with it. If the URI is the presentation URI for this presentation, any RTSP session identifier associated with the session is no longer valid. Unless all transport parameters are defined by the session description, a Setup request has to be issued before the session can be played again.

Stores information of a media track control. An RTSP Session may have multiple tracks such as Audio and Video.

A scale value of 1 indicates normal play or record at the normal forward viewing rate. If not 1, the value corresponds to the rate with respect to normal viewing rate. For example, a ratio of 2 indicates twice the normal viewing rate ("fast forward") and a ratio of 0.5 indicates half the normal viewing rate. In other words, a ratio of 2 has normal play time increase at twice the wallclock rate. For every second of elapsed (wallclock) time, 2 seconds of content will be delivered. A negative value indicates reverse direction.
Unless requested otherwise by the Speed parameter, the data rate SHOULD not be changed. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected key frames. For audio, it may time- scale the audio while preserving pitch or, less desirably, deliver fragments of audio.
The server should try to approximate the viewing rate, but may restrict the range of scale values that it supports. The response MUST contain the actual scale value chosen by the server.
If the request contains a Range parameter, the new scale value will take effect at that time.

Server header.

This request and response header field identifies an RTSP session started by the media server in a Setup response and concluded by Teardown on the presentation URL. The session identifier is chosen by the media server (see Section 3.4). Once a client receives a Session identifier, it MUST return it for any request related to that session. A server does not have to set up a session identifier if it has other means of identifying a session, such as dynamically generated URLs.

Represents the Speed Header in an RTSP message. This request header fields parameter requests the server to deliver data to the client at a particular speed, contingent on the server's ability and desire to serve the media stream at the given speed. Implementation by the server is OPTIONAL. The default is the bit rate of the stream.

Static configuration for RTSP message contents.

The timestamp general header describes when the client sent the request to the server. The value of the timestamp is of significance only to the client and may use any timescale. The server MUST echo the exact same value and MAY, if it has accurate information about this, add a floating point number indicating the number of seconds that has elapsed since it has received the request. The timestamp is used by the client to compute the round-trip time to the server so that it can adjust the timeout value for retransmissions.

A single transaction pairing a request with a response. Transactions are waitable objects that success or fail as a whole. Transactions can also be aborted.

This request header indicates which transport protocol is to be used and configures its parameters such as destination address, compression, multicast time-to-live and destination port for a single stream. It sets those values not already determined by a presentation description.

Header contains the name of the user agent.

WWW authentication header is used to authenticate a client with a server. Both Basic and Digest authentication are support.

Callback, called before any packet is parsed or passed on.

Callback, called before the TCP client sends a packet to the remote endpoint.

Callback is called when a TCP connection is terminated.

Reference Implementation of an RTSP Client using RTSP.NET
Manages RTSP Sessions and encapsulates useful functions to easily accomplish common tasks needed when working with RTSP.

Callback, called when new interleave data arrives.

Callback, called when the a new request is received.

Callback, called when a new response is received.

Enumeration of supported authentication types.

Enumeration of support header types.

The types of data an InterleaveSlice can contain.

Values that represent either request, response or an interleaved message.

Enumeration of supported RTSP method types.

Values that represent RangeDefinition.