Appendix D: Minimal RTSP implementation

D.1 Client

A client implementation MUST be able to do the following :

Generate the following requests: SETUP, TEARDOWN, and one of PLAY (i.e., a minimal playback client) or RECORD (i.e., a minimal recording client). If RECORD is implemented, ANNOUNCE must be implemented as well. * Include the following headers in requests: CSeq, Connection, Session, Transport. If ANNOUNCE is implemented, the capability to include headers Content-Language, Content-Encoding, Content- Length, and Content-Type should be as well. * Parse and understand the following headers in responses: CSeq, Connection, Session, Transport, Content-Language, Content- Encoding, Content-Length, Content-Type. If RECORD is implemented, the Location header must be understood as well. RTP-compliant implementations should also implement RTP-Info. * Understand the class of each error code received and notify the end-user, if one is present, of error codes in classes 4xx and 5xx. The notification requirement may be relaxed if the end-user explicitly does not want it for one or all status codes. * Expect and respond to asynchronous requests from the server, such as ANNOUNCE. This does not necessarily mean that it should implement the ANNOUNCE method, merely that it MUST respond positively or negatively to any request received from the server.

Though not required, the following are highly recommended at the time of publication for practical interoperability with initial implementations and/or to be a "good citizen".

Implement RTP/AVP/UDP as a valid transport. * Inclusion of the User-Agent header. * Understand SDP session descriptions as defined in Appendix C * Accept media initialization formats (such as SDP) from standard input, command line, or other means appropriate to the operating environment to act as a "helper application" for other applications (such as web browsers).

There may be RTSP applications different from those initially envisioned by the contributors to the RTSP specification for which the requirements above do not make sense. Therefore, the recommendations above serve only as guidelines instead of strict requirements.

D.1.1 Basic Playback

To support on-demand playback of media streams, the client MUST additionally be able to do the following: * generate the PAUSE request; * implement the REDIRECT method, and the Location header.

D.1.2 Authentication-enabled

In order to access media presentations from RTSP servers that require authentication, the client MUST additionally be able to do the following: * recognize the 401 status code; * parse and include the WWW-Authenticate header; * implement Basic Authentication and Digest Authentication.

D.2 Server

A minimal server implementation MUST be able to do the following:

Implement the following methods: SETUP, TEARDOWN, OPTIONS and either PLAY (for a minimal playback server) or RECORD (for a minimal recording server). If RECORD is implemented, ANNOUNCE should be implemented as well. * Include the following headers in responses: Connection, Content-Length, Content-Type, Content-Language, Content-Encoding, Transport, Public. The capability to include the Location header should be implemented if the RECORD method is. RTP-compliant implementations should also implement the RTP-Info field. * Parse and respond appropriately to the following headers in requests: Connection, Session, Transport, Require.

Though not required, the following are highly recommended at the time of publication for practical interoperability with initial implementations and/or to be a "good citizen".

Implement RTP/AVP/UDP as a valid transport. * Inclusion of the Server header. * Implement the DESCRIBE method. * Generate SDP session descriptions as defined in Appendix C

D.2.1 Basic Playback

To support on-demand playback of media streams, the server MUST additionally be able to do the following:

Recognize the Range header, and return an error if seeking is not supported. * Implement the PAUSE method.

In addition, in order to support commonly-accepted user interface features, the following are highly recommended for on-demand media servers:

Include and parse the Range header, with NPT units. Implementation of SMPTE units is recommended. * Include the length of the media presentation in the media initialization information. * Include mappings from data-specific timestamps to NPT. When RTP is used, the rtptime portion of the RTP-Info field may be used to map RTP timestamps to NPT.

Client implementations may use the presence of length information to determine if the clip is seekable, and visibly disable seeking features for clips for which the length information is unavailable. A common use of the presentation length is to implement a "slider bar" which serves as both a progress indicator and a timeline positioning tool.

Mappings from RTP timestamps to NPT are necessary to ensure correct positioning of the slider bar.

D.2.2 Authentication-enabled

In order to correctly handle client authentication, the server MUST additionally be able to do the following:

Generate the 401 status code when authentication is required for the resource. * Parse and include the WWW-Authenticate header * Implement Basic Authentication and Digest Authentication