Knowlegde Through Fun Welcome To Mady's Site.

RTSP has the following properties:
Extendable:
New methods and parameters can be easily added to RTSP.
Easy to parse:
RTSP can be parsed by standard HTTP or MIME parsers.
Secure:
RTSP re-uses web security mechanisms. All HTTP authentication mechanisms such as basic (RFC 2068) and digest authentication (RFC 2069) are directly applicable. One may also reuse transport or network layer security mechanisms.
Transport-independent:
RTSP may use either an unreliable datagram protocol (UDP), a reliable datagram protocol or a reliable stream protocol such as TCP as it implements application-level reliability.
Multi-server capable:
Each media stream within a presentation can reside on a different server. The client automatically establishes several concurrent control sessions with the different media servers. Media synchronization is performed at the transport level.
Control of recording devices:
The protocol can control both recording and playback devices, as well as devices that can alternate between the two modes ("VCR").
Separation of stream control and conference initiation:
Stream control is divorced from inviting a media server to a conference. The only requirement is that the conference initiation protocol either provides or can be used to create a unique conference identifier. In particular, SIP or H.323 may be used to invite a server to a conference.
Suitable for professional applications:
RTSP supports frame-level accuracy through SMPTE time stamps to allow remote digital editing.
Presentation description neutral:
The protocol does not impose a particular presentation description or metafile format and can convey the type of format to be used. However, the presentation description must contain at least one RTSP URI.
Proxy and firewall friendly:
The protocol should be readily handled by both application and transport-layer (SOCKS [14]) firewalls. A firewall may need to understand the SETUP method to open a "hole" for the UDP media stream.
HTTP-friendly:
Where sensible, RTSP reuses HTTP concepts, so that the existing infrastructure can be reused. This infrastructure includes PICS (Platform for Internet Content Selection [15, 16]) for associating labels with content. However, RTSP does not just add methods to HTTP since the controlling continuous media requires server state in most cases.
Appropriate server control:
If a client can start a stream, it must be able to stop a stream. Servers should not start streaming to clients in such a way that clients cannot stop the stream.
Transport negotiation:
The client can negotiate the transport method prior to actually needing to process a continuous media stream.
Capability negotiation:
If basic features are disabled, there must be some clean mechanism for the client to determine which methods are not going to be implemented. This allows clients to present the appropriate user interface. For example, if seeking is not allowed, the user interface must be able to disallow moving a sliding position indicator.
An earlier requirement in RTSP was multi-client capability. However, it was determined that a better approach was to make sure that the protocol is easily extensible to the multi-client scenario. Stream identifiers can be used by several control streams, so that "passing the remote" would be possible. The protocol would not address how several clients negotiate access; this is left to either a "social protocol" or some other floor control mechanism.
Extending RTSP
RTSP can be extended in three ways, listed here in order of the magnitude of changes supported:
* Existing methods can be extended with new parameters, as long as
these parameters can be safely ignored by the recipient. (This is
equivalent to adding new parameters to an HTML tag.) If the
client needs negative acknowledgement when a method extension is
not supported, a tag corresponding to the extension may be added
in the required field.
* New methods can be added. If the recipient of the message does
not understand the request, it responds with error code 501 (Not
implemented) and the sender should not attempt to use this method
again. A client may also use the OPTIONS method to inquire about
methods supported by the server. The server SHOULD list the
methods it supports using the Public response header.
* A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to
change.