Internet Engineering Task Force
`INTERNET-DRAFT
`draft-ietf-mmusic-rtsp-09.ps
`
`MMUSIC WG
`H. Schulzrinne, A. Rao, R. Lanphier
`Columbia U./Netscape/RealNetworks
`February 2, 1998
`Expires: August 2, 1998
`
`Real Time Streaming Protocol (RTSP)
`
`Status of this Memo
`
`Internet-Drafts are working documents of the Internet Engineering
`This document is an Internet-Draft.
`Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working
`documents as Internet-Drafts.
`Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced,
`or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material
`or to cite them other than as “work in progress”.
`To learn the current status of any Internet-Draft, please check the “1id-abstracts.txt” listing contained
`in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
`(Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
`Distribution of this document is unlimited.
`
`Copyright Notice
`Copyright (c) The Internet Society (1998). All Rights Reserved.
`
`Abstract
`The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the
`delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled,
`on-demand delivery of real-time data, such as audio and video. Sources of data can include both live
`data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide
`a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for
`choosing delivery mechanisms based upon RTP (RFC 1889).
`
`Contents
`
`1 Introduction
`. . . . . .
`. . . . .
`1.1 Purpose . . . . . .
`. . . . . .
`. . . . .
`1.2 Requirements . . .
`. . . . . .
`. . . . .
`1.3 Terminology . . . .
`. . . . . .
`. . . . .
`1.4 Protocol Properties
`. . . . . .
`. . . . .
`1.5 Extending RTSP . .
`. . . . . .
`. . . . .
`1.6 Overall Operation .
`. . . . . .
`. . . . .
`1.7 RTSP States . . . .
`1.8 Relationship with Other Protocols
`. . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`2 Notational Conventions
`
`3 Protocol Parameters
`3.1 RTSP Version . . .
`3.2 RTSP URL . . . .
`
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`
`5
`5
`. . . . . .
`6
`. . . . . .
`6
`. . . . . .
`8
`. . . . . .
`9
`. . . . . .
`. . . . . . 10
`. . . . . . 10
`. . . . . . 11
`
`11
`
`11
`. . . . . . 11
`. . . . . . 12
`
`Petitioners' Exhibit 1013
`Page 0001
`
`

`

`INTERNET-DRAFT
`
`draft-ietf-mmusic-rtsp-09.ps
`
`February 2, 1998
`
`. . . . . .
`. . . . .
`. . . . . .
`3.3 Conference Identifiers . . . .
`. . . . . .
`. . . . .
`. . . . . .
`3.4 Session Identifiers .
`. . . . .
`. . . . . .
`. . . . .
`3.5 SMPTE Relative Timestamps . . . . . .
`. . . . . .
`. . . . .
`3.6 Normal Play Time .
`. . . . .
`. . . . . .
`. . . . . .
`. . . . .
`3.7 Absolute Time . . .
`. . . . .
`. . . . . .
`. . . . . .
`. . . . .
`3.8 Option Tags . . . .
`. . . . .
`. . . . . .
`3.8.1 Registering New Option Tags with IANA . . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . . 13
`. . . . . . 13
`. . . . . . 13
`. . . . . . 13
`. . . . . . 14
`. . . . . . 14
`. . . . . . 15
`
`4 RTSP Message
`. .
`4.1 Message Types
`4.2 Message Headers .
`4.3 Message Body . . .
`4.4 Message Length . .
`
`5 General Header Fields
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`6 Request
`. . . . .
`. . .
`6.1 Request Line
`6.2 Request Header Fields
`. . .
`
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`
`7 Response
`. . . . . .
`. . . . .
`7.1 Status-Line . . . .
`7.1.1
`Status Code and Reason Phrase
`7.1.2 Response Header Fields
`. . . .
`
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`
`8 Entity
`8.1 Entity Header Fields
`8.2 Entity Body . . . .
`
`. . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`
`9 Connections
`. . . . . .
`. . . . .
`9.1 Pipelining . . . . .
`9.2 Reliability and Acknowledgements . . .
`
`10 Method Definitions
`10.1 OPTIONS . . . .
`. . . . . .
`. . . . .
`10.2 DESCRIBE . . . .
`. . . . . .
`. . . . .
`10.3 ANNOUNCE . . .
`. . . . . .
`. . . . .
`10.4 SETUP . . . . . .
`. . . . . .
`. . . . .
`10.5 PLAY .
`. . . . . .
`. . . . .
`. . . . . .
`10.6 PAUSE . . . . . .
`. . . . . .
`. . . . .
`10.7 TEARDOWN . . .
`. . . . . .
`. . . . .
`10.8 GET PARAMETER . . . .
`. . . . . .
`10.9 SET PARAMETER . . . .
`. . . . . .
`10.10REDIRECT . . . .
`. . . . . .
`. . . . .
`10.11RECORD . . . . .
`. . . . . .
`. . . . .
`10.12Embedded (Interleaved) Binary Data . .
`
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`15
`. . . . . . 15
`. . . . . . 15
`. . . . . . 16
`. . . . . . 16
`
`16
`
`16
`. . . . . . 17
`. . . . . . 17
`
`18
`. . . . . . 18
`. . . . . . 18
`. . . . . . 20
`
`20
`. . . . . . 20
`. . . . . . 22
`
`22
`. . . . . . 22
`. . . . . . 22
`
`23
`. . . . . . 23
`. . . . . . 24
`. . . . . . 25
`. . . . . . 26
`. . . . . . 27
`. . . . . . 28
`. . . . . . 29
`. . . . . . 30
`. . . . . . 30
`. . . . . . 31
`. . . . . . 31
`. . . . . . 32
`
`H. Schulzrinne, A. Rao, R. Lanphier
`
`Expires August 2, 1998
`
`[Page 2]
`
`Petitioners' Exhibit 1013
`Page 0002
`
`

`

`INTERNET-DRAFT
`
`draft-ietf-mmusic-rtsp-09.ps
`
`February 2, 1998
`
`11 Status Code Definitions
`. . . . . .
`. . . . .
`. . . . . .
`. . . . .
`11.1 Success 2xx . . . .
`. . . . . .
`. . . . .
`11.1.1 250 Low on Storage Space . . .
`. . . . . .
`. . . . .
`11.2 Redirection 3xx . .
`. . . . .
`. . . . . .
`. . . . . .
`. . . . .
`11.3 Client Error 4xx . .
`. . . . .
`. . . . . .
`. . . . . .
`. . . . .
`11.3.1 405 Method Not Allowed . . .
`. . . . . .
`. . . . .
`11.3.2 451 Parameter Not Understood .
`. . . . . .
`. . . . .
`11.3.3 452 Conference Not Found . . .
`. . . . . .
`. . . . .
`11.3.4 453 Not Enough Bandwidth . .
`. . . . . .
`. . . . .
`11.3.5 454 Session Not Found . . . . .
`. . . . . .
`11.3.6 455 Method Not Valid in This State . . .
`11.3.7 456 Header Field Not Valid for Resource . . . . . .
`11.3.8 457 Invalid Range
`.
`. . . . . .
`. . . . .
`. . . . . .
`11.3.9 458 Parameter Is Read-Only . .
`. . . . .
`. . . . . .
`11.3.10 459 Aggregate Operation Not Allowed .
`. . . . . .
`11.3.11 460 Only Aggregate Operation Allowed .
`. . . . . .
`11.3.12 461 Unsupported Transport
`. .
`. . . . .
`. . . . . .
`11.3.13 462 Destination Unreachable . .
`. . . . .
`. . . . . .
`11.3.14 551 Option not supported
`. . .
`. . . . .
`. . . . . .
`
`12 Header Field Definitions
`12.1 Accept .
`. . . . . .
`12.2 Accept-Encoding .
`12.3 Accept-Language .
`12.4 Allow .
`. . . . . .
`12.5 Authorization . . .
`12.6 Bandwidth . . . . .
`12.7 Blocksize . . . . .
`12.8 Cache-Control . . .
`12.9 Conference . . . .
`12.10Connection . . . .
`12.11Content-Base . . .
`12.12Content-Encoding .
`12.13Content-Language .
`12.14Content-Length . .
`12.15Content-Location .
`12.16Content-Type . . .
`12.17CSeq . .
`. . . . . .
`12.18Date . .
`. . . . . .
`12.19Expires
`. . . . . .
`12.20From . .
`. . . . . .
`12.21Host
`. .
`. . . . . .
`12.22If-Match . . . . . .
`12.23If-Modified-Since .
`12.24Last-Modified . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`33
`. . . . . . 33
`. . . . . . 33
`. . . . . . 33
`. . . . . . 33
`. . . . . . 33
`. . . . . . 33
`. . . . . . 33
`. . . . . . 33
`. . . . . . 33
`. . . . . . 34
`. . . . . . 34
`. . . . . . 34
`. . . . . . 34
`. . . . . . 34
`. . . . . . 34
`. . . . . . 34
`. . . . . . 34
`. . . . . . 34
`
`34
`. . . . . . 35
`. . . . . . 35
`. . . . . . 35
`. . . . . . 35
`. . . . . . 35
`. . . . . . 37
`. . . . . . 37
`. . . . . . 37
`. . . . . . 39
`. . . . . . 39
`. . . . . . 39
`. . . . . . 39
`. . . . . . 39
`. . . . . . 39
`. . . . . . 40
`. . . . . . 40
`. . . . . . 40
`. . . . . . 40
`. . . . . . 40
`. . . . . . 41
`. . . . . . 41
`. . . . . . 41
`. . . . . . 41
`. . . . . . 41
`
`H. Schulzrinne, A. Rao, R. Lanphier
`
`Expires August 2, 1998
`
`[Page 3]
`
`Petitioners' Exhibit 1013
`Page 0003
`
`

`

`INTERNET-DRAFT
`
`draft-ietf-mmusic-rtsp-09.ps
`
`February 2, 1998
`
`. . . . .
`12.25Location . . . . . .
`12.26Proxy-Authenticate . . . . .
`12.27Proxy-Require . . .
`. . . . .
`12.28Public .
`. . . . . .
`. . . . .
`12.29Range .
`. . . . . .
`. . . . .
`12.30Referer
`. . . . . .
`. . . . .
`12.31Retry-After
`. . . .
`. . . . .
`12.32Require . . . . . .
`. . . . .
`12.33RTP-Info . . . . .
`. . . . .
`12.34Scale . .
`. . . . . .
`. . . . .
`12.35Speed .
`. . . . . .
`. . . . .
`12.36Server .
`. . . . . .
`. . . . .
`12.37Session . . . . . .
`. . . . .
`12.38Timestamp . . . .
`. . . . .
`12.39Transport
`. . . . .
`. . . . .
`12.40Unsupported . . . .
`. . . . .
`12.41User-Agent
`. . . .
`. . . . .
`12.42Vary . .
`. . . . . .
`. . . . .
`12.43Via . . .
`. . . . . .
`. . . . .
`12.44WWW-Authenticate
`. . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`13 Caching
`
`14 Examples
`. . . . . .
`14.1 Media on Demand (Unicast)
`14.2 Streaming of a Container file . . . . . .
`14.3 Single Stream Container Files
`. . . . .
`14.4 Live Media Presentation Using Multicast
`14.5 Playing media into an existing session .
`14.6 Recording . . . . .
`. . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`15 Syntax
`15.1 Base Syntax . . . .
`
`16 Security Considerations
`
`. . . . .
`
`. . . . . .
`
`. . . . .
`
`. . . . . .
`
`. . . . . .
`
`. . . . .
`
`A RTSP Protocol State Machines
`A.1 Client State Machine . . . .
`A.2 Server State Machine . . . .
`
`B Interaction with RTP
`
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`
`C Use of SDP for RTSP Session Descriptions
`C.1 Definitions . . . . .
`. . . . .
`. . . . . .
`C.1.1 Control URL . . . .
`. . . . . .
`C.1.2 Media streams
`. . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . . 41
`. . . . . . 42
`. . . . . . 42
`. . . . . . 42
`. . . . . . 42
`. . . . . . 42
`. . . . . . 43
`. . . . . . 43
`. . . . . . 43
`. . . . . . 44
`. . . . . . 45
`. . . . . . 45
`. . . . . . 45
`. . . . . . 46
`. . . . . . 46
`. . . . . . 48
`. . . . . . 48
`. . . . . . 49
`. . . . . . 49
`. . . . . . 49
`
`49
`
`49
`. . . . . . 50
`. . . . . . 51
`. . . . . . 54
`. . . . . . 55
`. . . . . . 56
`. . . . . . 57
`
`59
`. . . . . . 60
`
`61
`
`62
`. . . . . . 63
`. . . . . . 63
`
`64
`
`65
`. . . . . . 65
`. . . . . . 65
`. . . . . . 66
`
`H. Schulzrinne, A. Rao, R. Lanphier
`
`Expires August 2, 1998
`
`[Page 4]
`
`Petitioners' Exhibit 1013
`Page 0004
`
`

`

`INTERNET-DRAFT
`
`draft-ietf-mmusic-rtsp-09.ps
`
`February 2, 1998
`
`. . . . . .
`C.1.3 Payload type(s) . . .
`C.1.4 Format-specific parameters . . .
`C.1.5 Range of presentation
`. . . . .
`C.1.6 Time of availability .
`. . . . . .
`C.1.7 Connection Information . . . .
`C.1.8 Entity Tag .
`. . . . .
`. . . . . .
`C.2 Aggregate Control Not Available . . . .
`C.3 Aggregate Control Available . . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . . 66
`. . . . . . 66
`. . . . . . 66
`. . . . . . 67
`. . . . . . 67
`. . . . . . 67
`. . . . . . 67
`. . . . . . 68
`
`D Minimal RTSP implementation
`. . . . . .
`D.1 Client
`.
`. . . . . .
`. . . . .
`. . . . . .
`D.1.1 Basic Playback . . .
`D.1.2 Authentication-enabled . . . . .
`D.2 Server .
`. . . . . .
`. . . . .
`. . . . . .
`D.2.1 Basic Playback . . .
`. . . . . .
`D.2.2 Authentication-enabled . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`. . . . . .
`
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`. . . . .
`
`E Author Addresses
`
`F Acknowledgements
`
`1 Introduction
`
`1.1 Purpose
`
`68
`. . . . . . 68
`. . . . . . 69
`. . . . . . 70
`. . . . . . 70
`. . . . . . 70
`. . . . . . 71
`
`71
`
`72
`
`The Real-Time Streaming Protocol (RTSP) establishes and controls either a single or several time-synchronized
`streams of continuous media such as audio and video. It does not typically deliver the continuous streams
`itself, although interleaving of the continuous media stream with the control stream is possible (see Section
`10.12). In other words, RTSP acts as a “network remote control” for multimedia servers.
`The set of streams to be controlled is defined by a presentation description. This memorandum does not
`define a format for a presentation description.
`There is no notion of an RTSP connection; instead, a server maintains a session labeled by an identifier.
`An RTSP session is in no way tied to a transport-level connection such as a TCP connection. During an
`RTSP session, an RTSP client may open and close many reliable transport connections to the server to issue
`RTSP requests. Alternatively, it may use a connectionless transport protocol such as UDP.
`The streams controlled by RTSP may use RTP [1], but the operation of RTSP does not depend on the
`transport mechanism used to carry continuous media.
`The protocol is intentionally similar in syntax and operation to HTTP/1.1 [2] so that extension mecha-
`nisms to HTTP can in most cases also be added to RTSP. However, RTSP differs in a number of important
`aspects from HTTP:
`
` RTSP introduces a number of new methods and has a different protocol identifier.
`
` An RTSP server needs to maintain state by default in almost all cases, as opposed to the stateless
`nature of HTTP.
`
` Both an RTSP server and client can issue requests.
`
`H. Schulzrinne, A. Rao, R. Lanphier
`
`Expires August 2, 1998
`
`[Page 5]
`
`Petitioners' Exhibit 1013
`Page 0005
`
`

`

`INTERNET-DRAFT
`
`draft-ietf-mmusic-rtsp-09.ps
`
`February 2, 1998
`
` Data is carried out-of-band by a different protocol. (There is an exception to this.)
`
` RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, consistent with current HTML
`internationalization efforts [3].
`
` The Request-URI always contains the absolute URI. Because of backward compatibility with a his-
`torical blunder, HTTP/1.1 [2] carries only the absolute path in the request and puts the host name in a
`separate header field.
`
`This makes “virtual hosting” easier, where a single host with one IP address hosts several document trees.
`
`The protocol supports the following operations:
`
`Retrieval of media from media server: The client can request a presentation description via HTTP or
`some other method. If the presentation is being multicast, the presentation description contains the
`multicast addresses and ports to be used for the continuous media. If the presentation is to be sent
`only to the client via unicast, the client provides the destination for security reasons.
`
`Invitation of a media server to a conference: A media server can be “invited” to join an existing confer-
`ence, either to play back media into the presentation or to record all or a subset of the media in a
`presentation. This mode is useful for distributed teaching applications. Several parties in the confer-
`ence may take turns “pushing the remote control buttons”.
`
`Addition of media to an existing presentation: Particularly for live presentations, it is useful if the server
`can tell the client about additional media becoming available.
`
`RTSP requests may be handled by proxies, tunnels and caches as in HTTP/1.1 [2].
`
`1.2 Requirements
`
`The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD
`NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described
`in RFC 2119 [4].
`
`1.3 Terminology
`
`Some of the terminology has been adopted from HTTP/1.1 [2]. Terms not listed here are defined as in
`HTTP/1.1.
`
`Aggregate control: The control of the multiple streams using a single timeline by the server. For au-
`dio/video feeds, this means that the client may issue a single play or pause message to control both
`the audio and video feeds.
`
`Conference: a multiparty, multimedia presentation, where “multi” implies greater than or equal to one.
`
`Client: The client requests continuous media data from the media server.
`
`Connection: A transport layer virtual circuit established between two programs for the purpose of commu-
`nication.
`
`H. Schulzrinne, A. Rao, R. Lanphier
`
`Expires August 2, 1998
`
`[Page 6]
`
`Petitioners' Exhibit 1013
`Page 0006
`
`

`

`INTERNET-DRAFT
`
`draft-ietf-mmusic-rtsp-09.ps
`
`February 2, 1998
`
`Container file: A file which may contain multiple media streams which often comprise a presentation
`when played together. RTSP servers may offer aggregate control on these files, though the concept of
`a container file is not embedded in the protocol.
`
`Continuous media: Data where there is a timing relationship between source and sink; that is, the sink
`must reproduce the timing relationship that existed at the source. The most common examples of
`continuous media are audio and motion video. Continuous media can be real-time (interactive), where
`there is a “tight” timing relationship between source and sink, or streaming (playback), where the
`relationship is less strict.
`
`Entity: The information transferred as the payload of a request or response. An entity consists of metain-
`formation in the form of entity-header fields and content in the form of an entity-body, as described
`in Section 8.
`
`Media initialization: Datatype/codec specific initialization. This includes such things as clockrates, color
`tables, etc. Any transport-independent information which is required by a client for playback of a
`media stream occurs in the media initialization phase of stream setup.
`
`Media parameter: Parameter specific to a media type that may be changed before or during stream play-
`back.
`
`Media server: The server providing playback or recording services for one or more media streams. Differ-
`ent media streams within a presentation may originate from different media servers. A media server
`may reside on the same or a different host as the web server the presentation is invoked from.
`
`Media server indirection: Redirection of a media client to a different media server.
`
`(Media) stream: A single media instance, e.g., an audio stream or a video stream as well as a single white-
`board or shared application group. When using RTP, a stream consists of all RTP and RTCP pack-
`ets created by a source within an RTP session. This is equivalent to the definition of a DSM-CC
`stream([5]).
`
`Message: The basic unit of RTSP communication, consisting of a structured sequence of octets matching
`the syntax defined in Section 15 and transmitted via a connection or a connectionless protocol.
`
`Participant: Member of a conference. A participant may be a machine, e.g., a media record or playback
`server.
`
`Presentation: A set of one or more streams presented to the client as a complete media feed, using a
`presentation description as defined below. In most cases in the RTSP context, this implies aggregate
`control of those streams, but does not have to.
`
`Presentation description: A presentation description contains information about one or more media streams
`within a presentation, such as the set of encodings, network addresses and information about the con-
`tent. Other IETF protocols such as SDP (RFC XXXX [6]) use the term “session” for a live presenta-
`tion. The presentation description may take several different formats, including but not limited to the
`session description format SDP.
`
`Response: An RTSP response. If an HTTP response is meant, that is indicated explicitly.
`
`H. Schulzrinne, A. Rao, R. Lanphier
`
`Expires August 2, 1998
`
`[Page 7]
`
`Petitioners' Exhibit 1013
`Page 0007
`
`

`

`INTERNET-DRAFT
`
`draft-ietf-mmusic-rtsp-09.ps
`
`February 2, 1998
`
`Request: An RTSP request. If an HTTP request is meant, that is indicated explicitly.
`
`RTSP session: A complete RTSP “transaction”, e.g., the viewing of a movie. A session typically consists
`of a client setting up a transport mechanism for the continuous media stream (SETUP), starting the
`stream with PLAY or RECORD, and closing the stream with TEARDOWN.
`
`Transport initialization: The negotiation of transport information (e.g., port numbers, transport protocols)
`between the client and the server.
`
`1.4 Protocol Properties
`
`RTSP has the following properties:
`
`Extendable: New methods and parameters can be easily added to RTSP.
`
`Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers.
`
`Secure: RTSP re-uses web security mechanisms, either at the transport level (TLS, RFC XXXX [7]) or
`within the protocol itself. All HTTP authentication mechanisms such as basic (RFC 2068 [2, Sec-
`tion 11.1]) and digest authentication (RFC 2069 [8]) are directly applicable.
`
`Transport-independent: RTSP may use either an unreliable datagram protocol (UDP) (RFC 768 [9]), a
`reliable datagram protocol (RDP, RFC 1151, not widely used [10]) or a reliable stream protocol such
`as TCP (RFC 793 [11]) as it implements application-level reliability.
`
`Multi-server capable: Each media stream within a presentation can reside on a different server. The client
`automatically establishes several concurrent control sessions with the different media servers. Media
`synchronization is performed at the transport level.
`
`Control of recording devices: The protocol can control both recording and playback devices, as well as
`devices that can alternate between the two modes (“VCR”).
`
`Separation of stream control and conference initiation: Stream control is divorced from inviting a me-
`dia server to a conference. The only requirement is that the conference initiation protocol either
`provides or can be used to create a unique conference identifier. In particular, SIP [12] or H.323 [13]
`may be used to invite a server to a conference.
`
`Suitable for professional applications: RTSP supports frame-level accuracy through SMPTE time stamps
`to allow remote digital editing.
`
`Presentation description neutral: The protocol does not impose a particular presentation description or
`metafile format and can convey the type of format to be used. However, the presentation description
`must contain at least one RTSP URI.
`
`Proxy and firewall friendly: The protocol should be readily handled by both application and transport-
`layer (SOCKS [14]) firewalls. A firewall may need to understand the SETUP method to open a
`“hole” for the UDP media stream.
`
`H. Schulzrinne, A. Rao, R. Lanphier
`
`Expires August 2, 1998
`
`[Page 8]
`
`Petitioners' Exhibit 1013
`Page 0008
`
`

`

`INTERNET-DRAFT
`
`draft-ietf-mmusic-rtsp-09.ps
`
`February 2, 1998
`
`HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so that the existing infrastructure can be
`reused. This infrastructure includes PICS (Platform for Internet Content Selection [15, 16]) for asso-
`ciating labels with content. However, RTSP does not just add methods to HTTP since the controlling
`continuous media requires server state in most cases.
`
`Appropriate server control: If a client can start a stream, it must be able to stop a stream. Servers should
`not start streaming to clients in such a way that clients cannot stop the stream.
`
`Transport negotiation: The client can negotiate the transport method prior to actually needing to process
`a continuous media stream.
`
`Capability negotiation: If basic features are disabled, there must be some clean mechanism for the client
`to determine which methods are not going to be implemented. This allows clients to present the
`appropriate user interface. For example, if seeking is not allowed, the user interface must be able to
`disallow moving a sliding position indicator.
`
`An earlier requirement in RTSP was multi-client capability. However, it was determined that a better approach
`was to make sure that the protocol is easily extensible to the multi-client scenario. Stream identifiers can be used
`by several control streams, so that “passing the remote” would be possible. The protocol would not address how
`several clients negotiate access; this is left to either a “social protocol” or some other floor control mechanism.
`
`1.5 Extending RTSP
`
`Since not all media servers have the same functionality, media servers by necessity will support different
`sets of requests. For example:
`
` A server may only be capable of playback thus has no need to support the RECORD request.
`
` A server may not be capable of seeking (absolute positioning) if it is to support live events only.
`
` Some servers may not support setting stream parameters and thus not support GET PARAMETER
`and SET PARAMETER.
`
`A server SHOULD implement all header fields described in Section 12.
`It is up to the creators of presentation descriptions not to ask the impossible of a server. This situation
`is similar in HTTP/1.1 [2], where the methods described in [H19.6] are not likely to be supported across all
`servers.
`RTSP can be extended in three ways, listed here in order of the magnitude of changes supported:
`
` Existing methods can be extended with new parameters, as long as these parameters can be safely
`ignored by the recipient. (This is equivalent to adding new parameters to an HTML tag.) If the client
`needs negative acknowledgement when a method extension is not supported, a tag corresponding to
`the extension may be added in the Require: field (see Section 12.32).
`
` New methods can be added. If the recipient of the message does not understand the request, it responds
`with error code 501 (Not implemented) and the sender should not attempt to use this method again.
`A client may also use the OPTIONS method to inquire about methods supported by the server. The
`server SHOULD list the methods it supports using the Public response header.
`
` A new version of the protocol can be defined, allowing almost all aspects (except the position of the
`protocol version number) to change.
`
`H. Schulzrinne, A. Rao, R. Lanphier
`
`Expires August 2, 1998
`
`[Page 9]
`
`Petitioners' Exhibit 1013
`Page 0009
`
`

`

`INTERNET-DRAFT
`
`draft-ietf-mmusic-rtsp-09.ps
`
`February 2, 1998
`
`1.6 Overall Operation
`
`Each presentation and media stream may be identified by an RTSP URL. The overall presentation and the
`properties of the media the presentation is made up of are defined by a presentation description file, the
`format of which is outside the scope of this specification. The presentation description file may be obtained
`by the client using HTTP or other means such as email and may not necessarily be stored on the media
`server.
`For the purposes of this specification, a presentation description is assumed to describe one or more
`presentations, each of which maintains a common time axis. For simplicity of exposition and without loss
`of generality, it is assumed that the presentation description contains exactly one such presentation. A
`presentation may contain several media streams.
`The presentation description file contains a description of the media streams making up the presenta-
`tion, including their encodings, language, and other parameters that enable the client to choose the most
`appropriate combination of media. In this presentation description, each media stream that is individually
`controllable by RTSP is identified by an RTSP URL, which points to the media server handling that par-
`ticular media stream and names the stream stored on that server. Several media streams can be located on
`different servers; for example, audio and video streams can be split across servers for load sharing. The
`description also enumerates which transport methods the server is capable of.
`Besides the media parameters, the network destination address and port need to be determined. Several
`modes of operation can be distinguished:
`
`Unicast: The media is transmitted to the source of the RTSP request, with the port number chosen by the
`client. Alternatively, the media is transmitted on the same reliable stream as RTSP.
`
`Multicast, server chooses address: The media server picks the multicast address and port. This is the
`typical case for a live or near-media-on-demand transmission.
`
`Multicast, client chooses address: If the server is to participate in an existing multicast conference, the
`multicast address, port and encryption key are given by the conference description, established by
`means outside the scope of this specification.
`
`1.7 RTSP States
`
`RTSP controls a stream which may be sent via a separate protocol, independent of the control channel. For
`example, RTSP control may occur on a TCP connectio