www.archive.org
`415.561.6767
`415.840-0391 e-fax
`
`Internet Archive
`300 Funston Avenue
`San Francisco, CA 94118
`
`AFFIDAVIT OF CHRISTOPHER BUTLER
`
`1. I am the Office Manager at the Internet Archive, located in San Francisco,
`California. I make this declaration of my own personal knowledge.
`2. The Internet Archive is a website that provides access to a digital library of
`Internet sites and other cultural artifacts in digital form. Like a paper library, we provide
`free access to researchers, historians, scholars, and the general public. The Internet
`Archive has partnered with and receives support from various institutions, including the
`Library of Congress.
`3. The Internet Archive has created a service known as the Wayback Machine. The
`Wayback Machine makes it possible to surf more than 450 billion pages stored in the
`Internet Archive's web archive. Visitors to the Wayback Machine can search archives
`by URL (i.e., a website address). If archived records for a URL are available, the visitor
`will be presented with a list of available dates. The visitor may select one of those
`dates, and then begin surfing on an archived version of the Web. The links on the
`archived files, when served by the Wayback Machine, point to other archived files
`(whether HTML pages or images). If a visitor clicks on a link on an archived page, the
`Wayback Machine will serve the archived file with the closest available date to the page
`upon which the link appeared and was clicked.
`4. The archived data made viewable and browseable by the Wayback Machine is
`compiled using software programs known as crawlers, which surf the Web and
`automatically store copies of web files, preserving these files as they exist at the point of
`time of capture.
`5. The Internet Archive assigns a URL on its site to the archived files in the format
`http://web.archive.org/web/[Year
`in yyyy][Month in mm][Day in dd][Time code in
`hh:mm:ss]/[Archived URL]. Thus, the Internet Archive URL
`http://web.archive.org/web/19970126045828/http://www.archive.org/ would be the
`URL for the record of the Internet Archive home page HTML file
`(http://www.archive.org/) archived on January 26, 1997 at 4:58 a.m. and 28 seconds
`(1997/01/26 at 04:58:28). A web browser may be set such that a printout from it will
`display the URL of a web page in the printout's footer. The date assigned by the Internet
`Archive applies to the HTML file but not to image files linked therein. Thus images that
`appear on a page may not have been archived on the same date as the HTML file.
`Likewise, if a website is designed with "frames," the date assigned by the Internet
`Archive applies to the frameset as a whole, and not the individual pages within each
`frame.
`6. Attached hereto as Exhibit A are true and accurate copies of printouts of the
`Internet Archive's records of the HTML files or txt files for the URLs and the dates
`specified in the footer of the printout.
`7. I declare under penalty of perjury that the foregoing is true and correct.
`
`DATE: 11 /1 /19.
`
`Christophe r Butler
`
`EX 1046 Page 1
`
`

`

`CALIFORNIA JURA T
`
`See Attached Document.
`
`State of California
`County of San Francisco
`
`A notary public or other officer completing this
`certificate verifies only the identity of the
`individual who signed the document to which this
`certificate is attached, and not the truthfulness,
`accuracy, or validity of that document.
`
`Subscribed and sworn to ( or affirmed) before me on
`this
`
`5-tv' day of f'J 0~
`
`Christopher Butler,
`
`JtJ (4 'by
`
`proved to me on the basis of satisfactory evidence to be
`the person who appeared be re me.
`
`,· ~ ·
`' AL/SOIi FlAHIIERY
`,
`J« "~
`. f
`N ta
`""""E O CC!ltM~·KCR5
`J' ,·
`. ~
`o ry Public • C11Utornla
`J .,,.-0,•''
`,,
`San Fr11ncrsco Coun
`.,
`!
`My Comm. Expires Feb 2, 20!31
`Commfssfon # 2276Ji1
`
`.Ii,, •
`
`EX 1046 Page 2
`
`

`

`
`Exhibit A
`
`Exhibit A
`
`EX 1046 Page 3
`
`EX 1046 Page 3
`
`

`

`https://web.archive.org/web/19980530070451if_/http://www.nic.it:80/mirrors/rfc/rfc2326.txt
`
`11/5/2019
`
`
`
`
`
`
`Network Working Group H. Schulzrinne
`Request for Comments: 2326 Columbia U.
`Category: Standards Track 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]
`
`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]
`
`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
`https://web.archive.org/web/19980530070451if_/http://www.nic.it:80/mirrors/rfc/rfc2326.txt
`
`1/40
`
`EX 1046 Page 4
`
`

`

`2/40
`
`https://web.archive.org/web/19980530070451if_/http://www.nic.it:80/mirrors/rfc/rfc2326.txt
`11/5/2019
` + 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]
`
`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]
`
`RFC 2326 Real Time Streaming Protocol April 1998
`
`
`
`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:
`https://web.archive.org/web/19980530070451if_/http://www.nic.it:80/mirrors/rfc/rfc2326.txt
`
` Introduction
`
` 1
`
`EX 1046 Page 5
`
`

`

`https://web.archive.org/web/19980530070451if_/http://www.nic.it:80/mirrors/rfc/rfc2326.txt
`
`11/5/2019
`
` * 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]
`
`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]
`
`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.
`
`
`https://web.archive.org/web/19980530070451if_/http://www.nic.it:80/mirrors/rfc/rfc2326.txt
`
`3/40
`
`EX 1046 Page 6
`
`

`

`https://web.archive.org/web/19980530070451if_/http://www.nic.it:80/mirrors/rfc/rfc2326.txt
`
`11/5/2019
`
`
`
`Schulzrinne, et. al. Standards Track [Page 7]
`
`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]
`
`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]
`
`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.
`
`https://web.archive.org/web/19980530070451if_/http://www.nic.it:80/mirrors/rfc/rfc2326.txt
`
`4/40
`
`EX 1046 Page 7
`
`

`

`https://web.archive.org/web/19980530070451if_/http://www.nic.it:80/mirrors/rfc/rfc2326.txt
`
`11/5/2019
` 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