Standards Track A. Rao Netscap - RFC Editor

More documents

Recommendations

Info

RFC 2326 Real Time Streaming Protocol April 1998Appendix A: RTSP Protocol State MachinesThe RTSP client and server state machines describe the behavior ofthe protocol from RTSP session initialization through RTSP sessiontermination.State is defined on a per object basis. An object is uniquelyidentified by the stream URL and the RTSP session identifier. Anyrequest/reply using aggregate URLs denoting RTSP presentationscomposed of multiple streams will have an effect on the individualstates of all the streams. For example, if the presentation /moviecontains two streams, /movie/audio and /movie/video, then thefollowing command:PLAY rtsp://foo.com/movie RTSP/1.0CSeq: 559Session: 12345678will have an effect on the states of movie/audio and movie/video.This example does not imply a standard way to represent streams inURLs 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 andare therefore not listed in the state tables.A.1 Client State MachineThe client can assume the following states:Init:Ready:SETUP has been sent, waiting for reply.SETUP reply received or PAUSE reply received while in Playingstate.Playing:PLAY reply receivedRecording:RECORD reply receivedIn general, the client changes state on receipt of replies torequests. Note that some requests are effective at a future time orposition (such as a PAUSE), and state also changes accordingly. If noexplicit SETUP is required for the object (for example, it isSchulzrinne, et. al. Standards Track [Page 76]
RFC 2326 Real Time Streaming Protocol April 1998available via a multicast group), state begins at Ready. In thiscase, there are only two states, Ready and Playing. The client alsochanges state from Playing/Recording to Ready when the end of therequested range is reached.The "next state" column indicates the state assumed after receiving asuccess response (2xx). If a request yields a status code of 3xx, thestate becomes Init, and a status code of 4xx yields no change instate. Messages not listed for each state MUST NOT be issued by theclient in that state, with the exception of messages not affectingstate, as listed above. Receiving a REDIRECT from the server isequivalent to receiving a 3xx redirect status from the server.state message sent next state after responseInit SETUP ReadyTEARDOWNInitReady PLAY PlayingRECORDRecordingTEARDOWNInitSETUPReadyPlaying PAUSE ReadyTEARDOWNInitPLAYPlayingSETUPPlaying (changed transport)Recording PAUSE ReadyTEARDOWNInitRECORDRecordingSETUPRecording (changed transport)A.2 Server State MachineThe server can assume the following states:Init:Ready:The initial state, no valid SETUP has been received yet.Last SETUP received was successful, reply sent or afterplaying, last PAUSE received was successful, reply sent.Playing:Last PLAY received was successful, reply sent. Data is beingsent.Recording:The server is recording media data.Schulzrinne, et. al. Standards Track [Page 77]
Page 2 and 3:
RFC 2326 Real Time Streaming Protoc
Page 4 and 5:
Page 7:
Page 10 and 11:
Page 12 and 13:
Page 14 and 15:
Page 16 and 17:
Page 18 and 19:
Page 20 and 21:
Page 22 and 23:
Page 24 and 25:
Page 26 and 27: RFC 2326 Real Time Streaming Protoc
Page 92: RFC 2326 Real Time Streaming Protoc
show all

Standards Track A. Rao Netscap - RFC Editor

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?