Standards Track A. Rao Netscap - RFC Editor

RFC 2326 Real Time Streaming Protocol April 1998method direction object requirementDESCRIBE C->S P,S recommendedANNOUNCE C->S, S->C P,S optionalGET_PARAMETER C->S, S->C P,S optionalOPTIONS C->S, S->C P,S required(S->C: optional)PAUSE C->S P,S recommendedPLAY C->S P,S requiredRECORD C->S P,S optionalREDIRECT S->C P,S optionalSETUP C->S S requiredSET_PARAMETER C->S, S->C P,S optionalTEARDOWN C->S P,S requiredTable 2: Overview of RTSP methods, their direction, and whatobjects (P: presentation, S: stream) they operate onNotes on Table 2: PAUSE is recommended, but not required in that afully functional server can be built that does not support thismethod, for example, for live feeds. If a server does not support aparticular method, it MUST return "501 Not Implemented" and a clientSHOULD not try this method again for this server.10.1 OPTIONSThe behavior is equivalent to that described in [H9.2]. An OPTIONSrequest may be issued at any time, e.g., if the client is about totry a nonstandard request. It does not influence server state.Example:C->S: OPTIONS * RTSP/1.0CSeq: 1Require: implicit-playProxy-Require: gzipped-messagesS->C: RTSP/1.0 200 OKCSeq: 1Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSENote that these are necessarily fictional features (one would hopethat we would not purposefully overlook a truly useful feature justso that we could have a strong example in this section).Schulzrinne, et. al. Standards Track [Page 30]