Appendix A: RTSP Protocol State Machines

The RTSP client and server state machines describe the behavior of the protocol from RTSP session initialization through RTSP session termination.

State is defined on a per object basis. An object is uniquely identified by the stream URL and the RTSP session identifier. Any request/reply using aggregate URLs denoting RTSP presentations composed of multiple streams will have an effect on the individual states of all the streams. For example, if the presentation /movie contains two streams, /movie/audio and /movie/video, then the following command:

PLAY rtsp://foo.com/movie RTSP/1.0 CSeq: 559 Session: 12345678

will have an effect on the states of movie/audio and movie/video.

This example does not imply a standard way to represent streams in URLs or a relation to the filesystem. See Section 3.2.

The requests OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER, SET_PARAMETER do not have any effect on client or server state and are therefore not listed in the state tables.

A.1 Client State Machine

The client can assume the following states:

Init: SETUP has been sent, waiting for reply.

Ready: SETUP reply received or PAUSE reply received while in Playing state.

Playing: PLAY reply received

Recording: RECORD reply received

In general, the client changes state on receipt of replies to requests. Note that some requests are effective at a future time or position (such as a PAUSE), and state also changes accordingly. If no explicit SETUP is required for the object (for example, it is

available via a multicast group), state begins at Ready. In this case, there are only two states, Ready and Playing. The client also changes state from Playing/Recording to Ready when the end of the requested range is reached.

The "next state" column indicates the state assumed after receiving a success response (2xx). If a request yields a status code of 3xx, the state becomes Init, and a status code of 4xx yields no change in state. Messages not listed for each state MUST NOT be issued by the client in that state, with the exception of messages not affecting state, as listed above. Receiving a REDIRECT from the server is equivalent to receiving a 3xx redirect status from the server.

state message sent next state after response Init SETUP Ready TEARDOWN Init Ready PLAY Playing RECORD Recording TEARDOWN Init SETUP Ready Playing PAUSE Ready TEARDOWN Init PLAY Playing SETUP Playing (changed transport) Recording PAUSE Ready TEARDOWN Init RECORD Recording SETUP Recording (changed transport)

A.2 Server State Machine

The server can assume the following states:

Init: The initial state, no valid SETUP has been received yet.

Ready: Last SETUP received was successful, reply sent or after playing, last PAUSE received was successful, reply sent.

Playing: Last PLAY received was successful, reply sent. Data is being sent.

Recording: The server is recording media data.

In general, the server changes state on receiving requests. If the server is in state Playing or Recording and in unicast mode, it MAY revert to Init and tear down the RTSP session if it has not received "wellness" information, such as RTCP reports or RTSP commands, from the client for a defined interval, with a default of one minute. The server can declare another timeout value in the Session response header (Section 12.37). If the server is in state Ready, it MAY revert to Init if it does not receive an RTSP request for an interval of more than one minute. Note that some requests (such as PAUSE) may be effective at a future time or position, and server state changes at the appropriate time. The server reverts from state Playing or Recording to state Ready at the end of the range requested by the client.

The REDIRECT message, when sent, is effective immediately unless it has a Range header specifying when the redirect is effective. In such a case, server state will also change at the appropriate time.

If no explicit SETUP is required for the object, the state starts at Ready and there are only two states, Ready and Playing.

The "next state" column indicates the state assumed after sending a success response (2xx). If a request results in a status code of 3xx, the state becomes Init. A status code of 4xx results in no change.

state message received next state Init SETUP Ready TEARDOWN Init Ready PLAY Playing SETUP Ready TEARDOWN Init RECORD Recording Playing PLAY Playing PAUSE Ready TEARDOWN Init SETUP Playing Recording RECORD Recording PAUSE Ready TEARDOWN Init SETUP Recording