rtsp protocols
RFC 2326 Real Time Streaming Protocol April 1998
The protocol supports the following operations:
Retrieval of media from media server:
The client can request a presentation description via HTTP or
some other method. If the presentation is being multicast, the
presentation description contains the multicast addresses and
ports to be used for the continuous media. If the presentation
is to be sent only to the client via unicast, the client
provides the destination for security reasons.
Invitation of a media server to a conference:
A media server can be "invited" to join an existing
conference, either to play back media into the presentation or
to record all or a subset of the media in a presentation. This
mode is useful for distributed teaching applications. Several
parties in the conference may take turns "pushing the remote
control buttons."
Addition of media to an existing presentation:
Particularly for live presentations, it is useful if the
server can tell the client about additional media becoming
available.
RTSP requests may be handled by proxies, tunnels and caches as in
HTTP/1.1 [2].
1.2 Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
1.3 Terminology
Some of the terminology has been adopted from HTTP/1.1 [2]. Terms not
listed here are defined as in HTTP/1.1.
Aggregate control:
The control of the multiple streams using a single timeline by
the server. For audio/video feeds, this means that the client
may issue a single play or pause message to control both the
audio and video feeds.
Conference:
a multiparty, multimedia presentation, where "multi" implies
greater than or equal to one.
Schulzrinne, et. al. Standards Track [Page 6]