Standards Track A. Rao Netscap - RFC Editor

More documents

Recommendations

Info

RFC 2326 Real Time Streaming Protocol April 1998HTTP or other means such as email and may not necessarily be storedon the media server.For the purposes of this specification, a presentation description isassumed to describe one or more presentations, each of whichmaintains a common time axis. For simplicity of exposition andwithout loss of generality, it is assumed that the presentationdescription contains exactly one such presentation. A presentationmay contain several media streams.The presentation description file contains a description of the mediastreams making up the presentation, including their encodings,language, and other parameters that enable the client to choose themost appropriate combination of media. In this presentationdescription, each media stream that is individually controllable byRTSP is identified by an RTSP URL, which points to the media serverhandling that particular media stream and names the stream stored onthat server. Several media streams can be located on differentservers; for example, audio and video streams can be split acrossservers for load sharing. The description also enumerates whichtransport methods the server is capable of.Besides the media parameters, the network destination address andport need to be determined. Several modes of operation can bedistinguished:Unicast:The media is transmitted to the source of the RTSP request,with the port number chosen by the client. Alternatively, themedia is transmitted on the same reliable stream as RTSP.Multicast, server chooses address:The media server picks the multicast address and port. This isthe typical case for a live or near-media-on-demandtransmission.Multicast, client chooses address:If the server is to participate in an existing multicastconference, the multicast address, port and encryption key aregiven by the conference description, established by meansoutside the scope of this specification.1.7 RTSP StatesRTSP controls a stream which may be sent via a separate protocol,independent of the control channel. For example, RTSP control mayoccur on a TCP connection while the data flows via UDP. Thus, datadelivery continues even if no RTSP requests are received by the mediaSchulzrinne, et. al. Standards Track [Page 12]
RFC 2326 Real Time Streaming Protocol April 1998server. Also, during its lifetime, a single media stream may becontrolled by RTSP requests issued sequentially on different TCPconnections. Therefore, the server needs to maintain "session state"to be able to correlate RTSP requests with a stream. The statetransitions are described in Section A.Many methods in RTSP do not contribute to state. However, thefollowing play a central role in defining the allocation and usage ofstream resources on the server: SETUP, PLAY, RECORD, PAUSE, andTEARDOWN.SETUP:Causes the server to allocate resources for a stream and startan RTSP session.PLAY and RECORD:Starts data transmission on a stream allocated via SETUP.PAUSE:Temporarily halts a stream without freeing server resources.TEARDOWN:Frees resources associated with the stream. The RTSP sessionceases to exist on the server.RTSP methods that contribute to state use the Session headerfield (Section 12.37) to identify the RTSP session whose stateis being manipulated. The server generates session identifiersin response to SETUP requests (Section 10.4).1.8 Relationship with Other ProtocolsRTSP has some overlap in functionality with HTTP. It also mayinteract with HTTP in that the initial contact with streaming contentis often to be made through a web page. The current protocolspecification aims to allow different hand-off points between a webserver and the media server implementing RTSP. For example, thepresentation description can be retrieved using HTTP or RTSP, whichreduces roundtrips in web-browser-based scenarios, yet also allowsfor standalone RTSP servers and clients which do not rely on HTTP atall.However, RTSP differs fundamentally from HTTP in that data deliverytakes place out-of-band in a different protocol. HTTP is anasymmetric protocol where the client issues requests and the serverresponds. In RTSP, both the media client and media server can issuerequests. RTSP requests are also not stateless; they may setparameters and continue to control a media stream long after theSchulzrinne, et. al. Standards Track [Page 13]
Page 2 and 3: RFC 2326 Real Time Streaming Protoc
Page 7: RFC 2326 Real Time Streaming Protoc
Page 62 and 63:
RFC 2326 Real Time Streaming Protoc
Page 64 and 65:
Page 66 and 67:
Page 68 and 69:
Page 70 and 71:
Page 72 and 73:
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
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?