Standards Track A. Rao Netscap - RFC Editor

More documents

Recommendations

Info

RFC 2326 Real Time Streaming Protocol April 199810.6 PAUSEThe PAUSE request causes the stream delivery to be interrupted(halted) temporarily. If the request URL names a stream, onlyplayback and recording of that stream is halted. For example, foraudio, this is equivalent to muting. If the request URL names apresentation or group of streams, delivery of all currently activestreams within the presentation or group is halted. After resumingplayback or recording, synchronization of the tracks MUST bemaintained. Any server resources are kept, though servers MAY closethe session and free resources after being paused for the durationspecified with the timeout parameter of the Session header in theSETUP message.Example:C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0CSeq: 834Session: 12345678S->C: RTSP/1.0 200 OKCSeq: 834Date: 23 Jan 1997 15:35:06 GMTThe PAUSE request may contain a Range header specifying when thestream or presentation is to be halted. We refer to this point as the"pause point". The header must contain exactly one value rather thana time range. The normal play time for the stream is set to the pausepoint. The pause request becomes effective the first time the serveris encountering the time point specified in any of the currentlypending PLAY requests. If the Range header specifies a time outsideany currently pending PLAY requests, the error "457 Invalid Range" isreturned. If a media unit (such as an audio or video frame) startspresentation at exactly the pause point, it is not played orrecorded. If the Range header is missing, stream delivery isinterrupted immediately on receipt of the message and the pause pointis set to the current normal play time.A PAUSE request discards all queued PLAY requests. However, the pausepoint in the media stream MUST be maintained. A subsequent PLAYrequest without Range header resumes from the pause point.For example, if the server has play requests for ranges 10 to 15 and20 to 29 pending and then receives a pause request for NPT 21, itwould start playing the second range and stop at NPT 21. If the pauserequest is for NPT 12 and the server is playing at NPT 13 serving thefirst play request, the server stops immediately. If the pauserequest is for NPT 16, the server stops after completing the firstSchulzrinne, et. al. Standards Track [Page 36]
RFC 2326 Real Time Streaming Protocol April 1998play request and discards the second play request.As another example, if a server has received requests to play ranges10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSErequest for NPT=14 would take effect while the server plays the firstrange, with the second PLAY request effectively being ignored,assuming the PAUSE request arrives before the server has startedplaying the second, overlapping range. Regardless of when the PAUSErequest arrives, it sets the NPT to 14.If the server has already sent data beyond the time specified in theRange header, a PLAY would still resume at that point in time, as itis assumed that the client has discarded data after that point. Thisensures continuous pause/play cycling without gaps.10.7 TEARDOWNThe TEARDOWN request stops the stream delivery for the given URI,freeing the resources associated with it. If the URI is thepresentation URI for this presentation, any RTSP session identifierassociated with the session is no longer valid. Unless all transportparameters are defined by the session description, a SETUP requesthas to be issued before the session can be played again.Example:C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0CSeq: 892Session: 12345678S->C: RTSP/1.0 200 OKCSeq: 89210.8 GET_PARAMETERThe GET_PARAMETER request retrieves the value of a parameter of apresentation or stream specified in the URI. The content of the replyand response is left to the implementation. GET_PARAMETER with noentity body may be used to test client or server liveness ("ping").Example:S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0CSeq: 431Content-Type: text/parametersSession: 12345678Content-Length: 15packets_receivedjitterSchulzrinne, et. al. Standards Track [Page 37]
Page 2 and 3: RFC 2326 Real Time Streaming Protoc
Page 7: RFC 2326 Real Time Streaming Protoc
Page 86 and 87:
RFC 2326 Real Time Streaming Protoc
Page 88 and 89:
Page 90 and 91:
Page 92:
show all

Standards Track A. Rao Netscap - RFC Editor

Create successful ePaper yourself

Delete template?

Save as template?