9/14/2020
`
`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`Network Working Group
`Request for Comments: 2326
`Category: Standards Track
`
`H. Schulzrinne
`Columbia U.
`A. Rao
`Netscape
`R. Lanphier
`RealNetworks
`April 1998
`
`Real Time Streaming Protocol (RTSP)
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo 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).
`
`Table of Contents
`
`* 1 Introduction ................................................. 5
`+ 1.1 Purpose ............................................... 5
`+ 1.2 Requirements .......................................... 6
`+ 1.3 Terminology ........................................... 6
`+ 1.4 Protocol Properties ................................... 9
`+ 1.5 Extending RTSP ........................................ 11
`+ 1.6 Overall Operation ..................................... 11
`+ 1.7 RTSP States ........................................... 12
`+ 1.8 Relationship with Other Protocols ..................... 13
`* 2 Notational Conventions ....................................... 14
`* 3 Protocol Parameters .......................................... 14
`+ 3.1 RTSP Version .......................................... 14
`
`Schulzrinne, et. al.
`
`Standards Track
`
`[Page 1]
`
`https://tools.ietf.org/html/rfc2326
`
`1/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 1 of 93
`
`

`

`9/14/2020
`
`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`RFC 2326
`
`Real Time Streaming Protocol
`
`April 1998
`
`+ 3.2 RTSP URL .............................................. 14
`+ 3.3 Conference Identifiers ................................ 16
`+ 3.4 Session Identifiers ................................... 16
`+ 3.5 SMPTE Relative Timestamps ............................. 16
`+ 3.6 Normal Play Time ...................................... 17
`+ 3.7 Absolute Time ......................................... 18
`+ 3.8 Option Tags ........................................... 18
`o 3.8.1 Registering New Option Tags with IANA .......... 18
`* 4 RTSP Message ................................................. 19
`+ 4.1 Message Types ......................................... 19
`+ 4.2 Message Headers ....................................... 19
`+ 4.3 Message Body .......................................... 19
`+ 4.4 Message Length ........................................ 20
`* 5 General Header Fields ........................................ 20
`* 6 Request ...................................................... 20
`+ 6.1 Request Line .......................................... 21
`+ 6.2 Request Header Fields ................................. 21
`* 7 Response ..................................................... 22
`+ 7.1 Status-Line ........................................... 22
`o 7.1.1 Status Code and Reason Phrase .................. 22
`o 7.1.2 Response Header Fields ......................... 26
`* 8 Entity ....................................................... 27
`+ 8.1 Entity Header Fields .................................. 27
`+ 8.2 Entity Body ........................................... 28
`* 9 Connections .................................................. 28
`+ 9.1 Pipelining ............................................ 28
`+ 9.2 Reliability and Acknowledgements ...................... 28
`* 10 Method Definitions .......................................... 29
`+ 10.1 OPTIONS .............................................. 30
`+ 10.2 DESCRIBE ............................................. 31
`+ 10.3 ANNOUNCE ............................................. 32
`+ 10.4 SETUP ................................................ 33
`+ 10.5 PLAY ................................................. 34
`+ 10.6 PAUSE ................................................ 36
`+ 10.7 TEARDOWN ............................................. 37
`+ 10.8 GET_PARAMETER ........................................ 37
`+ 10.9 SET_PARAMETER ........................................ 38
`+ 10.10 REDIRECT ............................................ 39
`+ 10.11 RECORD .............................................. 39
`+ 10.12 Embedded (Interleaved) Binary Data .................. 40
`* 11 Status Code Definitions ..................................... 41
`+ 11.1 Success 2xx .......................................... 41
`o 11.1.1 250 Low on Storage Space ...................... 41
`+ 11.2 Redirection 3xx ...................................... 41
`+ 11.3 Client Error 4xx ..................................... 42
`o 11.3.1 405 Method Not Allowed ........................ 42
`o 11.3.2 451 Parameter Not Understood .................. 42
`o 11.3.3 452 Conference Not Found ...................... 42
`
`Schulzrinne, et. al.
`
`Standards Track
`
`[Page 2]
`
`https://tools.ietf.org/html/rfc2326
`
`2/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 2 of 93
`
`

`

`9/14/2020
`
`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`RFC 2326
`
`Real Time Streaming Protocol
`
`April 1998
`
`o 11.3.4 453 Not Enough Bandwidth ...................... 42
`o 11.3.5 454 Session Not Found ......................... 42
`o 11.3.6 455 Method Not Valid in This State ............ 42
`o 11.3.7 456 Header Field Not Valid for Resource ....... 42
`o 11.3.8 457 Invalid Range ............................. 43
`o 11.3.9 458 Parameter Is Read-Only .................... 43
`o 11.3.10 459 Aggregate Operation Not Allowed .......... 43
`o 11.3.11 460 Only Aggregate Operation Allowed ......... 43
`o 11.3.12 461 Unsupported Transport .................... 43
`o 11.3.13 462 Destination Unreachable .................. 43
`o 11.3.14 551 Option not supported ..................... 43
`* 12 Header Field Definitions .................................... 44
`+ 12.1 Accept ............................................... 46
`+ 12.2 Accept-Encoding ...................................... 46
`+ 12.3 Accept-Language ...................................... 46
`+ 12.4 Allow ................................................ 46
`+ 12.5 Authorization ........................................ 46
`+ 12.6 Bandwidth ............................................ 46
`+ 12.7 Blocksize ............................................ 47
`+ 12.8 Cache-Control ........................................ 47
`+ 12.9 Conference ........................................... 49
`+ 12.10 Connection .......................................... 49
`+ 12.11 Content-Base ........................................ 49
`+ 12.12 Content-Encoding .................................... 49
`+ 12.13 Content-Language .................................... 50
`+ 12.14 Content-Length ...................................... 50
`+ 12.15 Content-Location .................................... 50
`+ 12.16 Content-Type ........................................ 50
`+ 12.17 CSeq ................................................ 50
`+ 12.18 Date ................................................ 50
`+ 12.19 Expires ............................................. 50
`+ 12.20 From ................................................ 51
`+ 12.21 Host ................................................ 51
`+ 12.22 If-Match ............................................ 51
`+ 12.23 If-Modified-Since ................................... 52
`+ 12.24 Last-Modified........................................ 52
`+ 12.25 Location ............................................ 52
`+ 12.26 Proxy-Authenticate .................................. 52
`+ 12.27 Proxy-Require ....................................... 52
`+ 12.28 Public .............................................. 53
`+ 12.29 Range ............................................... 53
`+ 12.30 Referer ............................................. 54
`+ 12.31 Retry-After ......................................... 54
`+ 12.32 Require ............................................. 54
`+ 12.33 RTP-Info ............................................ 55
`+ 12.34 Scale ............................................... 56
`+ 12.35 Speed ............................................... 57
`+ 12.36 Server .............................................. 57
`
`Schulzrinne, et. al.
`
`Standards Track
`
`[Page 3]
`
`https://tools.ietf.org/html/rfc2326
`
`3/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 3 of 93
`
`

`

`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`9/14/2020
`
`RFC 2326 Real Time Streaming Protocol April 1998
`
`
` + 12.37 Session ............................................. 57
` + 12.38 Timestamp ........................................... 58
` + 12.39 Transport ........................................... 58
` + 12.40 Unsupported ......................................... 62
` + 12.41 User-Agent .......................................... 62
` + 12.42 Vary ................................................ 62
` + 12.43 Via ................................................. 62
` + 12.44 WWW-Authenticate .................................... 62
` * 13 Caching ..................................................... 62
` * 14 Examples .................................................... 63
` + 14.1 Media on Demand (Unicast) ............................ 63
` + 14.2 Streaming of a Container file ........................ 65
` + 14.3 Single Stream Container Files ........................ 67
` + 14.4 Live Media Presentation Using Multicast .............. 69
` + 14.5 Playing media into an existing session ............... 70
` + 14.6 Recording ............................................ 71
` * 15 Syntax ...................................................... 72
` + 15.1 Base Syntax .......................................... 72
` * 16 Security Considerations ..................................... 73
` * A RTSP Protocol State Machines ................................. 76
` + A.1 Client State Machine .................................. 76
` + A.2 Server State Machine .................................. 77
` * B Interaction with RTP ......................................... 79
` * C Use of SDP for RTSP Session Descriptions ..................... 80
` + C.1 Definitions ........................................... 80
` o C.1.1 Control URL .................................... 80
` o C.1.2 Media streams .................................. 81
` o C.1.3 Payload type(s) ................................ 81
` o C.1.4 Format-specific parameters ..................... 81
` o C.1.5 Range of presentation .......................... 82
` o C.1.6 Time of availability ........................... 82
` o C.1.7 Connection Information ......................... 82
` o C.1.8 Entity Tag ..................................... 82
` + C.2 Aggregate Control Not Available ....................... 83
` + C.3 Aggregate Control Available ........................... 83
` * D Minimal RTSP implementation .................................. 85
` + D.1 Client ................................................ 85
` o D.1.1 Basic Playback ................................. 86
` o D.1.2 Authentication-enabled ......................... 86
` + D.2 Server ................................................ 86
` o D.2.1 Basic Playback ................................. 87
` o D.2.2 Authentication-enabled ......................... 87
` * E Authors' Addresses ........................................... 88
` * F Acknowledgements ............................................. 89
` * References ..................................................... 90
` * Full Copyright Statement ....................................... 92
`
`
`
`
`
`Schulzrinne, et. al. Standards Track [Page 4]
`
`https://tools.ietf.org/html/rfc2326
`
`4/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 4 of 93
`
`

`

`9/14/2020
`
`RFC 2326 Real Time Streaming Protocol April 1998
`
`
`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
` 1
`
` Introduction
`
`1.1 Purpose
`
` 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 mechanisms 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.
` * 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 historical 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.
`
`
`
`
`Schulzrinne, et. al. Standards Track [Page 5]
`
`https://tools.ietf.org/html/rfc2326
`
`5/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 5 of 93
`
`

`

`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`9/14/2020
`
`RFC 2326 Real Time Streaming Protocol April 1998
`
`
` 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
` conference, 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 conference 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 audio/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.
`
`
`
`
`
`Schulzrinne, et. al. Standards Track [Page 6]
`
`https://tools.ietf.org/html/rfc2326
`
`6/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 6 of 93
`
`

`

`9/14/2020
`
`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`RFC 2326
`
`Real Time Streaming Protocol
`
`April 1998
`
` 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 communication.
`
` 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 metainformation 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 playback.
`
` Media server:
`The server providing playback or recording services for one or
`more media streams. Different 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.
`
`Schulzrinne, et. al.
`
`Standards Track
`
`[Page 7]
`
`https://tools.ietf.org/html/rfc2326
`
`7/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 7 of 93
`
`

`

`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`9/14/2020
`
`RFC 2326 Real Time Streaming Protocol April 1998
`
`
` 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 whiteboard or shared application
` group. When using RTP, a stream consists of all RTP and RTCP
` packets 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
` content. Other IETF protocols such as SDP (RFC 2327 [6]) use
` the term "session" for a live presentation. 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.
`
` 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
`
`
`
`Schulzrinne, et. al. Standards Track [Page 8]
`
`https://tools.ietf.org/html/rfc2326
`
`8/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 8 of 93
`
`

`

`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`9/14/2020
`
`RFC 2326 Real Time Streaming Protocol April 1998
`
`
` 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. All HTTP authentication
` mechanisms such as basic (RFC 2068 [2, Section 11.1]) and
` digest authentication (RFC 2069 [8]) are directly applicable.
` One may also reuse transport or network layer security
` mechanisms.
`
` 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 media 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.
`
`
`
`
`
`Schulzrinne, et. al. Standards Track [Page 9]
`
`https://tools.ietf.org/html/rfc2326
`
`9/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 9 of 93
`
`

`

`9/14/2020
`
`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`RFC 2326
`
`Real Time Streaming Protocol
`
`April 1998
`
` 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.
`
` 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 associating 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
`
`Schulzrinne, et. al.
`
`Standards Track
`
`[Page 10]
`
`https://tools.ietf.org/html/rfc2326
`
`10/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 10 of 93
`
`

`

`9/14/2020
`
`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`RFC 2326
`
`Real Time Streaming Protocol
`
`April 1998
`
` 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.
`
`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
`
`Schulzrinne, et. al.
`
`Standards Track
`
`[Page 11]
`
`https://tools.ietf.org/html/rfc2326
`
`11/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 11 of 93
`
`

`

`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`9/14/2020
`
`RFC 2326 Real Time Streaming Protocol April 1998
`
`
` 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 presentation, 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 particular 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 connection while the data flows via UDP. Thus, data
` delivery continues even if no RTSP requests are received by the media
`
`
`
`Schulzrinne, et. al. Standards Track [Page 12]
`
`https://tools.ietf.org/html/rfc2326
`
`12/93
`
`FUBOTV AND WWE EXHIBIT 1031
`Page 12 of 93
`
`

`

`RFC 2326 - Real Time Streaming Protocol (RTSP)
`
`9/14/2020
`
`RFC 2326 Real Time Streaming Protocol April 1998
`
`
` server. Also, during its lifetime, a single media stream may be
` controlled by RTSP requests issued sequentially on different TCP
` connections. Therefore, the server needs to maintain "session state"
` to be able to c